Linux-Dual-boot mit GPT

h^2

hat ne Keule +1
Ich habe das System nach den "neueren" Regeln installiert also GPT mit freebsd-boot, freebsd-swap, freebsd-zfs (keine /boot partition). Läuft alles wunderbar. Nun habe ich in weiser Voraussicht vor der freebsd-zfs Partition noch eine linux-Partition eingerichtet, und auf der jetzt Linux installiert. Nur kann ich es nicht booten.

Mein Plan war: grub von Linux aus auf der Partition von Linux zu installieren und dann den boot0 von FreeBSD einfach das Linux device auswählen. Geht aber nicht. Das boot0 zeigt mir leider keine Optionen an. Muss ich dafür irgendwas mit der Parition machen, oder kann das moderne boot0 das einfach nicht (mehr)?

Was wären denn die Alternativen? Unter Linux grub2 direkt auf die Platte bügeln habe ich auch schon versucht, aber da will er nicht, weil das mache er bei GPT nicht, wenn da keine bios-legacy-boot-Partition eingerichtet sei. Die von FreeBSD findet er anscheindn nicht, aber die soll er ja auch nicht überschreiben.
Von FreeBSD aus Grub2 direkt auf die Platte bügeln geht auch nicht, weil das grub-install schon behauptet, dass es beim Start seine Dateien nicht finden würde.

Was tun?

Thx!
 
Disclaimer: Mein Kenntnisstand hierzu ist recht passabel aber beileibe noch ausbaufähig. Ausserdem bin ich bekennender grub Hasser (und ergo weitgehend grub kenntnislos).

Kurzversion: Vergiss es. Es gibt selbst für Masochisten erfreulicheres.

Längere Version:

Doch, boot0 kann noch alles. Aber boot0 wird nicht verwendet mit GPT. Sondern pmbr und gptboot. Leider ohne bootmenu, wie du ja schon bemerkt hast.

Prinzipiell geht das wohl, was du willst. Aber andersrum (FreeBSD als "zusätzliches" System). Mit grub2. Syslinux soll's auch können, hört man so. Aber es wird jedenfalls hässlich (wg. grub und Gefummel).
Vorbehaltlich einer ausgeprägten Bereitschaft zu experimentieren und zu fummeln läuft's auf Folgendes hinaus: altmodische Methode (bios/mbr) und boot0 (also auch boot menu) und wie früher gehabt mit slices - oder - gtp, partitions (auch für FreeBSD, statt slices), kein bootmenu oder bootmenu über linux mit elend Gefummel.

Falls du linux nur selten verwendest aber halt auf der Platte haben willst, wäre evtl. noch zu überlegen, deinen gpt Ansatz beizubehalten, linux aber via Stick zu booten. Denn soweit man das sinnvoll vermuten kann, hat deine linux Installation ja geklappt, nur kommst du halt nicht dran; und genau das könnte linux vom-Stick-booten lösen (und dann natürlich chmod -> Linux Partition auf Platte oder ähnliche Wege).

Übrigens: Um die Sache noch lustiger zu machen, ist es auch nicht egal, ob Dein Rechner Bios oder (U)efi hat.

Vielleicht bin ich ja altmodisch, aber: Wieviele riesige Partitionen brauchst du denn? Denn wenn das im halbwegs überschaubaren Bereich liegt und dir (bequemer) dual boot wichtig ist, dann wäre die herkömmliche Methode vielleicht doch brauchbar bis attraktiv. Und logische Partitionen sind doch höchstens ein kleines Ärgernis und allemal weniger schmerzvoll als dual boot mit gpt.
 
Ich hab das mit archlinux mal am laufen gehabt. Das hat ganz anständig funktioniert. Du musst halt eine bios- boot Partition vom Typ ef02 anlegen. So ca. 3 MB sollten reichen. Dazu musst du halt die Linux Partition nochmals löschen. In unserem Wiki steht ein Beitrag wie man grub2 dann einrichtet damit man den Kernel dann direkt booten kann.
 
Theoretisch kann man auch mehrere Kernel / Bootloader im EFI registrieren. In der Praxis hat das bei mir nie zuverlässig geklappt. :(
 
Kurzversion: Vergiss es. Es gibt selbst für Masochisten erfreulicheres.
Och, generell geht das schon, habe das über die Jahre unzählige Male gehabt...
Doch, boot0 kann noch alles. Aber boot0 wird nicht verwendet mit GPT. Sondern pmbr und gptboot. Leider ohne bootmenu, wie du ja schon bemerkt hast.
Das ist der springende Punkt. Ich hatte gehofft letzteres ließe sich doch irgendwie dazu überreden zu fragen ob er nicht eine andere Partition chainloaden soll.
Vielleicht bin ich ja altmodisch, aber: Wieviele riesige Partitionen brauchst du denn? Denn wenn das im halbwegs überschaubaren Bereich liegt und dir (bequemer) dual boot wichtig ist, dann wäre die herkömmliche Methode vielleicht doch brauchbar bis attraktiv. Und logische Partitionen sind doch höchstens ein kleines Ärgernis und allemal weniger schmerzvoll als dual boot mit gpt.
Joa, hab aber keine Lust das FreeBSD neu aufzusetzen. War schwer genug das ganze System mit TCG Opal hinzubekommen.

Ich hab das mit archlinux mal am laufen gehabt. Das hat ganz anständig funktioniert. Du musst halt eine bios- boot Partition vom Typ ef02 anlegen. So ca. 3 MB sollten reichen. Dazu musst du halt die Linux Partition nochmals löschen. In unserem Wiki steht ein Beitrag wie man grub2 dann einrichtet damit man den Kernel dann direkt booten kann.

Ja, das hatte ich mir auch überlegt. Nicht toll, aber wohl zu verschmerzen. Muss ich zumindest das FreeBSD nicht anfassen. Der Grub vom Linux kann dann aber auch FreeBSD von ZFS booten, hoffe ich (ich weiß dass er es können soll).
 
Toll. Grub kann natürlich das aktuelle ZFS nicht lesen. (lösbar irgendwie)
Und ZoL kann das aktuelle ZFS auch nicht lesen. WTF, ich dachte, wenn ich einen Pool nehme und keine fancy optionen auswähle, dann würden eben auch keine super-inkompatiblen features per default ausgewählt werden. Ich meine lz4 ist ja noch nichtmal default -- aus Kompatibitlitätsgründen, aber so unglaublich wichtige features wie embedded_data werden per default gesetzt? :grumble:
 
Was die features angeht, wenn ich für jedes Dataset ein neues erstelle, auf dem die features dekativiert werden, die Daten rüberkopiere und dann die alten Datasets lösche, dann müsste die features flags von active zurück auf enabled springen, oder?
 
Ah, sehr schön. ZoL hat auch nightly-Pakete. Die haben Unterstützung für die flags und bringen sogar gepatche grub2 versionen mit. Nun kann ich unter Linux den Pool mounten. Grub erkennt den Pool nun auch wieder richtig, kann aber leider den loader nicht laden, da er lz4 compression nicht kann -.-
Aber ich komme dem Ziel näher. Zur nur kopier ich mir das FreeBSD /boot einfach nach Linux rüber und lade von da irgendwie.
 
Wollte nurmal ein update geben, dass es insgesamt sehr reibungslos funktioniert. Das erste Mal, dass ich Daten lokal zwischen Linux und FreeBSD austausche mit RW und ohne Stress. Und das mit ZFS, wer hätte das gedacht! Die entsprechenden stabilen Pakete unterstützen nun auch die Flags...
Lediglich nervig ist, dass ich den ZoL-Skripten für den Pool kein altroot mitgeben kann.
 
Zurück
Oben