Errore al passaggio spawning / bin / plymouth EXEC (test Debian)

Dopo aver eseguito dist-upgradeun'istanza su un test Debian (Jessie), non riesco più ad avviarlo. Sono abbandonato al prompt dei comandi:

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

Viene visualizzato il seguente errore:

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

Sorprendentemente, Google non aiuta e il piccolo thread che vedo riguarda Arch (anche se aggiungo + debian nella mia ricerca) e non ha senso per me.

Qualche suggerimento su come recuperare da questo?

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

Ho anche avuto questo preciso errore oggi come risultato di un debian wheezy a jessie upgrade.

Il sistema non è stato riavviato nonostante non vi siano errori da "apt-get dist-upgrade". L'output dell'errore finale tramite "journalctl -xb" (o "-xd") era associato a "plymouth" (un'applicazione di cui non avevo mai sentito parlare). Ma il mancato riavvio non ha avuto nulla a che fare con plymouth, ma piuttosto un'anomalia minore in una voce ausiliaria in / etc / fstab: cambia "auto" in "noauto" per un dispositivo cdrom (niente a che fare con NFS) e poi systemd consentirà l'avvio. Questa è una linea fstab che ha funzionato sotto wheezy e non riesce silenziosamente a consentire un riavvio sotto jessie.

Non è stato riscontrato alcun errore tramite journalctl associato a fstab. Sono state le fortunate ricerche sul web che mi hanno portato a questa soluzione oscura.

Combinando le risposte precedenti, questo problema sembra essere causato da voci non valide in / etc / fstab.

Nel mio caso sono in esecuzione all'interno di virtualbox ed era una cartella condivisa che avevo impostato per il montaggio automatico all'avvio che rappresentava il problema. Nelle altre due risposte, il problema era il settign per il dispositivo NFS o CD-ROM.

Vorrei suggerire che per risolvere i problemi, basta commentare tutte le righe non essenziali in / etc / fstab e quindi aggiungerle una ad una fino a quando non si replica il problema.

La linea problematica può quindi essere diagnosticata e risolta. Durante l'aggiornamento dist è possibile che cose come cartelle condivise Vbox, condivisioni di rete o altri file system specializzati non siano state aggiornate correttamente.

Ho avuto l'errore esatto oggi.

Ho installato plymouth ma non ha modificato il risultato.

È stato causato da una voce nfs errata in / etc / fstab. Dopo aver eliminato quella voce, l'errore è scomparso. Immagino che questo comportamento orribile sia dovuto allo stupido sistema.

Confermo che è un problema in fstab. Se entri in fstab e cancelli l'ultima riga che hai creato tutto è come prima e il sistema si avvia. Ho un problema di automount nella condivisione in VirtualBox 5 / debian 8. Nessun problema in Virtualbox 4 / debian 7

Vedo che questo è un thread piuttosto vecchio a questo punto ... ma oggi ho riscontrato anche questo problema.

Ho dovuto commentare questa riga /etc/fstabper impedire l'avvio del sistema in "modalità di emergenza":

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

* (UUID è intenzionalmente offuscato)

AGGIORNARE:

La linea UUID /etc/fstabsembra essere in errore per questo problema. Dispari. Dopo aver letto di più su questo problema su questo thread non ero ancora più vicino a una risposta definitiva sulla causa principale, ma almeno lo SWAP è ora configurato.

Qualcuno è stato in grado di risolvere completamente questo problema? o trova la causa principale?