FreeBSD Boot über UEFI - wie geht der Eintrag in die EFI Partition richtig?

serie300

Well-Known Member
Hallo

habe auf einem Laptop mit UEFI FreeBSD 12 parallel zu Win installiert. Der FreeBSD Installer hat eine 2. efi Partition und die freeBSD Partitionen (GPD) angelegt. Gebootet hat der Rechner aber nur Redmond. Mangels besserer Einfälle habe ich dann bootx64.efi in der efi/boot Partition durch das bootx64.efi aus der von FreeBSD angelegten Partition ersetzt. Bei Boot von Harddisk (im Bootmenu Einträge: Win, Harddisk, USB) hat der Rechner dann FreeBSD gebootet :-)

Aber so ganz sauber ist das glaube ich nicht, was ich da gemacht habe. Weiß jemand wie ein EFI Verzeichnisbaum aussehen muß damit mehre BS im Bootmenu angezeigt werden (das Win wird ja angezeit und es hat eine Partition)?

Achja falls jemand Bedenken hat - FreeBSD kommt mit aktueller HW (Skylake, kein USB2 mehr) anscheinend problemlos zurecht (GraKa habe ich noch nicht ausprobiert).

Serie300
 
FreeBSDs UEFI-Support ist inzwischen schon ganz gut geworden, allerdings gibt es in 11.1 noch 3 Einschränkungen
  • Der UEFI-Loader kann keine GELI-Provider öffnen.
  • Das Multiboot-Protokoll wird nicht unterstützt.
  • FreeBSD kann nicht in den NVRAM schreiben.
Punkt 1 und 2 sind für die meisten Nutzer völlig egal, Punkt 3 leider nicht. Spätestens mit 12.0 werden voraussichtlich alle 3 Punkt behoben sein, bis dahin kommt man aber nicht drum herum sich mit etwas Improvisation zu helfen. Und nun zum Thema. :)

Das der Installer eine eigene EVI-Partition angelegt hat, ergibt sich auf Punkt 3. Da FreeBSD nicht in den NVRAM schreiben kann, muss der Loader im Standardpfad liegen, was eine eigene EFI-Partition erzwingt. Da können wir aber manuell drum herum frickeln. Dazu kopiert du die bootx64.efi auf die erste, vorher schon vorhandene UEFI-Partition. Zum Beispiel nach EFI/FreeBSD/FreeBSD.efi. Anschließend bootest du ein Linux vom USB-Stick, was das "efibootmgr" Tool mitbringt. Ich empfehle das Arch Linux Installationsimage, weil es dich einfach in eine flache, nicht irgendwie überzüchtete Shell wirft und auch noch einigermaßen ertragbar klein ist. Dort regierstrierst du dann mit efibootmgr den FreeBSD-Loader. Eine gute Anleitung inkl Beispiel findest du hier: https://wiki.ubuntuusers.de/efibootmgr/ Behalte dabei im Hinterkopf, dass UEFI tatsächlich Windows-Konvetionen folgt. Also die Pfade mit Backslashes (müssen auf der Unix-Shell escaped werden) erwartet und case-insensitive ist.

Achja falls jemand Bedenken hat - FreeBSD kommt mit aktueller HW (Skylake, kein USB2 mehr) anscheinend problemlos zurecht (GraKa habe ich noch nicht ausprobiert).
Jau. Allerdings ist Skylake auch die erste Generation, die ohne UEFI-Boot tendenziell zickig ist. Die GPU wird inzwischen von drm-next unterstützt: https://www.freshports.org/graphics/drm-next-kmod/
 
Hallo Yamagi

habe es jetzt verstanden. Current laeuft und X11 und drm-next auch.

Muss ich fuer die SSD etwas gesondert einstellen?

Noch ne Frage: Da ich Current auf aktueller HW habe, soll ich Konsole Ausgaben wie

lock order reversal
1st 0xfffff8004769cd50 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2606
2nd 0xfffffe01e611c700 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:280
3rd 0xfffff8004770d7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2606
stack backtrace:
#0 0xffffffff80ac

und hdacc1: Unexpected unsolicited response

bei FreeBSD melden. Oder ist das fuer current normal

Serie300
 
Hallo :)

Muss ich fuer die SSD etwas gesondert einstellen?
Das kommt drauf an. Wenn du ZFS nutzt, bist du fertig. Wenn du UFS nutzt, musst du TRIM noch explizit einschalten. Das machst du am Besten, indem du von einem USB-Stick bootest und es dort mit 'tunefs -t enable /dev/$device' setzt. Es sollte aber auch dem Single User Mode raus gehen.

lock order reversal
1st 0xfffff8004769cd50 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2606
2nd 0xfffffe01e611c700 bufwait (bufwait) @ /usr/src/sys/ufs/ffs/ffs_vnops.c:280
3rd 0xfffff8004770d7c8 ufs (ufs) @ /usr/src/sys/kern/vfs_subr.c:2606
stack backtrace:
#0 0xffffffff80ac
Das ist harmlos. Die Meldung besagt, dass /usr/src/sys/kern/vfs_subr.c:2606 einen Lock hält. Mit diesem Lock wird /usr/src/sys/ufs/ffs/ffs_vnops.c:280 aufgerufen, was wiederum /usr/src/sys/kern/vfs_subr.c:2606 aufruft. Dort wird der Lock dann wieder angefordert, was einen Deadlock bedeuten kann. Grundsätzlich ist das also sehr problematisch, dieser Fall ist allerdings ein bekanntes False Positive. Es wird also grundlos gemeckert.
 
@serie300: Das ist zwar harmlos, aber die Debug-Optionen machen CURRENT um einiges langsamer. Schau mal in /usr/src/UPDATING rein, direkt oben steht drin, was du machen musst, um das Debugging zu deaktivieren.
 
Zurück
Oben