grub-probe error unknown filesystem

Olaf Müller

Active Member
Jul 10, 2017
2
0
41
53
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
 

Attachments

  • grub-probe.txt
    56.8 KB · Views: 13
Last edited:
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
 
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
 
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!
 
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
 
Klingt fein! bitte den Thread als 'SOLVED' markieren - es hilft Anderen in einer ähnlichen Situation.
Danke!
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!