staging.inyokaproject.org

syscon-hh schrieb:

Hallo RapaNui - gute Informationen!!!

Nur liegt das Problem leider woanders → Die Bezeichnungen / Verzeichnisse, die Ubuntu auf die EFI-Partition schreibt, stimmen mit der EFI-Spezifikation nicht überein:

• Soll der Verzeichnisse:

  • EFI → boot → grubx64.efi

• Ist bei Ubuntu

  • EFI → ubuntu → grubx64.efi

Wobei die Schreibweise (groß / klein) des Leadvolume sowie die Bezeichnung der Datei egal ist, solange die Endung efi lautet.

Nachdem ich das händisch umgestellt habe, wird das auch korrekt angezeigt und ist auswählbar.

Kann jemand mal diesen Sachverhalt überprüfen.

Ich kann das Problem jetzt ehrlich gesagt nicht ganz nachvollziehen, weil mir nicht klar ist, was Du alles wann genau gemacht hast.

Mit den Verzeichnissen auf der ESP ist es so, dass sie dem Schema:

\EFI\<Hersteller-spezifisches bzw. Distributions-spezifisches Verzeichnist>\*.efi

genügen müssen. Was Ubuntu macht, ist also absolut innerhalb der Spezifikation und so wie es sein soll. Würden alle Linux-Distributionen, die GRUB nutzen, in /EFI/grub/grubx64.efi ablegen, dann würden sie sich jeweils gegenseitig den Bootloader überschreiben. Der Sinn von EFI und der ESP ist es ja nun aber gerade, dass die Bootloader sich nicht mehr gegenseitig überschreiben, sondern neben einander koexistieren können.

Du musst bitte zu jedem Problem, dass Du mit dem Start im EFI hast bitte immer

sudo efibootmgr --verbose

angeben. Damit sieht man nämlich den genauen hinter dem Boot-Eintrag im EFI-Boot-Menü steckenden Pfad. Dieser Pfad verwendet die unique GUID (siehe Auflistung mit sgdisk -i) der ESP, um auf den Eintrag zuzugreifen. D.h. wenn Du neu installierst und dabei eine neue ESP anlegen lässt oder eine vorhandene ESP formatierst, dann funktionieren die vor dieser Aktion angelegten Einträge nicht mehr auch wenn Du die Verzeichnisse so wählst wie vorher oder ein Verzeichnis-Backup zurückspielst. Du müsstest dann auch noch die GUID auf die alte zurück ändern.

Gruß, Martin

So ich muss jetzt aufgeben - das Gerät muss Montag wieder an Ort und stelle stehen.

Meine letzten Versuche auf der Systemebene im EFI-Modus ergaben:

root@ubuntu:/# efibootmgr --verbose
BootCurrent: 000C
Timeout: 2 seconds
BootOrder: 000C,0008,000B,000A
Boot0008* Optiarc DVD RW AD-7290H
Boot000A* IBA GE Slot 00C8 v1381
Boot000B* WDC WD1600BEVS-00RST0
Boot000C* UEFI: Optiarc DVD RW AD-7290H

root@ubuntu:/# grub-install /dev/sda
BootCurrent: 000C
Timeout: 2 seconds
BootOrder: 0000,000C,0008,000B,000A
Boot0008* Optiarc DVD RW AD-7290H
Boot000A* IBA GE Slot 00C8 v1381
Boot000B* WDC WD1600BEVS-00RST0
Boot000C* UEFI: Optiarc DVD RW AD-7290H
Boot0000* ubuntu
Installation finished. No error reported.

Die weiteren Versuche mit (alternativ):

root@ubuntu:/# efibootmgr -a -b 0000

root@ubuntu:/# efibootmgr --create --disk /dev/sda --part 1 --label "Precise - GRUB2" --loader '\EFI\ubuntu\grubx64.efi'

ergeben zwar auch obige Ausgaben (zweiter Teil), jedoch erscheint das nicht mehr im EFI-Menü des Rechners. Es ist wohl so, dass dieser Hinweis zutrifft. Da das auf einer anderen Maschine bei gleichem AMI BIOS-core Daten realisierbar war, vermute ich hier eine kleine Schweinerei seitens FUJITSU.

Sofern ich obige HD über eine USB-Umgebung einstecke, dann wird diese ordnungsgemäß angezeigt (zwei Einträge), nur startet dieser Eintrag auf selbiger Maschine nicht.

syscon-hh schrieb:

So ich muss jetzt aufgeben - das Gerät muss Montag wieder an Ort und stelle stehen.

Trotzdem schon mal Danke, für das Ausprobieren! 👍

Meine letzten Versuche auf der Systemebene im EFI-Modus ergaben:

root@ubuntu:/# efibootmgr --verbose
BootCurrent: 000C
Timeout: 2 seconds
BootOrder: 000C,0008,000B,000A
Boot0008* Optiarc DVD RW AD-7290H
Boot000A* IBA GE Slot 00C8 v1381
Boot000B* WDC WD1600BEVS-00RST0
Boot000C* UEFI: Optiarc DVD RW AD-7290H

root@ubuntu:/# grub-install /dev/sda
BootCurrent: 000C
Timeout: 2 seconds
BootOrder: 0000,000C,0008,000B,000A
Boot0008* Optiarc DVD RW AD-7290H
Boot000A* IBA GE Slot 00C8 v1381
Boot000B* WDC WD1600BEVS-00RST0
Boot000C* UEFI: Optiarc DVD RW AD-7290H
Boot0000* ubuntu
Installation finished. No error reported.

Die weiteren Versuche mit (alternativ):

root@ubuntu:/# efibootmgr -a -b 0000

root@ubuntu:/# efibootmgr --create --disk /dev/sda --part 1 --label "Precise - GRUB2" --loader '\EFI\ubuntu\grubx64.efi'

ergeben zwar auch obige Ausgaben (zweiter Teil), jedoch erscheint das nicht mehr im EFI-Menü des Rechners. Es ist wohl so, dass dieser Hinweis zutrifft. Da das auf einer anderen Maschine bei gleichem AMI BIOS-core Daten realisierbar war, vermute ich hier eine kleine Schweinerei seitens FUJITSU.

Den Hinweis habe ich aufgrund der Erfahrung mit dem Lenovo ThinkCenter M81 eingefügt. Auch wenn ich erst mal nicht alles im Detail nachvollziehen kann, was Du genau gemacht hast, sieht man hier sehr starke Parallelen zwischen beiden Systemen - nicht nur wegen der sehr ähnlichen Screenshots.

Auf dem ThinkCentre hatte ich übrigens nur auf interne HD installiert, mit einer USB-HD habe ich das nicht getestet. Ich gehe aber aufgrund Deiner Beschreibung sehr stark davon aus, dass das mit einer USB-HD genauso ausgegangen wäre, wie bei dem Fujitsu.

Beiden Systemen gemein ist ja auch, dass sie im Prinzip EFI rudimentär unterstützen, aber als BIOS-Installation (MBR-Schema) vorinstalliert sind. Ich kann mir gut vorstellen, dass die EFI-Fähigkeit des Systems - wenn überhaupt - nur hinsichtlich Windows getestet wurde. Denn so richtig EFI - wie es beim ASROCK-Mainboard ist - ist das zumindest hinsichtlich des Bootens nicht.

Was mich an dem Fujitsu noch interessiert hätte ist, wie efibootmgr --verbose aussieht, wenn auf die interne Platte Windows im EFI-Modus installiert ist. Das ist nämlich eine Ausgabe, die in meinem Aufzeichnungen zum Lenovo fehlt.

Sofern ich obige HD über eine USB-Umgebung einstecke, dann wird diese ordnungsgemäß angezeigt (zwei Einträge), nur startet dieser Eintrag auf selbiger Maschine nicht.

Sieht da dann efibootmgr --verbose genauso aus, wie Du hier gepostet hast?

Gruß, Martin

Hola,

was mich ein wenig verwundert ist, dass syscon-hh als root arbeitet, aber der efibootmgr --verbose listet nur die Kurzform. Ein ähnliches Verhalten gab es hier, es sollte ein blkid unter chroot ausgeführt werden und es gab keine Infos bzw. nur mit zusätzlichem sudo (Ob das chroot dort richtig eingerichtet war k.A.).

Kann es sein, dass da die Änderung bei sudo (Benutzer und Gruppen (Abschnitt „Gruppen“) admin>sudo) hineinspielt? Wenn dem so wäre, also ein Berechtigungsproblem vorliegt, dann macht es ja auch Sinn, dass der neue Eintrag nicht übernommen wurde.

Die Auszüge oben sind ja alle in der chroot-Umgebung entstanden → und da geht es nur mit sudo rein und dann bleibt man innerhalb dieses Systemes ein Root.

Ich habe alle Varianten durchgespielt (mit und ohne sudo) - das mit dem Setzen über

• efibootmgr

auch innerhalb des Livesystemes (also ohne in das System zu wechseln). Sowohl die Anzeigen als auch das Ergebnis war immer gleich - also geht nicht.

Diese Maschine werde ich noch mal Überprüfen - auch ob es dort von AMI direkt ggf. ein BIOS-Update gibt.

Meine Aufgabe hier war ja, diese Maschine dahingehend zu überprüfen, ob wir unsere alten HD's, samt Inhalt ohne viel Aufwand dort einsetzen können - da gab es schon mal für uns positive Ergebnisse.

RapaNui schrieb:

Hola,

was mich ein wenig verwundert ist, dass syscon-hh als root arbeitet, aber der efibootmgr --verbose listet nur die Kurzform.

Das ist höchst wahrscheinlich die Langform, wie sie dieses EFI hergibt. Ich habe damals auf dem ThinkCentre im Prinzip die gleicher Erfahrung gemacht. Nur hatte ich dort nie efibootmgr --verbose ausgeführt, weswegen ich jetzt keine Ausgabe habe, die das noch belegen würde.

efibootmgr hat eben nur insoweit Einfluss auf das NVRAM und die dortigen Boot-Einträge, wie es das EFI zulässt oder wie es die Schnittstelle zulässt. Möglich ist aber auch, dass es an efibootmgr selbst liegt. Leider bietet das ja keine --debug-Funktion, so dass man nicht nachvollziehen kann, was genau im Hintergrund abläuft und dabei gut oder schief geht.

Auch mit einer EFI-Shell, war es mir damals beim ThinkCentre nicht möglich, irgendwie an die NVRAM-Variablen - soweit sie das Booten betreffen - zu gelangen. Allerdings konnte ich auch nicht alles durchprobieren, weil ich es erstens zu dem Zeitpunkt auch noch nicht so genau wusste und zweitens das System nur für zwei Tage hatte an deren Ende eine Dual-Boot-Installation stehen musste.

EFI ist auch nicht gerade leicht zu durchschauen. Das ist ziemlich komplex, was auch einer der Kritikpunkte an EFI ist. Schlecht dokumentiert ist es nicht. Es gibt 100erdet von Seiten, allerdings werden die gleich sehr technisch. Ich blicke da als nicht Programmierer nicht gleich durch.

Gruß, Martin

Man soll niemals aufgeben!! Es läuft 👍

Hier die aktuelle Anzeige im neuen System:

root@ESPRIMO-E710:/home/laura# efibootmgr --verbose
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,000D,0008
Boot0000* Ubuntu 12.04.1	HD(1,800,2f000,1d0dab44-30bd-470f-aa10-8786acefab59)File(\EFI\ubuntu\bootx64.efi)
Boot0008* Optiarc DVD RW AD-7290H	BIOS(3,0,00)AMBO
Boot000D* WDC WD1600BEVS-00RST0	BIOS(2,0,00)AMBO
root@ESPRIMO-E710:/home/laura#

Was habe ich gemacht??

• Das AMI BIOS untersucht

Dort gibt es einen Menüpunkt

• "Boot → Remove Invalid Boot Options"

Und dieser war auf [Enabled] gesetzt - nachdem ich diese Funktion ausgeschaltet hatte ([Disabled]), wurde schon mal der mit

sudo efibootmgr --create --disk /dev/sda --part 1 --label "Ubuntu 12.04.1" --loader '\EFI\ubuntu\grubx64.efi' 

gesetzte Eintrag im EFI-Menü angezeigt - jedoch startete dieser überhaupt nicht.

• ??? 💡 !!!

Ich erinnerte mich an die Versuche unter Windows, dass man dort immer die Datei ***.efi in

• bootx64.efi

ändern musste, damit diese vom EFI akzeptiert wurden - also auch das noch im EFI Livesystem geändert - die EFI Partition eingebunden und im Verzeichnis

• /boot/efi/EFI/ubuntu aus grubx64.efi → bootx64.efi

gemacht. Danach noch

sudo efibootmgr --delete-bootnum -b 0000 

sudo efibootmgr --create --disk /dev/sda --part 1 --label "Ubuntu 12.04.1" --loader "\EFI\ubuntu\bootx64.efi" 

gesetzt - alle sind glücklich!!

gruß syscon-hh

Was mich da jetzt noch interessieren würde:

Hast Du noch die efibootmgr --verbose Ausgabe, die den Ubuntu Eintrag im Menü zwar zeigt, aber der sich nicht starten ließ? Denn eigentlich habe ich hier mehr die Vermutung, dass beim alten Ubuntu-Eintrag, den Du aus dem NVRAM hervorgraben konntest, der aber nicht starten konnte, die UUID eine andere war, also der im folgenden markierte Teil:

Boot0000* Ubuntu 12.04.1 HD(1,800,2f000,1d0dab44-30bd-470f-aa10-8786acefab59)File(\EFI\ubuntu\bootx64.efi)

Wenn es nur an der Namensänderung gelegen hätte, dann hättest Du nach der Änderung grubx64.efi → bootx64.efi nicht noch mal,

sudo efibootmgr --create --disk /dev/sda --part 1 --label "Ubuntu 12.04.1" --loader "\EFI\ubuntu\bootx64.efi" 

ausführen müssen und das System hätte schon alleine durch die Namensänderung starten müssen - auch wenn in dem Fall ja schon mal nicht alles zwangsläufig logisch sein muss.

Ich muss jetzt mal im Lenovo Handbuch nachschauen, ob es da so eine Option auch gegeben hätte.

Gruß, Martin

EDIT:
Lenovo-Handbuch kann man vergessen. Ergo kann ich es derzeit nicht überprüfen. Erinnern kann ich mich an eine solche Option aber nicht, sonst hätte ich bestimmt mal mit der gespielt.

Newubunti schrieb:

Was mich da jetzt noch interessieren würde:

Boot0000* Ubuntu 12.04.1 HD(1,800,2f000,1d0dab44-30bd-470f-aa10-8786acefab59)File(\EFI\ubuntu\bootx64.efi)

Diese GUID ist seit dem ersten Einsatz immer gleich - das entspricht wohl der Zuordnung im BIOS-Speicher. Ich habe inzwischen das System auf den Originaleintrag von Grub zurückgesetzt. Das Problem scheint wohl mit dem Hinweis im WIKI begründet

• --loader '\EFI\ubuntu\grubx64.efi'

dass dieses mit Hochkomma einzuschließen sei - damit geht es scheinbar nicht (falsche Syntax??) - jedenfalls führt der Einschluss mit

• --loader "\EFI\ubuntu\grubx64.efi"

zum erwünschten Ergebnis → muss also noch mal extern verifiziert werden!!!

Nun bin ich am Austesten, wie ich die Anzeige so hinkriege, wie sich Windows darstellt (siehe Anlage EFI-Menü). Jedenfalls lassen sich jetzt sowohl Windows als auch Ubuntu dort auswählen und starten.

Ich habe dabei Windows nach Ubuntu im UEFI-Modus installiert - es sieht so aus:

laura@ESPRIMO-E710:~$ sudo efibootmgr --verbose
[sudo] password for laura: 
BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0001,000E,0008
Boot0000* Ubuntu 12.04.1 LTS	HD(1,800,2f000,1d0dab44-30bd-470f-aa10-8786acefab59)File(\EFI\ubuntu\grubx64.efi)
Boot0001* Windows Boot Manager	HD(1,800,2f000,1d0dab44-30bd-470f-aa10-8786acefab59)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................
Boot0008* Optiarc DVD RW AD-7290H	BIOS(3,0,00)AMBO
Boot000E* WDC WD1600BEVS-00RST0	BIOS(2,0,00)AMBO

laura@ESPRIMO-E710:~$ sudo parted -l
Modell: ATA WDC WD1600BEVS-0 (scsi)
Festplatte  /dev/sda:  160GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt

Nummer  Anfang  Ende    Größe   Dateisystem     Name                          Flags
 1      1049kB  99,6MB  98,6MB  fat32                                         boot
 2      99,6MB  78,6GB  78,5GB  ext4
 3      78,6GB  78,7GB  134MB                   Microsoft reserved partition  msftres
 4      78,7GB  156GB   77,2GB  ntfs            Basic data partition
 5      156GB   160GB   4142MB  linux-swap(v1)

laura@ESPRIMO-E710:~$ 

Hinsichtlich der Installation von Windows (zur Zeit nur 64bit) werde ich noch eine getrennte Beschreibung liefern (sofern erwünscht?). Es beweist aber, das Windows gar nicht so intollerant ist, wie das hier im Forum gerne dargestellt wird.

gruß syscon-hh

syscon-hh schrieb:

Diese GUID ist seit dem ersten Einsatz immer gleich - das entspricht wohl der Zuordnung im BIOS-Speicher. Ich habe inzwischen das System auf den Originaleintrag von Grub zurückgesetzt. Das Problem scheint wohl mit dem Hinweis im WIKI begründet

Das wurde von linrunner und Newubunti so beschlossen bzw. geändert, man wolte diesen Eintrag auf das Minimum zurückstuzt haben. Dabei sind auch die Angaben zu --gpt und --write-signature sowie die doppelten Hochkommata und jeweils ein Backslash entsorgt worden. In der Revision findet man den Originaleintrag i.d.F.

sudo efibootmgr --create --gpt --disk /dev/sda --part 1 --write-signature --label "Precise - GRUB2" --loader "\\EFI\\ubuntu\\grubx64.efi"

so wie es auch bei der Suche im Netz nach efibootmgr zu Tage tritt.

Anmerkung zu:

/boot/efi/EFI/ubuntu aus grubx64.efi → bootx64.efi

Anscheinend machen die EFI-Systeme eine Existenzprüng des Loaders (Name) und übernehmen den Eintrag nur wenn dieser vorhanden ist. Dein Board geht dabei wohl fix von bootx64.efi.

EDIT. Ich bin für das Zurückändern auf den, von mir hier angeführten, Originaleintrag zu create.

syscon-hh schrieb:

Newubunti schrieb:

Was mich da jetzt noch interessieren würde:

Boot0000* Ubuntu 12.04.1 HD(1,800,2f000,1d0dab44-30bd-470f-aa10-8786acefab59)File(\EFI\ubuntu\bootx64.efi)

Diese GUID ist seit dem ersten Einsatz immer gleich - das entspricht wohl der Zuordnung im BIOS-Speicher.

Gut, ich weiß jetzt nicht, wie oft Du auf diesem Datenträger was und wie neu installiert hast. Auf jedenfall ist das die GUID die, zu der ESP gehört und die ändert sich, wenn Du die ESP formatierst oder wenn Du sie während des Setups löschst und dann neu erstellst. Wahrscheinlich hast Du immer mit der gleichen ESP gearbeitet, dann ändert sich die GUID nicht. Damit Du das nachvollziehen kannst installiere Dir mal gdisk und dann führst Du aus:

sgdisk -i1 /dev/sda

Voraussegesetzt die ESP ist /dev/sda1. Die Zahl hinter dem i ist die Partitionsnummer. Siehe auch bei sgdisk. Der markierte Bereich entspricht der "uniqu GUID" von gdisk.

Ich habe inzwischen das System auf den Originaleintrag von Grub zurückgesetzt. Das Problem scheint wohl mit dem Hinweis im WIKI begründet

• --loader '\EFI\ubuntu\grubx64.efi'

dass dieses mit Hochkomma einzuschließen sei - damit geht es scheinbar nicht (falsche Syntax??) - jedenfalls führt der Einschluss mit

• --loader "\EFI\ubuntu\grubx64.efi"

zum erwünschten Ergebnis → muss also noch mal extern verifiziert werden!!!

Ah, gut danke für den Hinweis. RapaNui hatte es zuerst in der Form:

sudo efibootmgr --create --disk /dev/sda --part 1 --label "Ubuntu 12.04.1" --loader "\\EFI\\ubuntu\\bootx64.efi"

Bei mir hat das ganze auch ohne den doppelten \ zusammen mit ". Ich habe jetzt eben noch mal in der manpage von efibootmgr nachgeschaut. Dort wird als Default angegeben: \\elilo.efi

Also doppelter Backslash ohne Anführungszeichen. Im Netz sieht man auch doppelter Backslash mit doppelten Anführungszeichen, das schadet nicht, ist aber irgendwie doppelt gemoppelt. Es geht auch einfacher Backslash mit doppelten Anführungszeichen.

Nun bin ich am Austesten, wie ich die Anzeige so hinkriege, wie sich Windows darstellt (siehe Anlage EFI-Menü).

Da kann ich nichts zu sagen, außer dass ein Windows Eintrag nicht immer so aussieht. Siehe den ASROCK Screenshot vom Boot-Menü im Artikel. Von Windows kommt "Windows Boot Manager". Ich denke der Rest kommt beim Fujitsu irgendwie vom EFI. Bei Lenovo war der Windows-EFI Eintrag aus meiner Erinnerung heraus so wie bei Deinem Fujitsu. Aber da habe ich kein Screenshot von.

Ich habe dabei Windows nach Ubuntu im UEFI-Modus installiert - es sieht so aus:

Ja, Windows nach Ubuntu installieren ist kein Problem bei EFI-GPT.

Es beweist aber, das Windows gar nicht so intollerant ist, wie das hier im Forum gerne dargestellt wird.

Ich weiß nicht genau auf welche Art der Intoleranz Du hier anspielst, auf die, dass Windows GRUB killt oder auf die, dass es immer am Anfang installiert werden muss und ähnliches.

EFI bringt eben den Vorteil, dass die ESP ein Nebeneinander von Bootloadern ermöglicht, das ist beim MSDOS-Schema mit MBR schlicht nicht möglich. Da kann nur ein Loader im Code-Bereich stehen. Und dieser eine Loader hat da ja schon kaum Platz.

GPT bringt den Vorteil, dass es nur noch eine Partitionsart gibt. Außerdem ist EFI ja 64bit, so dass sich Addressierungsprobleme für Partitionen die weiter hinten auf der Platte liegen, so schnell nicht ergeben werden. Man müsste z.B. bei derzeitigen Plattengrößen die ESP auch locker an das Ende der Platte legen können. Das ist ja nur dann ein Problem sobald das EFI die Adressierung des Bereichs nicht mehr bewerkstelligen kann. Da dürfte jetzt bei EFI erst mal ein paar Jahre Ruhe sein.

Bei MSDOS-Schema war das ja schon häufiger ein Problem und ist es nun aktuell wieder hinsichtlich der 2 TB Grenze.

Gruß, Martin

@ RapaNui

Anscheinend machen die EFI-Systeme eine Existenzprüfung des Loaders (Name) und übernehmen den Eintrag nur wenn dieser vorhanden ist. Dein Board geht dabei wohl fix von bootx64.efi.

Ich habe inzwischen das System auf den Originaleintrag von Grub zurückgesetzt.

Hat sich ja mit der richtigen (???) Syntax erledigt - dann wird es ja richtig übernommen und auch akzeptiert.

@ Newubunti - bitte sehr:

root@ESPRIMO-E710:/home/laura# sgdisk -i 1 /dev/sda
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: 1D0DAB44-30BD-470F-AA10-8786ACEFAB59
First sector: 2048 (at 1024.0 KiB)
Last sector: 194559 (at 95.0 MiB)
Partition size: 192512 sectors (94.0 MiB)
Attribute flags: 0000000000000000
Partition name: ''
root@ESPRIMO-E710:/home/laura# 

Nachtrag: Mal eine ganz andere Frage (zum Thema EFI-Installation):

Ich habe erhebliche Probleme, das Starten über die UEFI-Option vom USB-Stick zu realisieren - Grub meldet sich - aber am Prompt. Nur sind ihm dort (fast) alle Befehle abhanden gekommen. Ein Nachladen mittels

set root=(hd0,1) 

configfile /boot/grub/grub.cfg 

läd das noch vom USB-Stick nach und es erscheint das für EFI typische Auswahlmenü - nur dann ist endgültig Schluß. Stick erstellt mit UNetbootin, Startmedienersteller und auch mittels Shell/dd - immer gleich.

syscon-hh schrieb:

Nachtrag: Mal eine ganz andere Frage (zum Thema EFI-Installation):

Ich habe erhebliche Probleme, das Starten über die UEFI-Option vom USB-Stick zu realisieren -

Da kann ich nicht viel zu sagen. Einen USB-Stick hatte ich - soweit ich mich erinnere - nur mal am ASROCK gebootet und ich bin mir auch ziemlich sicher, dass das erfolgreich war - beschwören kann ich das aber nicht. Eine Installation vom Stick habe ich unter EFI aber definitiv noch nicht durchgeführt. Die waren immer von CD.

Ich meine auch schon vereinzelt gelesen zu haben, dass andere auch schon Probleme bei EFI und USB-Stick hatten.

Was passiert denn nach dem Laden der grub.cfg genau. Friert GRUB da ein oder kann man die Einträge noch auswählen. Und welche grub.cfg hast Du genau nachgeladen, da gibt es zwei, ich denke mal, es war die /boot/grub/grub.cfg, oder?

Die sieht ja so aus:

if loadfont /boot/grub/font.pf2 ; then
	set gfxmode=auto
	insmod efi_gop
	insmod efi_uga
	insmod gfxterm
	terminal_output gfxterm
fi

set menu_color_normal=white/black
set menu_color_highlight=black/light-gray

menuentry "Try Ubuntu without installing" {
	set gfxpayload=keep
	linux	/casper/vmlinuz  file=/cdrom/preseed/ubuntu.seed boot=casper quiet splash --
	initrd	/casper/initrd.lz
}
menuentry "Install Ubuntu" {
	set gfxpayload=keep
	linux	/casper/vmlinuz  file=/cdrom/preseed/ubuntu.seed boot=casper only-ubiquity quiet splash --
	initrd	/casper/initrd.lz
}
menuentry "Check disc for defects" {
	set gfxpayload=keep
	linux	/casper/vmlinuz  boot=casper integrity-check quiet splash --
	initrd	/casper/initrd.lz
}

Da würde ich mal schätzen, dass es eventuell etwas mit dem file=/cdrom/preseed/ubuntu.seed zu tun hat. Ich habe aber auch noch nicht weiter recherchiert, wie das mit EFI auf einem Wechseldatenträger organisiert ist. Da gibt es ja zum einen das Verzeichnis /boot/grub nebst-Unterverzeichnissen und dann aber auch noch /efi/boot/bootx64.efi.

Ich würde jetzt an Deiner Stelle mal so vorgehen, dass ich mal das eine und mal das andere Verzeichnis umbenenne und dann beobachten, ob es beide Verzeichnis braucht oder nicht und welches notwendig ist, damit im EFI-Menü der UEFI-Eintrag für den Stick erscheint.

Die weitere Frage wäre dann, was in den Image-Dateien /efi/boot/bootx64.efi und /boot/grub/efi.img an GRUB-Komponeten und modulen bereits enthalten ist. Mit grub-mkimage wäre es ja grundsätzlich möglich, ein angepasstes Image zu erzeugen, dass auf einen USB-Stick passt.

Beim Insallieren von GRUB wird auf jeden Fall ganz normal eine Image-Datei erzeugt, wie auch bei GRUB-PC und die wird am Ende in grubx64.efi bzw. in bootx64.efi umbenannt.

Mir ist auch noch nicht ganz klar, was mit der Datei /boot/grub/x86_64-efi/grub.cfg zu welchem Zeitpunkt angestellt wird.

Wie gesagt ich würde das mit Umbenenen jeweils einer der Komponenten versuchen heraus zu bekommen, sofern sich im Internet dazu nichts findet.

Gruß, Martin

Ja - das ist auf der Agenda - aber sehr weit hinten.

Heute haben wir (über CD) eine EFI-Installation mit einem Btrfs-Dateisystem aufgesetzt.

War aber nur halb richtig geworden - die Umsetzung der Subvolumes wurde vom Installer nicht richtig ausgeführt - das werden wir jetzt mal untersuchen.

Nachdem wir die Installation händisch in die richtige Form gebracht hatten (alle was außerhalb der Subvolumes war, in diese hinein verschoben), lies sich Grub wieder korrekt

• Installieren

• Updaten

Das System läuft jetzt auch wieder korrekt. Will heißen - grubx64.efi greift richtig auf das System zu.

Nachdem ich Eure Hinweise zur vorangigen Paketinstallation von

• efibootmgr

• gdisk

beachtet habe, wurde auch der Starteintrag für das UEFI-Menü gleich richtig gesetzt. Ist das Fehlen dieser Pakete eigentlich schon als gemeldet worden??

gruß syscon-hh

syscon-hh schrieb:

Nachdem ich Eure Hinweise zur vorangigen Paketinstallation von

• efibootmgr

• gdisk

beachtet habe, wurde auch der Starteintrag für das UEFI-Menü gleich richtig gesetzt. Ist das Fehlen dieser Pakete eigentlich schon als gemeldet worden??

Was meinst Du mit "Fehlen dieser Pakete"? Auf der Live-CD?

Wäre halt die Frage, ob es irgendwelche Gründe gab, es nicht direkt zu integrieren. efibootmgr fände ich grundsätzlich auf der CD schon sinnvoll, gdisk würde ich jetzt nicht unbedingt als essentiell bezeichnen, schön zu haben ja, aber vieles bekommt man auch mit parted schon raus. Also IMO keine muss.

Bei efibootmgr könnte ich mir vorstellen, dass es vielleicht etwas mit dem Nichtvorhandensein, von efivars im BIOS-Modus zu tun haben könnte. Dann würde efibootmgr Fehler produzieren, die sich vielleicht im BIOS-Modus nicht beheben lassen. Das bereitstellen von efivars erfolgt ja unter Ubuntu schon direkt im Kernel. Aber alles nur Spekulation.

Gruß, Martin