ubuntuusers.de

Hej Unix-Lover,

Unix-Lover schrieb:

...Gibt es einen Vorteil, wenn der USB-Stick eine GPT- statt einer MBR-Partitionstabelle hat?

Du kannst halt mehr primäre Partitionen einrichten (falls Du das brauchst; der artikel lautet ja auch "...auf_USB_flashkey_und_internen_HDD_und_SSD"

Sind die so korrekt (insbesondere der MBR hex code)?

ich habe doch dafür (extra) diesen DL angefügt. Schau ihn Dir an.

Und noch einen Satz zu meiner Vorgehensweise (mit getrennten Verzeichnissen/Partitionen): Ich setze ja die eigentliche grub.cfg auf eine Partition, die ich ohne Rechte bearbeiten kann und ohne jedesmal die esp erst mounten zu müssen.

Gruß black tencate

Hallo black_tencate,

ok, ich habe übersehen, dass es im Artikel auch um HDD‘s und SSD‘s geht. Ich habe meinen Blickwinkel auf USB-Sticks gerichtet und die anderen Medien ausgeblendet. ^^

Deinen DL habe ich mir angeschaut und ich habe mich auch danach gerichtet. Trotzdem habe ich eine andere Situation, da ich eine Partition weniger habe, als im Wiki-Eintrag vorgegeben (siehe mein letzter Post). Ich habe die Eingaben in deinem Download an meine Situation angepasst, bin aber nicht sicher, ob ich das so richtig gemacht habe. Deshalb frage ich ja hier.

Viele Grüße

Unix-Lover

Hej Unix-Lover,

paßt schon. Außerdem, kann doch nichts passieren, wenn es nicht funktionieren sollte, kannst Du den Stick ja wie beschrieben, wieder auf MBR zurücksetzen. (Evt. ist ja auch ein Blick in man gdisk nützlich - von wegen "Hilfe zur Selbsthilfe *grins*)

Gruß black tencate

Hi black_tencate,

irgendwas scheint da noch schief zu laufen. Also, der Stick ist wie im Wiki-Eintrag beschrieben partioniert (GPT) und die ersten beiden Partition, also die unformatierte mit 1 MB und die esp-Partition, wurden in den Hybrid-MBR hinzugefügt.

Anschließend habe ich sowohl grub-legacy als auch grub-efi in die esp-Partition installiert, so wie bisher auch (ich weiß, du bist dagegen, aber ich möchte das trotzdem so). Die grub.cfg habe ich von der Installation übernommen und in die esp-Partition kopiert.

In der /boot-Partition ist zwar auch eine grub.cfg vorhanden, auf die sollte der Stick aber beim Booten nicht zugreifen (war bisher ja auch so).

Das Komische ist nun aber, dass beim Booten im Legacy-Modus alles problemlos funktioniert, aber nicht beim Boot im UEFI-Modus: Aus irgendeinem Grund greift der Stick im UEFI-Modus auf die grub.cfg der /boot-Partition, und nicht die in der esp-Partition zu.

Vorgegangen bin ich allerdings wie vorher auch, abgesehen von der Partitionierung in GPT und dem anschließenden Hybrid-MBR habe ich nichts anders gemacht.

Kannst du mir sagen, woran dieser falsche Zugriff liegt?

Danke und viele Grüße

Unix-Lover

EDIT:

Es liegt vermutlich daran, dass ich den standalone-grub vor der systeminstallation auf den Stick installiert hatte. Während der Systeminstallation hat der installer die esp-Partition offenbar als EFI-Partition erkannt und deshalb dort sein Unwesen getrieben.

Ich versuche, den installer auszutricksen, indem ich das System ohne eine efi-Partition installiere. Danach richte ich erst die esp-Partition ein und installiere erst dann den standalone-grub.

EDIT 2:

Keine Chance, das funktioniert so nicht. Die Installation ist zwar durchgegangen (ohne Installation des GRUB-Bootloaders, da das - wohl wegen mangelnder EFI-Partition - in einen Fehler lief), aber ich kann grub-efi nicht in die esp-Partition installieren. Ich erhalte dabei den folgenden Fehler (die esp-Partition habe ich in /mnt eingehängt):

sudo grub-install --target=x86_64-efi --recheck --removable --efi-directory=/mnt --boot-directory=/mnt/boot
x86_64-efi wird für Ihre Plattform installiert.
grub-install: Fehler: Kanonischer Pfad von »/mnt/boot/grub« konnte nicht ermittelt werden.

Für einen goldenen Hinweis wäre ich sehr dankbar, ansonsten bleibe ich lieber bei MBR.

Viele Grüße

Unix-Lover

Hej Unix-Lover,

kann im Moment nicht experimentieren, habe meinen PC nicht dabei.

Versuch 's mal mit der Umstellung gemäß https://wiki.ubuntuusers.de/GRUB_2_von_BIOS_nach_EFI_umstellen/ und schau auch mal in besagte /boot/grub.cfg resp. in

sudo efibootmgr -v

Erzeuge einen NVRAM Eintrag für den stand-alone grub und benutze den.

Gruß black tencate

Edit.: Mach Dich auch mal schlau über diesen Aspekt, Du möchtest ja den stand-alone grub benutzen, der durch die Installation entstandene soll Dir ja nicht bei jedem update wieder dazwischen funken. Wenn Du deren configfile brauchst (anderer kernel etc.), kannst Du das die grub.cfg ja über ein menuentry mit

..
configfile /...

benutzen.

Hallo black_tencate,

ich war in der letzten Zeit leider sehr eingespannt und musste dieses Thema ruhen lassen, deshalb meine so verspätete Antwort.

Ich danke dir sehr für deine Hinweise, aber leider verstehe ich nur Bahnhof. Was hilft es mir, wenn ich einen bestehenden BIOS-Grub 2 nach EFI umstelle und dann in die grub.cfg schaue? Ist es da nicht einfacher, direkt ein EFI-Grub 2 zu installieren?

Dein zweiter Link (Einbinden einer anderen Distribution) bringt mich leider auch nicht weiter. Ich bräuchte also noch weitere Hilfe.

Viele Grüße

Unix-Lover

Hej Unix-Lover,

Unix-Lover schrieb:

... In der /boot-Partition ist zwar auch eine grub.cfg vorhanden, auf die sollte der Stick aber beim Booten nicht zugreifen (war bisher ja auch so).

• Frage: "/boot" → Partiiton? Oder Verzeichnis?

Diese grub.cfg wird ja bei einer Ubuntuinstallation erzeugt (zusätzlich dazu dann im EFI Modus auch ein entsprechender Eintrag im NVRAM), mit denen startet das neu installierte System (Hinweis: Jedes zusätzlich letztinstallierte macht das dann so). Wenn Du das (im EFI Modus) verhindern willst, mußt Du - wie in dem bereits verlinkten Artikelabschnitt EFI_Nachbearbeitung/#Andere-Distribution-einbinden - das eben unterbinden dadurch, daß diesem grub ein "anderer" Ort zugweisen wird, sodaß er nicht bei jedem entsprechenden update in der Installation sich wieder in den Vordegrund drängelt

Das Komische ist nun aber, dass beim Booten im Legacy-Modus alles problemlos funktioniert, aber nicht beim Boot im UEFI-Modus: Aus irgendeinem Grund greift der Stick im UEFI-Modus auf die grub.cfg der /boot-Partition, und nicht die in der esp-Partition zu.

klar, daß das im "legacy" Modus nicht passiert, Du hast ja die Installation im EFI Modus durchgeführt.

Gruß black tencate

Hallo black_tencate,

black_tencate schrieb:

Hej Unix-Lover,

• Frage: "/boot" → Partiiton? Oder Verzeichnis?

Boot-Partition, weil ich das installierte System auf dem USB-Stick verschlüsseln möchte.

Ich konnte lange nicht experimentieren, habe mich gestern aber nochmal rangesetzt und habe testweise den stand-alone grub und anschließend ein verschlüsseltes Debian auf den USB-Stick installiert, genau so, wie es vorher (erfolglos) versucht habe.

Überraschenderweise klappt diesmal alles und der grub innerhalb von Debian funkt nicht dazwischen, obwohl ich update grub ausgeführt habe.

Meine ESP-Partition hat die beiden Verzeichnisse "boot" und "EFI". "EFI" hat wiederum zwei Ordner:

1. Ordner mit Name "BOOT" –> Inhalt: BOOTX64.EFI

2. Ordner mit Name "debian" –> Inhalt: grubx64.efi

Bei dieser Installation wurde offenbar dem Debian-grub schon ein anderer Ort zugewiesen. Die Dateien des Debian-grub befinden sich auf der Boot-Partition, die des stand-alone grub auf der ESP-Partition (im o.g. Ordner "boot"). Dass es bei meinem ersten Versuch nicht geklappt hatte, lag wohl offensichtlich daran, dass ich einen Fehler gemacht hatte.

Ich werde die Installation nochmal durchführen. Falls es auch beim nächsten Mal klappt, dann war es wirklich ein Fehler meinerseits und ich markiere diesen Thread endgültig als gelöst.

In der Zwischenzeit aber eine andere Frage:

Der stand-alone grub bootet nicht auf Rechnern, in deren UEFI Secure Boot eingeschaltet ist, richtig? Könnte man das ändern und den stand-alone grub Secure Boot-tauglich machen?

Hej Unix-Lover,

Unix-Lover schrieb:

... Bei dieser Installation wurde offenbar dem Debian-grub schon ein anderer Ort zugewiesen

ja, nämlich

2. Ordner mit Name "debian" –> Inhalt: grubx64.efi

Die Dateien des Debian-grub befinden sich auf der Boot-Partition, die des stand-alone grub auf der ESP-Partition (im o.g. Ordner "boot").

die Dateien für grub schreibt der jeweilige Installer dorthin, wo es bei ihm im Programmablauf festgelegt ist, bei einem stand-alone grub wird das eben durch ...--boot-directory=/mnt/boot festgelegt, das kann aber auch sonst wo auf der Platte sein; da es keinen Verzeichnisbaum eines installierenden Linux gibt, habe ich mir einfach ein Verzeichnis auf der esp ausgesucht.

In der Zwischenzeit aber eine andere Frage:

Der stand-alone grub bootet nicht auf Rechnern, in deren UEFI Secure Boot eingeschaltet ist, richtig?

k.A., habe keine Möglichkeit, das zu testen, mein Lenovo T520 verfügt nicht über so eine Funktion.

Könnte man das ändern und den stand-alone grub Secure Boot-tauglich machen?

man (oder Du) könnten das ja mal testen.

Gruß black tencate

Hallo black_tencate,

dann liegt die Ursache des ersten Fehlversuchs mit GPT tatsächlich bei mir. Ich weiß bis heute nicht, was ich damals falsch gemacht habe. :S

black_tencate schrieb:

man (oder Du) könnten das ja mal testen.

Hab ich teilweise, heute morgen habe ich den Laptop mit aktiviertem Secure Boot den USB-Stick booten lassen und es hat nicht funktioniert.

Das liegt vermutlich daran, dass ich grub auf einem Debian installiert habe, denn Debian unterstützt Secure Boot noch nicht. Ich installiere den stand-alone grub von einem Ubuntu aus (Ubuntu unterstützt ja Secure Boot) und teste es dann nochmal, danach gebe ich hier Rückmeldung.

Viele Grüße

Unix-Lover

EDIT und Update:

Das unten erwähnte Problem bei der Installation des Secure-Boot-tauglichen stand-alone grub ist mittlerweile gelöst. In dem unten verlinkten Thread habe ich auch die Lösung gepostet. Direkter Link zur Lösung:

https://forum.ubuntuusers.de/topic/stand-alone-grub-und-secure-boot-vmlinuz-hat-e/#post-9105718

Die hier beschriebene Anleitung habe ich der o.g. Lösung entsprechend aktualisiert.

Hallo black_tencate,

ich habe es einerseits geschafft, den stand-alone grub mit Secure Boot zum Laufen zu kriegen, andererseits bin ich aber auf ein anderes Problem gestoßen. Ich werde hier aber nur die Lösung erklären. Das zusätzliche Problem werde ich in einem neuen Thread erläutern, da dieser hier sonst überdimensional wird. Der Link zum Thread ist der folgende:

https://forum.ubuntuusers.de/topic/stand-alone-grub-und-secure-boot-vmlinuz-hat-e/

Also:

stand-alone grub Secure-Boot-tauglich machen

Die Installation des Secure-Boot-tauglichen stand-alone grub sollte nur von einem Ubuntu-Livesystem durchgeführt werden. Bei einem Debian 10-Livesystem führte die Installation bei mir nur zu Fehlern. Daher ist davon auszugehen, dass der stand-alone grub (zumindest nach jetzigem Stand) nicht fehlerfrei bei Debian möglich ist.

Als erstes muss man auf dem (Ubuntu-)Livesystem, von dem man den stand-alone grub installiert, Secure-Boot (teilweise) nachrüsten. Dies macht man mit den folgenden Schritten, angelehnt an den folgenden Anleitung aus dem Wiki: EFI Nachbearbeitung (Abschnitt „Secure-Boot-nachruesten“)

Man installiert im Live-System das folgende Paket

• grub-efi-amd64-signed

sudo apt-get install grub-efi-amd64-signed 

Achtung:

Das Paket muss in Ubuntu 18.04.3 LTS nach Installation von grub-efi zusätzlich nachinstalliert werden. In Ubuntu 19.10 wird grub-efi-amd64-signed automatisch bei der Installation von grub-efi installiert, d.h. in Ubuntu 19.10 ist dieser o.g. zusätzliche Installationsschritt nicht mehr notwendig.

Anschließend geht man genauso vor, wie in der folgenden Anleitung von black-tencate beschrieben (also keine Änderungen im Vorgehen):

Universal stand-alone grub für BIOS und EFI auf USB flashkey und internen HDD und SSD

Mit dem so installierten stand-alone grub kann man sowohl ein danach installiertes Ubuntu als auch ein danach installiertes Debian 10 mit eingeschaltetem Secure-Boot starten. Dieser stand-alone grub funktioniert jedoch nicht beim Start eines Ubuntu-Livesystems über den loop-Boot des Ubuntu-Images, denn in diesem Fall erscheint eine vmlinuz-Fehlermeldung.

Unix-Lover schrieb:

Man installiert im Live-System das folgende Paket

• grub-efi-amd64-signed

sudo apt-get install grub-efi-amd64-signed 

Achtung:

Das Paket muss in Ubuntu 18.04.3 LTS nach Installation von grub-efi zusätzlich nachinstalliert werden. In Ubuntu 19.10 wird grub-efi-amd64-signed automatisch bei der Installation von grub-efi installiert, d.h. in Ubuntu 19.10 ist dieser o.g. zusätzliche Installationsschritt nicht mehr notwendig.

Wie ich seit meinen Experimenten feststelle, ist letzteres auch schon mit Ubuntu 18.04.4 LTS der Fall.

Und ansonsten ist das vorherige Installieren des quasi virtuellen Pakets grub-efi überflüssig.