staging.inyokaproject.org

Newubunti schrieb:

RapaNui schrieb:

Meine Fragen dazu wären:

• Geht das auch mit all den anderen Einträgen?

Welche Einträge meinst Du hier konkret? Die, die das UEFI z.B. für Wechsel-Medien automatisch erzeugt?

Alle Dateien die auf .efi enden. Ob dazu auch alle anderen Programm gehören, siehe auch efibootmgr (Abschnitt „Auflistung-aller-Eintraege-Langformat“), kann ich (da kein EFI verfügbar) nicht genau sagen.

Hintergrund ist ein Skript-Projekt, dass ich aufgesetzt habe ▶ Diskussionsbereich zum Projekt. Dabei soll die EFI-Umgebung analysiert und evtl. automatisch Grub-Menüeinträge für die grub.cfg erzeugt werden. Bei der Suche im Internet zu grub-efi, Menüeinbindung, Erkennung von Fremdsystemen .. habe ich nichts gefunden, daher bin ich schon mal aktiv geworden.

RapaNui schrieb:

Alle Dateien die auf .efi enden. Ob dazu auch alle anderen Programm gehören, siehe auch efibootmgr (Abschnitt „Auflistung-aller-Eintraege-Langformat“), kann ich (da kein EFI verfügbar) nicht genau sagen.

Ich kann das zwar auch mal testen - wobei ich mir dann erst mal eine andere EFI-fähige Distribution ziehen müsste - aber sofern es nur um die *.efi-Dateien geht, die ja immer von der Installationsroutine einer Distribution angelegt werden, bin ich mir schon von der Logik her ziemlich sicher, dass das funktioniert.

Also Du könntest mit der gleichen Methode z.B. auch /efi/redhat/fedorax64.efi laden.

Mir ist dabei nur noch nicht klar, wie Du Probleme mit efibootmgr dabei konkret umgehen willst. Das wäre deswegen hilfreich zu wissen, damit ich weiß, wie ich den Test konkret aufbaue.

Gruß, Martin

Newubunti schrieb:

Mir ist dabei nur noch nicht klar, wie Du Probleme mit efibootmgr dabei konkret umgehen willst. Das wäre deswegen hilfreich zu wissen, damit ich weiß, wie ich den Test konkret aufbaue.

Die Idee dabei ist, dass eben alle *.efi-Dateien (Anwendungen? sofern als *.efi abgelegt) über den GRUB verfügbar gemacht und ausgewählt werden können.

• Man braucht dann nicht unbedingt das Handling mit efibootmgr, auch wenn es sauberer ist.

• Zur Not, wenn efibootmgr, die grub-efi-install oder das EFI selbst versagen, muss nur ein bereits gültiger Eintrag dafür herhalten, z.B. durch umbenennen des /EFI/Boot/bootx64.efi und anschließendem kopieren des grubx64.efi als diesen. (Der User @YannUbuntu im engl. Forum macht so etwas ähnliches bei seinem boot-repair) Selbst die Namensgebung (vor der Extension) und/oder die dafür angelegten Verzeichnisse könnten vom EFI-Standard abweichen, mein Grub-Skript (40_os_prober_efi) findet sie immer. Alle weiteren Anwendungen, auch die Linuxe (Fedora, Debian, Suse ...), werden gefunden und können mit einem einzigen, funktionierendem GRUB verwaltet werden.

• Ein dritter Punkt bei meinem kleinen Projekt war, dass z.Zt. wohl keine Anstrengungen gemacht werden (ich hab zumindest zu den Stichpunkten nichts gefunden), um z.B. den Win.efi automatisch im Grubmenü aufzunehmen - analog zu os-prober für BIOS-Systeme. Du kennst das ja selbst, da Du beim Support immer einen manuellen Eintrag für die 40_custom lieferst. os-prober und 30_os_prober finden die normalen Bootloader und meine os-prober-efi und 40_os_prober_efi finden die EFI-Loader immer und bauen sie fürs Menue auf.

Sollte sich von Seiten der GRUB-Bauer dazu nichts ändern, dann ist mein Projekt ein "nice to have".
Sollte sich in absehbarer Zeit dort etwas ändern, dann kann man meine Skripte immer noch in die Tonne klopfen.

RapaNui schrieb:

Die Idee dabei ist, dass eben alle *.efi-Dateien (Anwendungen? sofern als *.efi abgelegt) über den GRUB verfügbar gemacht und ausgewählt werden können.

Das ist an sich eine gute Idee, als derzeit zusätzliches Skript, dass man nach der Installation laufen lassen könnte, um ein Einträge in GRUB aufzunehmen, wenn man das braucht.

• Man braucht dann nicht unbedingt das Handling mit efibootmgr, auch wenn es sauberer ist.

• Zur Not, wenn efibootmgr, die grub-efi-install oder das EFI selbst versagen, muss nur ein bereits gültiger Eintrag dafür herhalten, z.B. durch umbenennen des /EFI/Boot/bootx64.efi und anschließendem kopieren des grubx64.efi als diesen. (Der User @YannUbuntu im engl. Forum macht so etwas ähnliches bei seinem boot-repair) Selbst die Namensgebung (vor der Extension) und/oder die dafür angelegten Verzeichnisse könnten vom EFI-Standard abweichen, mein Grub-Skript (40_os_prober_efi) findet sie immer. Alle weiteren Anwendungen, auch die Linuxe (Fedora, Debian, Suse ...), werden gefunden und können mit einem einzigen, funktionierendem GRUB verwaltet werden.

Ah, da wolltest Du drauf hinaus. Da ist aber dann wie gesagt das Problem, dass bei meinem Problem-System es nicht mal funktioniert hat, die grubx64.efi in den Microsoft-Pfad zu legen. Warum konnte ich dann aus Zeitgründen nicht mehr herausbekommen. War darüber ziemlich verwundert. Auch der Standardpfad /EFI/Boot/bootx64.efi hat zwar die Windows-EFI-Datei geladen nicht aber die GRUB-EFI-Datei.

Im übrigen ist das MSI-System was ich hier habe für den Test dann auch ungeeignet, weil da dürften wahrscheinlich alle Varianten funktionieren.

Die wichtigste Frage für Dein Projekt ist ja, ob es dann auch auf einem Problem-System funktioniert. Also auf einem solchen auf dem sich mindestens keine weiteren EFI-Einträge außer für Windows setzen lassen.

Sollte sich von Seiten der GRUB-Bauer dazu nichts ändern, dann ist mein Projekt ein "nice to have".
Sollte sich in absehbarer Zeit dort etwas ändern, dann kann man meine Skripte immer noch in die Tonne klopfen.

Soweit ich das bisher verfolgt habe, ist man bei os-prober - das zunächst mal unabhängig von GRUB ist - der Ansicht, dass man das auf einem EFI-System nicht braucht. Finde ich für den Standardfall auch verständlich.

Von daher macht Dein Projekt IMO Sinn, weil es sinnvoller ist, dass das nur auf Wunsch ausgeführt wird, als wenn man das GRUB-Menü bei einem Multiboot erst mal aufgezwungen bekommt.

Bei BIOS-Systemen ist es ja so, dass man ohne GRUB andere OS nicht starten kann. Bei einem EFI-System ist das ja anders. Dass es da unrühmliche Ausnahmen gibt und am Anfang wahrscheinlich auch vermehrt, steht dem grundsätzlich nicht entgegen.

Ich würde Dir daher raten, das nicht als ein Projekt umzusetzen, sondern als zwei:

• Eines als os-prober-efi, um grundsätzlich Einträge in einen EFI-Bootloader aufnehmen zu können, also auch dann wenn GRUB-EFI an sich ohne Probleme installiert wurde und gestartet werden kann.

• Ein Projekt, für das versuchte Ersetzen von /EFI/boot/bootx64.efi für Problemfälle.

Gruß, Martin

Also so einfach ist das offenbar nicht. Ich habe das jetzt mal durchgespielt.

Also folgendes habe ich gemacht:

Newubunti schrieb:

RapaNui schrieb:

• Zur Not, wenn efibootmgr, die grub-efi-install oder das EFI selbst versagen, muss nur ein bereits gültiger Eintrag dafür herhalten, z.B. durch umbenennen des /EFI/Boot/bootx64.efi und anschließendem kopieren des grubx64.efi als diesen. (

... dass bei meinem Problem-System es nicht mal funktioniert hat, die grubx64.efi in den Microsoft-Pfad zu legen.

Das erklärt sich ja mit Deinen Tests. Man sollte auch immer im Hinterkopf behalten, dass es noch eine gültige (ausfürhbare) startup.nsh geben kann, die nochmals Umleitungen baut.

Die wichtigste Frage für Dein Projekt ist ja, ob es dann auch auf einem Problem-System funktioniert. Also auf einem solchen auf dem sich mindestens keine weiteren EFI-Einträge außer für Windows setzen lassen.

Die vorrangigsten Fragen für mich sind erst einmal:

1. Was verbirgt sich alles hinter der Endung *.efi ?

   • Nur Bootloader?

   • Generell unter EFI ablauffähige PGM (wie.zB. Treiber laden, Uhr, Wetter anzeigen, ....), also die ganzen Zusatzteile bei EFI.

2. Können diese generell aus GRUB aufgerufen werden?

   • Könntes Du das aus der GRUB-Shell mal testen - manuelles chainloaden auf so ein *.efi-Teil? Evlt. auch auf neue Namen und Verzeichnisse?

Sollte sich von Seiten der GRUB-Bauer dazu nichts ändern, dann ist mein Projekt ein "nice to have".

Soweit ich das bisher verfolgt habe, ist man bei os-prober - das zunächst mal unabhängig von GRUB ist - der Ansicht, dass man das auf einem EFI-System nicht braucht. Finde ich für den Standardfall auch verständlich.

Ist schon klar, os-prober wird ja auch von GRUB nur aufgerufen um die Daten in 30_os_prober zu verarbeiten.

Von daher macht Dein Projekt IMO Sinn, weil es sinnvoller ist, dass das nur auf Wunsch ausgeführt wird, als wenn man das GRUB-Menü bei einem Multiboot erst mal aufgezwungen bekommt.

Ich würde Dir daher raten, das nicht als ein Projekt umzusetzen, sondern als zwei:

• Eines als os-prober-efi, um grundsätzlich Einträge in einen EFI-Bootloader aufnehmen zu können, also auch dann wenn GRUB-EFI an sich ohne Probleme installiert wurde und gestartet werden kann.

• Ein Projekt, für das versuchte Ersetzen von /EFI/boot/bootx64.efi für Problemfälle.

Danke für den Hinweis. Für mich ist es z.Zt. immer noch ein Projekt:

• 30_os_prober_efi ist der GRUB-Teil

• Zusätzlich im Paket wird das kleine System-List-Pgm os-prober-efi mitgeliefert.

Ok, das lsdisk hab ich mal schnell untergeschoben 😉

Zu Deinen Tests:

Newubunti schrieb:

Ich sehe das genau so:

1. EFI prüft bereits verschärft und der /Boot/bootx64.efi muss der mitgelieferte, authorisierte Loader sein.

2. Der baut dann sogar noch eine Standardverbindung zum /EFI/Microsoft/Boot/bootmgrfw.efi auf (siehe auch mein Post).

3. Das üblche bei den Herstellern, es gibt erst einmal nur wir selbst und MS

Saludos de Chile

Newubunti schrieb:

3. Durchgang:¶

• MS *.efi-Dateien wieder durch originale ersetzt.

Ergebnis: Im EFI-Boot-Menü taucht ohne weiteres Zutun ein Eintrag "Windows Boot Manager" auf. Dieser Eintrag startet Windows.

Ich hatte einen vergleichbaren Test mal gemacht - alle Windowsdateien auf einen bootfähigen, FAT32-USB-Stick eins zu eins in das leere Verzeichnis EFI rüberkopiert.

Das auf diesem Rechner dazugehörige Windows wurde ohne Murren via USB-Stick gestartet - eine vergleichbare Installation auf einem anderen Rechner hingegen nicht. Obwohl im EFI-Menü bei beiden Rechner dieses Stick-Windows automatisch angezeigt (also zusätzlich aufgenommen) wurde - im Gegensatz zum Ubuntu-Eintrag, der nach wie vor von efibootmgr gesetzt werden muss.

Da scheint es noch mehr zu geben, denn zumindest wertet auch der Windows Bootmanager die UUID's aus.

Sonstiges:

• 1: Auch AMI arbeitet hart am efi-bios - habe gerade gestern ein Update bekommen.

• 2: Ich warte jetzt auf unser neues Asus P8B75-M-Board mit ASUS-EFI - mal sehen, welche Überraschungen da auf uns warten.

• 3: Nicht dass ich nicht wollte - die letzten drei Wochen hatte ich nur 5kB/s (maximal, trotz GSM-EDGE) zur Verfügung - es gibt noch fast INet-freie Zonen auf dieser Welt. 👍

gruß syscon-hh

Nachtrag @ RapaNui: Zu Deinem neuen Projekt!?!

Gerade unter GRUB_2 (Quetzal) entdeckt:

### BEGIN /etc/grub.d/05_debian_theme ###
insmod btrfs
set root='hd1,msdos2'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos2 --hint-efi=hd1,msdos2 --hint-baremetal=ahci1,msdos2 c3675ac3-36a2-4f92-9c83-800fe22001e3
else
  search --no-floppy --fs-uuid --set=root c3675ac3-36a2-4f92-9c83-800fe22001e3
fi
....

Dazu sagt die Help-Funktion der Grub-Shell:

search help
Aufruf: search [-f| -l| -u| -s| -n]  [ --hint HINWEIS [--hint HINT] NAME
Anhand von Bezeichnungen nach Gerätensuchen. Falls --set angegeben wird, dann wird das erste
gefundene Gerät zum Setzender Variable verwendet. Falls keine Variable angegeben wird, dann
wir >>root<< verwendet.
...
-h, --hint=HINT   Zuerst das Gerät HINWEIS versuchen. Falls Hinweis mit Komma endet, auch
Unterpartitionen versuchen.

Hola Ihr Beiden

Newubunti schrieb:

Also so einfach ist das offenbar nicht. Ich habe das jetzt mal durchgespielt.

Da sagst Du was 👍

Vorbemerkung: Wenn ich Dir auf den Geist gehe, dann sag das ruhig und ich werde ruhiger. Das Thema interessiert mich eben und ich habe keinen Zugriff auf ein EFI-System, sodass ich eben nur "trockernschwimmen" mache und so viel nachfrage bzw. spekuliere.

Zu Deinen Tests, die Erklärungen sind mir nicht so klar. Du hattest die NVRAM-Einträge gelöscht, ok.

• Waren das nur diese zwei (Win & Ubuntu), oder wird der \Boot\Bootx64.efi dort auch aufgeführt und der wurde auch entfernt?

• Galt das Gelöscht sein für die gesamten Durchführungen?

Ich versuche mal eine Interpretation - hoffentlich kommt es klar rüber:

1. Du hattest alle 3 gelöscht, dann erscheint es mir klar, keine Einträge im NVRAM = kein Finden & Starten möglich.

2. Du hattest nur die beiden BS-Loader gelöscht. Dabei gehe ich davon aus, dass EFI diesem \Boot\Bootx64.efi nur bestimmte Sachen erlaubt, wie z.B. Menue-Einträge anlegen, in ein Unterverzeichnis wechseln und von dort weitere Ausführung aufrufen. Unter diesen Bedingungen gehts nun wie folgt weiter:

   • 1. Durchführung:

     • kein Eintrag = kein Starten

     • Der abgelegte Ubuntu-Loader will sofort ins System starten und dies wird vom EFI verweigert - es muss ein Unterverzeichnis sein bzw. eine Anwendung (z.B. startuo.nsh) zwischengeschaltet sein.

   • 2. Durchführung:

     • Der kopierte \Boot\Bootx64.efi ist von MS selbst. Er macht verschiedene administrative Dinge: 1. Ins Unterverzeichnis (also sein eigenes /Microsoft/Boot/) wechseln. 2. Dort überprüft er den abgelegten bootmgrfw.efi, ob er auch von MS ist (Hashwerte oder wie auch immer). 3. War dies ebenfalls erfolgreich, dann wird ein Menue-Eintrag geschrieben und jetzt erst der bootmgrfw.efi zur Ausführung gebracht.

   • 3. Durchführung:

     • Da die Bedingungen aus der 2. Durchführung nun erfüllt waren, wurde der /Microsoft/Boot/bootmgrfw.efi gestartet.

3. Es sind halt immer noch viele Fragen offen, z.B.:

   • Was passiert, wenn Du statt dem MS/Bootx64.efi den von einem Ubuntu nimmst, der der im Image unter /efi/boot/ liegt? Das käme meiner Vermutung (Restriktion in der Ausführung) schon nahe. Dieser lädt anscheinend nur die grub.cfg (loopback.cfg?) aus dem Verzeichnis /boot/grub, also kein Systemstart. Aus diesem Menue wird ja dann wieder auf einen anderen Standort verwiesen (hier casper....) und dann erst gestartet.

   • Kann man aus der Built-In Shell manuell starten? z.B. mit so etwas ähnlichem:

     fs0:
     ls
     cd /unterverzeichnis
     grub64x.efi

     entnommen aus diesem pdf

   • Wenn das manuelle booten klappt, dann könnte man eine startup.nsh mit diesen Kommandos anlegen. Die muss mMn im /boot/efi/ liegen, also im / der EFI-Partition, vor dem /EFI/.

   • Wird diese immer automatisch ausgeführt?

   • .....

syscon-hh schrieb:

Nachtrag @ RapaNui: Zu Deinem neuen Projekt!?!

Danke erstmal für die Informationen. Die digitale Welt ist bekannt dafür, dass das heute entwickelte PGM morgen schon wieder auf den Müll wandert. Damit muss man lebem können 😉

Ok, Grub wird weiterentwickelt, dennoch ist unklar worum es bei den neuen Einträgen genau geht.

1. Sie sind aus einer aufgebauten grub.cfg (oder?) und unterstützen damit die Zuweisung der nachfolgenden Einträge.

2. Sie erscheinen z.Zt. im Themenbereich (05_debian_theme) und das könnte auf Erweiterungen dazu schließen lassen.

3. Es wurden zwar neue search-Argumente eingebaut, aber das --hint-bios= --hint-efi= deutet mehr auf die verschiedenen Betriebsarten hin.

Wenn es in naher Zukunft ein Bereitstellen der abgelegten *.efi-Loader gibt, dann ist das super und mein Skript kann in der Versenkung verschwinden. Wenn dem aber nicht so ist, dann könnte es nützlich werden.

Saludos aus Chile
RapaNui

RapaNui schrieb:

Vorbemerkung: Wenn ich Dir auf den Geist gehe, dann sag das ruhig und ich werde ruhiger.

Nein, Nachfragen ist ok. Das habe ich bei syscon-hh ja auch gemacht. Es ist für mich normal, dass man nicht immer gleich alles nachvollziehen kann, auch wenn sich der andere um verständliche Erklärungen bemüht.

• Waren das nur diese zwei (Win & Ubuntu), oder wird der \Boot\Bootx64.efi dort auch aufgeführt und der wurde auch entfernt?

Im NVRAM waren zu diesem Zeitpunkt - neben den Einträgen die für Laufwerke vom EFI automatisch generiert werden - nur der Eintrag für Windows und der für Ubuntu. Beide habe ich gelöscht.

Einen Eintrag im NVRAM für \Boot\Bootx64.efi gab es im NVRAM nicht. Einen solcher Eintrag war bis jetzt auch noch auf keinem der drei EFI-Systeme, die ich bisher gesehen habe, vorhanden. Das ist für mich soweit auch logisch, für einen Standardpfad.

Das Verzeichnis und die Datei \Boot\Bootx64.efi wurde auf der EFI-System-Partition von Windows angelegt.

Die Datei Bootx64.efi habe ich für Durchgang 1 mit der grubx64 ersetzt, die während des Ubuntu-Setups angelegt wurde.

• Galt das Gelöscht sein für die gesamten Durchführungen?

Ja. Außer eben, dass beim 3. Durchgang beim Neustart der Eintrag für Windows neu vom EFI generiert wurde.

Ich versuche mal eine Interpretation - hoffentlich kommt es klar rüber:

1. Du hattest alle 3 gelöscht, dann erscheint es mir klar, keine Einträge im NVRAM = kein Finden & Starten möglich.

Ja, zunächst mal schon, aber die Frage war ja, ob sich der Eintrag bzw. das Verzeichnis \Boot\Bootx64.efi als sog. Standard-Eintrag für jeden beliebigen Loader ohne Erstellen eines NVRAM-Eintrages nutzen lässt. Weil nur dann könnte er ja überhaupt für Problemfälle, bei denen efibootmgr keinen Eintrag im NVRAM erzeugen kann herhalten.

Für mich war dabei vor allem beim zweiten Durchgang überraschend, dass das nicht mal mit der bootx64.efi von Windows funktioniert hat.

1. Du hattest nur die beiden BS-Loader gelöscht. Dabei gehe ich davon aus, dass EFI diesem \Boot\Bootx64.efi nur bestimmte Sachen erlaubt, wie z.B. Menue-Einträge anlegen, in ein Unterverzeichnis wechseln und von dort weitere Ausführung aufrufen. Unter diesen Bedingungen gehts nun wie folgt weiter:

Ich bin soweit der Ansicht, dass die Menü-Einträge nicht durch eine efi-Datei von MS angelegt werden, sondern vom EFI selbst.

• 1. Durchführung:

  • kein Eintrag = kein Starten

  • Der abgelegte Ubuntu-Loader will sofort ins System starten und dies wird vom EFI verweigert - es muss ein Unterverzeichnis sein bzw. eine Anwendung (z.B. startuo.nsh) zwischengeschaltet sein.

Eine startup.nsh habe ich bisher noch nirgendwo gesehen. Es sei denn die wäre Bestandteil einer efi-Datei. Ich habe aber von der startup.nsh auch bisher weder gehört noch habe ich sonst irgendwie eine Ahnung davon.

Das grundlegende Problem ist, dass man keine Möglichkeit zum Überprüfen hat - zumindest keine mir bisher bekannte - wie ich feststellen könnte in wie weit das EFI jetzt etwas abgearbeitet hat oder nicht.

• 2. Durchführung:

  • Der kopierte \Boot\Bootx64.efi ist von MS selbst. Er macht verschiedene administrative Dinge: 1. Ins Unterverzeichnis (also sein eigenes /Microsoft/Boot/) wechseln. 2. Dort überprüft er den abgelegten bootmgrfw.efi, ob er auch von MS ist (Hashwerte oder wie auch immer). 3. War dies ebenfalls erfolgreich, dann wird ein Menue-Eintrag geschrieben und jetzt erst der bootmgrfw.efi zur Ausführung gebracht.

Dazu habe ich jetzt mal noch folgendes gemacht:

• \Boot\Bootx64.efi gelöscht

• Windows Eintrag im NVRAM gelöscht

• bootmgr.efi in \Microsoft\Boot umbenannt und damit nur \Microsoft\boot\bootmgrfw.efi übriggelassen. Das ist die Datei bzw. der Pfad auf den der Windows-Eintrag - der automatisch angelegt wird - lautet.

Ergebnis: Nach Ausschalten und Neustarten, ist der Windows-Eintrag wieder da und Windows lässt sich damit starten.

Für mich spricht das mehr dafür, dass das EFI diesen Eintrag selbständig generiert.

• 3. Durchführung:

  • Da die Bedingungen aus der 2. Durchführung nun erfüllt waren, wurde der /Microsoft/Boot/bootmgrfw.efi gestartet.

Dafür braucht es aber den /EFI/Boot/bootx64.efi nicht, wie ich eben siehe vorhergehnder Absatz zu Deinen Kommentaren zum 2. Durchlauf, gezeigt habe.

1. Es sind halt immer noch viele Fragen offen, z.B.:

Das ist klar und ich möchte hier noch mal darauf hinweisen, dass diese Testreihe mit bereits vollständig Installationen auf einer interne Festplatte stattgefunden haben. Ob das einen Unterschied zu anderen Bootmedien macht, weiß ich noch nicht sicher - soweit bin ich noch nicht - vermute es aber im Moment stark.

• Was passiert, wenn Du statt dem MS/Bootx64.efi den von einem Ubuntu nimmst, der der im Image unter /efi/boot/ liegt? Das käme meiner Vermutung (Restriktion in der Ausführung) schon nahe. Dieser lädt anscheinend nur die grub.cfg (loopback.cfg?) aus dem Verzeichnis /boot/grub, also kein Systemstart. Aus diesem Menue wird ja dann wieder auf einen anderen Standort verwiesen (hier casper....) und dann erst gestartet.

Das habe ich jetzt erst mal ausgelassen - auch weil ich hier noch nicht durchsteige in wie weit dieser Test etwas beweisen soll. Da denke ich später noch mal drüber nach.

• Kann man aus der Built-In Shell manuell starten? z.B. mit so etwas ähnlichem:

  fs0:
  ls
  cd /unterverzeichnis
  grub64x.efi

  entnommen aus diesem pdf

Das manuelle Booten klappt schon mal und zwar genau so. Eine EFI-Datei muss dabei tatsächlich auch auf .efi enden. Ist also so, wie man es von MS-Systemen gewohnt ist. Dateien werden nur anhand ihrer Endung richtig erkannt.

Also eine bootx64.old kann man z.B. über die Shell so nicht laden. Auch wenn die bootx64.old bis auf das ".old" tatsächlich eine EFI-Datei ist - also nur bezüglich der Endung umbenannt wurde.

• Wenn das manuelle booten klappt, dann könnte man eine startup.nsh mit diesen Kommandos anlegen. Die muss mMn im /boot/efi/ liegen, also im / der EFI-Partition, vor dem /EFI/.

Das hat jetzt zumindest mal unter der Maßgabe funktioniert, dass

• Ich den Windows-Eintrag im NVRAM gelöscht habe.

• Die EFI-Dateien in /EFI/Boot und /EFI/Microsoft/Boot umbenannt habe, so dass sie das EFI nicht finden konnte.

• Die startup.nsh in /EFI/Boot abgelegt habe.

• Die startup.nsh den Ubuntu-EFI-Loader (grubx64.efi) startet - Code wie in den Einzelschritten. (Einen anderen Ort für die startup.nsh habe ich jetzt noch nicht probiert)

Damit ließe sich in der Tat nun ein efibootmgr-Problem umgehen. Dabei muss man allerdings beachten, dass nicht jedes EFI-System die Shell mitbringt. Bei dem Lenovo war das damals so, allerdings konnte ich da eine EFI-Shell nachladen und zwar so, wie das im Arch-Wiki beschrieben ist. Mit startup.nsh habe ich auf dem Lenovo aus Zeitgründen nicht mehr experimentieren können.

Man kann nun weiterhin aus GRUB heraus den folgenden Eintrag laden:

 menuentry "Windows 7 UEFI" {
    insmod fat
    search --fs-uuid --no-floppy --set=root 6050-A107
    chainloader (${root})/efi/Microsoft/Boot/bootmgfw.old

Den Pfad /efi/Microsoft/Boot darf man dabei nicht ändern, weil der in der bootmgfw.efi enthalten ist und von dort den BCD-Store nachlädt. Was ich jetzt noch nicht getestet habe, inwieweit es im laufenden Windows-Betrieb zu Problemen kommt - z.B. auch bei Updates - wenn die bootmgfw.efi und die bootmgr.efi jeweils auf die Endung .old enden.

Da wären Komplikationen denkbar. Energiesparmodi etc..

Ansich aus GRUB heraus ist das System aber erst mal startbar.

• Wird diese immer automatisch ausgeführt?

Ja, und zwar über die EFI-Shell. Sofern man ein Board mit integierter EFI-Shell hat, dann kann man auch bestimmen, an welcher Position die Shell in der Bootreihenfolge steht.

In dem Fall kann man sich dann das Umbenennen sparen. Aber praktisch getestet habe ich das jetzt noch nicht.

Gruß, Martin

Newubunti schrieb:

Eine startup.nsh habe ich bisher noch nirgendwo gesehen. Es sei denn die wäre Bestandteil einer efi-Datei. Ich habe aber von der startup.nsh auch bisher weder gehört noch habe ich sonst irgendwie eine Ahnung davon.

Darum hatte ich den Link zu einem Intel-PDF gelegt: ftp://87.249.47.106/DiVS_Software/Board_Drivers/MB/S3420GP/GP_06_03_2010/EFIScripts/EFI_Instructions.pdf. Kurze Erklärung für die Mitleser: Dabei handelt es sich eigtl. um die alt-bekannte BAT-Datei speziell auf EFI ausgerichtet. Sie sollte lt. Spezifikationen im Root-Verzeichnis / liegen und sollte dann auch autom. ausgeführt werde. Ob sie auch aus dem /Boot automatisch startet bleibt noch zu klären. Inhalte sind eben auch die von Dir gemachten Ladekommandos.

Das grundlegende Problem ist, dass man keine Möglichkeit zum Überprüfen hat - zumindest keine mir bisher bekannte - wie ich feststellen könnte in wie weit das EFI jetzt etwas abgearbeitet hat oder nicht.

Nicht ausprobiert, aber es gibt ja auch eine erweiterte EFI-Shell, die 2.0, (hier mal ein Link ins Arch-Wiki, incl. ⮷-Angebot ist Dir bereit bekannt), die kennt eine DUMP-Funktion

Shell> bcfg bootx64 dump -v

Ergebnis: Nach Ausschalten und Neustarten, ist der Windows-Eintrag wieder da und Windows lässt sich damit starten.

Das unterstützt teils meine alte These ,hier mit Deiner kombiniert:

Für mich spricht das mehr dafür, dass das EFI diesen Eintrag selbständig generiert.

Das Board ist eben auf den /Microsoft/Boot ausgelegt und reagiert sofern vorhanden - Eintrag und Ausführung (da nicht im Hauptverzeichnis klappt es). Beantwortet aber noch nicht die Frage, ob aus dem /Boot direkt gestartet werden darf oder es den Umweg über eines Unterverzeichnisses bedarf bzw. was passier bei dem Ubuntu-Bootx64.

• 3. Durchführung:

  • Da die Bedingungen aus der 2. Durchführung nun erfüllt waren, wurde der /Microsoft/Boot/bootmgrfw.efi gestartet.

Dafür braucht es aber den /EFI/Boot/bootx64.efi nicht, wie ich eben siehe vorhergehnder Absatz zu Deinen Kommentaren zum 2. Durchlauf, gezeigt habe.

Da tappen wir weiterhin im Dunkeln ☹, siehe auch vorheriger Absatz.

• Was passiert, wenn Du statt dem MS/Bootx64.efi den von einem Ubuntu nimmst, ...

Das habe ich jetzt erst mal ausgelassen - auch weil ich hier noch nicht durchsteige in wie weit dieser Test etwas beweisen soll. Da denke ich später noch mal drüber nach.

Bei Deinem 3. Durchlauf waren eben beide Loader von MS. Im 2. Durchlauf wurde nicht gestartet, da ich vermute das die miteinander kommunizieren. Interessant bleibt weiterhin die Frage nach dem "Was macht der Ubuntu/Bootx64":

• Kann der Im Ubuntuverzeichnis liegen und dann über eine startup (weiter unten) automatisch aufgerufen werden?

• Wohin genau verweist dieser GRUB, auf welche grub.cfg (/boot/grub ...) ?

Das manuelle Booten klappt schon mal und zwar genau so.

Das ist super 👍 .

Also eine bootx64.old kann man z.B. über die Shell so nicht laden. Auch wenn die bootx64.old bis auf das ".old" tatsächlich eine EFI-Datei ist - also nur bezüglich der Endung umbenannt wurde.

Das habe ich mittlerweile auch herausgefunden. Liegt wohl daran, dass die Extensionen entweder efi oder nsh lauten müssen (analog zu Win exe,com,bat), um autom. gestartet zu werden. In anderen startup.nsh-Dokumentation (genau diese Lade-Kommandos kann man ja dort hinterlegen) wird der Ladeteil auch in Kurzform ausgeführt:

fs0:
cd \unterverzeichnis
grub64x
   ODER
fs0:\unterverzeichnis\grub64x
   ODER eben auch über ein (weiteres) startup-Skript mit frei wählbarem Namen (eclusive Ext.):
fs1:\unterverzeichnis\grub

Das hat jetzt zumindest mal unter der Maßgabe funktioniert, dass

Das könnte im Notfall hilfreich sein, evtl. auch im Zusammenhang mit dem Ubunt-Bootx64 und/oder einem startup-Skript.

Damit ließe sich in der Tat nun ein efibootmgr-Problem umgehen. Dabei muss man allerdings beachten, dass nicht jedes EFI-System die Shell mitbringt. Bei dem Lenovo war das damals so, allerdings konnte ich da eine EFI-Shell nachladen und zwar so, wie das im Arch-Wiki beschrieben ist. Mit startup.nsh habe ich auf dem Lenovo aus Zeitgründen nicht mehr experimentieren können.

Ups, dann hatten die wohl noch keine Built-In Shell bereitgestellt. Hoffen wir mal, dass dies bei neuen Boards zum Standard gehört.

Man kann nun weiterhin aus GRUB heraus den folgenden Eintrag laden:

 menuentry "Windows 7 UEFI" {
    insmod fat
    search --fs-uuid --no-floppy --set=root 6050-A107
    chainloader (${root})/efi/Microsoft/Boot/bootmgfw.old

Den Pfad /efi/Microsoft/Boot darf man dabei nicht ändern, weil der in der bootmgfw.efi enthalten ist und von dort den BCD-Store nachlädt.

Danke, dass ist nochmals positiv, auch dass dann die Extension nicht zwingend ist. Bleibt zum wiederholten male die Frage nach: "Was passiert beim /Ubuntu-Loader" bzw. bei dem /Boot/bootx64 von Ubuntu?

Was ich jetzt noch nicht getestet habe, inwieweit es im laufenden Windows-Betrieb zu Problemen kommt - z.B. auch bei Updates - wenn die bootmgfw.efi und die bootmgr.efi jeweils auf die Endung .old enden.

Das wäre ein Windosproblem 😠. Wichtiger ist, was passiert bei den so gestarteten Ubuntuloadern bei Ubuntu?

Danke für die ausführlichen Infos.

Saludos aus Chile
RapaNui

RapaNui schrieb:

Ok, Grub wird weiterentwickelt, dennoch ist unklar worum es bei den neuen Einträgen genau geht.

1. Sie sind aus einer aufgebauten grub.cfg (oder?) und unterstützen damit die Zuweisung der nachfolgenden Einträge.

Dieser Auszug stammt aus einer nach update-grub generierten grub.cfg.

2. Sie erscheinen z.Zt. im Themenbereich (05_debian_theme) und das könnte auf Erweiterungen dazu schließen lassen.

Nein das war nur ein Auszug - diese Kombination aus if >> else >> fi findet sich auch in allen Menüeinträgen.

3. Es wurden zwar neue search-Argumente eingebaut, aber das --hint-bios= --hint-efi= deutet mehr auf die verschiedenen Betriebsarten hin.

Da kann ich zur Zeit noch kein Band dran fest machen - ich schaue mir das aber an. Möglicherweise wird das aber auch zum Aufbau der grubx64.efi herangezogen, denn es wird ja innerhalb der übergeordnetetn Lib-Datei

• /usr/share/grub/grub-mkconfig_lib

(ab Grub-Version 2.0, Quetzal) aufgebaut/ausgewertet. Und zumindest aus dem Aufbau kann man ja ersehen, dass das Vorhandensein einer dieser Ausdrücke, bei entsprechender Auswertung auf eine dann unterschiedliche UUID verweist.

gruß syscon-hh

RapaNui schrieb:

Newubunti schrieb:

Eine startup.nsh habe ich bisher noch nirgendwo gesehen. Es sei denn die wäre Bestandteil einer efi-Datei. Ich habe aber von der startup.nsh auch bisher weder gehört noch habe ich sonst irgendwie eine Ahnung davon.

Darum hatte ich den Link zu einem Intel-PDF gelegt: ...

Ich war da an dieser Stelle davon ausgegangen, dass Du eine Startup.nsh als Bestandteil von Ubuntu oder Windows meinst. Ist aber jetzt auch egal, da sich dass Missverständnis meinerseits im Laufe der Tests geklärt hat.

Das grundlegende Problem ist, dass man keine Möglichkeit zum Überprüfen hat - zumindest keine mir bisher bekannte - wie ich feststellen könnte in wie weit das EFI jetzt etwas abgearbeitet hat oder nicht.

Nicht ausprobiert, aber es gibt ja auch eine erweiterte EFI-Shell, die 2.0, (hier mal ein Link ins Arch-Wiki, incl. ⮷-Angebot ist Dir bereit bekannt), die kennt eine DUMP-Funktion

Shell> bcfg bootx64 dump -v

Die 2.0 Shell habe ich weder auf dem Lenovo noch auf dem ASROCK - das auch eine Built-in Shell hatte - zum laufen gebracht. Auf dem MSI habe ich es jetzt noch nicht probiert - kann ich auch frühstens heute abend testen. Ich befürchte aber, das wird auf dem MSI genauso sein.

Bei den Built-in Shell vom AROCK und vom MSI gibt es das Kommando bcfg nicht.

Ergebnis: Nach Ausschalten und Neustarten, ist der Windows-Eintrag wieder da und Windows lässt sich damit starten.

Das unterstützt teils meine alte These ,hier mit Deiner kombiniert:

Für mich spricht das mehr dafür, dass das EFI diesen Eintrag selbständig generiert.

Das Board ist eben auf den /Microsoft/Boot ausgelegt und reagiert sofern vorhanden - Eintrag und Ausführung (da nicht im Hauptverzeichnis klappt es). Beantwortet aber noch nicht die Frage, ob aus dem /Boot direkt gestartet werden darf oder es den Umweg über eines Unterverzeichnisses bedarf bzw. was passier bei dem Ubuntu-Bootx64.

• 3. Durchführung:

  • Da die Bedingungen aus der 2. Durchführung nun erfüllt waren, wurde der /Microsoft/Boot/bootmgrfw.efi gestartet.

Dafür braucht es aber den /EFI/Boot/bootx64.efi nicht, wie ich eben siehe vorhergehnder Absatz zu Deinen Kommentaren zum 2. Durchlauf, gezeigt habe.

Da tappen wir weiterhin im Dunkeln ☹, siehe auch vorheriger Absatz.

• Was passiert, wenn Du statt dem MS/Bootx64.efi den von einem Ubuntu nimmst, ...

Das habe ich jetzt erst mal ausgelassen - auch weil ich hier noch nicht durchsteige in wie weit dieser Test etwas beweisen soll. Da denke ich später noch mal drüber nach.

Bei Deinem 3. Durchlauf waren eben beide Loader von MS. Im 2. Durchlauf wurde nicht gestartet, da ich vermute das die miteinander kommunizieren.

Ne, die kommunizieren offenbar nicht miteinander. Dafür spricht im übrigen auch, dass md5sum von /EFI/Boot/bootx64.efi und /EFI/Microsoft/Boot/efibootmgfw.efi gleich sind. Daneben gibt es wie gesagt noch eine /EFI/Microsoft/Boot/bootmgr.efi die einen anderne Hashwert hat.

Diese Datei wird für den Systemstart aber nach meinen Tests nichts gebraucht.

Da beim MSI-Board das Verzeichnis /EFI/Boot aber scheinbar ignoriert wird - was die interne Festplatte anbelangt - habe ich die die /EFI/Boot/bootx64.efi mal über die EFI-Shell geladen, wobei ich die /EFI/Microsoft/Boot/efibootmgfw.efi und die /EFI/Microsoft/Boot/efibootmgr.efi dabei gelöscht hatte.

Ergebnis: Windows wird gestartet.

Das einzige was man wie gesagt nicht machen sollte ist das Umbenennen des Pfades /EFI/Microsoft/Boot, weil da eben noch die für den Windows-Start wichtige Datei BCD enthalten ist und dieser Pfad fester Bestandteil von bootmgfw.efi und bootx64.efi ist.

Interessant bleibt weiterhin die Frage nach dem "Was macht der Ubuntu/Bootx64":

Welchen meinst Du da jetzt? Den von der Ubuntu-Installations-CD?

• Kann der Im Ubuntuverzeichnis liegen und dann über eine startup (weiter unten) automatisch aufgerufen werden?

Du kannst IMO über die EFI-Shell jede EFI-Boot-Anwendung laden, die auf .efi endet. Wo die liegt ist dabei egal. Du kannst ja den Pfad angeben bzw. mit cd dort hinwechseln (mittels startup.nsh).

• Wohin genau verweist dieser GRUB, auf welche grub.cfg (/boot/grub ...) ?

Das manuelle Booten klappt schon mal und zwar genau so.

Damit ließe sich in der Tat nun ein efibootmgr-Problem umgehen. Dabei muss man allerdings beachten, dass nicht jedes EFI-System die Shell mitbringt. Bei dem Lenovo war das damals so, allerdings konnte ich da eine EFI-Shell nachladen und zwar so, wie das im Arch-Wiki beschrieben ist. Mit startup.nsh habe ich auf dem Lenovo aus Zeitgründen nicht mehr experimentieren können.

Ups, dann hatten die wohl noch keine Built-In Shell bereitgestellt. Hoffen wir mal, dass dies bei neuen Boards zum Standard gehört.

Also bei einem im Handel erhältlichen Mainboard gehe ich mal davon aus, dass in der Regel eine EFI-Shell enthalten sein wird.

Bei OEM-Geräte kann ich mir vorstellen, dass es da häufiger an einer Shell fehlen wird. Insbesondere bei Laptops, die tratditionell in der Regel mit spartanischen BIOS-Einstellungen aufwarten.

Bleibt zum wiederholten male die Frage nach: "Was passiert beim /Ubuntu-Loader" bzw. bei dem /Boot/bootx64 von Ubuntu?

Die /Boot/bootx64.efi von Ubuntu gibt es ja nur auf dem Ubuntu-Installations-Medium, nicht bei einem installiertem Ubuntu.

Wechselmedien sind dann für mich noch mal eine extra Testreihe. Das kommt dann später. Wie gesagt: Zeitkontingent knapp!

Das wäre ein Windosproblem 😠. Wichtiger ist, was passiert bei den so gestarteten Ubuntuloadern bei Ubuntu?

Ähm, nein! Wenn man von außen ohne Windows etwas an den Bootdateien oder deren Pfad ändert, dann ist das kein Windows-Problem sondern eines, dass durch den Nutzer selbst oder durch die Applikation, die das entsprechend ändert verursacht wird. Wie soll Windows da drauf reagieren können.

Bennene von einem Live-System die /boot/grub/grub.cfg in /boot/grub/rauschenimwald.fun um. Dann kann das installierte Ubuntu auch nichts dafür, dass erst mal nicht mehr starten kann.

Allerdings:

In der Zwischenzeit habe ich noch ein wenig weiter getestet. Zumindest bei dem MSI-Board ist es möglich. Die EFI-Shell als erstes Boot-Device festzulegen. Damit kann man sämtliche Windows-Pfade und Dateien unangetastet lassen. Das Booten funktioniert jetzt wie folgt:

• EFI-Shell im EFI-Setup als erstes EFI-Boot-Device eingestellt.

• startup.nsh wurde in /EFI/Boot angelegt, wird auch nur in dem Pfad von der EFI-Shell gefunden (funktioniert nicht in /EFI!) und hat folgenden Inhalt:

  fs0:
  cd \EFI\ubuntu
  grubx64.efi

• /etc/grub.d/40_custom enthält den bekannten Eintrag für Windows:

  menuentry "Windows 7 UEFI" {
      search --fs-uuid --no-floppy --set=root 6050-A107
      chainloader (${root})/efi/Microsoft/Boot/bootmgfw.efi

Das System startet dann so:

• EFI-POST

• EFI-Shell wird geladen und zeigt 5 Sekunden Countdown für "ESC" um an Shell-Prompt zu wechseln

• Nach 5 Sekunden wird sichtbar die startup.nsh abgearbeitet und somit dann GRUB von der Ubuntu-Installation geladen.

• Über GRUB-Menü kann man dann Windows laden.

Eine funktionierende Lösung, für mich aber nur in Problemfällen. Weil der EFI-Countdown auf dauer nervt, und das Zwangs-GRUB-Menü auch. Aber für Härtefälle auf alle Fälle besser als nichts.

Gruß, Martin

Newubunti schrieb:

Interessant bleibt weiterhin die Frage nach dem "Was macht der Ubuntu/Bootx64":

Welchen meinst Du da jetzt? Den von der Ubuntu-Installations-CD?

Ja, die meine ich immer, wenn ich von Ubuntu/Bootx64 schreibe, kann man ja einfach aus der CD herauskopieren. Da aber die im Loader hinterlegen Verweise auf das /boot/grub identisch sein sollten, müsste der, rein theoretisch, auch auf einem installierten System einsetzbar sein. Darum immer meine Nachfrage: Was macht der? (Bei Win kann man übrig. den eig. Loader der CD auf einen vorbereiteten USB ziehen und der startet dann auch.)

Danke für den Rest der Infos.

Saludos aus Chile

Edit:

• startup.nsh wurde in /EFI/Boot angelegt, wird auch nur in dem Pfad von der EFI-Shell gefunden (funktioniert nicht in /EFI!)

Dabei meinte ich /, so wie bei normalen Windowssystemen der Bootloaderteil auch in der Wurzel liegt.

P.S. So jetzt geh ich feiern. Wir haben hier Nationalfeiertag (18./19. und heute da Sonntag) und das sind 3 Tage lang Fiesta, Fiesta Fiesta 😊

Hallo Martin - ich verstehe im Moment nicht ganz Deinen Ansatz??

Ich habe mir für eine Reparatur bzw. zum externen Starten einfach einen 1GB USB-Stick mit UNetbootin (aktuelles Daily Quetzal) angelegt und mit diesem kann ich alles - sowohl einen EFI-Start als auch einen normalen Start bzw. Bearbeitung realisieren. Dazu habe ich auf diesem Stick die dortige Datei

• /boot/grub/gruib.cfg

ergänzt um:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

menuentry "Ubuntu von Festplatte nachladen" {
	set gfxpayload=keep
	insmod gzio
	insmod part_gpt
	insmod ext2
	insmod btrfs
	set root=''
	if search -n -f --set=root /@/boot/grub/grub.cfg; then
	configfile    /@/boot/grub/grub.cfg; fi
}
menuentry "Windows von Festplatte nachladen" {
    search -n -f --set=root /EFI/Microsoft/Boot/bootmgfw.efi
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}

also angepasst an spezielle Bedürfnisse - jeder andere Eintrag ist möglich. Das ergibt dann mit Grub Version 2.0 u.a. die im Anhang dargestellten Informationen (ja - ich war zu faul alles abzuschreiben). Hier auch gleich zusätzliche Info für RapaNui - ja das wird hinsichtlich EFI ausgewertet..

syscon-hh schrieb:

Hallo Martin - ich verstehe im Moment nicht ganz Deinen Ansatz??

Der Ansatz ist dabei mal in erster Linie, den ganzen Ablauf zu verstehen und wie man das ganze rein intern ohne Hilfe eines externen Bootsticks verwirklichen kann.

Dass es mit einem USB-Medium einfacher geht, weil dort in der Regel /EFI/boot/bootx64.efi greift, ist für mich nach meinem bisherigen Verständnis und Erfahrung schon klar.

Ebenso ist mir klar, dass das, was sich jetzt auf dem MSI-Board zeigt, auf einem anderen Board/System wieder anders aussehen kann.

Die jetzt gefunden Lösung ist dabei jetzt so schlecht nicht. Aber wie gesagt, in erster Linie geht es mir persönlich um das Verständnis.

Ich habe mir für eine Reparatur bzw. zum externen Starten einfach einen 1GB USB-Stick mit UNetbootin (aktuelles Daily Quetzal) angelegt und mit diesem kann ich alles - sowohl einen EFI-Start als auch einen normalen Start bzw. Bearbeitung realisieren. Dazu habe ich auf diesem Stick die dortige Datei

• /boot/grub/gruib.cfg

ergänzt um:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

menuentry "Ubuntu von Festplatte nachladen" { set gfxpayload=keep insmod gzio insmod part_gpt insmod ext2 insmod btrfs set root='' if search -n -f --set=root /@/boot/grub/grub.cfg; then configfile /@/boot/grub/grub.cfg; fi } menuentry "Windows von Festplatte nachladen" { search -n -f --set=root /EFI/Microsoft/Boot/bootmgfw.efi chainloader /EFI/Microsoft/Boot/bootmgfw.efi }

Ja, im Prinzip ist das ein Light-Ansatz der Super-GRUB-Disk. Das geht dann auf jeden Fall auch auf Systemen ohne EFI-Shell.

Gruß, Martin