.png)
Ich habe eine Proxmox-Installation (v5.4, glaube ich) auf ZFS in einem Server mit 6 Festplatten. Es gibt 2 Pools: rpool in einem Spiegel von zwei SSDs, der das Proxmox-Root-Dateisystem und einige Container und Zvols enthält. Und die anderen 4 Festplatten befinden sich in einem anderen Pool (HDD) in raidz-1.
Vor zwei Monaten habe ich einige Optimierungsarbeiten an den ZFS-Parametern durchgeführt und diese dnodesize = autoin allen Pools aktiviert, einschließlich des rpool-Pools und der untergeordneten Pools. Jetzt habe ich den Server neu gestartet und die folgende Meldung hat mich begrüßt:
error: no such device: 40d7d14f38cc...
error: unknown filesystem
Entering rescue mode...
grub rescue>
Nach meinen Recherchen glaube ich, dass es mit dem dnodesizeParameter zusammenhängt (sieheHier,HierUndHier). Direktes Zitat aus dem ersten Link:
Eine Datei muss eine nicht veraltete Dnode-Größe (512 Byte) im Datensatz ausgelöst haben, was bedeutete, dass GRUB das Laufwerk nicht mehr lesen konnte.
Nun habe ich einige Ideen, wo ich anfangen könnte, aber auch viele Zweifel (ich bin ein nicht sehr erfahrener Admin), deshalb wollte ich zuerst Sie fragen, bevor ich in einer Sackgasse gerate und/oder definitiv etwas kaputt mache.
Zunächst könnte ich einen Live-USB mit einem ZFS-fähigen Betriebssystem erstellen. Die beste Option wäre wahrscheinlich, dasselbe 5.4 Proxmox ISO zu verwenden. Wäre es dann möglich, die alten Proxmox-Pools vom Live-USB zu laden und zu bearbeiten? Wie?
Das Problem ist, dass das nicht ausreicht, dnodesize = legacyda Änderungen nicht rückwirkend angewendet werden. Ich weiß also nicht genau, wie ich hier vorgehen soll. Die Optionen, die ich habe, sind jedoch die folgenden:
- Wenn es eine Möglichkeit gibt, festzustellen, welche Dateien das Standard-Dnode-Limit von 512 Byte überschreiten, schneiden Sie sie aus/verschieben Sie sie an einen anderen Ort und fügen Sie sie wieder ein/verschieben Sie sie zurück. Das Problem besteht hier darin, wie diese Dateien erkannt werden können.
- Schneiden Sie den gesamten Rpool-Inhalt auf eine externe Festplatte und fügen Sie ihn erneut in Rpool ein. Das Problem dabei ist, dass ich mich nicht sicher fühle, das Proxmox-Root-Dateisystem vorwärts und rückwärts zu verschieben und zu erwarten, dass es wieder funktioniert. Vielleicht mit
cp -a? - Es scheint, dass der einzige Inhalt, der von Grub gelesen werden muss, der Inhalt in /boot ist. Aber der /boot-Ordner befindet sich im rpool-Pool und ZFS-Pools sind nicht verkleinerbar. Ich kann also keinen der aktuellen Pools verkleinern, um einen neuen für den Bootvorgang zu erstellen, und ich kann dem Server keine zusätzliche Festplatte hinzufügen. Die einzige Möglichkeit wäre, /boot auf einen USB-Stick zu verschieben und Grub anzuweisen, dort zu suchen. Aber das scheint keine sehr robuste oder endgültige Lösung zu sein.
Irgendein Rat?
EDIT: Wie wäre es, grub2 durch einen ZFS-freundlicheren Bootloader zu ersetzen? Aus dem Proxmox-Wiki:
systemd-boot ist ein leichter EFI-Bootloader. Er liest die Kernel- und Initrd-Images direkt von der EFI Service Partition (ESP), auf der er installiert ist. Der Hauptvorteil des direkten Ladens des Kernels von der ESP besteht darin, dass die Treiber für den Zugriff auf den Speicher nicht neu implementiert werden müssen. Im Kontext von ZFS als Root-Dateisystem bedeutet dies, dass Sie alle optionalen Funktionen in Ihrem Root-Pool verwenden können, anstatt der Teilmenge, die auch in der ZFS-Implementierung in Grub vorhanden ist, oder einen separaten kleinen Boot-Pool erstellen zu müssen.
Tatsächlich scheint es so:
Proxmox VE verwendet derzeit einen von zwei Bootloadern, abhängig von der im Installationsprogramm ausgewählten Festplattenkonfiguration. Für EFI-Systeme, die mit ZFS als Root-Dateisystem installiert sind, wird systemd-boot verwendet. Alle anderen Bereitstellungen verwenden den Standard-Grub-Bootloader.
Ich weiß also nicht, warum es mit Grub statt mit systemd-boot installiert wurde. Ist es möglich, den Bootloader zu ersetzen, ohne etwas zu beschädigen?
Vielen Dank für Ihre Hilfe.