Здесь — как по журналу найти строку fstab, на которой загрузка остановилась.
Сообщение аварийного режима само называет первую команду — journalctl -xb (в Вики): -b — записи этой загрузки, -x — пояснения systemd к ним. Записей тысячи, поэтому начинают с ошибок и списка того, что не запустилось. Оболочка — root, sudo не нужен:
Каждую строку fstab systemd превращает в юнит монтирования с именем по точке: /srv/cache → srv-cache.mount. Цепочку в журнале — вот выдержка из journalctl -b — читают от причины к следствию:
Ядро не приняло опцию szie, юнит монтирования упал, local-fs.target не достигнута, и systemd ушёл в аварийный режим. Опечатку в опции findmnt --verify не заметил: её ловит само монтирование. Поэтому после правки fstab, до перезагрузки, запускают sudo mount -a: он ответил бы wrong fs type, bad option на эту строку сразу.
Другой сервер после перезагрузки тоже стоит в аварийном режиме, а в его journalctl -b — другие строки:
Что остановило загрузку другого сервера по строкам его журнала?
-
Опечатку в опции журнал назвал бы сообщением
mountили ядра, какUnknown parameter. Здесь до монтирования не дошло: systemd не дождался устройства. -
Служб в этих строках нет:
srv-backup.mount— юнит монтирования из строки fstab для /srv/backup. -
local-fs.target цела:
Dependency failedзначит, что она не дождалась своего юнита монтирования. Первая строка называет причину — устройство с UUID так и не появилось.
systemd полторы минуты ждал устройство с UUID из строки /srv/backup и не дождался, поэтому её юнит монтирования не запустился, а за ним и local-fs.target. Исправляют строку — UUID по blkid или nofail, если без диска можно жить.
Главное в шаге
-
journalctl -b -p errиsystemctl --failedпоказывают, какой юнит монтирования упал и почему. -
Цепочка в журнале: причина от
mountили ядра →Failed to mount→Dependency failed for local-fs.target. -
findmnt --verifyне заметил ошибку в опции: строку целиком проверяетsudo mount -aдо перезагрузки.