Proxmox NVMe SSD bootet nach restore nur in einem System?

[sandreas]

Hallo zusammen,

ich weiß nicht so recht, ob der Thread hier in diese Kategorie passt. Ich nutze Proxmox mit ZFS auf einem Heimserver mit EINER SSD (ja ich weiß, Ausfallsicherheit brauche ich nicht). Nun ist mir letzte Woche meine SSD abgeraucht (Samsung 980 Pro). Hat nix mit Consumer-Hardware oder Wearout zu tun, die war einfach von Anfang an ein Montags-Gerät. Nun habe ich das System via zfs send über SSH wieder hergestellt - läuft auch alles einwandfrei.

Das Problem: Ich habe ein nahezu identisches Zweitsystem um Tests zu machen (gleiches Fujitsu D3417 Board, gleiche Xeon 1225v5 CPU, gleicher 64GB ECC RAM). Nehme ich nun die SSD nach dem restore aus dem Produktivsystem ins Test-System (oder umgekehrt), bootet es nicht. Die Daten sind noch drauf (über Recovery Live System getestet). Stecke ich nun nach dem Umbau die SSD wieder zurück ins Prod-System, bootet es auch nicht mehr!! Selbst nach dem Ausbau der SSD OHNE Umbau in ein anderes System und direktem Wiedereinbau (ohne zwischendrin Einzuschalten) habe ich dieses Phänomen manchmal - aber nicht immer.

Es funktioniert nur, wenn ich die SSD im Produktiv-System einbaue, Proxmox über einen Live-USB-Stick (Ventoy) dort installiere und das Backup dort einspiele. Die SSD muss die ganze Zeit drin bleiben.

Ursprünglich hatte ich es so gedacht, dass ich im Testsystem "rumspielen" kann und bei Bedarf einfach die SSD aus dem Testsystem ins Produktivsystem umbaue. Das klappt aber einfach nicht.

Es ist weder auf Test UND Prod im BIOS weder Secure-Boot oder HDD-Passwort oder irgend ein TPM aktiviert, von dem ich wüsste. Ich habs mit mehreren SSDs verschiedener Hersteller probiert (Samsung 980 Pro 256GB, WD SN850x, Kingston NVMe), überall das gleiche.

Kann mir jemand das erklären bzw. hab ich was nicht mitgekriegt?

 

[atze303]

Man muss Logical Volumes usw auf neuen system importieren lvm export lvm import,, ist bei ZFS denke nicht anders. zpool export. zpool mport.

Die Pool onfiguration wird in \etc gespeichert und sollte man nach änderungen exportieren und sichern.

Kenn Proxmox nicht diirekt., aber da kann man über die Gui die Pools bestimmt auch importieren.

 

[sandreas]

Man muss Logical Volumes usw auf neuen system importieren lvm export lvm import,, ist bei ZFS denke nicht anders. zpool export. zpool mport.

Vielen Dank für die Antwort... die Idee ist die richtige. Leider ist es so: Wenn der Pool nicht exportiert wurde, meldet der Proxmox-Bootloader das und schreibt sinngemäß: Konnte Pool nicht importieren
Anschließend kann ich mit einem Rescue-System den Pool exportieren, dann bootet er normal.

In meinem Fall ist der Ablauf aber so:

• Ich installiere Proxmox auf System A (ZFS, RAID0, nur eine NVMe, der zweite RAID0 "Slot" ist leer)
• Nach dem Neustart bootet System A einwandfrei
• Ich baue die NVMe von System A in System B ein und starte
• System B bootet nicht und zeigt auch keinen Fehler - es kommt schlicht nur "Fehlendes Bootmedium"
• Baue ich jetzt die Platte wieder zurück, bootet auch System A nicht mehr - auch ohne Fehler nur mit "Fehlendes Bootmedium"

Irgendwie scheint der Umbau den Bootloader kaputt zu machen - manchmal schon das aus- und wieder einbauen, was ja eigentlich nicht sein kann. Das habe ich mit "normalen" Platten / SSDs (mit oder ohne ZFS) noch nie erlebt und ich kann mir das nicht erklären.

 

[sandreas]

Also es gibt was neues... bzw. zumindest einen neuen Ansatz. Auf hackernews wurde kürzlich ein "Vanishing BIOS" auf Fujitsu Notebooks beschrieben, was aber in dem Artikel sehr interessante Informationen zu Tage gefördert hat.

• Hackernews: https://news.ycombinator.com/item?id=39070871
• Der Artikel: https://blog.timschumi.net/2024/01/20/ah532-bios-investigation.html

Da ich auch ein Fujitsu Board habe, kommt mir das so vor, als könnte es ein ähnliches Problem sein. Vielleicht versaubeutelt Proxmox die EFI-Booteinträge. Das würde auch erklären, wieso die Platte an sich noch lesbar ist, aber booten nicht mehr funktioniert und die Platte auch nicht mehr im Bootmenü auftaucht...

Es gibt auch noch das proxmox boot tool, um mit den bootmanagern rumzuspielen. Wie es scheint, ist der Boot wie folgt aufgebaut:

• a 1 MB BIOS Boot Partition (gdisk type EF02)
• a 512 MB EFI System Partition (ESP, gdisk type EF00)

Ein Backup davon könnte hilfreich sein, jedoch weiß ich nicht sicher, ob das Zurückspielen eines Images der ersten 513MB die nicht mehr bootbare Platte wieder zum Laufen gebracht hätte.
Als letztes noch dieser Artikel, den fand ich interessant, aber für ZFS wird diese Methode vielleicht nicht funktionieren.

 

[TimSchumi]

Also es gibt was neues... bzw. zumindest einen neuen Ansatz. Auf hackernews wurde kürzlich ein "Vanishing BIOS" auf Fujitsu Notebooks beschrieben, was aber in dem Artikel sehr interessante Informationen zu Tage gefördert hat.

• Hackernews: https://news.ycombinator.com/item?id=39070871
• Der Artikel: https://blog.timschumi.net/2024/01/20/ah532-bios-investigation.html

Da ich auch ein Fujitsu Board habe, kommt mir das so vor, als könnte es ein ähnliches Problem sein. Vielleicht versaubeutelt Proxmox die EFI-Booteinträge. Das würde auch erklären, wieso die Platte an sich noch lesbar ist, aber booten nicht mehr funktioniert und die Platte auch nicht mehr im Bootmenü auftaucht...

Hast du denn schonmal einen CMOS-Reset und/oder einen BIOS flash probiert? Das sollte eigentlich alles in der Richtung wieder temporär gerade biegen. Falls du irgendwo in ein laufendes Linux-System kommst gerne auch mal berichten ob ls -l /sys/firmware/efi/efivars/ irgendwelche Einträge auflistet. Wenn da keine sind, dann haben wir eventuell sogar schon einen Teil des Problems gefunden.

Das einzige was dagegen spricht ist dass das ja bei dir sehr instabil zu sein scheint. Die im Blog-Artikel beschriebenen Probleme sind deterministisch. Auch das Aus- und Einbauen sollte in diesem Fall keinen Einfluss haben, allenfalls wenn die Festplatte dann in irgendeinem anderen Server landet und die EFI-Einträge noch irgendwelche UUIDs gespeichert haben (die er dann natürlich nicht mehr findet).

Es gibt auch noch das proxmox boot tool, um mit den bootmanagern rumzuspielen. Wie es scheint, ist der Boot wie folgt aufgebaut:

• a 1 MB BIOS Boot Partition (gdisk type EF02)
• a 512 MB EFI System Partition (ESP, gdisk type EF00)

Ein Backup davon könnte hilfreich sein, jedoch weiß ich nicht sicher, ob das Zurückspielen eines Images der ersten 513MB die nicht mehr bootbare Platte wieder zum Laufen gebracht hätte.
Als letztes noch dieser Artikel, den fand ich interessant, aber für ZFS wird diese Methode vielleicht nicht funktionieren.

Auf diesen beiden Partitionen ist im Normalfall nichts was sich im normalen Betrieb verändert, allenfalls bei Updates.

 

[sandreas]

Hast du denn schonmal einen CMOS-Reset und/oder einen BIOS flash probiert?

Nee, da traue ich mich seit der Zickerei nicht ran, bis mein Backup-System vollständig läuft. Aber das werde ich auf jeden Fall mal machen, wenn ich alles aufgebaut habe.

Auf diesen beiden Partitionen ist im Normalfall nichts was sich im normalen Betrieb verändert, allenfalls bei Updates.

Ja... sobald ich alles am Laufen und meine 3-2-1 Backups wieder da liegen habe (ich hab beim Upgrade auf Proxmox 8.1 einiges umgestellt), verifiziere ich das Verhalten noch mal mit dem Testsystem.

Ich kanns mir nach wie vor nicht erklären. zfs-auto-snapshot kann auch nicht der Grund sein, die Platte hatte noch genügend freien Speicher.