Gdzie wyniki fsck są rejestrowane w czasie uruchamiania, po / forcefsck?

37

Podczas pracy zdalnej ustawiłem serwer tak, aby wymuszał fsck podczas uruchamiania za pomocą sudo touch /forcefsckpolecenia i zrestartował się.

Po ponownym uruchomieniu sprawdziłem /var/log/fsckwyniki sprawdzania dysku.
Zarówno checkfs, jak i checkroot powiedział: Nic jeszcze nie zostało zarejestrowane

Gdzie więc zapisuje wyniki?

boot logging fsck

— Bart Silverstrim
źródło

Mając ten sam problem na Ubuntu 12.04 LTS. Znalazłem dziennik fsck w /var/log/boot.log.

15

Być może ten błąd dotyczy: „Nie rejestruje wywołań fsck w / var / log / fsck /”

— pluśnięcie
źródło

Najprawdopodobniej. Nie powinienem się już dziwić, że prawdopodobnie nie zostanie rozwiązany ...

— Bart Silverstrim

Wpływa to również na nas bardzo negatywnie - jesteśmy na EC2, a kiedy serwery się restartują, potrzebujemy szczegółów takich rzeczy. Jak można to uznać za „listę życzeń”? Jest to podstawowa funkcjonalność i jest zepsuta.

— tamale

@tamale Masz całkowitą rację. Uderzyło mnie to również. Moja /partycja miała nieprzyjemne dziwactwo, a kiedy wchodził w tryb odzyskiwania, wymusił e2fsckna niej. Jest to idealne, ale ponieważ naprawdę trudno jest zapamiętać, które pliki zastąpić z kopii zapasowej, trzeba być w stanie wyśledzić nazwy plików, które podobno są uszkodzone.

— syntaxerror

13

W przypadku Ubuntu 14.xx:

Znalazłem kilka logów fsck /var/log/upstart/mountall.log.

— Shay
źródło

1

Witamy w Ask Ubuntu. ;-) W tym czasie w 11.10 pojawiał się błąd, więc twoja odpowiedź na nowy system nie dodaje żadnej wartości temu 3-letniemu pytaniu. Na przyszłość: spójrz na datę pytania i czy jest już odpowiedź. ;-)

— Fabby

4

@Fabby, ale myślę, że dla przyszłych gości nadal może być przydatny, tak myślę? Wersja jest podana (@Shay, masz na myśli 14.04 lub 14.10?) I dlatego powiedziałbym, że jest to poprawna odpowiedź, chociaż może nie pomóc OP (który znalazł rozwiązanie 3 lata temu ...)

— Byte Commander

Dodałem tag, aby pomóc wyszukiwarkom pokazać to jako stare pytanie.

— NGRhodes

Całkowita racja! :-) Właśnie dlatego zostawiłem komentarz. Dla przypomnienia: nie oddałem głosu! ;-)

— Fabby

1

@Byte Commander To rzekomo „stare” pytanie pomogło mi naprawdę DUŻO! Nigdy bym nie przypuszczał, że fsckdzienniki będą odpowiednio ukryte /var/log/upstart/mountall.log. /var/log/upstart/mountall.*.log.gz. Dość nielogiczne. JEDNAK wydaje się, że nazwy plików zgłoszone jako uszkodzone nie zostały zarejestrowane, tylko ich i-węzły.

— syntaxerror

6

Dla partycji głównych Ubuntu 16.04 i 18.04

Prawdopodobnie szukasz /run/initramfs/fsck.log.

Fsck głównego systemu plików musi się zdarzyć, zanim główny system plików zostanie zamontowany jako zapisywalny, więc sprawdzenie systemu plików następuje na wczesnym etapie procesu rozruchu, gdy system nadal działa z poziomu initramfs. Dziennik fsck jest zapisywany w systemie plików z pamięcią RAM (tmpfs), który jest obecnie dostępny do zapisu, i jest nadal dostępny po uruchomieniu w /run/initramfs/fsck.log. Jest to pamięć niestabilna, dlatego logi fsck są tracone po ponownym uruchomieniu systemu. Byłoby miło, gdyby te dzienniki zostały skopiowane do pamięci trwałej po zamontowaniu głównego systemu plików jako zapisywalne, ale nie wydaje się, aby tak było.

Oto przykład:

$ 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
źródło

1

W przypadku partycji root wydaje się to jedyną prawidłową odpowiedzią dla 16.04 + systemd.

— Jonah Braun

5

Dla Ubuntu 16.04

Komenda journalctl -b --no-pager | grep systemd-fsck

zgłasza kontrole systemu plików partycji innej niż root. podobnie:

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

Aby sprawdzić partycję root podczas uruchamiania, wydaj polecenie more /var/log/boot.log

Zapewnia wyniki podobne do tego:

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

— Starszy Geek
źródło

2

Testowałem to z Ubuntu 12.04.5 LTS i znalazłem dziennik na /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

— barbuk
źródło

0

Dla Ubuntu 18.04

Polecenie journalctl -b --no-pager | grep systemd-fsckigrep systemd-fsck /var/log/syslog

oba zgłaszają kontrole systemu plików partycji innej niż root. podobnie:

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

Kontrole partycji głównych zamontowanych przez wyniki UUID nie wydają się być rejestrowane, nawet jeśli są wymuszone.

— Starszy Geek
źródło