Моя Ubuntu запускает fsck при каждой загрузке

/ dev / sda1: clean, 908443/38690816 Files, 44176803/154733312 Blocks

Строка, создающая это сообщение, - this :

/* Print the summary message when we're skipping a full check */
log_out(ctx, _("%s: clean, %u/%u files, %llu/%llu blocks"),

Он пропускает «полную проверку», но только что удостоверился, что некоторые быстрые тесты в журнале чистые и нет лишних инодов:

cat /var/log/boot.log 
fsck from util-linux 2.20.1
fsck from util-linux 2.20.1
/dev/sda1: clean, 260598/771552 files, 1684682/3080192 blocks
/dev/sdb10: recovering journal
/dev/sdb10: Clearing orphaned inode 142568 (uid=1000, gid=1000, mode=0100664, size=32768)
/dev/sdb10: Clearing orphaned inode 138527 (uid=1000, gid=1000, mode=0100600, size=9580)
/dev/sdb10: clean, 54957/991232 files, 3498365/3958006 blocks

Это нормально и ожидаемо. Если бы это была действительно тщательная проверка, это заняло бы намного больше времени, но обычно это занимает секунду или меньше. Страница справочника Systemd systemd-fsck(8) имеет условия, при которых запускается полная проверка:

systemd-fsck-root.service отвечает за проверки файловой системы в корневой файловой системе, но только если корневая файловая система не был проверен в initramfs. systemd-fsck @ .service используется для всех других файловых систем и для корневой файловой системы в initramfs.

Эти службы запускаются при загрузке, если для passno в / etc / fstab для файловой системы установлено значение больше нуля. Проверка файловой системы на наличие root выполняется перед другими файловыми системами. Другие файловые системы могут проверяться параллельно, кроме случаев, когда они находятся на одном вращающемся диске.

systemd-fsck не знает каких-либо подробностей о конкретных файловых системах и просто выполняет проверки файловой системы, специфичные для каждого типа файловой системы (/sbin/fsck.*). Этот помощник решит, следует ли проверять файловую систему на основе времени с момента последней проверки, количества монтирований, нечистого демонтажа и т. Д.

Вы можете просто проверить, что тесты практически не выполнялись (если вы используете systemd):

sudo systemd-analyze blame | grep fsck
          1.608s systemd-fsck@dev-disk-by\x2duuid-408535fe\x2d28e6\x2d4d82\x2dbb59\x2d9810ead089a3.service
            87ms systemd-fsck@dev-mapper-vlhome\x2dlvhome.service

Вы уверены, что fsck требует 30 секунд, а не только то, что следующее консольное сообщение, касающееся udevd, занимает 30 секунд? Другими словами, может быть, udevd тратит 30 секунд на тайм-аут работы с библиотекой, прежде чем показывать консольное сообщение?

Попробуйте удалить (или временно переместить в другое место)

/lib/udev/rules.d/45-libticables.rules

и посмотрите если это поможет.

Этот fsck при каждой загрузке случался со мной из-за плохих часов. Похоже, что systemd-fsck @ запускается до systemd-timesyncd, и без RTC с резервным питанием от батареи системное время неверно во время запуска fsck.

Я подтвердил, что это действительно то, что запускает полную проверку (вместо быстрого выхода из fsck), отключив systemd-timesynd, установив в clock значение предварительной синхронизации, найденное в journalctl, и запустив fsck. Затем e2fsck переходит к полной проверке, как только обнаруживает, что время последней записи суперблока находится в будущем:

fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Superblock last write time (Mon Jun 19 00:48:11 2017,
    now = Tue Jan 31 20:09:28 2017) is in the future.
Fix<y>? yes
Pass 1: Checking inodes, blocks, and sizes
...

Обратите внимание, что этот триггер для полной проверки не связан с другими триггерами max число монтирования и интервал времени с момента последней проверки, замеченный в dumpe2fs -h, упомянутом в других ответах здесь.

Обратите внимание, что без установки часов (то есть синхронизации timeyncd) fsck не выполнит полную проверку, но быстро завершит работу с сообщением «очистка файловой системы».

В качестве обходного пути я отключил fsck в / etc / fstab, установив в поле «pass» значение 0. В конце концов, я куплю RTC с батарейным питанием для этого устройства.

Мои поиски позволяют мне сделать вывод, что максимальное количество монтировок в Ubuntu по умолчанию установлено равным -1. Это означает, что fsck никогда не запустится ни при какой загрузке, независимо от количества монтирований. Вы можете проверить свои по команде -

sudo dumpe2fs -h /dev/sda8 | grep -i 'mount count'

Вы можете увеличить его по вашему требованию, используя tune2fs. Типичный пример:

sudo tune2fs -c 30 -i 1w /dev/sda8

Настройте его по своему усмотрению.

Поскольку другие опубликовали максимальное число монтирования, по умолчанию может быть -1, что означает, что fsck запускается при каждой загрузке, что, естественно, замедляет процесс загрузки.

Измените частоту fsck на каждые 50 загрузок или каждые 30 дней, используя:

$ sudo tune2fs -c 50 -i 1m /dev/sdc3

tune2fs 1.42.13 (17-May-2015)
Setting maximal mount count to 50
Setting interval between checks to 2592000 seconds

Предполагая, что сегодня 13 ноября 2016 года, проверьте, когда будет запущен fsck, используя:

$ sudo dumpe2fs -h /dev/sdc3 | grep Next

dumpe2fs 1.42.13 (17-May-2015)
Next check after:         Tue Dec 13 22:45:39 2016