/ forcefsck 이후 부팅시 fsck 결과는 어디에 기록됩니까?

37

원격으로 작업 할 때 sudo touch /forcefsck명령을 사용하여 부팅시 fsck를 강제 실행하고 재부팅 하도록 서버를 설정했습니다 .

다시 시작한 후 /var/log/fsck디스크 검사 결과를 체크인했습니다.
두 checkfs 및 checkroot는 말했다 : 아무것도 아직 기록되지 않은

결과를 어디에 저장합니까?

boot logging fsck

— 바트 실버 스트림
소스

Ubuntu 12.04 LTS에서 동일한 문제가 있습니다. /var/log/boot.log에서 fsck 로그를 찾았습니다.

15

아마도이 버그의 영향을받습니다. "/ var / log / fsck /에 fsck 호출을 기록하지 않습니다"

— 튀김
소스

가능성이 높습니다. 아마 해결되지 않을 것이라는 사실에 더 이상 놀라지 말아야합니다 ...

— Bart Silverstrim

이것은 매우 부정적인 방식으로 우리에게도 영향을 미칩니다. 우리는 EC2를 사용하고 있으며 서버를 재부팅 할 때 이와 같은 세부 정보가 필요합니다. 이것이 어떻게 '위시리스트'항목으로 간주 될 수 있습니까? 이것은 핵심 기능이며 깨졌습니다.

— tamale

@tamale 당신은 완전히 옳습니다. 나도 이것에 맞았다. 내 /파티션에 불쾌한 단점이 있었으며 복구 모드로 들어갈 때 강제로 e2fsck설정했습니다. 이것은 완벽하지만 백업에서 대체 할 파일을 기억하기가 어렵 기 때문에 손상된 파일 이름을 추적 할 수 있어야합니다.

— syntaxerror

13

우분투 14.xx의 경우 :

에서 일부 fsck 로그를 찾았습니다 /var/log/upstart/mountall.log.

— 역마차
소스

1

Ask Ubuntu에 오신 것을 환영합니다. ;-) 당시에는 11.10에 버그가 있었기 때문에 지금 새로운 시스템에 대한 답변은이 3 년 된 질문에 아무런 가치도 부여하지 않습니다. 앞으로 : 질문 날짜와 답이 있는지 확인하십시오. ;-)

— Fabby

4

@Fabby 그러나 향후 방문자에게는 여전히 유용 할 것입니다. 버전이 제공되며 (@Shay는 14.04 또는 14.10을 의미합니까?) OP (3 년 전 해결책을 찾은 사람 ...)에게 도움이되지 않더라도 올바른 답변이라고 말할 수 있습니다.

— Byte Commander

검색 엔진이이를 오래된 질문으로 표시하는 데 도움이되는 태그를 추가했습니다.

— NGRhodes

확실히 맞아! :-) 그래서 방금 코멘트를 남겼습니다. 기록을 위해 : 나는 투표하지 않았다! ;-)

— Fabby

1

@Byte Commander이 "오래된"질문은 많은 도움이되었습니다. 나는 fsck로그가 /var/log/upstart/mountall.logresp에 숨겨져 있다고 추측하지 않았을 것 입니다. /var/log/upstart/mountall.*.log.gz. 상당히 비논리적입니다. 그러나 손상되었다고보고 된 파일 이름 은 기록 된 것이 아니라 단지 inode로 기록 된 것 같습니다 .

— syntaxerror

6

우분투 16.04 및 18.04 루트 파티션

찾고있을 것입니다 /run/initramfs/fsck.log.

루트 파일 시스템의 쓰기 권한은 루트 파일 시스템이 쓰기 가능한 것으로 마운트되기 전에 반드시 발생하므로 시스템이 여전히 initramfs에서 실행되는 동안 부트 프로세스 초기에 파일 시스템 검사가 수행됩니다. fsck 로그는 현재 쓸 수있는 RAM 지원 파일 시스템 (tmpfs)에 기록되며 부팅 후에도 계속 사용할 수 있습니다 /run/initramfs/fsck.log. 이것은 휘발성 저장소이므로 시스템이 재부팅되면 fsck 로그가 손실됩니다. 루트 파일 시스템을 쓰기 가능으로 마운트 한 후 이러한 로그를 비 휘발성 저장소에 복사하면 좋을 것입니다.

예를 들면 다음과 같습니다.

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 238.5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0   238G  0 part /

$ cat /run/initramfs/fsck.log 
Log of fsck -C -a -V -t ext4 /dev/sda2 
Fri Nov 30 22:35:21 2018

fsck from util-linux 2.31.1
[/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2 
/dev/sda2: clean, 653295/15597568 files, 6658147/62383360 blocks

Fri Nov 30 22:35:21 2018
----------------

— ven42
소스

1

루트 파티션의 경우 이것은 16.04 + systemd에 대한 유일한 정답입니다.

— 요나 브라운

5

우분투 16.04

명령 journalctl -b --no-pager | grep systemd-fsck

루트 파티션이 아닌 파일 시스템 검사를보고합니다.

Mar 22 15:06:26 64bitUbuntu systemd-fsck[750]: /dev/sdb1: clean, 146223/121454592 files, 356711795/485818368 blocks

부팅시 루트 파티션을 확인하려면 다음 명령을 실행하십시오 more /var/log/boot.log

다음과 유사한 결과를 제공합니다.

/dev/sda2: clean, 349091/1954064 files, 2379983/7814912 blocks

— eek 장로
소스

2

우분투 12.04.5 LTS로 이것을 테스트하고 /var/log/boot.log에서 로그를 찾았습니다.

└❯ grep -A 1 fsck /var/log/*
/var/log/boot.log:fsck from util-linux 2.20.1
/var/log/boot.log-/dev/vda1: 209262/2621440 files (0.1% non-contiguous), 3239494/10485504 blocks

— 바북
소스

0

우분투 18.04

명령 journalctl -b --no-pager | grep systemd-fsck과grep systemd-fsck /var/log/syslog

둘 다 루트가 아닌 파티션 파일 시스템 검사를보고합니다.

Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[615]: Scratch: clean, 19/6520832 files, 555602/26081280 blocks
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[609]: /dev/sda1: clean, 47014/89374720 files, 294970235/357492992 blocks
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[613]: /dev/sda5: clean, 6707/32727040 files, 7464312/130885120 blocks

UUID 결과로 마운트 된 루트 파티션 검사는 강제 실행 되더라도 기록되지 않는 것으로 보입니다.

— eek 장로
소스