ZFS als root Fehlermeldung "can't work out which disk we are booting from..."

pbtraveller

Well-Known Member
Hallo zusamen,

ich bin gerade etwas am verzweifeln. Ich wollte meinen Home-Server von einem HP ProLiant MicroServer N36L auf einen HP ProLiant MicroServer G1610T (siehe http://www.hardwareluxx.de/communit...0t-i3-3240-e3-1220lv2-microserver-963207.html) umziehen.

Der eingebaute SATA Raid-Controller wird wohl von Freebsd nicht unterstützt und man kann auch nicht die Bootreihenfolge der devices an dem Controller festlegen (siehe unter "Man beachte:" in dem oben eingefügten Link). Da ich ohnehin mehr Platten anschließen will, habe ich also einen weiteren SATA Controller in den PCIe-Steckplatz eingebaut. Es handelt sich dabei um einen mit einem mit einem Marvell 9215 controller. Diesen habe ich im Bios als Controller ausgewählt, von dem gestartet werden soll. Den internen controller habe ich auf AHCI-Modus umgestellt.

Schließe ich meine bisherige SSD mit dem System an den neuen Controller an und baue sonst keine Platten ein, fährt der Server problemlos hoch. Baue ich weitere Festplatten mit meinem ZFS Daten-Pool in die dafür vorgesehenen Schächte ein (diese sind dann über den anderen Controller verbunden) und starte das System, komme ich nur bis zu der Fehlermeldung

can't work out which disk we are booting from...
Guessed BIO device 0xffffffff not found by probes, defaulting to disk0:..... ......
...

panic: Assertion failed: (FALSE), function ficlCompileSoftCore, file softcore.c, line 428 --> Press a key on the console to reboot <----​

Ich habe zu der Fehlermeldung nur diesen Eintrag hier gefunden: http://www.bsdforen.de/threads/cant-work-out-which-disk-we-are-booting-from.7475/. Der ist ja aber schon ziemlich alt und hat mir nicht geholfen.


Wenn ich die Platten und die SSD mit dem System in die "normalen Schächte" des Servers einbaue, die alle über den internen Controller angesteuert werden, so dass die SSD im Schacht 1 ist, der ja im AHCI Modus als erster gestartet werden soll (siehe obiger Link bei Hardwareluxx), bekomme ich die gleiche Fehlermeldung.

Hat jemand ne Idee? Ich würde ungern das "Gefriggel" über eine weitere Platte/USB-Stick mit Bootloader gehen, wie auf hardwareluxx beschrieben (wobei überhaupt die Frage ist, ob das hier helfen würde).

Das OS ist übrigen Freebsd 10.3

Vielen Dank und viele Grüße

pbtraveller
 
Bar jeder Kenntnis und mit ähnlichen Erfahrungen, würde ich mal eine leere Platte einsetzen und darauf einen frischen Install des FreeBSD 10.3 machen und schauen, ob er das Ding dann booten kann.
 
habe gerade noch mal ein paar Tests gemacht, mit folgenden Ergebnissen:

Was geht:
1) booten von einer zroot mit neu installiertem System ohne weitere platten
2) booten von der alten SSD mit zroot ohne weitere platten
3) booten von der neuen zroot oder SSD mit einem neu generierten pool auf einer zweiten Platte (also neuer Datenpool).

Was geht nicht:
a). booten von der dem neuen zroot oder der SSD, wenn die Platten des alten Datenpools im Server stecken, unabhängig davon, ob der alte Datenpool importiert ist oder nicht.

Muss ich jetzt wirklich die Daten des alten Datenpools auf andere Platten schaffen und den neu anlegen und vor allem warum? Hat jemand ne Idee?

Danke und Gruß

pbtraveller
 
Vermutlich ist es am einfachsten, einen neuen Pool anzulegen und die Daten zu übertragen. Die Inkonsistenzen würde ich am ehesten irgendwo im BIOS suchen oder halt in mangelnder Fehlertoleranz des ZFS bzw. BSD.
Vielleicht hilft Dir eine der Mailinglisten weiter.
 
Ich habe eine "default" Installation gemacht (auf der SSD vermutlich noch 9.3 und dann über die Zeit immer wieder ein upgrade). Der default loader ist doch bios, oder?

pbtraveller
 
Um diese Frage abschließen zu können und für den Fall, dass mal jemand ein ähnliche Problem hat: Habe jetzt sowohl den ZFS-pool mit den Daten, als auch den mit dem System (letzteren aus anderen Gründen) neu aufgesetzt. Der Loader ist definitiv BIOS, da die Kiste EFI nicht kann. Woran das Problem letztlich lag, kann ich nicht sagen. Als ich zwischenzeitlich mal einen anderen Pool importiert hatte und per zfs send und receive einige file systeme auf den bereits neu aufgesetzten pool überspielt. Danach hatte ich das gleich Problem. Der dirty workaround bestand letztlich darin, die Platten mit dem Datenpool aus dem Gehäuse rauszunehmen, die Kiste hochzufahren und dann während des Betriebs wieder reinzuschieben. Der Pool wurde daraufhin erkannt und eingebunden. Teilweise musste ich noch einen zpool import -f machen. Aber am Ende hat es immer funktiontiert...

Gruß

pbtraveller
 
Zurück
Oben