Не вдалося на кроці нересту EXEC / bin / plymouth (тестування Debian)

Після того, як я виконав 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, яке переживає Джесі.

Не вдалося перезавантажити систему, незважаючи на помилки "apt-get dist-upgrade". Остаточний вихід помилки через "journalctl -xb" (або "-xd") був пов'язаний з "plymouth" (програма, про яку я ніколи не чув). Але виявляється, що неможливість перезавантаження не мала нічого спільного з plymouth, скоріше незначна аномалія під допоміжним записом у / etc / fstab: змінити "auto" на "noauto" для пристрою cdrom (нічого спільного з NFS), а потім systemd дозволить завантажувати. Це лінія fstab, яка функціонує під хрипом і не вдається мовчки дозволити перезавантаження під Джессі.

Не було помилки через journalctl, пов’язаний з fstab. Везучі пошуки в Інтернеті привели мене до цього незрозумілого рішення.

Поєднуючи попередні відповіді, ця проблема, як видається, викликана невірними записами в / etc / fstab.

У моєму випадку я працюю всередині virtualbox, і це була загальна папка, яку я створив для автоматичного монтажу під час завантаження. У двох інших відповідях саме проблема була встановлена ​​для пристроїв NFS або CD-ROM.

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

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

У мене сьогодні була точна помилка.

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

Це було викликано неправильним записом nfs в / etc / fstab. Після видалення цього запису помилка зникла. Я думаю, ця жахлива поведінка пов'язана з дурною системою.

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

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

Мені довелося прокоментувати цей рядок, /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 налаштований зараз.

Хтось зміг повністю вирішити це питання? або знайти першопричину?