staging.inyokaproject.org

Also ich habe jetzt noch mal in die UEFI-Spezifikation geschaut (Version 2.3.1 vom 7. September 2011).

Dort wird in der Tat recht wenig zum Boot-Manager festgeschrieben. Fest definiert ist dort vor allem, wie Einträge im NVRAM aufgebaut sind. Das ist im wesentlichen das Format, wie man es auch mit efibootmgr angezeigt bekommt. Der Rest ist aber ziemlich frei - mal abgesehen davon dass es halt bestimmte festgeschriebene, programmiertechnische Funktionen gibt - also Befehle, mit dem das Laden einer EFI-Datei eingeleitet wird und mit welchem Befehl der EFI-Loader zum Boot-Manager zurückkehren kann, wenn das misslingt usw..

So wie ich das lese, kann man da nicht drauf hoffen, dass es da irgend ein einheitliches Verhalten gibt.

Bei meinem MSI-Board ist es übrigens - neben dem, was ich schon genannt habe so. Der EFI-Boot-Manger richtet für jeden Datenträger, der ein vom EFI lesbares Dateisystem hat (FAT oder NTFS), die beiden folgenden Pfade in der PAHT-Variablen fest:

• /efi/boot

• /efi/tools

Die PATH-Variable kann man in einer EFI-Shell über set abfragen.

Gruß, Martin

Ich danke euch!

Ich habe hier ein neues Thema gemacht. Hoffentlich habe ich bald wieder mein geliebtes Ubuntu auf meinem Rechner! http://forum.ubuntuusers.de/topic/ubuntu-installation-auf-dell-precision-m6700-m/

Gruß

Hallo Newubunti, neues aus dem Testlabor:

• Sachstand:

  • Ubuntu + Windows auf /dev/sda (SSD) vorhanden mit:

    • /dev/sda1 = efi-Partition

    • /dev/sda3 = Windows

    • /dev/sda4 = Ubuntu

  • KUbuntu Installation auf

    • leere externe Festplatte (/dev/sdd)

    • Auswahl in ubiquity: ganze Festplatte (automatische Installation)

• Ergebnis:

  • Das KUbuntu wurde ganz normal, lauffähig im EFI-Modus auf der /dev/sdd installiert mit:

    • /dev/sdd1 = efi-Partition

    • /dev/sdd2 = KUbuntu

    • /dev/sdd3 = SWAP

Soweit und ganz gut. Beim Reboot im EFI-Menü den Eintarg für die Festplatte ausgewählt, denn dieser wurde nun zusätzlich als UEFI-Startmedium angezeigt. Das System startete auch (nur ...dazu weiter unten) und am KUbuntu-Desktop gleich mal die

• /etc/fstab

kontrolliert und siehe da:

# /boot/efi was on /dev/sda1
UUID=4682-C2C4			/boot/efi		vfat	defaults	0	1

Sowohl der Hinweis auf /dev/sda1 als auch die UUID ließen nichts Gutes ahnen.

Ja der Originaleintrag für ubuntu auf der /dev/sda1 war überschrieben, dafür war auf der eigentlich richtigen efi-Partition nichts eingetragen.

Inzwischen habe ich alles reparieren können - dazu:

• Nachbesserungen:

  • Das KUbuntu-System gestartet

    • die efi-Partiton richtig eingebunden (dev/sdd1 nach /boot/efi)

    • mit sudo grub-install Eintrag grubx64.efi erzeugt

    • als Verzeichnis wurde /EFI/ubuntu angelegt

  • Das Ubuntu-System

    • via chroot komplett eingebunden

    • mit sudo grub-install Eintrag grubx64.efi erneuert

Beide System sind jetzt getrennt aufrufbar und starten ohne Fehler!!

Es zeigt aber, dass es viele Kombinationen hinsichtlich der EFI-Einträge möglich sind. Zum Schluss habe ich noch ein Verzeichnis

• /EFI/kubuntu auf /dev/sda1 angelegt

• den Eintrag aus .../ubuntu gesichert

• den Mountpunkt in der KUbuntu-/etc/fstab nach /dev/sda1 geändert

• die grubx64.efi-Einträge wieder richtig eingeordnet (umkopiert)

• mit efibootmgr mittels --create einen KUbuntu-Eintrag für das EFI-Menü erzeugt

Jetzt läßt sich alles von der /dev/sda1 starten.

gruß syscon-hh

Falls Du das System mit Ubuntu und Kubuntu noch hast, dann führe mal bitte den folgenden Befehl aus - ich schätze mal, dass es keinen Unterschied macht ob von Ubuntu oder Kubuntu:

sudo grub-mkdevicemap --device-map=/dev/stdout | sudo grub-probe --target=device --device-map=/dev/stdin /boot/efi

Der Befehl stammt so im Prinzip aus dem Skript "grub-install". Und IMO dürfte dort der Fehler begraben liegen. Neben ein paar anderen Problemen, die das Skript nicht berücksichtigt - wie z.B. dass Kubuntu auch /EFI/ubuntu/grubx64.efi verwendet.

Ich bin nicht so der Skritping-Experte aber so wie ich grub-install verstehe, zieht das gar nicht in Betracht, dass es zwei oder mehrere EFI-System-Partitionen geben kann.

Davon abgesehen waren Mehr-Platten-Systeme ja noch nie eine besondere Stärke der GRUB-Installation. Liegt natürlich auch ein Stück weit in der Natur der Sache.

In Deinem Fall ist das für mich aber ein schwerer BUG. Wenn ich im Setup eine Platte komplett für (K)Ubuntu auswähle, dann darf ich IMO schon erwarten, dass GRUB auch auf dieser Platte landet.

Gruß, Martin

Ergibt folgende Ausgaben:

• Aus Ubuntu, gestartet von /dev/sda1

  • /dev/sda1

• Aus KUbuntu, gestartet von /dev/sda1

  • /dev/sda1

• Aus KUbuntu, gestartet von /dev/sdd1

  • /dev/sdd1

Ja ich halte das auch für einen schwerwiegenden Fehler - nur liegt der in den grub-efi-Paketen. Schon die Distri-Bezeichnung ist unter grub-efi auch im Grub-Menü immer

• Ubuntu

anders als unter grub-pc (=Kubuntu) *) und damit wird da wohl etwas falsch ausgelesen. Sagen wir es mal so - auch die GRUB_2-Macher sind vermutlich noch gar nicht so weit, die Unterschiede heraus zu arbeiten - man hofft erst einmal die Basis hinzubekommen.

*) Nachtrag: Auch im BIOS-Modus wird bei Grub-2.0 aus einer KUbuntu-Installation im Grub-Menu generell Ubuntu - scheint also eine allgemeiner Fehler zu sein. Ich kann im Moment aber nicht behaupten, ob dass unter grub 1.99 auch schon so war - müsste mal einer bei 12.04 LTS gezielt nachschauen.

Ich glaube ein Stück weit hatte ich da jetzt auch einen Denkfehler in meinem letzten Post. grub-install wird ja unter Angabe des Ziel-Datenträgers aufgerufen. Kann also schon gut sein, dass da der falsche Zieldatenträger von Ubiquity an grub-install übergeben wird.

Gruß, Martin

Newubunti schrieb:

Ich glaube ein Stück weit hatte ich da jetzt auch einen Denkfehler in meinem letzten Post. grub-install wird ja unter Angabe des Ziel-Datenträgers aufgerufen. Kann also schon gut sein, dass da der falsche Zieldatenträger von Ubiquity an grub-install übergeben wird.

Nein - das ist zwar nicht falsch, aber das Skript unterdrückt alles was über den Befehl hinaus geht (Abtrennung mit sed bzw. über eine Abfrage der Optionen, z.B. --version oder --help), ganz gleich, ob da ein Laufwerk angeben wird oder nicht (passt eben in kein Optionsmuster)! Auch die Abarbeitung für grub-install orientiert sich über grub-probe u.a., ob ein Device und welches (vfat) sich hinter dem Mountpoint

• /boot/efi

befindet und schreibt dann die Datei grubx64.efi in das Verzeichnis /boot/efi/EFI/ubuntu und veranlasst einen Eintrag in das NVRAM (sofern das nicht über eine Option --no-nvram abgewählt wurde.

Und das Skript gibt auch Auskunft, warum bei einem Nichtvorhandensein des EFI-Pfades (siehe weiter oben) nichts geschrieben wird - diese Abfrage endet in einem schlichten exit 0 - eine unglückliche Lösung, ein Warnhinweis wäre besser gewesen. Auszüge aus der --help-Funktion:

• grub 1.99-21ubuntu3.4 (Precise)

grub-install [OPTION] [install_device]
...
Install_device can be a GRUB device name or a system device filename.

• grub 2.00-7ubuntu2 (Quantal)

grub-install [OPTION] [INSTALLATIONSGERÄT]
...
Installationsgerät muss als Name einer Systemdatei angegeben werden.

Wird also auch schon unterschiedlich vorgegeben?!?

gruß syscon-hh

Noch etwas: Wenn man bei grub-install die Option --removable verwendet, dann wird die Startdatei als/nach

• /boot/efi/EFI/Boot/BOOTX64.EFI

direkt (auf dem externen Datenträger) angelegt und damit wird die Erkennung dieses Eintrages wohl besser erkannt. Das Verzeichnis auf dem externen Datenträger .../EFI/ubuntu wird dann nicht mehr angelegt noch gefüllt! Andererseits wird dann auch der Eintrag für ubuntu im EFI-BIOS deaktiviert. Hier behindern sich also Doppelfunktionen gegenseitig - oder wie Du anmerktest - das darf nicht sein.

Übrigens: Mein letztes automatisches BIOS-Update hat mir dieses hier hinzugefügt →

• CSM Configuration, siehe Anlage:

syscon-hh schrieb:

Newubunti schrieb:

Ich glaube ein Stück weit hatte ich da jetzt auch einen Denkfehler in meinem letzten Post. grub-install wird ja unter Angabe des Ziel-Datenträgers aufgerufen. Kann also schon gut sein, dass da der falsche Zieldatenträger von Ubiquity an grub-install übergeben wird.

Nein - das ist zwar nicht falsch, aber das Skript unterdrückt alles was über den Befehl hinaus geht (Abtrennung mit sed bzw. über eine Abfrage der Optionen, z.B. --version oder --help), ....

Danke, für die Erklärung! Ich hatte das zumindest schon soweit verstanden, dass die Prüfung hier doch recht einfach gestrickt ist.

Auszüge aus der --help-Funktion:

• grub 1.99-21ubuntu3.4 (Precise)

grub-install [OPTION] [install_device]
...
Install_device can be a GRUB device name or a system device filename.

• grub 2.00-7ubuntu2 (Quantal)

grub-install [OPTION] [INSTALLATIONSGERÄT]
...
Installationsgerät muss als Name einer Systemdatei angegeben werden.

Wird also auch schon unterschiedlich vorgegeben?!?

Hm, könnte jetzt auch eine unglückliche Übersetzung sein, da müsste man erst mal zwei gleichsprachige Pakete vergleichen. Mit Quantal habe ich übrigens noch gar nicht getestet, da meine Erfahrung mittlerweile ist, dass man Fehler in Ubiquity nicht unbedingt vorrangig behebt - da mag ich vielleicht auch falsch liegen.

gruß syscon-hh

Noch etwas: Wenn man bei grub-install die Option --removable verwendet, dann wird die Startdatei als/nach

• /boot/efi/EFI/Boot/BOOTX64.EFI

direkt (auf dem externen Datenträger) angelegt und damit wird die Erkennung dieses Eintrages wohl besser erkannt.

Das stützt ja zunächst mal meine Theorie, dass Wechsel-Medien bei EFI anders behandelt werden - was sich teilweise auch schon im EFI selbst erkennen lässt.

Das Verzeichnis auf dem externen Datenträger .../EFI/ubuntu wird dann nicht mehr angelegt noch gefüllt! Andererseits wird dann auch der Eintrag für ubuntu im EFI-BIOS deaktiviert. Hier behindern sich also Doppelfunktionen gegenseitig - oder wie Du anmerktest - das darf nicht sein.

Sagen wir mal so:

Im Prinzip ist dieses Verhalten ja erst mal sinnvoll. Bei Wechselmedien wird der EFI-Loader - wenigstens als standard - über /efi/boot geladen (siehe ja auch die Ubuntu-CD). Dafür muss es sich dann auch nicht zwangsweise um eine EFI-System-Partition handeln. Dieser Pfad wird immer schon vom EFI selbst abgefragt. Siehe auch meine Erfahrung mit der EFI-Shell.

Das deckt sich ja soweit erst mal.

IMO wäre es aber dennoch sinnvoll - wenigstens als Option für grub-install - wenn man beides auf einem Datenträger einrichten könnte. So wie man ja auch optional auf einen NVRAM-Eintrag verzichten kann.

Übrigens: Mein letztes automatisches BIOS-Update hat mir dieses hier hinzugefügt →

• CSM Configuration, siehe Anlage:

Ja, mit den ganze Optionen im UEFI-Setup ist das so eine Sache. Ich steige da auch erst mal nicht immer dahinter. Was ich mir bei Deinem Screenshot vorstellen könnte ist, dass sich

• Other PCI Device ROM Priority

auf

• Boot Option filter

bezieht. Also Du hast ja da im Moment auf "UEFI and Legacy" stehen und das dann durch die letzte Option "UEFI" erst mal vorangig behandelt wird. Passt zwar dann nicht so richtig von der Umschreibung, aber könnte zumindest sein - es sei denn das lässt sich noch mal an anderer Stelle einstellen.

Auch noch vorstellbar:

Ähnlich wie bei Server-Boards - in denen ja häufig mehrere Controller (z.B. SAS) sitzen - und bei denen man im Setup in der Regel Controller, an denen das Boot-Device hängt priorisieren kann.

Auf Dein Board übertragen. Steckst Du einen Controller hinzu über den auch Boot-Devices zur Verfügung gestellt werden, dann wird bei Deiner jetzigen Einstellung vorangig über Board-interne Controller gestartet.

Aber alles nur Mutmaßung - kann natürlich auch sonst was heißen.

Gruß, Martin

syscon-hh schrieb:

... Ich kann im Moment aber nicht behaupten, ob dass unter grub 1.99 auch schon so war - müsste mal einer bei 12.04 LTS gezielt nachschauen.

Das ist Standard - mit erheblichen Konsequenzen bei (U)EFI - siehe KUbuntu.de Forum !!

Dass solltest Du als Hinweis in das zukünftige WIKI aufnehmen - und wie man das ggf. in den Griff bekommt:

• sudo grub-install --removable --no-nvram

händisch für beide Systeme - sofern diese auf verschiedenen HD's liegen. Ich werde jetzt noch mal mit zwei vfat-Partitionen (auf einer HD) experimentieren, hinsichtlich Erkennung und Startverhalten.

Mal noch eine andere Frage zu Deinem Ubuntu-Kubuntu-EFI-Experiment:

Wurde denn Ubuntu in das GRUB-Menü von Kubuntu aufgenommen, oder scheitert das auch daran, dass GRUB - oder besser gesagt os-prober - keine anderen über EFI gestarteten Systeme erkennt? Eigentlich hätte doch Ubuntu in das GRUB-Menü von Kubuntu aufgenommen werden müssen.

Gruß, Martin

Newubunti schrieb:

Mal noch eine andere Frage zu Deinem Ubuntu-Kubuntu-EFI-Experiment:

Wurde denn Ubuntu in das GRUB-Menü von Kubuntu aufgenommen, oder scheitert das auch daran, dass GRUB - oder besser gesagt os-prober - keine anderen über EFI gestarteten Systeme erkennt? Eigentlich hätte doch Ubuntu in das GRUB-Menü von Kubuntu aufgenommen werden müssen.

Solange das andere Ubuntu auf einer EFI-Partition liegt - wird es nicht beachtet, nicht gefunden oder ignoriert, was kann ich im Moment nicht einordnen!

Ich habe jetzt das Thema Multiboot (also mehrere Ubuntuversionen) so gelöst:

• 1. Installation

Diese normal durchlaufen lassen (bzw. bestehende verwenden), dabei wird (wurde) im EFI-Bootmenü der Eintrag ubuntu angelegt, das entspricht Verzeichnis/Datei:

• .../EFI/ubuntu/grubx64.efi

Nun habe ich mir als erstes manuell das Verzeichnis

• .../EFI/precise

angelegt und dort hinein die Datei grubx64.efi als bootx64.efi kopiert. Nun noch dieses als neuen Eintrag mit

sudo efibootmgr --create --disk /dev/sda --part 1 --label "Precise Pangolin" --loader \\EFI\\precise\\bootx64.efi 

in das EFI-Bootmenü eingetragen, Bootreihenfolge auf 0000 gesetzt und damit gestartet - alles OK!

• 2. und weitere Installation:

Wie oben ab mauelles Verzeichnis beschrieben ein weiteres angelegt z.B. mit

• .../EFI/k_quantal

um dort dann die Datei von der Quantal KUbuntu Installation rüberkopiert und einen Eintrag im EFI-Bootmenü entsprechend angelegt. Die KUbuntu-Installation selbst ist auf der /dev/sdc5 angelegt und wurde mit "Was Anderes" vorab konfiguriert - der Installer hatte schon selbstständig die /dev/sda1 als EFI-Partition gewählt.

Aber da gibt es noch diverse andere Wege, um das zu realisieren! Mit obigen Vorgehen wird zumindest sichergestellt, falls eines der Systeme einen Update durchläuft, insbesondere bei den Paketen grub-efi, der revidierte Eintrag nicht unbeabsichtigt angetastet/überschrieben wird.

gruß syscon-hh

Hallo Ihr Beiden → es gibt wieder was Neues!!

Ab Quantal Quetzal gibt es innerhalb von grub-efi das Skript

• 30_uefi-firmware

Ich habe den Sinn und Auswirkung noch nicht überprüfen können - aber hier mal der auf's Wesentliche gekürzte Inhalt:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

#! /bin/sh -e

. "${datarootdir}/grub/grub-mkconfig_lib"

efi_vars_dir=/sys/firmware/efi/vars
EFI_GLOBAL_VARIABLE=8be4df61-93ca-11d2-aa0d-00e098032b8c
OsIndications="$efi_vars_dir/OsIndicationsSupported-$EFI_GLOBAL_VARIABLE/data"
if [ -e "$OsIndications" ] && \
   [ "$(( $(printf %x \'"$(cat $OsIndications | cut -b1)") & 1 ))" = 1 ]; then
  LABEL="System setup"
  gettext_printf "Adding boot menu entry for EFI firmware configuration\n" >&2
  onstr="$(gettext_printf "(on %s)" "${DEVICE}")"

cat << EOF
menuentry '$LABEL' \$menuentry_id_option 'uefi-firmware' {
	fwsetup
}
EOF
fi

Als Hinweis habe ich bisher dieses im change.log gefunden:

   * debian/patches/ubuntu_uefi_firmware_setup.patch: Output a menu entry
     for firmware setup on UEFI FastBoot systems.

Sobald ich weitere Informationen, Ergebnisse habe und die Auswirkungen kenne, werde ich das hier kundtun.

gruß syscon-hh

Nachtrag: Dieser Menüeintrag ist nur dazu da, um in das BIOS-Menü zu booten - der help-Text besagt.

• "reboot into the system firmware"

und meint damit einen BIOS-Aufruf - was dann auch ausgeführt wird.

Über den Sinn bzw. Unsinn dieses Menüpunktes kann + mag man streiten! Erleichtert aber denen das Leben, wo die Eingriffszeit zum EFI-Menü (z.B. F12 ) sehr kurz ist.

syscon-hh schrieb:

Hallo Ihr Beiden → es gibt wieder was Neues!!

Ah, das ist ja interessant. Danke, für das Herausfinden!

Über den Sinn bzw. Unsinn dieses Menüpunktes kann + mag man streiten! Erleichtert aber denen das Leben, wo die Eingriffszeit zum EFI-Menü (z.B. F12 ) sehr kurz ist.

Ist auch für Systeme sinnvoll, bei denen die Taste zum Aufrufen des Boot-Menüs nicht dokumentiert ist. Das war zumindest bei BIOS-Systemen gar nicht so selten.

Ich hoffe nur, dass in 12.10 - hatte noch keine Zeit zum Forschen - nun die Erkennung von EI-Systemen gescheit läuft. Das wäre im Moment doch dringender.

Gruß, Martin

Noch eine weitere Information - hinsichtlich Windows 8

Dort sind die Partitionen bei einer UEFI-Installation wie folgt aufgebaut (leere Festplatte, automatischer Ablauf):

• Partition /dev/sdx1 → NTFS, 300MiB, "Data Basic Partition" (Recovery, hidden)

• Partition /dev/sdx2 → VFAT, 100MiB, "EFI System Partition" Inhalt wie bisher

• Partition /dev/sdx3 → RAW , 128MiB, "System-reserviert" - unter EFI nicht benutzt

• Partition /dev/sdxY → NTFS, "System, Daten usw."

Letztere kann je nach Plattengröße schon bei der Installation in der Größe begrenzt werden - Mindestgröße aber > 40 GB für alle vier(4), auch wenn Microsoft in den Spezifikationen nur 20 GB vorgibt.

Ich wollte das nur kundtun, damit man bei der Beantwortung von Fragen nicht in diese Falle mit der EFI-Partition wie oben aufgelistet auf der Position 2 oder andere tappt (siehe Anlage). Im Prinzip ist dieses ja auch schon immer so - die EFI-Partition muss nicht die erste sein, sollte aber in der Reihenfolge die erste mit VFAT im System sein.

gruß syscon-hh