Мій Ubuntu працює за допомогою fsck при кожному завантаженні

У кожному завантаженні це одне і те ж:

/dev/sda1: clean, 908443/38690816 files, 44176803/154733312 blocks

Це якась опція, яку Ubuntu використовує для забезпечення узгодженості файлової системи або щось не так з моїм жорстким диском? fsckзаймає до 30-х років під час завантаження, і т. д. збільшує час, необхідний інакше.

Повний вихід (частково німецькою мовою):

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
fsck von util-linux 2.20.1
/dev/sda1: sauber, 908443/38690816 Dateien, 44176803/154733312 Blöcke
udevd[623]: unknown key 'SYSFS{idVendor}' in /lib/udev/rules.d/45-libticables.rules:6

udevd[623]: invalid rule '/lib/udev/rules.d/45-libticables.rules:6'

 * Starting mDNS/DNS-SD daemon                                                 [ OK ]
 * Starting Reload cups, upon starting avahi-daemon to make sure remote queues are populated                                                                   [ OK ]
 * Starting configure network device security                                  [ OK ]
 * Starting bluetooth daemon                                                   [ OK ]
 ####* Starting all other stuff

/ dev / sda1: чистий, файли 908443/38690816, 44176803/154733312 Блоки

Рядок, що видає це повідомлення, такий :

/* 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-fsck(8)Сторінка керівництва Systemd містить умови, коли спрацьовує повна перевірка:

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 секунд? Іншими словами, можливо, удевд забирає 30 секунд на час очікування роботи над справою з зобов'язаннями, перш ніж показувати консольне повідомлення?

Спробуйте видалити (або перемістити кудись інше тимчасово)

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

і подивіться, чи це допомагає.

Цей fsck на кожному завантаженні траплявся зі мною через поганий годинник. Здається, що systemd-fsck @ працює перед systemd-timesyncd, і без RTC, що підтримується батареєю, системний час неправильний у момент запуску fsck.

Я підтвердив, що саме це ініціює повну перевірку (замість того, щоб швидко виходити з fsck), відключивши systemd-timesynd, встановивши годинник на значення попередньої синхронізації, знайдене в 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
...

Зауважте, що цей тригер для повної перевірки не пов’язаний з іншими тригерами максимальної кількості монтажу та інтервалом часу з часу останньої перевірки, про яку dumpe2fs -hйдеться у, зазначеній в інших відповідях тут.

Зауважте, що без встановлення годинника (тобто, дозволяючи timesyncd синхронізувати його), 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

Налаштуйте його за своїм бажанням.