Mein Problem ist folgendes: Nach meinem letzten Update (Pacman -Syu) bleibt mein System beim Booten hängen und ich kann die Ursache nicht herausfinden (es macht mich wirklich verrückt).
Bei einer Suche im Internet habe ich herausgefunden, dass die Ursache möglicherweise eine fehlerhafte fstab-Datei ist, aber das scheint nicht der Fall zu sein.
Die von mir verwendete Distribution ist Manjaro Linux (basierend auf Arch) und meine Systemd-Version ist 231
Das hat journalctl -xb dazu zu sagen
Oct 04 11:45:02 manjarobox systemd[350]: rescue.service: Faied at step EXEC spawning /bin/plymouth: No such file or directory
-Subject: Process /bin/plymouth could not be executed
-Defined-by: systemd
-Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-
-The process /bin/plymouth could not be executed and failed
-
-The error number returned by this process is 2
Dies ist die Ausgabe von ls -l /etc/systemd/system/multi-user.target.wants
total 0
lrwxrwxrwx 1 root root 38 Dec 22 2015 cronie.service -> /usr/lib/systemd/system/cronie.service
lrwxrwxrwx 1 root root 42 Dec 27 2015 lm_sensors.service -> /usr/lib/systemd/system/lm_sensors.service
lrwxrwxrwx 1 root root 44 Dec 22 2015 ModemManager.service -> /usr/lib/systemd/system/ModemManager.service
lrwxrwxrwx 1 root root 46 Dec 22 2015 NetworkManager.service -> /usr/lib/systemd/system/NetworkManager.service
lrwxrwxrwx 1 root root 40 Dec 22 2015 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target
lrwxrwxrwx 1 root root 35 Dec 22 2015 tlp.service -> /usr/lib/systemd/system/tlp.service
lrwxrwxrwx 1 root root 35 Jan 13 2016 ufw.service -> /usr/lib/systemd/system/ufw.service
Und meine /etc/fstab-Datei sieht folgendermaßen aus:
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
# DEVICE DETAILS: /dev/sda1 UUID=c52d9ae9-48a8-487c-931b-77deedf8e242 LABEL=DskA_Linux
# DEVICE DETAILS: /dev/sda5 UUID=170E967E185647C6 LABEL=DskD_Files
# DEVICE DETAILS: /dev/sda6 UUID=eeaa09fa-4ace-4e5a-8fef-170a18e41940 LABEL=DskE_Swap
UUID=c52d9ae9-48a8-487c-931b-77deedf8e242 / ext4 defaults 0 1
#UUID=170E967E185647C6 /mnt/Files ntfs-3g defaults 0 1
#UUID=eeaa09fa-4ace-4e5a-8fef-170a18e41940 swap swap defaults 0 0
Außerdem habe ich noch nie Plymouth installiert und habe auch nicht vor, dies zu tun, wenn ich es vermeiden kann.
Was kann ich tun, um das Problem zu lösen? :S
Dank im Voraus
Antwort1
Es ist schon eine Weile her und es scheint viele Ursachen für dieses Problem zu geben (falsche Konfiguration von fstab, verwaiste Konfigurationsdateien usw.), aber für mich hat die Verwendung von 'grep -r plymouth /' und das anschließende Löschen der Anweisungen, die plymouth aufrufen, das Problem gelöst.
Antwort2
Manjaro Linux 5.9 bootet in einer kreisförmigen Schleife zur Root-Shell für die Notfallwartung
Sie gelangen nie zu einem GUI-Bildschirm! Sie müssen also ein paar CLI-Anweisungen kennen, um Ihr Problem zu beheben und die Ursache des Problems zu ermitteln. Ich hatte dasselbe Problem mit Skriptdateien, die /usr/bin/plymouth auf Manjaro 5.9 aufriefen, und ich habe auf Manjaro 5.10 aktualisiert und hatte dasselbe Problem, dass der Start auf einen GUI-Desktop (KDE Plasma, glaube ich) fehlschlug und ich auf eine Root-Shell für die Notfallwartung zurückfiel. Geben Sie Ihr „ROOT-PASSWORT“ ein, um sich bei dieser Root-Shell für die Notfallwartung anzumelden. Ich glaube, Sie befinden sich im Einzelbenutzermodus.
Es ist ein Dbus-Fehler aufgetreten. Datei /run/dbus/dbus_xxx_socket nicht gefunden. Der Dbus-Daemon wurde nicht ausgeführt . ps aux | grep dbus
Befehl dbus-monitorkonnte nicht ausgeführt werden.
Ich glaube, es gab einen Konflikt zwischen dbus und dbus-x11. Der Befehl „pacman -S dbus“ hat das dbus-Problem behoben, aber das fehlende /usr/bin/plymouth existierte immer noch. Ich dachte, vielleicht würde ein Wechsel von Linux59 zu Linux510 das Skript bereinigen. Aber nein, das hat das Problem nicht behoben.
journalctl -xb oder journalctl -b -i -p4 Dies sind die zu verwendenden Journalbefehle.
journalctl -xb > My_journalctl_error1.txt Ich werde eine Kopie auf meiner Festplatte speichern, um die einzelne Fehlerzeile später in einem Forum wie diesem zu posten.
Außerdem konnte ich über die Befehlszeilenschnittstelle „nmcli“ des Network Managers keine Verbindung zum Internet herstellen, wenn ich das vorhandene WLAN des Laptops, einen Broadcom BRM4313 (oder 4727-Chip), verwendete. Also nutzte ich USB-Tethering von meinem Android-Handy, um auf das Internet zuzugreifen und die Computersoftware mit dem Befehl „pacman“ zu aktualisieren. Dies war ein Versuch, herauszufinden, ob ein aktualisiertes Linux andere Skriptdateien verwenden und den Problemfehler überschreiben würde. Upps, kein Problem!
Ich habe mein Android-Handy mit einem USB-Kabel an den Laptop angeschlossen und bin in die Einstellungen gegangen ---> Netzwerk ----> habe USB-Tethering aktiviert. Ich habe auch die Datenspareinstellung „AUS“ gestellt, um den schnellen Download von Kernel-Update-Dateien mit einer Größe von 150 Megabyte zu ermöglichen. Oder viel kleinere „dbus“-Pakete.
ip a s
ifconfig enp0s20u2 up
ip a s
ping -c 3 he.net
ping -c 3 8.8.4.4 the google DNS server, got me a NO route to network.
pacman -Syu
pacman -S dbus
sudo mhwd-kernel -i linux510
grep -R -n plymouth /etc
Daher glaube ich, dass die Lösung darin besteht, das Plymouth aus den folgenden Skriptdateien zu entfernen
/etc/systemd/display-manager.service file at line 5 plymouth-quit.service
/etc/systemd/getty.target.wants/[email protected] file at line 14 plymouth-quit-wait.service