Fehler beim Ausführen von EXEC / bin / plymouth (Debian-Test)

Nachdem ich dist-upgradeeine Debian-Testinstanz (Jessie) ausgeführt habe, kann ich nicht mehr booten. Ich bin an der Eingabeaufforderung abgestürzt:

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

Der folgende Fehler wird angezeigt:

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

Überraschenderweise hilft Google nicht und der kleine Thread, den ich sehe, ist für Arch (auch wenn ich bei meiner Suche + debian hinzufüge) und ergibt für mich keinen Sinn.

Irgendwelche Hinweise, wie man sich davon erholt?

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

Ich hatte heute auch genau diesen Fehler als Ergebnis eines Debian-Wheezy-to-Jessie-Upgrades.

Das System konnte nicht neu gestartet werden, obwohl bei "apt-get dist-upgrade" keine Fehler aufgetreten sind. Die endgültige Fehlerausgabe über "journalctl -xb" (oder "-xd") wurde mit "plymouth" (einer Anwendung, von der ich noch nie gehört hatte) in Verbindung gebracht. Es stellte sich jedoch heraus, dass ein fehlgeschlagener Neustart nichts mit Plymouth zu tun hatte, sondern eine geringfügige Anomalie unter einem zusätzlichen Eintrag unter / etc / fstab: Ändern Sie "auto" für ein CD-ROM-Gerät in "noauto" (nichts mit NFS zu tun) und dann systemd erlaubt das Booten. Dies ist eine fstab-Zeile, die unter Wheezy funktioniert und keinen Neustart unter Jessie zulässt.

Es gab keinen Fehler über journalctl in Verbindung mit fstab. Es waren glückliche Websuchen, die mich zu dieser obskuren Lösung führten.

In Kombination mit den vorherigen Antworten scheint dieses Problem auf ungültige Einträge in / etc / fstab zurückzuführen zu sein.

In meinem Fall arbeite ich in virtualbox und es war ein freigegebener Ordner, den ich so eingerichtet hatte, dass er beim Booten automatisch eingebunden wurde, was das Problem war. Bei den beiden anderen Antworten handelte es sich um die Einstellungen für NFS- oder CD-ROM-Geräte.

Ich würde vorschlagen, dass Sie zur Fehlerbehebung einfach alle nicht wesentlichen Zeilen in / etc / fstab auskommentieren und sie dann einzeln hinzufügen, bis Sie das Problem replizieren.

Die problematische Leitung kann dann diagnostiziert und behoben werden. Es ist möglich, dass während des dist-Upgrades Dinge wie freigegebene Vbox-Ordner, Netzwerkfreigaben oder andere spezialisierte Dateisysteme nicht korrekt aktualisiert wurden.

Ich hatte heute den genauen Fehler.

Ich habe plymouth installiert, aber es hat das Ergebnis nicht verändert.

Es wurde durch einen falschen nfs-Eintrag in / etc / fstab verursacht. Nach dem Löschen dieses Eintrags ist der Fehler verschwunden. Ich denke, dieses schreckliche Verhalten ist auf das blöde System zurückzuführen.

Ich bestätige, dass dies ein Problem in fstab ist. Wenn Sie in fstab gehen und die letzte Zeile löschen, die Sie gemacht haben, ist alles wie zuvor und das System startet. Ich habe ein Automount-Problem bei der Freigabe in VirtualBox 5 / debian 8. Kein Problem in VirtualBox 4 / debian 7

Ich sehe, dass dies zu diesem Zeitpunkt ein ziemlich alter Thread ist ... aber ich habe dieses Problem auch heute erlebt.

Ich musste diese Zeile in /etc/fstabauskommentieren, um zu verhindern, dass das System im Notfallmodus bootet:

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

* (UUID ist absichtlich verschleiert)

AKTUALISIEREN:

Der UUID-Eingang /etc/fstabscheint an diesem Problem schuld zu sein. Seltsam. Nachdem ich in diesem Thread mehr über dieses Problem gelesen hatte, war ich noch nicht näher an einer endgültigen Antwort auf die Grundursache, aber zumindest ist der SWAP jetzt konfiguriert.

War jemand in der Lage, dieses Problem vollständig zu lösen? oder die Ursache finden?