Где записываются результаты fsck во время загрузки, после / forcefsck?

37

При удаленной работе я настроил сервер для принудительного запуска fsck во время загрузки с помощью sudo touch /forcefsckкоманды и перезагрузился.

После перезапуска я проверил /var/log/fsckрезультаты проверки диска.
И checkfs, и checkroot сказали: еще ничего не было зарегистрировано

Так, где это сохраняет результаты?

Барт Сильверстрим
источник
Имея ту же проблему на Ubuntu 12.04 LTS. Я нашел журнал fsck в /var/log/boot.log.

Ответы:

15

Возможно, вы подвержены этой ошибке: «Не регистрирует вызовы fsck в / var / log / fsck /»

всплеск
источник
Скорее всего. Не стоит больше удивляться, что это, вероятно, не будет решено ...
Барт Сильверстрим
Это также очень негативно влияет на нас - мы находимся в EC2, и когда серверы перезагружаются, нам нужны подробности о подобных вещах. Как это можно считать «списком пожеланий»? Это основная функциональность, и она сломана.
тамале
@tamale Ты полностью прав. Меня это тоже поразило. Мой /раздел имел неприятную причуду, и при входе в режим восстановления, он принудительно e2fsckна нем. Это прекрасно, но так как очень трудно запомнить, какие файлы заменить из резервной копии, нужно иметь возможность отслеживать имена файлов, которые, по сообщениям, повреждены.
синтаксическая ошибка
13

Для Ubuntu 14.xx:

Я нашел несколько журналов fsck /var/log/upstart/mountall.log.

фаэтон
источник
1
Добро пожаловать в Спросите Ubuntu. ;-) В то время в 11.10 была ошибка, поэтому ваш ответ о новой системе сейчас не добавляет никакой ценности к этому трехлетнему вопросу. На будущее: посмотрите на дату вопроса и есть ли уже ответ. ;-)
Fabby
4
@ Fabby, но для будущих посетителей это все еще может быть полезно, я думаю? Версия дается (@Shay, вы имеете в виду 14.04 или 14.10?), И поэтому я бы сказал, что это правильный ответ, хотя он может не помочь ОП (который нашел решение 3 года назад ...)
Byte Commander
Я добавил тег, чтобы поисковые системы показывали это как старый вопрос.
NGRhodes
Совершенно верно! :-) Вот почему я просто оставил комментарий. Для справки: я не голосовал против! ;-)
Fabby
1
@Byte Commander Этот, якобы, «старый» вопрос действительно помог мне! Я бы никогда не догадался, что fsckжурналы будут спрятаны в /var/log/upstart/mountall.logсоотв. /var/log/upstart/mountall.*.log.gz, Довольно нелогично. ОДНАКО, кажется, что имена файлов, о которых сообщалось, что они повреждены, не были зарегистрированы, только их inode.
синтаксическая ошибка
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
barbuk
источник
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, не регистрируются, даже если принудительно.

Старейшина Гик
источник