Błąd w kroku EXEC spawn / bin / plymouth (test Debiana)

16

Po wykonaniu dist-upgradeinstancji testowej Debiana (Jessie) nie mogę już uruchomić systemu. Jestem uwięziony w wierszu polecenia:

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

Pojawia się następujący błąd:

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

Zaskakujące jest to, że Google nie pomaga, a mały wątek, który widzę, dotyczy Archa (nawet jeśli dodam + debian w wyszukiwaniu) i nie ma dla mnie sensu.

Jakiś wskaźnik, jak się z tego zregenerować?

# 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
źródło

Być może należy to zmienić, aby usunąć testowanie z nagłówka, ponieważ jest to „potwierdzone” na Jessie / stable itp., Wszystko od SystemD; (

— Hvisage

20

Miałem również ten dokładny błąd w wyniku aktualizacji debiana wheezy do jessie.

System nie uruchomił się ponownie pomimo braku błędów z „apt-get dist-upgrade”. Końcowy błąd wyprowadzany przez „Journalctl -xb” (lub „-xd”) był powiązany z „plymouth” (aplikacją, o której nigdy nie słyszałem). Ale okazuje się, że ponowne uruchomienie nie miało nic wspólnego z plymouth, a raczej niewielką anomalią pod dodatkowym wpisem w / etc / fstab: zmień „auto” na „noauto” dla urządzenia cdrom (nic wspólnego z NFS), a potem systemd pozwoli na rozruch. Jest to linia fstab, która działała w wheezy i po cichu nie pozwala na ponowne uruchomienie w Jessie.

Nie wystąpił błąd przez dziennikl związany z fstab. Szczęśliwe wyszukiwania w sieci doprowadziły mnie do tego niejasnego rozwiązania.

— Theophrastus
źródło

4

Poprawny. Błąd plymoutha przykuł moją uwagę i przeoczyłem rzeczywistą przyczynę.

— youri

Tak, w moim przypadku to już nie było , ale system plików, który nie był „tam” z powodu dodatkowego dodanego dysku ... <adding-French-choice-words> systemd, który absolutnie musiał po prostu wyssać montaż systemy plików ... powinien to być raport o błędzie przeciwko systemd ... ale znając LP z poprzednich doświadczeń dotyczących montowania systemu plików, zostanie zignorowany; (wszystkiego najlepszego w rozwiązywaniu problemów związanych z systemem w przyszłości

— Hvisage

Zamiast komentować linię w fstab, dodaj nofailopcję dla wszystkich nieistotnych systemów plików. Ta opcja mówi systemdowi, aby ignorował błędy podczas montowania i kontynuował normalny proces uruchamiania.

— Marki555,

11

Łącząc poprzednie odpowiedzi, wydaje się, że przyczyną tego problemu są nieprawidłowe wpisy w / etc / fstab.

W moim przypadku działam w programie virtualbox i był to folder udostępniony, który skonfigurowałem do automatycznego montowania przy rozruchu, który był problemem. W pozostałych dwóch odpowiedziach problemem były ustawienia NFS lub CD-ROM.

Sugeruję, aby rozwiązać problem, po prostu skomentuj wszystkie nieistotne linie w / etc / fstab, a następnie dodaj je kolejno, aż do odtworzenia problemu.

Problematyczną linię można następnie zdiagnozować i naprawić. Podczas aktualizacji dist możliwe jest, że rzeczy takie jak foldery współdzielone Vbox, udziały sieciowe lub inne specjalistyczne systemy plików nie zostały poprawnie zaktualizowane.

— Chris Noldus
źródło

TAK!!!!! patrz mój komentarz w innej odpowiedzi

— Hvisage

3

Miałem dzisiaj dokładny błąd.

Zainstalowałem Plymouth, ale nie zmieniło to wyniku.

Było to spowodowane niewłaściwym wpisem nfs w / etc / fstab. Po usunięciu tego wpisu błąd zniknął. Myślę, że to okropne zachowanie jest spowodowane głupim systemem.

— Can Kavaklıoğlu
źródło

2

Potwierdzam, że jest to problem w fstab. Jeśli wejdziesz do fstab i usuniesz ostatni wiersz, który zrobiłeś, wszystko jest jak przedtem i system się uruchomi. Mam problem z automatycznym podłączeniem w VirtualBox 5 / debian 8. Nie ma problemu w Virtualbox 4 / debian 7

— reylon
źródło

0

Widzę, że w tym momencie jest to dość stary wątek ... ale dzisiaj ten problem też się zdarzyło.

Musiałem skomentować ten wiersz, /etc/fstababy zapobiec uruchamianiu systemu w „trybie awaryjnym”:

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

* (UUID jest celowo zaciemniony)

AKTUALIZACJA:

/etc/fstabWydaje się, że linia UUID jest winna tego problemu. Dziwny. Po przeczytaniu więcej na ten temat w tym wątku wciąż nie byłem bliżej ostatecznej odpowiedzi na temat głównej przyczyny, ale przynajmniej SWAP jest teraz skonfigurowany.

Czy ktoś był w stanie całkowicie rozwiązać ten problem? lub znaleźć podstawową przyczynę?

— kanidrive
źródło