Как точно определить, почему Systemd переходит в аварийный режим

Мой настольный компьютер с Debian Jessie начинал падать в оболочку аварийного режима при каждой загрузке. Экран говорит, чтобы использовать, journalctl -xbчтобы найти причину, и использовать, systemctl defaultчтобы продолжить загрузку. Когда я выполняю systemctl default, система продолжает загружаться, и после пары недель использования системы, очевидно, нет ничего плохого.

Если смотреть сквозь journalctl -xb, то ничто не является причиной падения в аварийный снаряд. Есть ли простой способ точно определить причину, по которой он решил перейти в аварийный режим? Существуют ли другие флаги или параметры загрузки, которые позволят понять, где проблема?

Ошибка должна была показать красный цвет [ FAIL ]на консоли (вместо [ OK ]) с описанием устройства рядом с ним. Как правило, первые неудачи являются наиболее важными. Используйте shift + pageup на консоли для прокрутки вверх и просмотра последних нескольких скриншотов вывода. Это может не сработать, если вывод слишком большой.

Это работает, даже если вы обычно не видите [ OK ]сообщений, например, из- quietза командной строки ядра, используемой Debian. При первом сбое systemd переключается в подробный режим.

В противном случае вы можете использовать systemctl. Без каких-либо опций, он показывает огромный список известных юнитов с отказами, выделенными красным. Чтобы показать только неудачные, используйте systemctl --state=failedили systemctl --failed.

Если вы просматриваете файлы модуля, есть только несколько способов вернуться к загрузке emergency.target. Обычно происходит .mountсбой модуля для локальной файловой системы, что приводит local-fs.targetк сбою. Или когда ваш initramfs не может смонтировать корневую файловую систему, если ваш initramfs использует systemd.

local-fs.targetесть OnFailure=emergency.target. И это происходит сбой, потому что модули для локальных файловых систем автоматически добавляются в список Требуется local-fs.target (если они не имеют DefaultDependencies=no).

$ systemctl show --property Requires local-fs.target
Requires=-.mount home.mount boot.mount boot-efi.mount

Время от времени я сталкиваюсь с приглашением «режим обслуживания», и мне приходится просматривать журнал Journal на наличие ошибок. Так как journalctl использует меньше как пейджер, вы должны иметь возможность применять любые менее быстрые клавиши для поиска.

Обычно я полагаюсь на функцию поиска (/) и ищу что-либо, эквивалентное «ошибка», «предупреждение» или «сбой». И убедитесь, что -i для принудительного поиска без учета регистра.

Поэтому мои нажатия клавиш выглядят так:

-i (case insensitive)
g (move to start)
/error
nnnn (skip through results)
g (move to start)
/fail
nnnn (skip through results)
g (move to start)
/warn
nnnn (skip through results)

Технически это не исчерпывающий или точный поиск точной проблемы, но я никогда не пропускал проблему загрузки таким образом.

Ниже приведены некоторые связанные с ними сочетания клавиш:

http://www.thegeekstuff.com/2010/02/unix-less-command-10-tips-for-effective-navigation/