Naja, du schriebst ja:
Daher dachte ich, dass die SSDs in einem USB3-Rahmen hängen würden. Was ja immer etwas wackelig ist.
Daher dachte ich, dass die SSDs in einem USB3-Rahmen hängen würden. Was ja immer etwas wackelig ist.
zfs-mirror reparieren
- Ersteller georg
- Erstellt am
So nun habe ich meinen Bootversuch/Neustart an dem Original-System hinter mir. Kurz gesagt es hat nicht geklappt, es gibt Probleme beim Booten, ich habe aber bereits gewisse Ideen, was das Problem ist:
Also beim Booten stoppt er irgendwann und bringt folgende Meldungen:
ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS of pool zroot
gptzfsboot: failed to mount default pool zroot
FreeBSD/X86 boot
---
procezor Register Informationen
Also beim Booten stoppt er irgendwann und bringt folgende Meldungen:
ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS of pool zroot
gptzfsboot: failed to mount default pool zroot
FreeBSD/X86 boot
---
procezor Register Informationen
Das mit den Mountpoints ist mir unklar, worauf willst Du hinaus?
Ich habe beim googeln einen Fall mit der selben Fehlermeldung "ZFS: can't read MOS of pool zroot" gefunden und dort wurde vorgeschlagen die boottcodes neu auf die Disk zu schreiben
(gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1 da0). Der Verdacht war wohl, dass das Pool format upgegradet wurde.
Ich habe beim googeln einen Fall mit der selben Fehlermeldung "ZFS: can't read MOS of pool zroot" gefunden und dort wurde vorgeschlagen die boottcodes neu auf die Disk zu schreiben
(gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1 da0). Der Verdacht war wohl, dass das Pool format upgegradet wurde.
Morgen.... vieles wurde ja schon gesagt.
Wenn Du einen I/O Error hast, dürfte das Problem nicht bem Pool sondern bei der SSD oder am USB liegen, sprich Hardware. Prinzipiell...lass Dir erst mal mit
zpool history
raus was Du auf dem Pool so alles "verbrochen" hast. Speicher Dir die zpool history in irgend einem Texteditor/Wiki/whatever ab.
Im nächsten Schritt würde ich die Platten/SSD's ersetzen und mal prüfen ob die USB Schnittstellen nicht doch einen Hau haben.
Spuckt das Syslog zum Thema "Hardware" was aus?
Wenn Du Die Ersatz Devices hast.... entweder mal eines der "neuen guten" Devices in den Pool aufnehmen, ja man kann Mehrwege Mirrors bauen...
.
Zum Thema zpool.cache:
Zpool Cache ist mittlerweile, weder auf Solaris noch auf FreeBSD ein Problem. Größere Schmerzen gab es höchstens im Solaris Cluster, wobei heir auch die Betonung auf "gab" liegt.
Wenn das alles nichts bringt, mit den neuen Devices einen neuen Pool aufbauen.... auf dem Alten Pool zfs snapshots anlegen....
Die Snapshots, mittels zfs send receive auf den neuen Pool migrieren.
Im übrigen ist es nicht schädlich sich mal die Sun/Oracle Doku zum Thema ZFS rein zu ziehen.
Dort gibt es zwar ein paar Unterschiede zu FreeBSD prinzipiell ist das aber immer noch die beste Quelle.
EDIT: Falls Du mal fest stellen möchtest wie resistent ZFS beim Thema ändern der Devicenamen ist, nimm ein paar USB Sticks... bau damit einen Zpool auf. Reiss alle Sticks raus misch sie queerbeet durch und steck die Sticks in zufälliger Reihenfolge wieder ein. Der Pool sollte genau so funkionieren wie vorher. :-)
Wenn Du einen I/O Error hast, dürfte das Problem nicht bem Pool sondern bei der SSD oder am USB liegen, sprich Hardware. Prinzipiell...lass Dir erst mal mit
zpool history
raus was Du auf dem Pool so alles "verbrochen" hast. Speicher Dir die zpool history in irgend einem Texteditor/Wiki/whatever ab.
Im nächsten Schritt würde ich die Platten/SSD's ersetzen und mal prüfen ob die USB Schnittstellen nicht doch einen Hau haben.
Spuckt das Syslog zum Thema "Hardware" was aus?
Wenn Du Die Ersatz Devices hast.... entweder mal eines der "neuen guten" Devices in den Pool aufnehmen, ja man kann Mehrwege Mirrors bauen...
.
Zum Thema zpool.cache:
Zpool Cache ist mittlerweile, weder auf Solaris noch auf FreeBSD ein Problem. Größere Schmerzen gab es höchstens im Solaris Cluster, wobei heir auch die Betonung auf "gab" liegt.
Wenn das alles nichts bringt, mit den neuen Devices einen neuen Pool aufbauen.... auf dem Alten Pool zfs snapshots anlegen....
Die Snapshots, mittels zfs send receive auf den neuen Pool migrieren.
Im übrigen ist es nicht schädlich sich mal die Sun/Oracle Doku zum Thema ZFS rein zu ziehen.
Dort gibt es zwar ein paar Unterschiede zu FreeBSD prinzipiell ist das aber immer noch die beste Quelle.
EDIT: Falls Du mal fest stellen möchtest wie resistent ZFS beim Thema ändern der Devicenamen ist, nimm ein paar USB Sticks... bau damit einen Zpool auf. Reiss alle Sticks raus misch sie queerbeet durch und steck die Sticks in zufälliger Reihenfolge wieder ein. Der Pool sollte genau so funkionieren wie vorher. :-)
Zuletzt bearbeitet:
Bevor ich auf die technischen Fragen/Probleme eingehe, noch kurz etwas persönliches, ich selber habe gesundheitliche Probleme, die gerade baehandelz werden, ausserdem legt meine Frau im Krankenhaus. Wenn ich also nur verzögert reagiere hier im Forum, dann ist das nicht, weil ich Eure Beiträge nicht schätze. Ich bitte Euch also verspätete Antworten zu entschuldigen.
@peterle, ich habe gedacht Du hättest konkrete Ideen bezüglich der Mountpoint setting im zpoool respektive auf den einzelnen zfs datasets. Wegen des zpool upgrades, Ich bin mir nicht sicher, wie ich damals das System aufgesetzt habe. Ich glaube, dass ich über ein mfsbsd die Disks vorbereitet habe (spart .. und schreiben der bootcodes). Ob es sich dabei um ein FreeBSD9 / Freebsd10 gehandelt hat weiss ich nicht, aber ziemlich sicher noch Pre-FreeBSD11. Nach Installation habe ich dann sicher auf FreeBSD11 hochgezogen und vermutlich auch ein zpool upgrade gemacht (werde ich noch versuchen herauszufinden). Was ich allerdings nicht verstehe ist, dass das System, damit ja problemlos gelaufen ist und auch gebootet ist. Die Probleme treten ja erst jetzt nach dem halb oder ganz aus dem USB-Slot gezogene Disk auf. Zuvor gab es beim Booten des Systems nie Probleme.
@solarix, ich bin mir nicht sicher one es wirklich am USB oder den SSDs liegt, bisher habe ich keinen Hinweis ergoogelt "ZFS: can't
read MOS of pool zroot" wird nicht in Zusammenhang gebracht mit USB/SSD Problemen.
Was ich gefunden habe, will ich mal kurz auflisten, vielleichtführt es ja zu Ideen was ich da tun kann, im Augenblick stehe ich vor einem Berg von Fragezeichen:
1) Problematik mit älteren Bootcode gegenüber einem upgegradeten zpool. Lösungsvorschläge waren gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1 da0/da1. Bei den ergoogelten Thread habe ich aber keinen "Status solide" gefunden.
2) Hinweis auf falsch gesetzte Mount options . Aber auch hier kein Hinweis auf einen "Status solved"
3) Hinweis das man einen boot-zpool "never exportieren soll" aber keine Lösung angegeben.
4) eine etwas seltsame "Lösung" des Problems, die ich aber nicht verstehen/nachvollziehen kann:
After upgrading it to 10.3-RELEASE, it wouldn't reboot with "zfs i/o error - all block copies unavailable".
Fix it by doing (using the live file system of a 10.3-RELEASE CDROM:
# mkdir /tmp/mnt
# zpool import -R /tmp/mnt -f zroot
# cd /tmp/mnt
# mv boot boot.orig
# mkdir boot
# cd boot.orig
# cp -Rp * /tmp/mnt/boot
# zpool export
# reboot
This is cool and all, but why did this happen in the first place? I followed normal procedure:
Soweit mal dazu. Wie gesagt ich stehe an, ich werde jetzt erstmal den zpool auf meinem Laptop unter alternative root, wie zuvor von Yamagi beschrieben, importieren und reinschauen was ich herausfinden kann (zpool history und ... ).
Wäre aber froh wenn von Euch Hinweise und Unterstützung käme. Vieleicht hat jemand ja diesen Fehler:
ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS of pool zroot
gptzfsboot: failed to mount default pool zroot
FreeBSD/X86 boot
schon gehabt und weiss was es mit dem "all block copies unavailable" und dem can't read MOS of pool zroot und dem Mount-Problem von gptzfsboot auf sich haben könnte.
@peterle, ich habe gedacht Du hättest konkrete Ideen bezüglich der Mountpoint setting im zpoool respektive auf den einzelnen zfs datasets. Wegen des zpool upgrades, Ich bin mir nicht sicher, wie ich damals das System aufgesetzt habe. Ich glaube, dass ich über ein mfsbsd die Disks vorbereitet habe (spart .. und schreiben der bootcodes). Ob es sich dabei um ein FreeBSD9 / Freebsd10 gehandelt hat weiss ich nicht, aber ziemlich sicher noch Pre-FreeBSD11. Nach Installation habe ich dann sicher auf FreeBSD11 hochgezogen und vermutlich auch ein zpool upgrade gemacht (werde ich noch versuchen herauszufinden). Was ich allerdings nicht verstehe ist, dass das System, damit ja problemlos gelaufen ist und auch gebootet ist. Die Probleme treten ja erst jetzt nach dem halb oder ganz aus dem USB-Slot gezogene Disk auf. Zuvor gab es beim Booten des Systems nie Probleme.
@solarix, ich bin mir nicht sicher one es wirklich am USB oder den SSDs liegt, bisher habe ich keinen Hinweis ergoogelt "ZFS: can't
read MOS of pool zroot" wird nicht in Zusammenhang gebracht mit USB/SSD Problemen.
Was ich gefunden habe, will ich mal kurz auflisten, vielleichtführt es ja zu Ideen was ich da tun kann, im Augenblick stehe ich vor einem Berg von Fragezeichen:
1) Problematik mit älteren Bootcode gegenüber einem upgegradeten zpool. Lösungsvorschläge waren gpart bootcode -b /tmp/zroot/boot/pmbr -p /tmp/zroot/boot/gptzfsboot -i 1 da0/da1. Bei den ergoogelten Thread habe ich aber keinen "Status solide" gefunden.
2) Hinweis auf falsch gesetzte Mount options . Aber auch hier kein Hinweis auf einen "Status solved"
3) Hinweis das man einen boot-zpool "never exportieren soll" aber keine Lösung angegeben.
4) eine etwas seltsame "Lösung" des Problems, die ich aber nicht verstehen/nachvollziehen kann:
After upgrading it to 10.3-RELEASE, it wouldn't reboot with "zfs i/o error - all block copies unavailable".
Fix it by doing (using the live file system of a 10.3-RELEASE CDROM:
# mkdir /tmp/mnt
# zpool import -R /tmp/mnt -f zroot
# cd /tmp/mnt
# mv boot boot.orig
# mkdir boot
# cd boot.orig
# cp -Rp * /tmp/mnt/boot
# zpool export
# reboot
This is cool and all, but why did this happen in the first place? I followed normal procedure:
Soweit mal dazu. Wie gesagt ich stehe an, ich werde jetzt erstmal den zpool auf meinem Laptop unter alternative root, wie zuvor von Yamagi beschrieben, importieren und reinschauen was ich herausfinden kann (zpool history und ... ).
Wäre aber froh wenn von Euch Hinweise und Unterstützung käme. Vieleicht hat jemand ja diesen Fehler:
ZFS: i/o error - all block copies unavailable
ZFS: can't read MOS of pool zroot
gptzfsboot: failed to mount default pool zroot
FreeBSD/X86 boot
schon gehabt und weiss was es mit dem "all block copies unavailable" und dem can't read MOS of pool zroot und dem Mount-Problem von gptzfsboot auf sich haben könnte.
Das heißt einfach, dass gptzfsboot den Pool nicht lesen kann. Das kann mehrere Ursachen haben:
- Die wahrscheinlichste Ursache ist, dass der Pool mit einem "zpool upgrade" auf eine neue Version aktualisiert wurde, der Bootcode aber nicht neugeschrieben wurde. ZFS sagt sogar, wenn ein neuer Bootcode notwendig ist, aber wer weiß was der Kunde da getrieben hat. In diesem Fall würde genau das helfen, einfach den Bootcode eines FreeBSD 11.1 reinschreiben und es geht wieder.
- Auf dem Pool werden Features genutzt, die der Bootloader nicht unterstützt. Das sind im Moment meines Wissens - ich bin da aber nicht ganz auf Stand - das "large_blocks" Feature und "sha512", sowie "skein" Checksums. Die hätten aber explizit eingeschaltet werden müssen. In dem Fall hilft es nur einen neuen Pool zu erstellen und die Daten zu übertragen.
- Der Bootloader kommt durcheinander und versucht vom falschen Pool zu starten. Das kann vorkommen, da die Möglichkeiten des BIOS Devices aufzulisten leider sehr beschränkt sind. Die Logik ist recht einfach: gptzfsboot nimmt den ersten Pool auf der Platte, von der er selbst geladen wurde. Das geht schief, wenn das BIOS die falsche Platte kommunziert. Da es bisher ging, wird das aber kaum das Problem sein.
peterle
Forenkasper
Nein, ich hatte nur mal flott gegooglet und mir war das mehrfach begegnet.
Ich habe mehrere Server bei einem großen Hoster stehen, die laufen alle mit zwei HDs als zfs mirror. Nun gehen die Platten immer wieder mal kaputt - weil ist ja günstig und mittlerweile auch schon schlappe 8 Jahre oder so alt - und dann und wann gibt es beim booten mal Schwierigkeiten.
Zum einen habe ich für die ganz harten Fälle einen AMANDA Backupserver laufen, der alle wichtigen Dateien beieinander hält und zum anderen hat bis jetzt immer eine überlebende Platte mit mountbarem zpool überlebt.
Neue Platte rein -> neuen zpool drauf -> neue Installation des OS - > alte Platten einhängen und Daten rüberschieben -> alte Platte neu partitionieren und den neu erstellten zpool auf einen mirror erweitern.
Damit bin ich meist schneller, als mit dem ganzen rumgestocher im Nebel und verzweifelten Versuchen, während die Kiste tot ist.
@Yamagi
zu 1) ich vermute, dass Dein 1 Punkt zutrifft, kann mir aber nicht vorstellen, dass meine Kunden einen zpool upgrade gemacht haben. Das habe ich wohl selber verbockt, das interessante ist aber dass die Maschine damit die längste Zeit gelaufen ist, und die ist auch damit gebootet worden. Das Problem trat erst jetzt nach dem Vorfall mit der herausgezogenen Disk auf. Ich werde auf jedenfall mal versuchen, neue bootcodes auf beide Platten zu schreiben. Zuerst versuche ich es mit den Bootcodes, die auf dem betroffenen zpool in ..../zroot/boot/pmbr und gptzfsboot liegen. Die müssten ja versionsmässig mit dem zpool verträglich sein.
zu 2: Ich glaube kaum, dass irgendwelche speziellen Features eingeschaltet wurden ( weder von mir - die müssten dann auch schon seit langem aktiv sein, noch von meinen Kunden, bei denen fehlt schlicht das Know How , die kommen sicher nicht auf die Idee irgendwelche Features auf zfs/zpool einzustellen), aber ich schaue mir auf jedem Fall den pool auf meinem Laptop an und suche gezielt nach solchen Features.
zu 3: Da ist nur ein Pool, so das ich mich deiner Meinung dass das kaum das Problem ist, anschliesse.
So jetzt starte ich erstmal meine Untersuchungen auf dem Laptop und schreibe dann die Bootcodes neu.
zu 1) ich vermute, dass Dein 1 Punkt zutrifft, kann mir aber nicht vorstellen, dass meine Kunden einen zpool upgrade gemacht haben. Das habe ich wohl selber verbockt, das interessante ist aber dass die Maschine damit die längste Zeit gelaufen ist, und die ist auch damit gebootet worden. Das Problem trat erst jetzt nach dem Vorfall mit der herausgezogenen Disk auf. Ich werde auf jedenfall mal versuchen, neue bootcodes auf beide Platten zu schreiben. Zuerst versuche ich es mit den Bootcodes, die auf dem betroffenen zpool in ..../zroot/boot/pmbr und gptzfsboot liegen. Die müssten ja versionsmässig mit dem zpool verträglich sein.
zu 2: Ich glaube kaum, dass irgendwelche speziellen Features eingeschaltet wurden ( weder von mir - die müssten dann auch schon seit langem aktiv sein, noch von meinen Kunden, bei denen fehlt schlicht das Know How , die kommen sicher nicht auf die Idee irgendwelche Features auf zfs/zpool einzustellen), aber ich schaue mir auf jedem Fall den pool auf meinem Laptop an und suche gezielt nach solchen Features.
zu 3: Da ist nur ein Pool, so das ich mich deiner Meinung dass das kaum das Problem ist, anschliesse.
So jetzt starte ich erstmal meine Untersuchungen auf dem Laptop und schreibe dann die Bootcodes neu.
pit234a
Well-Known Member
schaden wird das ja in keinem Fall.
Bei meinem Umzug letztens von SAS auf SSD (einen Mirror aus drei SSDs), hatte ich dieses merkwürdige Verhalten allerdings auch. Nur eine der vorbereiteten SSDs boote korrekt, die beiden anderen brachten Fehler, die aber anders als deine waren. Nachdem ich hier dann den Bootcode nochmal neu geschrieben hatte, funktionierten alle drei als Bootmedium, was ich dann manuell jeweils getestet habe.
Was ich dabei falsch gemacht haben könnte, ist mir schleierhaft. Ich wendete ja den gleichen Befehl für alle Platten an und änderte jeweils nur das Ziel. Und der zweite Versuch war identisch zum ersten Versuch und hatte dann Erfolg.
Ebenfalls einen ähnlichen Fehler verursachte es, dass ich vfs.root.mountfrom in der loader.conf gezielt auf meinen Pool gesetzt habe (das will ich so) und dann natürlich zunächst vergessen hatte, den Namen des neuen Pools dort auch zu setzen. Der alte konnte dann nicht mehr auf dem Device gefunden werden. Das war dann irgendein mountroot Fehler, glaube ich.
Hat nicht so viel mit deinem Szenarium zu tun, aber manchmal helfen auch solche Geschichten dabei, einen neuen Ansatz zu sehen.
so, habe die beiden Disks wieder an meinem Laptop und den Pool wieder importiert und die Bootcodes neu geschrieben. Ausserdem habe ich die Features auf dem Pool angesehen. Das Feature large_blocks ist enabled. Ich bin mir aber einigermassen sicher, dass ich das Feature damals nicht explizit gesetzt habe. Wo kann ich herausfinden welche Features der bootcode momentan unterstützt?
Und es tauchen natürlich die gleichen Fragen auf wie zuvor, wieso hat das booten bisher (mindestens über ein Jahr hinweg, wobei sooft wird die Maschine ja nicht gebootet) funktioniert, und das Problem erst auftritt, seit dem unglücklichen Herausziehen einer Disk aus ihrem USB-Slot.
Und es tauchen natürlich die gleichen Fragen auf wie zuvor, wieso hat das booten bisher (mindestens über ein Jahr hinweg, wobei sooft wird die Maschine ja nicht gebootet) funktioniert, und das Problem erst auftritt, seit dem unglücklichen Herausziehen einer Disk aus ihrem USB-Slot.