Де записуються результати fsck під час завантаження, після / forcefsck?

37

Під час віддаленої роботи я встановив сервер, щоб змусити fsck під час завантаження sudo touch /forcefsckкомандою та перезавантажився.

Після його перезавантаження я зареєструвався /var/log/fsckна результати перевірки диска.
Обидва checkfs і checkroot сказали: Нічого не було ще авторизуватися

То де це економить результати?

boot logging fsck

— Барт Сільверстрім
джерело

З тією ж проблемою на Ubuntu 12.04 LTS. Я знайшов журнал fsck у /var/log/boot.log.

15

Можливо, на вас впливає ця помилка: "Не записує виклики fsck в / var / log / fsck /"

— сплеск
джерело

Швидше за все. Не варто більше дивуватися, що це, мабуть, не буде вирішуватися ...

— Барт Сільверстрім

Це також впливає на нас вкрай негативно - ми перебуваємо на EC2, і коли сервери перезавантажуються, нам потрібні такі деталі. Як це можливо вважати пунктом "списку бажань"? Це основна функціональність, і вона порушена.

— tamale

@tamale Ви абсолютно праві. Мене теж вразило це. Мій /розділ мав жахливу химерність, і коли входив у режим відновлення, він змусив e2fsckйого застосувати. Це ідеально, але оскільки насправді важко запам’ятати, які файли потрібно замінити на резервну копію, треба відслідковувати імена файлів, як повідомляється, пошкоджені.

— синтаксичний помилок

13

Для Ubuntu 14.xx:

Я знайшов кілька журналів fsck /var/log/upstart/mountall.log.

— Шай
джерело

1

Ласкаво просимо до Ask Ubuntu. ;-) Раніше помилка була в 11.10, тому ваша відповідь у новій системі зараз не додає жодних значень цьому 3-річному питанню. На майбутнє: подивіться дату питання і чи вже є відповідь. ;-)

— Fabby

4

@Fabby, але для майбутніх відвідувачів це все ще може бути корисним, я думаю? Версія надана (@Shay? Ви маєте на увазі 14.04 чи 14.10?), І тому я б сказав, що це правильна відповідь, хоча це може не допомогти ОП (хто знайшов рішення 3 роки тому ...)

— Byte Commander

Я додав тег, щоб пошукові системи показали це як старе питання.

— НГР

Абсолютно вірно! :-) Ось чому я просто залишив коментар. Для запису: Я не проголосував! ;-)

— Fabby

1

@Byte Commander Це нібито "старе" питання мені дуже допомогло! Я б ніколи не здогадувався, що fsckжурнали будуть заховані у /var/log/upstart/mountall.logвідповідності. /var/log/upstart/mountall.*.log.gz. Досить нелогічно. ЗАРАЗ, здається, що імена файлів, про які повідомлялося, були пошкоджені, не були записані, а лише їхні вставки.

— синтаксичний помилок

6

Для кореневих розділів Ubuntu 16.04 та 18.04

Ви, ймовірно, шукаєте /run/initramfs/fsck.log.

Fsck кореневої файлової системи обов'язково відбувається до монтажу кореневої файлової системи як записуваної, тому перевірка файлової системи відбувається на початку завантажувального процесу, поки система все ще працює з initramfs. Журнал fsck записується до файлової системи, підтримуваної оперативною пам'яттю (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

Для Ubuntu 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

— Старійшина Гік
джерело

2

Тестуючи це за допомогою Ubuntu 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

Для Ubuntu 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, не реєструються, навіть якщо вони примусові.

— Старійшина Гік
джерело