ZFS-Boot-Problem "I/O error - can't read MOS"

defcon999

Member
Guten Tag,

ich hoffe, ich finde hier - als ZFS-Laie - die Lösung meines Problems:

Ich nutze die aktuelle Version von XigmaNAS auf einem HP Microserver Gen8. Es sind 2 Pools (1 x RaidZ1 und 1 x Stripe) eingerichtet. Nach dem letzten Update (möglicherwiese auch schon früher) ist mir aufgefallen, dass es beim Booten zu folgenden Fehlermeldung kommt:

I/O error - all block copies unavailable - can't read MOS pool home

Für den 2. Pool erscheint die selbe Fehlermeldung.

Das System lief zuvor problemlos auf einer SSD als RootOnZFS-System. Der Wechsel auf die "embedded"-Version mit Booten von einem USB-Stick brachte auch keine Änderung. Was mich wundert ist, dass die Fehlermeldung auch erscheint, wenn ich von einem frischen Live-USB-Stick boote.

Ich gehe davon aus, dass der fehlerhafte Bootcode auf den Platten der Pools gespeichert ist.

Beide Pools sind allerdings fehlerfrei "online" und "zpool status" zeigt keinerlei Fehler.

Ich hatte in einem anderen Thread hier gelesen, dass man mit

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0

den Bootcode neu schreiben soll.

Bei mir wären das die Platten ada0 bis ada4. Leider scheitert dies mit der Fehlermeldung "invalid arguments".

Nun bin ich natürlich mit meinem Latein am Ende :zitter:

Wie lautet denn der "richtige" Befehl, um den Bootcode auf den Platten neu zu schreiben?? Und was genau bedeutet eigentlich die Fehlermeldung?? Sind die Daten in den Pools in Gefahr??

Fragen über Fragen .....

defcon999
 
Einen wunderschönen guten Morgen. :)

Erst einmal vorweg: Wenn zpool status keine Fehler anzeigt, sind dort aller Wahrscheinlichkeit auch keine Fehler und deine Daten sind in besten Zustand. Kein Grund zu Sorge. Ein Backup sollte man natürlich immer haben, aber das ist ein anderes Thema.

Normalerweise würde ich bei der Fehlermeldung vermuten, dass das BIOS nicht alle Platten sieht. Das ist gerade bei älteren Systemen, die noch kein UEFI haben, oft ein Problem. Also als Beispiel hat der Pool 8 Platten, dass BIOS sieht aber nur 6. Daher fehlen dem Bootloader zwei Stück und er kann nicht booten. Das würde auch erklären, wieso es mit einer SSD als Root-Dateisystem ging, nun aber nicht mehr. Es erklärt aber nicht, wieso der USB-Stick nicht bootet. Und außerdem sind die HP Gen8 nun auch nicht sooo alt.

Die zweite Idee ist tatsächlich, dass die Pool mit zpool upgrade (eventuell durch die Automagie) aktualisiert wurden, aber der Bootcode nicht aktuell ist. Der alte Bootcode kann das neue Poolformat nicht lesen und das führt dann zu obskuren Fehlermeldungen. Auch da ist die Frage, wieso der USB-Stick nicht bootet, aber ich würde trotzdem einmal probieren, den Bootcode neuzuschreiben. Wie du es ja auch schon versuchst.

Dafür wäre es schön, einmal die komplette Ausgabe von gpart show zu sehen. Gerne auch als Foto. Denn daraus kann man ableiten, auf welche Devices und Partitionen der Bootcode muss. Und es ist sicherer als zu raten und womöglich Daten zu überschreiben...
 
Danke für die erste Rückmeldung!

Nur zur Erklärung und falls ich das falsch rübergebracht habe: Das System fährt absolut problemlos hoch!!

Aktuell von einem USB-Stick mit der "embedded"-version ... aber auch vom Live-USB-Stick gibt es kein Problem. Derzeit scheint es mehr ein "kosmetisches" Problem im Bootvorgang zu sein.

Die gpart show-Daten reiche ich gleich mal nach ...

defcon999
 

Anhänge

  • 20191010_092705.jpg
    20191010_092705.jpg
    747,2 KB · Aufrufe: 333
  • IMG_20191010_094638.jpg
    IMG_20191010_094638.jpg
    349,8 KB · Aufrufe: 346
Zuletzt bearbeitet:
Nur zur Erklärung und falls ich das falsch rübergebracht habe: Das System fährt absolut problemlos hoch!!
Achsooo... Ich dachte, er würde gar nicht starten. Die Bootloader können schon interessante Meldungen ausgeben. Diese kenne ich allerdings nicht.

Zum Bootcode: Du hast nur ein partitioniertes und damit bootbares Gerät, /dev/da0. Das ist der USB-Stick. Der Stick bootet im BIOS-Mode, erkennbar an der freebsd-boot Partition. UEFI-Boot hätte eine efi Partition. Die Boot-Partition hat Index 1, also ist es: gpart bootcode -p /boot/gptzfsboot -b /boot/pmbr -i 1 da0
 
Schreiben hat funktioniert... aber nun steht der Bootvorgang!!! :confused:

Der Hinweis auf "gptzfsboot" war vorher nie zu sehen.

Es stellt sich zudem die Frage, warum die Fehlermeldung auch bei einem Live-USB-Stick erscheint. Der "kennt" zu diesem Zeitpunkt die ZFS-Pools ja noch gar nicht.

Kann es nicht doch sein, dass die "fehlerhaften" Bootcodes in den Poolplatten stehen??!!

Der Pool 'home' wird ja nun gar nicht mehr erkannt; 'backup-1' aber schon ... :rolleyes:

defcon999
 

Anhänge

  • 20191010_105714.jpg
    20191010_105714.jpg
    144,6 KB · Aufrufe: 332
Zuletzt bearbeitet:
Kann es nicht doch sein, dass die "fehlerhaften" Bootcodes in den Poolplatten stehen??!!
Nein, definitiv nicht. Booten kannst du nur, wenn du Partitionen hast und du hast keine. :)

Also, das Kommando hat gemacht:
  • -b /boot/pmbr: Schreibt den Master Boot Record neu. Das Ding in /boot/pmbr liest die GPT ein, identifiziert die erste Partition vom Typ freebsd-boot, liest ihren Inhalt in den RAM und führt den aus. Damit das klappt, darf die freebsd-boot Partition nicht zu groß sein. Denn das BIOS kann ja nur 640 Kilobyte RAM ansprechen. Du bist da mit 512 Kilobyte schon am allerobersten Ende.
  • -p /boot/gptzfsboot: Schreibt den Inhalt der freebsd-boot Partition. Das ist die eigentliche Magie, die dir deine Probleme macht. gptzfsboot ist die Variante für GPT mit ZFS. Er liest alle GPT im System ein (genauer alle, die das BIOS sieht), sucht den ersten Pool und versucht den zu starten.
Und es hat auch geklappt, er lädt den Bootloader ja noch. Die Ausgabe sagt aber, dass etwas richtig böse schief geht. Sind das vielleicht 8TB Platten? Das würde all das Gekasper erklären. Denn die allermeisten BIOSe können nur booten, wenn die für den Boot notwendigen Daten innerhalb der ersten 2TB liegen... Darüber braucht es dann UEFI-Boot.
 
Sorry für die Unannehmlichkeiten und Danke, dass Du Dich so bemühst :)

Der Pool 'home' besteht aus 4 x 2 TB - WD-Red-Platten; Pool 'backup-1' aus einer 6-TB WD-Red ...

defcon999
 
Da der Stick ja nicht mehr bootete, habe ich das System über einen Live-USB-Stick gestartet ... die altbekannte Fehlermeldung kam wieder! Nun ist doch wirklich die Frage, wie dieser Fehler generiert wird, da ja auf den Pool-Platten offenkundig "nur" Daten und kein Bootcode ist ..... :rolleyes:

Die Konfiguration ist ja sehr schnell wieder hergestellt und ich werde wohl mit diesem ominösen Fehler leben müssen, der ja im laufenden Betrieb zu keinerlei Einschränkungen führt.

Verstehen tu' ich das allerdings nicht .....

defcon999
 

Anhänge

  • Zwischenablage01.jpg
    Zwischenablage01.jpg
    16,2 KB · Aufrufe: 244
Moin und willkommen! :)

Den Fehler habe ich auch noch nicht gesehen. Was mir bei einem der Screenshots auffällt: einmal kommt die Meldung und meckert den poolnamen 'zfs' an, den du anscheinend gar nicht hast. 'backup-1' aber schon.

Es kann sein, dass da was doppelt gemoppelt ist. Bevor wir irgendwas tun, eine Frage: hast du noch ein komplettes anderes Backup außer den Platten der screenshots?

Wenn man parallel zwei USB-Sticks (1x die live zum booten und den zweiten leeren zum embedded drauf installieren) stecken hat, verdrückt man sich ganz schnell, wenn man nicht aufmerksam hinschaut. Der Installer fragt erst den Quellstick ab, dann den Zielstick. Bin auch schon oft einfach drauf reingefallen.

Wenn du nun ein drittes Backup hast (u.a. auch eine exportierte config von xigmanas!), probier mal folgendes:
  1. die live-iso zum booten auf einen stick schreiben (hast du wohl schon)
  2. den zweiten Zielstick komplett sauber ausnullen (keine Esoterik, kann mir die Zickigkeiten mit xigmanas auch nicht immer erklären) -> dd if=/dev/zero of=/dev/da0 bs=2M status=progress
  3. alle Festplatten abzupfen, sodaß beim Booten nur die beiden Sticks verfügbar sind. Den Stick mit 'live' booten, installer starten, embedded auf zweiten Stick installieren. Wenn fertig, dann ersten Stick raus und du bootest mal blank die frische embedded vom zweiten Stick. (da sollte der Fehler zumindest mal gar nicht auftauchen)
  4. Wenn bis hierher alles cool, dann stöpsel nur die Festplatten von deinem Hauptpool und bootest danach die embedded neu. Checke hier erneut, ob der Fehler kommt.
  5. Wenn das sauber bootet, kannst du nun die Platten adden. Also das ganze Spektakel-> Festplatten Management-> +-> Vorformatiertes Dateisystem(!wichtig!)-> ZFS storage pool(!wichtig!)
  6. Dann Festplatten > ZFS > Konfiguration > Synchronisierung->Importiere Festplatten, die in der Konfiguration benutzt werden.
  7. Prüfe, ob der Pool korrekt importiert wurde und alle datasets da sind.
  8. Jetzt rebooten und nach dem Fehler Ausschau halten.
  9. Wenn bis hierher auch ok, dann backupplatte mit pool 'backup-1' ran und wie ab Punkt 5 damit verfahren.
 
@mr44er

Erst mal Danke für Deine ausführliche Antwort.

Du bist sehr aufmerksam .... "zfs" war ein alter Pool, den ich nach dem Fehler schon einmal komplett aufgelöst hatte und in "home" geändert habe. Der Screenshot ist schon etwas älter! Ich hatte die Hoffnung, dass durch die neue Installation des Pools der Fehler weg geht.

Zunächst war es aber auch so, aber nach dem letzten XigmaNAS-Update habe ich dann den Fehler durch Zufall wieder gesehen ... insofern kann ich den Zeitraum nur ungefähr eingrenzen.

Was die beiden Sticks angeht, ist mir genau das, was Du beschreibst, schon passiert ... bin fast wahnsinnig geworden, bis ich merkte, dass die erste Abfrage dem Quellstick gilt.

Insofern bin ich da vorgewarnt und inzwischen absolut sicher, da ich das schon häufiger gemacht habe. Ich werde mich jetzt mal an Deine Anleitung machen .... :D ... und berichten! Backups sind vorhanden.

Eine Verständnisfrage: Platten ausstöpseln ist verstanden ... soll ich die Pools vorher exportieren???

defcon999
 
Tja, was soll ich sagen ... das Booten vom frisch installierten (vorher ausgenullten) USB-Stick ohne Platten verläuft natürlich problemlos. Sowie ich 4 Platten vom Pool "home" anstöpsel und neu boote erscheint der Fehler! Der Pool ist dann noch gar nicht importiert ....

Ich bleibe dabei, auch, wenn ich keine Ahnung habe .... auf den Platten muss irgendwas stehen, was den Bootloader so aus dem Tritt bringt. Ich kann mit dem Fehler leben (was immer der auch bedeuten mag), so lange die Daten vorhanden (und sicher!!) sind und "zpool status" keinerlei Auffälligkeiten zeigt.

defcon999
 
Tut mir Leid, dass ich gestern nicht mehr geantwortet habe. Die Arbeit kam dazwischen... Also: Ich würde damit einfach leben. Spätestens wenn zpool scrub keine Fehler findet, wird der Pool in Ordnung sein. Egal was der Bootloader sagt. Auch wenn ich die Meldung immer noch seltsam finde.
 
Ja, denke ich auch... der Scrub ist problemlos über beide Pools drüber.

Im XigmaNAS-Forum gibt es ähnliche Fehlermeldungen zum Bootloader. Mochte nur mal wissen, welche "block copies" mit der Fehlermeldung gemeint sind.

Danke Dir und mr44er für die Bemühungen und die Hilfestellung. Ich habe wieder etwas dazu gelernt. :D

defcon999
 
Ich kann mir jetzt maximal noch zusammenreimen, dass du mal FreeNAS ausprobiert hast (evtl. in grauer Vorzeit?). FreeNAS hat oder hatte irgendwann die Funktion drin, sich selber auf einen pool verteilt zu installieren + die Restkapazität als Datenpool zu verwursten, sodaß die Kiste auch redundant booten kann. Daher könnten das die Metadaten davon sein, die xigmanas (als das noch nas4free hieß, erinnere ich mich an die Diskussion im Forum, ob man das Feature auch einbaut) anmeckert. Somit stimme ich dir zu, dass 'irgendwas' auf den Platten ist, aber ich würd' auch einfach damit leben oder wenn jetzt die regnerischen, trüben Tage kommen alle Platten ausnullen und das Backup neu draufschubbern... ;)
 
Ja, ZFS und GPT muss man sauber rauskratzen, dass die im Nachgang keine Probleme mehr machen....
 
Ich nutze XigmaNAS bzw. zuvor NAS4Free seit ca. 4 Jahren ... davor einmal ganz kurz FreeNAS, aber mit anderen Platten :cool:

Der aktuelle "Hauptpool" wurde komplett neu erstellt, allerdings nur nach "normalen Formatieren" in XigmaNAS ... am WE soll es es regnen! Das schreit förmlich nach einer Ausnull-Orgie :D:D

defcon999
 
ZFS kann sich mit zpool labelclear selbst rauskratzen. Aber das darf natürlich nicht auf einen Pool, den man noch braucht, losgelassen werden... Lacht nicht, hier im Forum hat das mal jemand gemacht. Gab Tränen.
 
Uhoh (ICQ-Sound)...naja, Versuch macht kluch. ;)

zpool labelclear haute in meinen Installationstestorgien nicht immer hin (komplett alles wegputzen, was ich mir darunter vorstelle). Mutmaßung: xigmanas kann hier Schneeflocke sein.
 
Ich habe zum Glück 2x 6 TB-Platten als (geprüfte) Backups ... insofern bin ich da guter Dinge :belehren: ... als ZFS-Dummie kannte ich diesen Befehl nicht :rolleyes: Irgendwie muss ich die Platten ja "sauber" bekommen :grumble:

defcon999
 
Sooooo ... letzte Mail zu diesem Problem: Stick neu erstellt; alle Platten entfernt ... NULL Problem.

Dann eine ganz alte Platte mit einem ZFS-Pool aus dem letzten Jahr angeschlossen... diese Platte war noch nie(!) an diesem NAS angeschlossen... und was soll ich sagen: ZFS I/O Error!! Der Pool ist problemlos zu importieren.

Der 12.0-Bootloader scheint ein massives Problem zu haben!!

Ich gebe es jetzt auf und werde mit diesem komischen (offenkundig kosmetischen) Boot-Error leben...

defcon999
 
Zurück
Oben