FreeBSD 13.x - Installation auf ZFS mirror, kein Boot von 2. Platte möglich

turrican

turrican

Well-Known Member
Hallo liebe Forenkollegen,

falls ihr 13.x auf nem mirror installiert:
Ich hatte heute nach Installation von 13.2 auf einem ZFS Mirror (UEFI System, zwei Platten, ada0 und ada1, im Installer "ZFS (auto)", "mirror" und "encryption" gewählt, Standard-Partitionsschema des Installers) festgestellt, dass das System nicht von der zweiten Platte booten kann.

Es werden sämtliche Partitionen korrekt angelegt (siehe Schema unten) und der zpool auf den jeweiligen 4. Partitionen funktioniert auch korrekt, allerdings wird die efi-Partition auf der zweiten Platte nicht beschrieben, die war bei meiner Installation leer - äußerte sich dann so, dass der Rechner gar keine Platte zum Booten sieht falls die erste nicht mehr vorhanden sein sollte (aber das ist vielleicht von UEFI zu UEFI Implementierung verschieden);

Partitionsschema wie vom Installer angelegt, beide Platten gleich:

Code: 
=>       40  488397088  ada0  GPT  (233G)

         40     409600     1  efi  (200M)

     409640       1024     2  freebsd-boot  (512K)

     410664        984        - free -  (492K)

     411648    4194304     3  freebsd-swap  (2.0G)

    4605952  483790848     4  freebsd-zfs  (231G)

  488396800        328        - free -  (164K)

Hab dann den Content manuell von ada0p1 auf ada1p1 kopiert, damit sieht der Rechner ab da die Platte als Bootplatte an, bootet ins OS, dieses stoppt jedoch ziemlich früh in eine Rettungs-Shell, da er die Datei /dev/gpt/efiboot0 nicht findet (es gibt zu dem Zeitpunkt nur ne Datei /dev/gpt/efiboot1) es scheint also noch was außer den fehlenden Loadern bei der Installation nicht richtig zu laufen, ich hab das nicht mehr tiefergehend getestet.

Code: 
Mounting local filesystems:mount_msdosfs: /dev/gpt/efiboot0: Invalid fstype: Invalid argument
Mounting /etc/fstab filesystems failed, will retry after root mount hold release
mount_msdosfs: /dev/gpt/efiboot0: Invalid fstype: Invalid argument
.
Mounting /etc/fstab filesystems failed, startup aborted
ERROR: ABORTING BOOT (sending SIGTERM to parent)!
<Date- and timestamp> - init 1 - - /bin/sh on /etc/rc terminated abnormally, going to single user mode
Enter full pathname of shell or RETURN for /bin/sh:

Bei 12.x gings noch (aktuell getestet, frische Installation von 12.4: klappt auch mit boot von ada1 ohne ada0, die Datei /dev/gpt/efiboot0 ist vorhanden, wenn von ada1 gebootet wird);
Es soll laut Internet auch mit 13 gehen, wenn man das System von ner 12er Version hochgehievt hat - das würde evtl. begründen, warum das noch niemandem so richtig aufgefallen ist.

Es gibt schon nen bugeintrag dazu, aber noch keine Lösung.
 
Ui, danke für die Warnung. Ich hab zwar schon 13.2 frisch installiert, allerdings nicht redundant in VMs.

Wär vllt. ganz gut, wenn du den part aus deiner /var/log/bsdinstall_log dort mit anhängst.
 
hätte mir gestern fast nen Account da angelegt, hab aber das install_log nicht gesichert
evtl kann ichs nochmal neu installieren, wenn mal Zeit is;
der bugreport is von Oktober 21, es scheint also eh keine Prio zu haben, das mal zu reparieren

Gemein is halt, dass nach außen hin nach Installation erstmal alles ok ausschaut;
man meint man hat eine funktionierende (boot-)Redundanz; aber dafür testet man es ja ^_^
 
turrican schrieb:
es scheint also noch was außer den fehlenden Loadern bei der Installation nicht richtig zu laufen, ich hab das nicht mehr tiefergehend getestet.
Zum Vergrößern anklicken....
Das Problem ist hier, dass die EFI-Partition seit 13.x (bei Nutzung von bsdinstall) permanent per fstab gemountet wird, wohl um den Loader einfacher aktualisieren zu können. Wenn nun z.B. die erste Platte rausfällt, kann die EFI-Partition nicht eingebunden werden und der Boot-Prozess bleibt dort hängen.

Dieser Mountpoint ist überflüssig.

Rob
 
Das ist das was Laurent in seinem BR beschreibt - müsste man im Fehlerfall also mittels Rettungsshell in der fstab auf der noch vorhandenen ada1 das auf den korrekten Wert (von ada1 andstatt ada0) abändern bzw gleich ganz rauswerfen?

Es war beim Hochfahren von ada1 (nach dem befüllen von ada1p1:/efi mit den Loadern aus ada0p1) wie gesagt ein /dev/gpt/efiboot1 anstatt ein /dev/gpt/efiboot0 im laufenden System vorhanden; die Namensgebung scheint von der aktuell bootenden Platte zu kommen? Die Disk wurde jedoch in diesem Fall als ada1 angezeigt, egal auf welchem Slot sie steckte.

Wenn ich das ganze unter 12.4 mache, wird auch die ursprüngliche ada1 als ada0 beim hochfahren angezeigt, egal ob sie auf dem Steckplatz von ada0 oder ada1 steckt, die Datei unter /dev/gpt heißt dann korrekterweise auch efiboot0 und der Bootvorgang klappt einwandfrei

EDIT: ersten Satz angepasst
 
Zusammenfassend kann ich aktuell sagen:

Es verhält sich so wie beschrieben, Problem tritt bei Update 12.4 -> 13.2 nicht auf, da bei 12.4 der EFI Content noch korrekt auch auf die 2. Platte geschrieben wird, ferner gibts da den störenden fstab-Eintrag zur EFI Partition nicht; dies alles wird beim Update 1:1 in die 13er Version übernommen;

Ein Boot-Environment mittels bectl hilft hier nicht, da sich das Geschehen außerhalb der zfs-mirror Partition abspielt.

Eine "defekte" 13er Direkt-Installation kann man wie oben beschrieben retten, indem man manuell den Content der p1 der ersten Platte auf p1 der zwoten Platte kopiert, und alle fstab-Einträge wie von @KobRheTilla vorgeschlagen dazu entfernt.

Falls jemand von euch nen bugzilla Account hat, könntet ihr obigen Eintrag ergänzen (und den Ruhm ernten).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben