grub-probe error unknown filesystem

[Olaf Müller]

Hi,

dafür habe ich 4 Tage benötigt und verschiedene Testszenarien, bin mir mit dem Ergebnis aber nun sehr sicher. Sobald ein Node damit beginnt, Linux Container und VMs auf einen anderen Node zu replizieren, zerstört er die Grub Config des anderen Nodes, so dass dieser beim nächsten Reboot im 'grub rescue' mit der Fehlermeldung 'unknown filesystem' hängen bleibt. Die Daten selbst sind noch erreichbar, per Live-CD und 'zpool import'.

Umgebung:

• 3 Node Cluster
• 2 Nodes mit RAIDZ-1 und ein Node mit Ext4
• repliziert (HA) wird natürlich zwischen den beiden Nodes mit RAIDZ-1
• pve-manager/5.3-11/d4907f84 (running kernel: 4.15.18-10-pve)

Nachdem ein Node nach Updates und Reboot im 'grub rescue' hing, habe ich angefangen zu debuggen:

• Node aus dem Cluster genommen
• Node komplett neu aufgesetzt, Updates eingespielt und wieder in den Cluster genommen
• Node mehrfach rebootet
• 'grub-probe /' zeigt 'zfs' an, also alles gut
• Nun startet Replikation in Richtung des neuen Nodes und 'grub-probe /' zeigt 'unknown filesystem', d.h. der neue Node wird nicht mehr booten

Getestet habe ich mit

• RAIDZ-1 und ZFS RAID-1 auf dem neuen Node
• zuerst alles aktuell, bei späteren Installationen dann mit Paketen (von ISO 5.2.1) auf 'hold', ich hatte erst zfs-initramfs, dann Kernel und dann Grub in Verdacht
  grub-common hold
  grub-efi-amd64-bin hold
  grub-efi-ia32-bin hold
  grub-pc hold
  grub-pc-bin hold
  grub2-common hold
  libzfs2linux hold
  pve-firmware hold
  pve-kernel-4.15 hold
  pve-kernel-4.15.18-10-pve hold
  zfs-initramfs hold
  zfsutils-linux hold
  
  
• 'zpool scrub rpool' ist mehrfach gelaufen
• mit SSDs im RAIDZ-1 und ZFS RAID-1 und dann noch einmal alles mit HDDs

Am zweiten Node mit RAIDZ-1 habe ich nichts verändert. Der läuft durch (toitoitoi) und ist mit den Paketen auf dem aktuellen Stand. Er zeigt ebenfalls bei 'grub-probe /' den Fehler 'unknown filesystem' an. D.h. sobald ich den booten werde, wird der Host hängen bleiben. Ursprünglich haben beide Nodes jeweils ihre LXCs und VMs auf den jeweils anderen Node repliziert.

Beim ersten Node habe ich versucht, die Grub Config zu retten. Reinstall Pakete, danach Pool Import unter Live-CD und Chroot und etc. Hat aber leider nicht funktioniert.

Das alles ist schon ziemlich merkwürdig, aber da hier zwei Nodes betroffen sind und einer davon mehrfach neu aufgesetzt wurde, ist meiner Meinung nach was bzgl. der Replikation in den Proxmox Paketen kaputt.
Ich hoffe gerade auf aktuellere Pakete.

Eventuell hat jemand ein ähnliches Problem?


Danke euch und Gruß
Olaf

 

[dcsapak]

grub-core/fs/zfs/zfs.c:2112: zap: name = org.zfsonlinux:large_dnode, value = 14, cd = 0

es scheint als wäre large_dnodes aktiviert, damit kann grub leider nicht umgehen
(siehe https://github.com/zfsonlinux/zfs/wiki/Debian-Stretch-Root-on-ZFS#step-2-disk-formatting und http://savannah.gnu.org/bugs/?func=detailitem&item_id=48885 )

wahrscheinlich ist es am source pool aktiviert und die replizierung sorgt dafür dass es auch am ziel node aktiviert wird[/quote]

 

[Olaf Müller]

Hi Dominik,

vielen Dank für Deine Erklärung. Es ist tatsächlich aktiviert, auf beiden Nodes.

# zpool get all | grep large_dnode
rpool feature@large_dnode active local


Ich habe letztes Wochenende folgendes für meine Pools nutzen wollen. Den Hinweis hatte ich von der Proxmox Wiki Seite "ZFS: Tips and Tricks" (pve.proxmox.com/wiki/ZFS:_Tips_and_Tricks). Inzwischen ist der Eintrag von der Seite verschwunden, aber im Google Cache kann man sich die Version der Seite mit dem folgenden Text noch anzeigen lassen.


"LXC with ACL on ZFS

ZFS uses as default store for ACL hidden files on filesystem. This reduces performance enormously and with several thousand files a system can feel unresponsive. Storing the xattr in the inode will revoke this performance issue.

Modification to do

zfs set xattr=sa dnodesize=auto rpool"


Ich denke dnodesize=auto war dann der Auslöser.

Freue mich riesig über Deine Antwort, denn so richtig erklären konnte ich mir das ganze nicht.


Danke Dir und Gruß
Olaf

 

[docbobo]

Hallo,

ich bin gerade wohl in das gleiche Problem gelaufen. Proxmox bootet nicht mehr und landen immer im "grub rescue", sowohl grub-probe als auch grub-install liefern ein "Unknown filesystem". Hinzu kommt, dass large_dnode active ist.

Kann man large_dnode wieder deaktivieren? Oder was ist die beste Möglichkeit, um das System wieder booten zu können?

Danke
Boris

 

[Stoiko Ivanov]

Kann man large_dnode wieder deaktivieren? Oder was ist die beste Möglichkeit, um das System wieder booten zu können?

* large dnode deaktivieren geht auf dem bestehenden dataset, bei dem es aktiv ist nicht mehr:
** neues dataset anlegen (zfs create) bei dem das 'dnode' setting auf 'legacy' ist und die daten mittels zfs send/recv (oder rsync rüberspielen)
* je nach dem wann und wie das system aufgesetzt wurde (seit der PVE 5.3 (oder 5.4) ISO wird per default eine 512MB ESP angelegt (/dev/sda2) - falls diese vorhanden ist (oder eine andere partition mit mindestens ~500 MB) und das system mit UEFI booten kann besteht auch die Möglichkeit über systemd-boot direkt von der ESP zu booten - siehe https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysboot

Ich hoffe das hilft!

 

[docbobo]

Ja, ich hab es mit etwas basteln hinbekommen. Hatte zwar die EFI Partitionen, allerdings in einem unbekannten Dateisystem. Hab das allerdings aufgesetzt bekommen und boote jetzt per EFI.

Danke
Boris

 

[Stoiko Ivanov]

Klingt fein! bitte den Thread als 'SOLVED' markieren - es hilft Anderen in einer ähnlichen Situation.
Danke!