Boot environment von Hetzner Rescue-System aus ändern?

S

SolarCatcher

Well-Known Member
Hallo, nach Upgrade auf 14.3-RELEASE und Reboot kann ich meinen Server nicht mehr erreichen. Ich habe per Linux-Rescue-System ein Rollback von zroot/ROOT/default auf vor dem Upgrade gemacht. Aber das kommt auch nicht hoch (keine Änderungen in /var/log z.B.).

Muss ich irgendwo noch einstellen, was gebootet wird? Wo? Wie?
 
?Hast du mehr Informationen? Was kommt nicht? Was siehst du?
was erwartest du? Was passiert? Was passiert nicht?
 
Im Hetzner Robot wird der Server mit grünem Punkt gelistet (running). Ich kann ihn weder per ssh oder ping erreichen.

Wenn ich über das Linux-Rescue-System den pool zroot unter /mnt mount kann ich sehen, dass sich in /var/log nichts getan hat. Der Server scheint also gar nicht regulär hochzufahren.

Über das Rescue-System kann ich weder bectl noch beadm nutzen. Ich weiß nicht, wie/wo im System die Info hinterlegt wird, welcher Snapshot, welches Boot Environment gebootet wird. Vielleicht zeigt es auf das, dass ich per zfs rollback schon zerstört habe.
 
Gibt es keine Konsole, der du beim Booten zugucken kannst?
Fuer mich klingt das so, als wuerde ENTWEDER

1. der Bootloder nicht zu potte kommen
2. der Kernel die Root-Partition nicht finden
3. der Kernel beim Booten crashen

Deine Beschreibung schraenkt es somit noch nicht wirklich ein.
 
Standardmaßig nicht. Man kann den Anschluss einer KVM beauftragen, was ich dann wohl machen werde.

Aber ich hatte gehofft, der Zugriff auf den Zpool und das ZFS-Dateisystem würden vielleicht reichen, um das zu lösen. Ich glaube ja immer noch, dass mir nur die Info fehlt, wie/wo hinterlegt ist, was gebootet wird.
 
Du kannst das System auch via Qemu aus dem Rescue heraus booten und dann schauen, wo er haengt. Falls es kein Netzwerk bekommt, kannst Du das dann fixen. Wenigstens solltest Du die boot messages sehen und kannst evtl. daraus Rueckschluesse ziehen.

Bei mir habe ich das damals so gemacht:
Code: 
# apt update && apt install qemu-kvm
# qemu-system-x86_64 -m 4G -hda /dev/nvme0n1 -hdb /dev/nvme1n1 -curses

Mein System hatte 2 Platten im Raid, daher hda und hdb. Die genauen Plattendevices muesstest Du evtl. noch anpassen.
 
Zuletzt bearbeitet:
Danke für Eure Hilfe!

Am Ende hat es die KVM von Hetzner gebracht (qemu hätte das vermutlich auch gezeigt, aber da hatte ich die KVM schon laufen): Ich sah, dass irgendwas in /etc/fstab nicht gemountet werden konnte. Und danach lauter Fehlermeldungen wegen nicht gefundener Datasets.

Stellte sich raus, dass offenbar in 14.3 die Reihenfolge, in der Datasets gemounted werden, verändert ist. Ich hatte schon in /etc/fstab jahrelang folgendes drin stehen, um mit ports-mgmt/synth gebaute Packages auch in einer Jail zur Verfügung zu haben:
Code: 
/var/synth/live_packages /jails/web1/root/var/synth/live_packages      nullfs  ro,nosuid,noexec        0       0

Jetzt versuchte das System, das Dataset in die Jail zu mounten, bevor die überhaupt gemounted war. Dadurch brach anscheinend das Mounten aller nachfolgenden Datasets ab.

Ich hatte parallel einen anderen Server ge-upgraded und dort trat exakt dasselbe Problem auf (ich hatte hier nur einen erwähnt). Das Problem konnte ich dort dann ohne KVM - einfach durch das Auskommentieren der synth-bezogenen Zeile(n) - lösen.
 
Du kannst es mit der Option late mounten. In dem Fall wird erst gemountet, wenn alle lokalen und entfernten Dateisysteme ohne late-Option durch sind. Das müsste das Problem lösen.

Und für das Archiv noch die Ausgangsfrage: Das Boot Environment ist in der Pool Property bootfs hinterlegt. Zum Beispiel setzt zpool set bootsfs=tank/ROOT/14.2-RELEASE tank das Boot Environment des Pool tank auf das Dataset tank/ROOT/14.2-RELEASE.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben