GPT, ZFS, loader.efi und meine Nerven

Alexco

Well-Known Member
Ich habe hier auf meinem PC FreeBSD, Haiku und Linux parallel installiert. Jetzt ging mir so langsam der Platz aus und so dachte ich, ziehe ich das mal auf eine neue SSD mit 1TB um. Da ich gerade in Linux unterwegs war, habe ich schnell die neue SSD mit GParted partitioniert und schon mal das Linux-System und die EFI Partition rübergeschoben. Danach Haiku umgezogen und dann FreeBSD gebootet, neuen zpool erstellt, snapshot, zfs send/receive, bootfs setzen..... fertig.
Platte umgebaut und tadaaaaaaa... nur Haiku bootet.
Okay, bei Linux hatte ich diesen Grub Mist mit seinen diversen Configs vergessen, aber bei FreeBSD hat loader.efi schon gestreikt, keine root partition gefunden, lsdev zeigt nichts mit ZFS an, nur ein paar Partitionen. Auch konnte ich kurz nach dem Start sehen, dass loader.efi nur 3 Partitionen scannt, die anderen wurden ignoriert.
Das ganze Thema hat mich einen Tag gekostet, bis loader.efi zumindest wieder die Partion gestartet hat. Dann lief das System im Single-User bis zur Shell, im Multi-User gab es aber immer die Fehler:
Code:
no pools available to import
eval: zfs: not found
eval: touch: not found
/etc/rc: cannot create /dev/null: No such file or directory
/etc/rc: date: not found
mit anschließendem Hängen des Systems.

Das hat mich jetzt wieder einen weiteren Tag gekostet. Und das habe ich dabei gelernt:
  • loader.efi sucht nach einer Datei "loader.env", wo man ggfls. Variablen setzen kann(Link, hat mir allerdings nicht geholfen)
  • loader.efi wertet GPT Partitions-Attribute aus!! War mir völlig unbekannt und habe dazu auch noch nichts gefunden. MS hat für einfache Datenpartitionen ein paar Attribute definiert (MS Docs), u.a. den "bekommt keinen Laufwerksbuchstaben, also kein Automount". Warum auch immer hatte GParted das (und noch andere Attribute) gesetzt und somit wurde meine ZFS Partition von loader.efi ignoriert.
  • zoot darf keinen mountpoint haben. Keine Ahnung, ob das schon immer so war, oder warum das bei meinem neuen zpool so war, aber ein "zfs set mountpoint=none zroot" brachte dann endlich Abhilfe und das System startet wieder.

Eventuell kennt jemand noch so ein paar Dinge über loader.efi oder ZFS, die nicht ganz so offensichtlich sind?
 
Nein, mein Ehrgeiz war zu groß, ich wollte das System so wieder hinbekommen, ohne Neuinstallieren o.ä., was ja auch dann irgendwann geklappt hat :-).
Was versprichst Du Dir denn davon bzw. was würdest Du denn erwarten?
 
Meine Idee war, daß der Bios / UEFI Loader Einfluß auf den Start des OS hat. So wie ich dich verstehe wird BSD gestartet findet dann aber seine eigene Partition nicht.
 
Ja, richtig. Aber nur weil diese Attribute gesetzt waren, die wohl von loader.efi ausgewertet werden. Ich glaube, ich hätte dann aber einen anderen Bootloader installieren müssen, denn loader.efi wird ja beim Legacy/CSM nicht gebootet.
 
Beruhige deine Nerven! ;)


Was ich gemerkt habe, ist, dass FreeBSD bei der Installation ein Filesystem verwendet, welches Grub einfach nicht kann.
GAR KEIN PROBLEM! Die Loesung ist: FreeBSD NOCHMAL installieren, Komma, aaaber:
Vorher findest du die EFI-Partition, und machst unter Linux ein mkfs.vfat, oder newfs.dos, oder was die coolen Kids heutzutage so verwenden...

Danach benutzt der Installer von FreeBSD die naemlich so, wie die ist. (Es ist etwas fummelig, dass man beim Installieren nicht auswaehlen kann welches Filesystem die kriegen soll...)


Anschliessend machst du bei Schritt 7 von dem hier weiter:

Die EFI-Partition sollte dann auf einer VFAT-Partion liegen, die der Grub auch versteht.
 
Och Du, danke, mittlerweile bin ich wieder ganz entspannt, die Kiste läuft ja wieder. :)
Was mich halt so irritiert hat, ist, dass die Sache mit den GPT Attributen nirgendwo dokumentiert ist.
Als ich mir das mit den Attributen angesehen habe (und mit der alten Version verglichen habe), war das einfach ein Schuss ins Blaue, eine Tat der Verzweiflung...
 
Zurück
Oben