ZFS-Mirror bootet nicht.

pit234a

pit234a

Well-Known Member
Als ich meinen alten PC letztens mit FreeBSD 10.3 neu aufsetzte, entschied ich mich auch dazu, die beiden vorhandenen Platten zu einem ZFS-Mirror zusammen zu fassen. Die Platten hängen physikalisch an einem On-Board HW-Raid-Controller, dessen Funktion ich im Bios aber abgeschaltet habe, so dass mir die Platten nun einzeln und ganz "normal" erscheinen.
Das Anlegen des Pools habe ich dem Installer von FreeBSD überlassen, es gab dabei nichts, das mir irgendwie auffällig erschienen oder was holperig verlaufen wäre.
Das habe ich nun:
Code: 
pit@senyo ~:- > gpart show ada0
=>       34  312581741  ada0  GPT  (149G)
         34          6        - free -  (3.0K)
         40       1024     1  freebsd-boot  (512K)
       1064        984        - free -  (492K)
       2048  312578048     2  freebsd-zfs  (149G)
  312580096       1679        - free -  (840K)

pit@senyo ~:- > gpart show ada1
=>       34  312581741  ada1  GPT  (149G)
         34          6        - free -  (3.0K)
         40       1024     1  freebsd-boot  (512K)
       1064        984        - free -  (492K)
       2048  312578048     2  freebsd-zfs  (149G)
  312580096       1679        - free -  (840K)

pit@senyo ~:- > zpool status zroot
  pool: zroot
 state: ONLINE
  scan: none requested
config:

	NAME        STATE     READ WRITE CKSUM
	zroot       ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    ada0p2  ONLINE       0     0     0
	    ada1p2  ONLINE       0     0     0

errors: No known data errors
pit@senyo ~:- > zpool get bootfs
NAME   PROPERTY  VALUE               SOURCE
zroot  bootfs    zroot/ROOT/default  local
Im Bios kann ich eine der beiden Platten mit höherer Priorität fürs Booten eintragen, aber ich kann nicht eine einzige eintragen und die zweite löschen. Nach meinem Verständnis sollte das auch egal sein, von der ersten oder zweiten Platte sollte eben gebootet werden können.
Das tut es aber nicht.
Ohne Meldung bleibt der Bootvorgang mit einem blinkenden Cursor stehen.

Mein Workarround ist ein USB-Stick, auf dem ich mal ein BSD (ich glaube Dragonfly) drauf kopiert hatte und wo der alte FreeBSD Bootloader installiert ist. Der erkennt das installierte System neben jenem auf dem Stick und ich kann es dann zum Booten auswählen.

Das ist also nicht so ganz problematisch, aber doch ärgerlich, vor allem, weil ich glaube, dass ich da wohl etwas übersehe. Fehler, die man übersieht, treiben einen ja am ehesten zur Verzweiflung, vor allem, wenn alle anderen kein Problem dabei haben.
Möglicherweise könnte natürlich die HW verantwortlich sein und hier irgendwas vermurxen. Dann wäre das halt so und ich würde mit meinem Provisorium weiter machen.
Vielleicht hat aber jemand einen Tip oder Hinweis.
 
Vielleicht noch ein Nachtrag. Der erste Block, also der quasi-MBR in der GPT-Tabelle, der ist auf beiden Platten identisch und sieht so aus:
Code: 
00000000  fc 31 c0 8e c0 8e d8 8e  d0 bc 00 0e be 1a 7c bf  |.1............|.|
00000010  1a 06 b9 e6 01 f3 a4 e9  00 8a 80 fa 80 72 0b 8a  |.............r..|
00000020  36 75 04 80 c6 80 38 f2  72 02 b2 80 e8 c8 00 b6  |6u....8.r.......|
00000030  01 bb 00 0e be 88 07 e8  a3 00 66 81 3e 00 0e 45  |..........f.>..E|
00000040  46 49 20 75 0d 66 81 3e  04 0e 50 41 52 54 75 02  |FI u.f.>..PARTu.|
00000050  eb 19 80 fe 01 0f 85 b2  00 b6 00 be 10 12 bf 88  |................|
00000060  07 66 ff 0c b9 02 00 f3  a5 eb c6 be 48 0e bb 00  |.f..........H...|
00000070  10 e8 69 00 89 de bf 90  07 b1 10 f3 a6 75 3f 89  |..i..........u?.|
00000080  df 8d 75 20 bb c0 07 8e  c3 31 db 56 e8 4e 00 5e  |..u .....1.V.N.^|
00000090  66 8b 45 28 66 3b 04 75  0f 66 8b 45 2c 66 3b 44  |f.E(f;.u.f.E,f;D|
000000a0  04 75 05 8e c3 e9 58 75  66 ff 04 66 83 54 04 00  |.u....Xuf..f.T..|
000000b0  8c c0 83 c0 20 3d 00 90  73 4c 8e c0 eb cd 66 ff  |.... =..sL....f.|
000000c0  0e 50 0e 74 50 a1 54 0e  01 c3 81 fb 00 12 72 a4  |.P.tP.T.......r.|
000000d0  66 ff 06 48 0e 66 83 16  4c 0e 00 eb 8e 66 ff 74  |f..H.f..L....f.t|
000000e0  04 66 ff 34 06 53 6a 01  6a 10 89 e6 b8 00 42 cd  |.f.4.Sj.j.....B.|
000000f0  13 83 c4 10 72 1a c3 be  00 12 c7 04 1e 00 b8 00  |....r...........|
00000100  48 cd 13 72 0b c3 be 28  07 eb 16 be 3e 07 eb 11  |H..r...(....>...|
00000110  be 56 07 eb 0c be 74 07  eb 07 bb 07 00 b4 0e cd  |.V....t.........|
00000120  10 ac 84 c0 75 f4 eb fe  42 6f 6f 74 20 6c 6f 61  |....u...Boot loa|
00000130  64 65 72 20 74 6f 6f 20  6c 61 72 67 65 00 49 6e  |der too large.In|
00000140  76 61 6c 69 64 20 70 61  72 74 69 74 69 6f 6e 20  |valid partition |
00000150  74 61 62 6c 65 00 49 2f  4f 20 65 72 72 6f 72 20  |table.I/O error |
00000160  6c 6f 61 64 69 6e 67 20  62 6f 6f 74 20 6c 6f 61  |loading boot loa|
00000170  64 65 72 00 4d 69 73 73  69 6e 67 20 62 6f 6f 74  |der.Missing boot|
00000180  20 6c 6f 61 64 65 72 00  01 00 00 00 00 00 00 00  | loader.........|
00000190  9d 6b bd 83 41 7f dc 11  be 0b 00 15 60 b8 4f 0f  |.k..A.......`.O.|
000001a0  90 90 90 90 90 90 90 90  90 90 90 90 90 90 90 90  |................|
000001b0  90 90 90 90 90 90 90 90  00 00 00 00 00 00 00 00  |................|
000001c0  02 00 ee ff ff ff 01 00  00 00 af 9e a1 12 00 00  |................|
000001d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|
00000200
 
Du hast das System komplett neu und komplett über den Installer installiert? Also nichts von Hand partitioniert oder angepasst?
Das System zeigt dir direkt nach dem BIOS-Kram einen leeren Bildschirm mit Cursor, keine Fehlermeldung?
 
Dann muss ich passen... Ich kann nur noch stochern:
- Kann von dem Controller gebootet werden (grundsätzlich)?
- Bootreihenfolge irgendwas verdreht?
- Nicht supportete Geräte in der Bootreihenfolge?
- Ein Daten-Stick (ohen Bootcode) eingesteckt?
- Eine CD im Laufwerk?

Im übrigen ist es tatsächlich egal von welcher Platte du bootest. Kannst theoretisch mal diese mal jene nehmen. Es müssen nur beide mit Bootcode versehen sein und das bootable-flag haben. Das macht der Installer aber eigentlich beides.

Edit: Ist das eigentlich noch ein gutes altes BIOS oder ein EFI?
 
Rakor schrieb:
Ist das eigentlich noch ein gutes altes BIOS oder ein EFI?
Zum Vergrößern anklicken....

altes BIOS, aber ich würde es mal weniger gut nennen. Die Einstellmöglichkeiten sind zwar zahlreich, aber nicht an den Stellen, wo man das eigentlich mal haben möchte.

Vom Controller hatte ich immer gebootet, aber da hatte ich ihn auch als solchen genutzt und die beiden Platten von ihm zusammen schalten lassen. Seit dem ich diese Funktion angeschaltet habe, ist das mit dem ZFS nun mein erster Versuch. Kann also gut sein, dass das so gar nicht geht (wieso auch immer).
Alle anderen Punkte habe ich mehrfach geprüft und daran liegt es eindeutig nicht.
Der Bootcode sieht auch nicht unvernünftig aus, also es steht ja da zumindest etwas und so würde ich denn auch eine Fehlermeldung erwarten. Scheinbar ist es so, wie du ja schon vermutest. irgendwas (obwohl nichts vorhanden und im BIOS eingestellt) verhindert den Zugriff auf die Platten.

Mit der Starthilfe "externer USB-Stick" wird da etwas umgangen und es läuft.
 
Wenn Du GPT einsetzt, ist der MBR-Inhalt irrelevant (sog. Protective MBR).

Vielleicht hat es aus unbekannten Gründen den Bootcode auf den beiden freebsd-boot Partitionen beschädigt - immerhin kannst Du über den USB-Stick weiterhin booten.
Du kannst den aus dem laufenden System neu schreiben:

gpart bootcode -p /boot/pmbr -p /boot/gptzfsboot -i 1 ada0
gpart bootcode -p /boot/pmbr -p /boot/gptzfsboot -i 1 ada1

Gruß
 
vto schrieb:
Wenn Du GPT einsetzt, ist der MBR-Inhalt irrelevant
Zum Vergrößern anklicken....

Das glaube ich nicht.
Zwar ist es eine Weile her, seit ich mich da mal eingelesen hatte und ich nutze das ja auch nicht allzu oft, aber woher soll mein BIOS denn wissen, dass plötzlich GPT und nicht MBR an der Reihe ist? Der erste Block im GPT ist dieser Protective MBR und weil mein BIOS es nicht besser kennt, muss es diesen zum Booten auswerten und denkt, es sei ein normaler MBR. Deshalb muss der Bootcode hier stehen.

Das neu Schreiben mit /boot/gptzfsboot war mir noch zu viel Aufwand. Ich muss dazu ja auch das sichern, was ich nun habe und für den Fall der Fälle von einem Live-System aus zugänglich haben. So ist der Unterschied zwischen dem pmbr in /boot und dem auf meinen Platten exakt im Bereich der Partitionstabellen zu finden. Im pmbr auf /boot steht da nichts, bei mir steht da etwas und ich habe das nicht übersetzt, aber es wäre ja sicher verloren, wenn ich es überschreibe. Den weiteren Verlauf des GPT habe ich mir dann noch gar nicht angesehen, aber überschreiben macht natürlich erst Sinn, wenn etwas anderes drin steht, als was ich nun habe und das könnte unbeabsichtigte Folgen für mein laufendes System haben. In einem Schnellschuss sieht das jedenfalls auch sehr ähnlich aus, was ich auf der Platte habe und was von gptzfsboot kommen könnte.

Es ist natürlich kein riesiger Aufwand, das zu testen, aber es war mir bisher noch zu viel.

Aber danke für die Idee.
 
pit234a schrieb:
Zwar ist es eine Weile her, seit ich mich da mal eingelesen hatte und ich nutze das ja auch nicht allzu oft, aber woher soll mein BIOS denn wissen, dass plötzlich GPT und nicht MBR an der Reihe ist?
Zum Vergrößern anklicken....
Das ist der GPT-Hack. Das BIOS liest den veränderten und damit nicht mehr standardkonformen Protective MBR und der dann die GPT. Das kann bei einigen überkorrekten UEFIs Ärger machen, die den veränderten Protective MBR verweigern oder beim Erkennen einer GPT stumpf einen EFI-Boot probieren. Ganz besonders toll sind UEFIs, die sich bei USB-Sticks anderes als bei AHCI-Festplatten und SSDs verhalten. Wenn das System aber schon mal von einer GPT auf den SSDs gebootet hat, wird das eher nicht das Problem sein. Ich würde auch erstmal stumpf den Bootcode neuschreiben. Das tut nicht weh und schließt ihn aus.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben