FreeBSD 14.1 und 13.3 auf einem UEFI-PC

MichaZ

MichaZ

Well-Known Member
Hallo @all.

Hat jemand eine Idee, wie ich beiden FreeBSD-Versionen auf einem UEFI-PC ans laufen bringen kann?

Beide Systeme haben selbstverständlich eigene Festplatten.
Das Problem ist die EFI-Partition. Das nachträglich installierte 13.3 meinte, die EFI-Partition erstmal ganz frisch zu machen und nur sich dort zu dulden.
Ok, das war nicht schlimm, da nur Windoof und der Refind flöten gingen.

Wie bekomme ich das System dazu, einen anderen EFI-Ordner (z.B. freebsd14) zu akzeptieren?

Einfacher ginge es mit GhostBSD als Zweitsystem, aber wer geht schon gern den leichten Weg? ;)

Vielen Dank schon mal.

Gruß

Micha
 
Ein Weg der gehen würde wäre, den "Bootcode" gar nicht schreiben zu lassen und dies manuell zu tun.
Im Grunde muss ja nur die loader.efi in die EFI-Partition an die entsprechende Stelle. Und dann sagt man noch via efibootmgr Bescheid, das da ein weiteres System ist.
Wenn man mal so gucken will, was bsdinstall an der Stelle macht, kann man auch mal in das entsprechende Skript gucken: bsdinstall/scripts/bootconfig
 
Meine Erfahrungen mit EFI sind hier eher bescheiden. Die einzig funktionierende Loesung ist, Festplatte A einzubauen und Festplatte B auszubauen, dann FreeBSD (oder sonstiges OS) auf Festplatte A zu installieren. EFI wird dann auf Festplatte A installiert. Danach Festplatte A ausbauen und Festplatte B einbauen und das gleiche Spiel von vorne.
 
medV2 schrieb:
Spricht denn etwas gegen 2 EFI Partitionen?
Zum Vergrößern anklicken....
daran würde ich da auch erst mal denken und dann die Auswahl über das Bootmenü des BIOS. Das funktioniert ja auch bei externen Datenträgern so und sollte auch intern vollkommen problemlos funktionieren, wenn eine eigene Festplatte für ein weiteres System vorhanden ist. Das erspart einem dann auch den efibootmgr.
Also, ich habe das überhaupt nur einmal kurz versucht und dabei die Erfahrung mit einem einzigen Rechner und einem einzigen BIOS gemacht, dass ich das System auf der zweiten Platte nicht über efibootmgr einrichten konnte. Also über die Loader in der EFI auf der ersten Platte. Es schien mir zwar alles richtig eingetragen zu sein, aber das System der zweiten Platte wurde niemals gefunden. Das beschäftigte mich deshalb nur kurz, weil ich den Vorteil nicht sah, gegenüber der direkten Auswahl des Bootmediums aus dem BIOS-Startmenü, wie oben erwähnt.

Nebenbei: die root-pools sollten für die beiden Systeme unterschiedliche Namen haben und in der loader.conf benannt werden. afaik sucht nämlich ZFS auf allen vorhandenen Medien und wenn es dann mypool/ROOT/default auf der ersten Platte findet, wird es sich den greifen, wenn nicht ein anderer genannt wird.
 
Danke für eure zahlreichen Tipps.
2 EFI-Partitionen könnten funktionieren, dann müsste ich aber die 2. Installation manuell partitionieren, sonst greift die Installation wieder auf die 1. EFI zurück.
Vermutlich wäre ein Backup und Restore der EFI-Partition und das umbennenen eines freebsd-Ordners möglich.
Refind sollte das egal sein.

Danke für den Tipp mit den unterschiedlichen Namen der Pools. Das hatte ich unbewusst schon gemacht. Alternativ könnte man den Pools auch unterschiedliche Passwörter zuweisen.
 
Moin !

Ich habe hier mehrere System , die jeweils Ihre eigene Festplatte haben mit
dazu-gehörender FAT32-Bootpartition --> UEFI markiert !

Refind findet alle ohne Probleme !

Wenn du FreeBSD*.* bei der Installation die gesamte Platte zuweist , wird auch
auf dieser Platte die UEFI-Partition erstellt !

Gruss
 
Ich bekomme es nicht hin.
fbsd13 fragt bei der Installation, dass es mehrere Instanzen von freeBSD gibt und ob es bereinigt werden soll.
Trotz klick auf "nein", wird die primäre EFI-Partiion neu geschrieben, refind entfernt und der efiloader durch die neue Version ersetzt.
Und das alles, obwohl das zweite fBSD eine eigene EFI-Partition für sich anlegt.
Trotz unterschiedlicher Namen und Passwörter der Pools, will das 2. fBSD beide Passwörter.
Bekommt es nur sein eigenes Passwort, findet es keine bootbare Partition.
Das "alte" fBSD14 bootet erst, hängt dann aber irgendwo innerhalb des BSD-Logos.

Ich muss erst die neue Festplatte löschen (neue Partitionstabelle) und dann startet das "alte" fBSd wieder.

Ich versuche das auf dem alten PC ohne EFI, da kann ich wenigstens die einzelnen SATA-Ports im BIOS (de)aktivieren.

Danke an alle für eure Hilfe.
 
MichaZ schrieb:
refind
Zum Vergrößern anklicken....
du hattest das schon erwähnt und ich gestehe, dass ich das einfach ignoriert habe.
Also, refind, wieso?
Ich erinnere, dass ich vor gefühlten 50 Ewigkeiten mal auf einem MacBook refind benutzte, um irgendwas alternatives zu booten.
Seit Jahren können aber so ziemlich alle PCs direkt (U)EFI, zumindest, nachdem man das im BIOS aktiviert hat.

Also, nicht falsch verstehen.
Meine Gedanken sind einfach die: warum benutzt jemand refind und damit eine zusätzliche Fehlerquelle und kann man vielleicht das Problem vereinfachen, indem man das mal weg lässt?
 
Auch wenn ich zu deiner eigentlichen Frage leider keine Hilfe weiß, könnte meine Idee vielleicht trotzdem Abhilfe (eher Workaround) sein: Reicht es evtl. FreeBSD 13.3 in einer Jail laufen zu haben? Oder als bhyve-Instanz?
 
MichaZ schrieb:
Und das alles, obwohl das zweite fBSD eine eigene EFI-Partition für sich anlegt.
Trotz unterschiedlicher Namen und Passwörter der Pools, will das 2. fBSD beide Passwörter.
Bekommt es nur sein eigenes Passwort, findet es keine bootbare Partition.
Das "alte" fBSD14 bootet erst, hängt dann aber irgendwo innerhalb des BSD-Logos.
Zum Vergrößern anklicken....
Ich glaube, das Problem besteht in der Methode, wie der Loader arbeitet. Der durchsucht nämlich (soviel ich weiß) alle Platten/Pools, damit er Kernel usw. findet. Man müsste gucken, ob man dem irgendwie explizit sagen kann: Nutze Pool XYZ
Bin in dem Loader-Thema nicht so drin. Vielleicht kann jemand was dazu sagen, der sich auskennt.

pit234a schrieb:
warum benutzt jemand refind und damit eine zusätzliche Fehlerquelle
Zum Vergrößern anklicken....
Der wird in dem Fall vermutlich eher nicht das Problem sein, aber generell hast Du natürlich recht.
Mit UEFI ist so was wie ein Bootmanager eigentlich überflüssig geworden (bzw. in den Fällen, wo man einen braucht, weiß man i.d.R. auch warum).
Und dann würde ich den als potentielle Fehlerquelle auch eher weglassen.
 
pit234a schrieb:
Also, nicht falsch verstehen.
Meine Gedanken sind einfach die: warum benutzt jemand refind und damit eine zusätzliche Fehlerquelle und kann man vielleicht das Problem vereinfachen, indem man das mal weg lässt?
Zum Vergrößern anklicken....
Refind ist hier nicht das Problem.
Der wird eh bei der installation von freebsd 13 gekillt und somit werden die Starts über das UEFI-Bootmenü gearbeitet.

Refind nutze ich, weil damit das aufpassen unnötig wird, zur rechten Zeit die Taste fürs Bootmenü drücken zu müssen.
Columbo0815 schrieb:
Auch wenn ich zu deiner eigentlichen Frage leider keine Hilfe weiß, könnte meine Idee vielleicht trotzdem Abhilfe (eher Workaround) sein: Reicht es evtl. FreeBSD 13.3 in einer Jail laufen zu haben? Oder als bhyve-Instanz?
Zum Vergrößern anklicken....
Das 13er sollte auch mit Virtualbox arbeiten.
Das wäre dann Virtualisierung in der Virtualisierung, falls das überhaupt geht.
 
MichaZ schrieb:
Der wird eh bei der installation von freebsd 13 gekillt
Zum Vergrößern anklicken....
Ich habe Dir ja nahegelegt, das ggf. manuell zu machen.

MichaZ schrieb:
Das 13er sollte auch mit Virtualbox arbeiten.
Zum Vergrößern anklicken....
Jetzt verstehe ich gar nix mehr. Wenn das eh ein virtuelles System ist, dann besteht ja eh keine Notwendigkeit das auf eine "Platte" zu packen.

MichaZ schrieb:
Das wäre dann Virtualisierung in der Virtualisierung, falls das überhaupt geht.
Zum Vergrößern anklicken....
Das geht durchaus.
Die Frage ist halt wie sinnvoll das ist oder nicht ist.
Dazu müsste man aber wissen, was Du eigentlich konkret vor hast. Evtl. kann man dann auch alternative Wege aufzeigen.
 
Ich kenne mich mit dem FreeBSD Installer nicht aus aber mein loaderupdate Skript installiert normalerweise nach /EFI/FreeBSD und macht einen entsprechenden efibootmgr Eintrag.
 
Code: 
# efibootmgr
Boot to FW : false
BootCurrent: 0006
Timeout    : 1 seconds
BootOrder  : 0006, 0005, 0007, 0008, 0009, 000A
+Boot0006* UEFI OS
 Boot0005* UEFI OS
 Boot0007* UEFI: PXE IPv4 Intel(R) Ethernet Controller X550
Vielleicht kann das was helfen und wenn ich es erkläre. Die Ausgabe ist von meinem laufenden PC und um die noch folgenden PXE's verkürzt.
Ich habe zwei Platten zum Booten. Auf jeder Platte liegt eine EFI-Partition und auf jeder EFI ein identischer FreeBSD-Boot-Mechanismus. Die zweiten Partitionen der beiden Platten sind zu einem ZFS-Mirror verbunden. Es ist egal, von welcher der beiden Platten ich das System boote, also, im Falle eines Plattentodes, kann ich immer noch mit einer einzigen Platte das System booten.
Für die "gelegentlich notwendigen" Rettungsarbeiten, habe ich einen USB-Stick. Auch hier liegt eine EFI-Partition und dann folgt ein freeBSD. Beim Start des PCs kann ich diesen Stick als Medium auswählen und er wird dann auch gebootet und zwar komplett vom Stick. Auf dem Stick habe ich irgendwo eine Variable gesetzt, dass er mir nicht automatisch vorhandene Pools einbinden soll. Trotzdem achte ich darauf, stets die Pools auch wieder zu entfernen, bevor ich dieses System herunter fahre.
Keines der Systeme wurde mit dem bsdinstaller installiert. Verschlüsselung nutze ich dabei nicht.

Ohne nun den konkreten Fall durchgespielt zu haben und vor Allem auch, ohne zu wissen, wie da refind womöglich noch integriert werden muss, würde es mich wundern, wenn nicht auf ähnliche Weise recht einfach zwei unterschiedliche FreeBSDs auf unterschiedlichen Platten in einem PC benutzt werden könnten.

Aber bevor nun darauf eingegangen wird, wie man denn FreeBSD ohne den Installer auf eine Platte bringen kann oder wann man wie manuell eingreifen kann, ist sicher die Frage interessant, was denn überhaupt sein muss, wenn hier auch von der Möglichkeit der Virtualisierung gesprochen wird.
 
pit234a schrieb:
Auf dem Stick habe ich irgendwo eine Variable gesetzt, dass er mir nicht automatisch vorhandene Pools einbinden soll.
Zum Vergrößern anklicken....
da habe ich mich wahrscheinlich geirrt, falsch erinnert.
Als ich das schrieb, war mir so..., aber seither versuche ich vergeblich, diese "Variable" zu finden.

ZFS versucht ja, vorhandene Pools einzubinden und das kann für Chaos sorgen (und hat es bei mir schon manchmal), wenn dann zwei (ROOT-)Pools sich übereinander legen. Deshalb wünschte ich mir eine solche Funktion, nicht automatisch die vorhandenen Pools einzubinden und ich erinnere vom letzten Einsatz des Systems vom Stick, dass das auch tatsächlich befolgt wurde. Vermutlich aber, weil die System-Pools nicht exportiert wurden, nachdem das System geschrottet war (durch unglücklichen Update).
In meiner Einbildung habe ich das Verhalten aktiv verhindert, aber, wie gesagt, gerade kann ich derartiges Setting nicht nachvollziehen und finden.
 
Andy_m4 schrieb:
Wenn man ein zpool import oder ein zpool export macht, wird diese Datei entsprechend modifiziert.
Zum Vergrößern anklicken....
und weil mein System auf dem Stick ja ein Klon des laufenden Systems ist (und dann nur einige Änderungen zur Anpassungen erfahren hat), müsste es auch die gleiche /boot/zfs/zpool.cache haben.
Vielleicht war meine gesuchte "Variable" das Löschen dieser Datei auf dem USB-Stick?
Hört sich jedenfalls danach an und passt auch zu meiner Vorsicht, immer alle darauf importierte Pools auch wieder zu exportieren.
 
Da hatte ich soeben Veranlassung, nochmal einen Klon des laufenden Systems auf ein externes USB-Medium zu legen und damit habe ich dann das Booten des neuen Mediums getestet.
Es werden die Internen Pools automatisch eingebunden. Was schlecht ist, weil man dann doppelte Mounts bekommt. Kann das nicht wirklich gut beschreiben, aber es gibt ja auf beiden ROOT-Pools zB ein .../usr/home und dann wird sowohl Pool-1/usr/home als auch Pool-2/usr/home auf /usr/home eingebunden. Was nun genau passiert, hatte ich keine Nerven, zu testen. Nach dem üblichen Mount würde ja der zuletzt eingebundene Speicherplatz überlagern. Wie auch immer, dieses Verhalten wollte ich ja nicht.
Ein zpool export -f konnte das beseitigen und dann auch für die Zukunft merken. Also beim nächsten Boot wurde der exportierte Pool nicht mehr automatisch eingebunden.
Mit Verschlüsselung sieht das vielleicht wieder anders aus, weil da ja gar nicht so automatisch auf einen Pool zugegriffen werden kann. Aber immerhin ist es doch ein kleiner Hemmschuh für zwei FreeBSD-Systeme nebeneinander im gleichen Rechner, wenn alle Platten (Pools) beim Booten präsent sind. Man kann sich natürlich helfen, wenn man das Verhalten kennt und daran denkt. Die ZFS-Option canmount wirkt ja erst beim nächsten Boot und das wäre vielleicht besser gewesen, als meine Hazard-Nummer mit zwei Pools auf gleichen Mountpoints.

Die vermeintliche "Variable", die ich oben mal erwähnte, habe ich gefunden und das war ein kompletter Irrtum. Ich hatte auf dem ersten Live-System ein vfs.zfs.recover="1" gesetzt, aber wegen eines ganz anderen Problems und dies nun verwechselt oder falsch erinnert.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben