Ошибка на шаге EXEC spawning / bin / plymouth (тестирование Debian)

16

После того, как я выполнил dist-upgradeтестирование на экземпляре Debian (Jessie), я больше не могу загружаться. Я заброшен в командной строке:

Welcome to emergency mode! After logging in, type "journalctl -xb" to view system logs

Появляется следующая ошибка:

root@debian:~# journalctl -xb
debian systemd[222]: Failed at step EXEC spawning /bin/plymouth: No such file or directory

Удивительно, но Google не помогает, и небольшая нить, которую я вижу, относится к Arch (даже если я добавлю + debian в моем поиске) и не имеет смысла для меня.

Любой указатель о том, как оправиться от этого?

# uname -a
Linux debian 3.16.0-4-amd64 #1 SMP Debian 3.16.7-2 (2014-11-06) x84_64 GNU/Linux

debian upgrade plymouth

— Youri
источник

Возможно, это нужно изменить, чтобы убрать тестирование из заголовка, поскольку оно «подтверждено» на Jessie / stable и т. Д., Начиная с SystemD; (

— Hvisage

20

У меня также была эта точная ошибка сегодня в результате обновления Debian до Джесси.

Системе не удалось перезагрузиться, несмотря на отсутствие ошибок из «apt-get dist-upgrade». Окончательный вывод ошибки через "journalctl -xb" (или "-xd") был связан с "plymouth" (приложением, о котором я никогда не слышал). Но оказывается, что сбой перезагрузки не имеет ничего общего с plymouth, а скорее является незначительной аномалией под вспомогательной записью в / etc / fstab: измените «auto» на «noauto» для устройства cdrom (ничего общего с NFS), а затем systemd разрешит загрузку. Это строка fstab, которая работала под wheezy и молча не позволяет перезагрузиться под jessie.

Не было ошибки через journalctl, связанной с fstab. Именно счастливые поиски в сети привели меня к этому неясному решению.

— Теофраст
источник

4

Верный. Плимутская ошибка привлекла мое внимание, и я упустил из виду реальную причину.

— youri

Да, в моем случае это уже был noauto, но файловая система, которой не было "там" из-за дополнительного добавленного диска ... <добавление-французского-выбора-слова> systemd, который просто должен был поглотить монтирование файловые системы ... на самом деле это должен быть отчет об ошибках в systemd ... но, зная LP из предыдущего опыта монтирования файловой системы, он будет проигнорирован; (Все лучшее в решении проблем, связанных с systemd в будущем

— Hvisage

Вместо того, чтобы комментировать строку в fstab, добавьте nofailопцию для всех несущественных файловых систем. Эта опция указывает systemd игнорировать ошибки во время монтирования и продолжать обычный процесс загрузки.

— Marki555

11

Объединяя предыдущие ответы, эта проблема, по-видимому, вызвана неправильными записями в / etc / fstab.

В моем случае я работаю внутри virtualbox, и это была общая папка, которую я настроил для автоматического монтирования при загрузке, и это была проблема. В двух других ответах проблема заключалась в настройке NFS или устройства CD-ROM.

Я бы предложил, чтобы устранить неполадки, просто закомментируйте все несущественные строки в / etc / fstab, а затем добавляйте их по очереди, пока вы не воспроизведете проблему.

Проблемная линия может быть диагностирована и исправлена. Во время обновления dist возможно, что такие вещи, как общие папки Vbox, сетевые папки или другие специализированные файловые системы, не были обновлены правильно.

— Крис Нолдус
источник

ДА!!!!! см мой комментарий в другом ответе

— Hvisage

3

У меня была точная ошибка сегодня.

Я установил Плимут, но это не изменило результат.

Это было вызвано неправильной записью nfs в / etc / fstab. После удаления этой записи ошибка исчезла. Я предполагаю, что это ужасное поведение происходит из-за глупой системы.

— Может Каваклыоглу
источник

2

Я подтверждаю, что это проблема в fstab. Если вы зайдете внутрь fstab и удалите последнюю сделанную вами строку, все будет как прежде, и система запустится. У меня проблема с автоматическим монтированием в VirtualBox 5 / debian 8. Нет проблем в Virtualbox 4 / debian 7

— reylon
источник

0

Я вижу, что это довольно старая тема на данный момент ... но я также столкнулся с этой проблемой сегодня.

Мне пришлось закомментировать эту строку, /etc/fstabчтобы система не загружалась в «аварийном режиме»:

#UUID=0x0000x0-0x00-0000-xx00-0000xxx00000 /boot           ext2    defaults        0       2
/dev/mapper/Ubuntu16043LTSVM--vg-swap_1 none            swap    sw              0       0

* (UUID намеренно скрыт)

ОБНОВИТЬ:

Линия UUID в, /etc/fstabкажется, виновата в этой проблеме. Странный. После прочтения более подробно об этой проблеме в этой теме я все еще не был ближе к окончательному ответу на основную причину, но по крайней мере SWAP настроен сейчас.

Кто-нибудь смог решить эту проблему полностью? или найти причину?

— kanidrive
источник