UlfZibis
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Hallo, ich habe hier 2 Ubuntu 64-Bit Installationen auf unterschiedlichen Partitionen. Dafür wird im Wiki empfohlen, ein weiteres Bootverzeichnis, hier ubuntu-64, und einen entsprechenden UEFI-Bootmenü-Eintrag zu erstellen. Wird nun über diesen 2. gestartet, wird trotzdem die /boot/grub/grub.cfg der ersten Installation abgearbeitet. Untersucht man die grubx64.efi im 2. Bootverzeichnis mit einem Hexeditor, kann man auch darin den String EFI/ubuntu finden. Erst nachdem ich den manuell auf EFI/ubuntu-64 geändert hatte, wurde die richtige /boot/grub/grub.cfg abgearbeitet. Hat sich da in Xenial was geändert, oder war der Hinweis im Wiki immer schon falsch? Ich habe nun auch einen Fehlerbericht gepostet.
|
Lidux
Anmeldungsdatum: 18. April 2007
Beiträge: 15900
|
Hallo UlfZibis, Hast du kontrolliert ob das "ubuntu-64" mit Bindestrich zulässig ist. Der zweite Eintrag soll lt. WIKI aber im NVRAM wieder gelöscht werden, weil dein zweites Ubuntu über den sekundären Eintrag und dann per grub2 gestartet wird .... Gruss Lidux
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
Hallo Lidux schrieb: schön, dass Du Dir Gedanken gemacht hast. Hast du kontrolliert ob das "ubuntu-64" mit Bindestrich zulässig ist.
Tja, woran könnte man das erkennen sollen. Fehlermeldungen gab's keine. Ich könnte aber mal spaßeshalber mit Unterstrich oder ganz ohne testen. Der zweite Eintrag soll lt. WIKI aber im NVRAM wieder gelöscht werden,
Das ist der Teil der Anleitung, dessen Sinn ich nicht verstehe. Ziel soll doch sein, folgendes zu vermeiden: "insbesondere bei einem Update von GRUB 2-Paketen führt das dann zu unkontrollierten Startbedingungen". Ich will nämlich die erste Installation durch ein 32-Bit Ubuntu ersetzen, und dann könnte so ein Update den befürchteten Schaden anrichten.
weil dein zweites Ubuntu über den sekundären Eintrag
Das funktionierte ja schon vor dem Anlegen des sekundären Eintrags, also wozu erst anlegen und dann wieder löschen. und dann per grub2 gestartet wird ....
Ubuntu wird doch immer über grub2 gestartet, egal in welcher Konfiguration.
|
bowman
Anmeldungsdatum: 17. Februar 2010
Beiträge: 7502
|
Ich will nämlich die erste Installation durch ein 32-Bit Ubuntu ersetzen, und dann könnte so ein Update den befürchteten Schaden anrichten.
Seit wann lässt sich ein 32-Bit-Ubuntu im EFI-Mode installieren? Das wäre mir neu. 🙄
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
UlfZibis schrieb: Lidux schrieb: Hast du kontrolliert ob das "ubuntu-64" mit Bindestrich zulässig ist.
Tja, woran könnte man das erkennen sollen. Fehlermeldungen gab's keine. Ich könnte aber mal spaßeshalber mit Unterstrich oder ganz ohne testen.
Also ohne Bindestrich und nur mit Buchstaben ändert sich nichts, wie ich vermutete. Falls Du Zeit hast, vielleicht magst Du mal probieren es nachzuvollziehen und dann Dich in dem Bug als "affected" hinzufügen, dann gilt er als "confirmed" und wird eher bearbeitet.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
In diesem Zusammenhang habe ich dann noch einen 2. Fehler entdeckt.
|
lionlizard
Anmeldungsdatum: 20. September 2012
Beiträge: 6244
Wohnort: Berlin
|
Mit Grub Version 2.02~beta2-36ubuntu3.2 funktioniert das tadellos.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
lionlizard schrieb: Mit Grub Version 2.02~beta2-36ubuntu3.2 funktioniert das tadellos.
Kommt drauf an, was Du unter funktionieren verstehst. Wenn ich die Anleitung befolge, und dann den Rechner mittels dem UEFI-Bootmenu "Ubuntu-64" starte, bekomme ich dieses GRUB-Menü:
Ubuntu
Erweiterte Optionen für Ubuntu
Windows Boot Manager (auf /dev/sda1)
Ubuntu 16.04.1 LTS (16.04) (auf /dev/sda8)
Erweiterte Optionen für Ubuntu 16.04.1 LTS (16.04) (auf /dev/sda8)
Das ist aber das aus der /dev/sda5/boot/grub/grub.cfg, das ich auch bekomme, wenn ich mittels dem primären UEFI-Bootmenu "Ubuntu" starte. Erst wenn ich wie eingangs beschrieben die /dev/sda1/EFI/ubuntu-64/grubx64.efi manupuliere, wird die richtige /dev/sda8/boot/grub/grub.cfg ausgeführt:
Ubuntu-64 GNU/Linux
Erweiterte Optionen für Ubuntu-64 GNU/Linux
Windows Boot Manager (auf /dev/sda1)
Ubuntu 16.04.1 LTS (16.04) (auf /dev/sda5)
Erweiterte Optionen für Ubuntu 16.04.1 LTS (16.04) (auf /dev/sda5)
Ist das bei Dir anders?
|
lionlizard
Anmeldungsdatum: 20. September 2012
Beiträge: 6244
Wohnort: Berlin
|
UlfZibis schrieb: Ist das bei Dir anders?
Ja. Was sagt den bei Dir grub-mkconfig -v BTW: Ich verwende unterschiedliche Grub-Hintergrundbilder, um auf den ersten Blick zu sehen, auf welche grub.cfg zugegriffen wird.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
lionlizard schrieb: Ja. Was sagt den bei Dir grub-mkconfig -v
grub-mkconfig (GRUB) 2.02~beta2-36ubuntu3.2
BTW: Ich verwende unterschiedliche Grub-Hintergrundbilder, um auf den ersten Blick zu sehen, auf welche grub.cfg zugegriffen wird.
Auch bei mir ist das Design unterschiedlich, denn, vermutlich durch das veränderte GRUB_DISTRIBUTOR="Ubuntu-64", habe ich ein blaues statt ein violettes GRUB-Menü: ### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
statt: ### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=white/black
set menu_color_highlight=black/light-gray
if background_color 44,0,30,0; then
clear
fi
### END /etc/grub.d/05_debian_theme ###
Ich möchte noch hinzufügen, dass UEFI secure boot durch die manipulierte /dev/sda1/EFI/ubuntu-64/grubx64.efi nicht mehr geht, ich muss es deaktivieren.
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
lionlizard schrieb: UlfZibis schrieb: Ist das bei Dir anders?
Ja.
Das könnte auch noch einen anderen Grund haben. Ich verwende hier die signierte Variante von grubx64.efi. Dort ist der String /EFI/ubuntu fest eincodiert, egal, ob in /dev/sda1/EFI/ubuntu oder /dev/sda1/EFI/ubuntu-64 installiert, sodass immer zuerst /dev/sda1/EFI/ubuntu/grub.cfg ausgeführt wird, und da steht dann der Link zur primär installierten Ubuntu-Installation drin. Bei der unsignierten Variante von grubx64.efi ist der String .(,gpt5)/boot/grub fest eincodiert, wenn in /dev/sda1/EFI/ubuntu installiert oder .(,gpt8)/boot/grub, wenn in /dev/sda1/EFI/ubuntu-64. Damit wird im Fall der unsignierten Variante immer die richtige /boot/grub/grub.cfg ausgeführt. Könntest Du bitte mal posten (ubuntu-64 durch das passende ersetzen): sudo ls -al /boot/efi/EFI/ubuntu ; sudo ls -al /boot/efi/EFI/ubuntu-64
|
lionlizard
Anmeldungsdatum: 20. September 2012
Beiträge: 6244
Wohnort: Berlin
|
Ich habe mal meine EFI-Partition in eine Datei gelistet EFI.txt
- EFI.txt (12.8 KiB)
- Download EFI.txt
|
UlfZibis
(Themenstarter)
Anmeldungsdatum: 13. Juli 2011
Beiträge: 3035
Wohnort: Köln
|
lionlizard schrieb: Ich habe mal meine EFI-Partition in eine Datei gelistet
Danke, meine Vermutung scheint zu stimmen: Diese Anleitung funktioniert nur für unsignierte Installationen von Grub. Außer in crypt-kububntu, crypt-ubuntu und KubuntuSSD verwendest Du überall die unsignierte Variante (erkennbar an Größe ~ 119 kB). In allen EFI-Verzeichnissen außer /EFI/ubuntu kannst Du die grub.cfg löschen, da sie nicht verwendet werden. Die signierten Varianten von Kubuntu sollten /EFI/kubuntu/grub.cfg verwenden, die es bei Dir nicht gibt. Jetzt weiß ich natürlich nicht, mit welchen Du getestet hast. Kannst Du mal bei den signierten Varianten (erkennbar an Größe ~ 1100 kB) testen, ob da auch immer die richtige /boot/grub/grub.cfg ausgeführt wird? Edit: Ob die Krypto-Varianten von grubx64.efi der Größe ~ 950 kB signiert sind, kann ich von hier nicht beurteilen, da ich keine habe.
|
lionlizard
Anmeldungsdatum: 20. September 2012
Beiträge: 6244
Wohnort: Berlin
|
UlfZibis schrieb: Kannst Du mal bei den signierten Varianten (erkennbar an Größe ~ 1100 kB) testen, ob da auch immer die richtige /boot/grub/grub.cfg ausgeführt wird?
Nö.
die Kombination von 32bit-Installation + UEFI + Secure-Boot finde ich schon relativ abwegig Im Wiki ist sowieso nirgendwo die Rede davon, dass man mehrere Bootverzeichnisse verwenden soll. Die Erstellung eines "weiteren Bootverzeichnisses" soll nur verhindern, dass die verschiedenen Grub-Installationen sich nicht gegenseitig immer wieder überschreiben. Vorgesehen ist, alle Installationen durch das Grub-Menü der Ursprungsinstallation gestartet werden, dabei wird sogar empfohlen, die NV-Ram Einträge der "weiteren Bootverzeichnisse" wieder zu löschen.
Dass Secure-Boot bemängelt, wenn die Startdateien verändert werden, deutet doch lediglich darauf hin, dass das Konzept funktioniert. Insofern fehlt mir die Motivation, hier Dinge zu erforschen, die mich und den größten Teil der User sowieso nicht betreffen. Mir ist nur aufgefallen, dass der von Dir beschriebene Fehler eben nicht so global auftritt, wie von Dir dargestellt. Deine neueste Vermutung, dass der Fehler bei aktiviertem Secure-Boot auftritt, kann durchaus zutreffen.
|