☰

Systemd hängt in Xen Dom0 unmittelbar nach switch_root im Bootvorgang

tag-icon • tag-icon arch-linux systemd xen init
Systemd hängt in Xen Dom0 unmittelbar nach switch_root im Bootvorgang

Ich habe versucht, Xen so einzurichten, dass es mit UEFI und meiner Arch Linux-Installation funktioniert (3.18.2) als Dom0, konnte aber nicht booten. Bemerkenswert ist die Tatsache, dass es ansonsten völlig problemlos bootet, nur nicht unter Xen.

Genauer gesagt friert mein Computer komplett ein und ich muss ihn hart zurücksetzen, ohne dass meines Wissens relevante Fehlermeldungen angezeigt werden. Nach viel Mühe (und dem Entdecken von debug=postmount) habe ich festgestellt, dass er direkt nach dem systemdAufruf von einfriert switch_root.

Das eigentliche Problem ist, dass ich systemd nicht dazu bringen konnte, irgendwelche Protokolle oder Informationen auszugeben, bevor der Computer einfriert. Ich habe verschiedene kernel- und systemd-spezifische Protokollierungsoptionen ausprobiert, aber gleich nachdem ich diese Post-Mount-Shell verlasse, blinkt der Cursor vielleicht ein halbes Mal, ohne dass Protokolle vorliegen, bevor der Bildschirm einfriert.

Mein aktuelles Setup istGummistiefelStarten des Xen EFI mithilfe von zwei kleinen Konfigurationsdateien, die unten aufgeführt sind, falls sie relevant sind:

$esp/loader/conf/xen.conf:

title   Xen
efi     xen-4.5.0.efi

$esp/xen.cfg(dasselbe Verzeichnis wie xen-4.5.0.efi):

[global]
default=xen

[xen]
options=console=none dom0_mem=2048M,max=2048M dom0_max_vcpus=1 loglvl=all noreboot
kernel=vmlinuz-linux root=/dev/sda3 rw systemd.unit=emergency.service systemd.log_level=debug
ramdisk=initramfs-linux.img

Zu beachten:

  • Habe dies mit dem AUR Xen 4.4.1-3-Paket versucht und auch Xen 4.5.0 aus dem Quellcode heruntergeladen und kompiliert, aber beide Versionen frieren am gleichen Punkt des Startvorgangs ein.
  • Ich musste die Binutils zur x86_64-pepUnterstützung neu kompilieren, um das EFI zu generieren, habe das aber nur ersetzt. Ich müsste doch nicht auch GCC ersetzen, oder? Beachten Sie auch, dass dieArch-Wiki-Seite für Xenerwähnt, dass eine heruntergestufte Version von Binutils erforderlich ist, doch sowohl diese als auch die aktuelle Version beider Programme booten nicht auf die gleiche Weise.
  • Ich habe auch versucht, alle mit Xen verbundenen systemd.services zu aktivieren/deaktivieren, aber da sieht es so aus, als würde systemd abstürzen, bevor es überhaupt irgendwelche Dienste lädt.
  • Leider gelingt es weder systemd.crash_shell=truenoch , mich nach dem Aufruf von systemd in eine Shell zu bringen.systemd.unit=emergency.service
  • init=/bin/shfunktioniert einwandfrei, soweit ich das beurteilen kann, also liegt das Problem definitiv hier systemdund nicht dort selbst.switch_root
  • Das Ausführen von systemd von der Shell (über init=/bin/shund exec /usr/lib/systemd/systemd) stürzt auf die gleiche Weise ab, und das Ausführen systemd --system --test --log-level=debugscheint nicht allzu sehr auszuflippen. Das heißt, es wird ausgegeben, dass es weiß, dass es sich in einer Xen-Virtualisierung und in einem x86_64-System befindet, aber es wird insgesamt nicht mehr als etwa 5 Zeilen ausgegeben. Der Test schlägt dann fehl miteinige Fehlerhängt ironischerweise damit zusammen, dass systemd noch nicht läuft.

Ich hoffe wirklich (und fürchte mich ein bisschen), dass es einen einfachen Kernelparameter oder eine Xen Dom0-Option gibt, die ich übergeben muss, um das Problem zu beheben, aber ich wäre für alle Erkenntnisse oder Vorschläge dankbar.

Antwort1

Das Problem wurde in meinem Fall letztendlich gelöst, indem das no-efi-rsFlag (keine EFI-Laufzeitdienste) an die Xen-Bootoptionen in übergeben wurde xen.cfg.

Wenn Ihr Startvorgang bis zu diesem /sbin/initPunkt gelangen kann, finden Sie unten eine nützliche Konfiguration für Xen:

[global]
default=xen

[xen]
options=loglvl=all guest_loglvl=all conring_size=10M console_to_ring=true noreboot
kernel=vmlinuz-linux root=/dev/whatever rw init=/bin/sh log_buf_len=10M loglevel=9 
ramdisk=initramfs-linux.img

Sobald Sie in die Shell fallen, können Sie ausführen

# mount xenfs so that the next command actually works
mount -t xenfs xenfs /proc/xen
# display the Xen log, pipe it to a file if you want to save it for later
xl dmesg

verwandte Informationen