☰

Wie kann ich Upstart debuggen, wenn es hängt, während Root schreibgeschützt ist?

tag-icon • tag-icon boot mount upstart
Wie kann ich Upstart debuggen, wenn es hängt, während Root schreibgeschützt ist?

Ich versuche, einen erfolglosen/abgestürzten Systemstart (Upstart) auf 14.04.2 LTS zu debuggen. Root ist ein ext4-Dateisystem in einem Luks-Container. Die Dateisysteme sind in einem sauberen Zustand.

Der Bootvorgang stoppt nach upstart-socket-bridge (nicht unbedingt nach diesem bestimmten Dienst, z. B. als cups-daemon installiert wurde, stoppte er danach). init -vist auch nicht sehr hilfreich. Der einzige Protokolleintrag, der nicht nur das Starten/Stoppen verschiedener Dienste protokolliert, ist einer über udev direkt vor init.

Begin: Running /scripts/init-bottom ... done.
udev exit failed --rc=2

(Bearbeiten) Das erneute Einbinden des Root-RW schien zunächst immer zu einem sauberen Neustart zu führen, aber Tatsache ist, dass es irgendwie unvorhersehbar ist und ich in beiden Fällen sowohl fehlgeschlagene als auch erfolgreiche Neustarts erlebt habe. Was?

Beobachtung: Alles scheint in Ordnung zu sein, das System mountet das beschreibbare Root-Verzeichnis einfach nicht erneut oder setzt den Bootvorgang nicht fort.

Q:Wie finde ich heraus, welcher Dienst dafür verantwortlich ist, dass der Startvorgang hängen bleibt?

Update: Eine zweite Shell kann über Getty gestartet werden, initctl listnachdem sie sich aufgehängt hat. Dies sind die laufenden Jobs

mountnfs-bootclean.sh start/running
udev start/running, process 438
upstart-udev-bridge start/running, process 432
plymouth start/running, process 122
resolvconf start/running
ssh start/running, process 767 <-- this one was manually started
mountall start/running, process 337
mountkernfs.sh start/running
mountnfs.sh start/running
bootmisc.sh start/running
upstart-socket-bridge start/running, process 745**
cryptdisks start/running
mountdevsubfs.sh start/running
mtab.sh start/running
network-interface (lo) start/running
network-interface (eth0) start/running
plymouth-ready (startup) start/running, process 315
plymouth-upstart-bridge start/running, process 316
mountall-bootclean.sh start/running
network-interface-security (network-interface/eth0) start/running
network-interface-security (network-interface/lo) start/running

Aktualisierung 2:

  • Die Neuinstallation von Upstart und aller abhängigen Pakete (ist mühsam und) hat keine Wirkung.
  • Mit der zweiten Konsole kann ich init 5das festgefahrene System dazu bringen, den normalen Bootvorgang fortzusetzen.
  • das System blieb nun hängen, selbst wenn ich das Root-RW manuell neu gemountet habe (oder den Kernel-Parameter RW verwendet habe) - meine anfängliche Beobachtung, dass das Erzwingen des Schreibzugriffs auf das Root-RW das Problem umgeht, ist falsch

Problemumgehung:

Es scheint, als sei es ureadaheadseine Schuld. Das Löschen führte zu 5 sauberen Neustarts ohne Probleme. Ich lasse die Frage (und die 100 zusätzlichen Wiederholungen) einfach offen für alle, die interessiert sind oder eine Antwort auf die ursprüngliche Frage kennen: Wie hätte ich das herausfinden können, wenn nicht durch zufälliges Ausprobieren?

Antwort1

Als Referenz die (erfolglosen) Debug-Schritte, die ich versucht habe, die jedoch für andere nützlich sein könnten:

  • besorgen Sie sich ein anderes Debian-ähnliches System, das bootet (z. B. ein Live-Ubuntu auf einem bootfähigen USB-Stick) und nehmen Sie mit chroot Konfigurations- oder Softwareänderungen am untersuchten System vor. Verwenden Sie qemu-static, um dies auf einem System mit anderer Architektur tun zu können.
  • Installieren Sie eine Standalone-Shell wie sash, ändern Sie dann Ihre Kernel-Befehlszeile (verwenden Sie die Taste e in Grub oder bearbeiten Sie grub.cfg/cmdline.txt) und fügen Sie hinzu init=/bin/sash, starten Sie neu, untersuchen Sie die Situation auf dieser Shell und verwenden Sie erst dann, exec initum mit dem Booten fortzufahren
  • Verwenden Sie initden -vSchalter, um die Protokollierung zu erhöhen
  • mounten Sie das Root-Dateisystem frühzeitig schreibbar (z. B. fügen Sie vor der Ausführung von init 'rw' zur Kernel-Befehlszeile hinzu mount -o remount,rw /) - dies ermöglicht mehr Protokollierung
  • prüfen/var/log/upstart
  • Starten Sie beispielsweise ein zusätzliches Terminal auf tty2, bevor Sie init ausführen. getty -n -l /bin/bash 38400 tty2 &Dies hilft dabei, den Status des Systems zu überprüfen (z. B. ps -Af, iotop).
  • verwenden initctl list, um herauszufinden, welche Dienste sich in welchem ​​Status befinden

verwandte Informationen