Efibootmgr - Versionsgeschichte

Gehrke: Schreibweise openSUSE

2015-09-04T05:36:35Z

Schreibweise openSUSE

Gehrke: interne Verlinkung: SecureBoot -> Secure Boot

2015-09-04T05:34:34Z

interne Verlinkung: SecureBoot -> Secure Boot

Robi: 1 Version importiert: Übernahme der Wikiseiten aus der Arbeitsumgebung des NosNis Wiki

2015-08-29T22:04:56Z

1 Version importiert: Übernahme der Wikiseiten aus der Arbeitsumgebung des NosNis Wiki

Gehrke: Ich habe fertig - Review bitte...

2015-05-04T15:40:35Z

Ich habe fertig - Review bitte...

Neue Seite

[[Kategorie:UEFI]]
{{Review|Gesamter Artikel}}
--[[Benutzer:Gehrke|Gehrke]] 17:40, 4. Mai 2015 (CEST)

Die [[UEFI/Bootloader|UEFI-Bootkonfiguration]] kann von Linux aus über das Tool ''efibootmgr'' gesteuert werden. Dabei können die gesetzten Eigenschaften ausgelesen und verändert werden.

Im Gegensatz zum herkömmlichen [[BIOS]] bietet UEFI eine eindeutig spezifizierte Schnittstelle, wie der Bootvorgang eines Systems stattfindet. Diese Schnittstelle kann von den Firmware-Herstellern auf unterschiedlichste Art und Weise implementiert werden, insbesondere unterscheiden sich die einzelnen Implementierungen in Funktionsumfang, dem User Interface (UI) und auch dem Aktualisierungsprozess. Die Lösungen der einzelnen Hersteller gehen in diesen Punkten weit auseinander und es scheint unmöglich, zu diesem Themenbereich eine Übersicht oder gar eine umfassende Dokumentation zu generieren.

Dies kann insbesondere im Supportfall eine große Hürde darstellen, wenn ein User ein Problem mit der Boot-Konfiguration hat. Im Falle eines Support-Forums müsste er zunächst mal jemanden finden, der diese spezielle Firmware-Implementierung kennt und kämpft zusätzlich noch mit dem Problem, dass in dieser frühen Phase kaum die notwendigen Werkzeuge zur Analyse und Kommunikation (OS, Netzwerk, Browser, Password-Safe...) zur Verfügung stehen. In der Regel bleibt hier dann nur der beschwerliche Weg über echte Fotos von den UEFI-Settings und Zugriff auf ein Support-Forum über externe Systeme.

Eine effizientere Vorgehensweise sollte der Zugriff auf diese standardisierten Funktionalitäten über die Werkzeuge des Betriebssystems sein. Sowohl Linux als auch andere Betriebssysteme bieten hier entsprechende Tools, welche nicht unter den oben genannten Einschränkungen leiden. Wenn beispielsweise im Falle eines Boot-Problemes eine Live-Distribution von USB-Stick gestartet werden kann, dann steht eine mächtige Arbeitsumgebung für Analyse und Kommunikation bereit und bietet mit ''efibootmgr'' ein standardisiertes Werkzeug, um die Boot-Konfiguration von UEFI zu verändern.

'''Einschränkung:''' Dieses Tool kann nur dann für die Konfiguration des EFI-BootManagers verwendet werden, wenn das laufende Linux im sogenannten '' 'UEFI native mode' '' gestartet wurde (siehe hierzu 'Full UEFI native boot entry' im [[#Boot-Konfiguration von EFI|Abschnitt 'Boot-Konfiguration von EFI']]). Fest installierte Linux-Systeme oder Live-Versionen aktueller Distributionen sorgen in der Regel genau dafür, so dass die Funktionalität hier genutzt werden kann.

=Usage=
<pre>
suse131-win10:~ # efibootmgr -?
efibootmgr: invalid option -- '?'
efibootmgr version 0.6.0
usage: efibootmgr [options]
-a | --active sets bootnum active
-A | --inactive sets bootnum inactive
-b | --bootnum XXXX modify BootXXXX (hex)
-B | --delete-bootnum delete bootnum (hex)
-c | --create create new variable bootnum and add to bootorder
-d | --disk disk (defaults to /dev/sda) containing loader
-e | --edd [1|3|-1] force EDD 1.0 or 3.0 creation variables, or guess
-E | --device num EDD 1.0 device number (defaults to 0x80)
-g | --gpt force disk with invalid PMBR to be treated as GPT
-H | --acpi_hid XXXX set the ACPI HID (used with -i)
-i | --iface name create a netboot entry for the named interface
-l | --loader name (defaults to "\efi\linux\grub.efi")
-L | --label label Boot manager display label (defaults to "Linux")
-n | --bootnext XXXX set BootNext to XXXX (hex)
-N | --delete-bootnext delete BootNext
-o | --bootorder XXXX,YYYY,ZZZZ,... explicitly set BootOrder (hex)
-O | --delete-bootorder delete BootOrder
-p | --part part (defaults to 1) containing loader
-q | --quiet be quiet
| --test filename don't write to NVRAM, write to filename.
-t | --timeout seconds set boot manager timeout waiting for user input.
-T | --delete-timeout delete Timeout.
-u | --unicode | --UCS-2 pass extra args as UCS-2 (default is ASCII)
-U | --acpi_uid XXXX set the ACPI UID (used with -i)
-v | --verbose print additional information
-V | --version return version and exit
-w | --write-signature write unique sig to MBR if needed
-@ | --append-binary-args file append extra args from file (use "-" for stdin)
</pre>

=Setup der Testmaschine=
Im Folgenden soll die Anwendung dieses Werkzeuges anhand von Beispielen erläutert werden. Zum besseren Verständnis wird vorweg das Setup der Testmaschine beschrieben.

Als Testsystem wurde eine virtuelle Maschine (VM) verwendet. Dabei wurde als UEFI-Implementierung [[OVMF]] eingesetzt. In dieser VM wurde eine klassische Dual-Boot-Installtion aufgesetzt, welche aus 'OpenSUSE 13.1' einerseits und 'Microsoft Windows10 (Technical Preview)' andererseits besteht. Als BootManager agiert [[GRUB2]]. Dabei wird UEFI im [[SecureBoot]]-Modus gefahren.

==Partitionierung==
Sowohl Linux als auch Windows teilen sich eine Festplatte 'sda'.
*sda2: [[ESP|EFI system partition (ESP)]]
*sda4: Windows (NTFS)
*sda5: /boot ([[GRUB2]])
*sda6: [[LVM]] mit LV für / und /swap
<pre>
suse131-win10:~ # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 50G 0 disk
├─sda1 8:1 0 300M 0 part
├─sda2 8:2 0 99M 0 part /boot/efi
├─sda3 8:3 0 128M 0 part
├─sda4 8:4 0 30G 0 part
├─sda5 8:5 0 311M 0 part /boot
└─sda6 8:6 0 19.2G 0 part
├─system-swap 253:0 0 512M 0 lvm [SWAP]
├─system-opensuse131-root 253:1 0 9G 0 lvm /
└─system-unused 253:2 0 9.7G 0 lvm
</pre>

<pre>
suse131-win10:~ # gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.7

Partition table scan:
MBR: protective
BSD: not present
APM: not present
GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 104857600 sectors, 50.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 16E1A025-C2AF-4108-A2D4-25320B203216
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 104857566
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number Start (sector) End (sector) Size Code Name
1 2048 616447 300.0 MiB 2700 Basic data partition
2 616448 819199 99.0 MiB EF00 EFI system partition
3 819200 1081343 128.0 MiB 0C01 Microsoft reserved part
4 1081344 63895551 30.0 GiB 0700 Basic data partition
5 63895552 64532479 311.0 MiB 0700 primary
6 64532480 104855551 19.2 GiB 8E00 primary
</pre>

==Boot-Konfiguration von EFI==
Die aktuelle Boot-Konfiguration von EFI kann man von der linux-Kommandozeile aus wie folgt abfragen:
<pre>suse131-win10:~ # efibootmgr -v
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0007,0006,0009,0000,0001,0002,0003,0004,0005
Boot0000* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot0001* EFI DVD/CDROM 1 ACPI(a0341d0,0)PCI(1,1)ATAPI(0,0,0)
Boot0002* EFI Floppy ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot0003* EFI Floppy 1 ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot0004* EFI Hard Drive ACPI(a0341d0,0)PCI(1,1)ATAPI(0,1,0)
Boot0005* EFI Internal Shell MM(b,900000,10fffff)
Boot0006* opensuse HD(2,96800,31800,78c4e591-a88a-44d3-80c1-930cc36f40ae)File(\EFI\opensuse\grubx64.efi)
Boot0007* opensuse-secureboot HD(2,96800,31800,78c4e591-a88a-44d3-80c1-930cc36f40ae)File(\EFI\opensuse\shim.efi)
Boot0009* Windows Boot Manager HD(2,96800,31800,78c4e591-a88a-44d3-80c1-930cc36f40ae)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.}...C................</pre>
Neben anderen Informationen werden hier alle verfügbaren [[UEFI/Bootloader|Bootloader]] angezeigt.

Man erkennt, dass der Bootloader 'Boot0007* opensuse-secureboot' als aktiv markiert ist (BootCurrent: 0007). Dahinter verbirgt sich der signierte Bootloader [[shim]], welcher wie die anderen Bootloader auch auf einer hier genau definierten [[ESP|EFI system partition (ESP)]] liegen.

''shim'' ist ein einfacher Pre-Boot-Loader, dessen Aufgabe es ist, den nächsten in der Bootreihenfolge stehenden Bootloader unter Berücksichtigung der Zertifikatskette ([[SecureBoot]]) zu starten. In diesem Beispiel ist der nächste Eintrag 'Boot0006* opensuse', welcher ebenfalls ein signierter Bootloader ist.

Unter 'BootOrder' wird die Reihenfolge aufgezeigt, in welcher nach startbaren Devices gesucht wird.

Der Zusammenhang wird deutlicher, wenn man sich die UUIDs ansieht:
<pre>suse131-win10:~ # blkid
/dev/sda1: LABEL="Wiederherstellung" UUID="0ED62AE4D62ACC31" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="d96e3f2c-da75-4831-9e07-29c273d4a5a0"
/dev/sda2: UUID="BA2C-5359" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="78c4e591-a88a-44d3-80c1-930cc36f40ae"
/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="345523d6-4fab-4dd5-a8d8-0f3dae793aca"
/dev/sda4: UUID="20DE2F40DE2F0E1A" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="b08eb833-6fe9-434d-b614-41eccde5caf4"
/dev/sda5: UUID="e464c3a4-a89f-42d4-b270-03a6555fb4be" TYPE="ext3" PARTLABEL="primary" PARTUUID="81434400-3aca-4935-be82-2838abec5e80"
/dev/sda6: UUID="b6Izp6-XsdX-nYON-dHpa-0nmj-lbpx-lJCfsb" TYPE="LVM2_member" PARTLABEL="primary" PARTUUID="b96d43f0-1f2d-45ab-bb28-e94c2736379a"
/dev/mapper/system-swap: UUID="5bff2383-88f9-4021-82fd-75ffd0204e58" TYPE="swap"
/dev/mapper/system-opensuse131-root: UUID="58d175a0-c60c-42fc-9ead-64485731d2c9" TYPE="ext4"</pre>

Zum besseren Verständnis soll beispielhaft dieser Eintrag näher erläutert werden:
<pre>
Boot0006* opensuse HD(2,96800,31800,78c4e591-a88a-44d3-80c1-930cc36f40ae)File(\EFI\opensuse\grubx64.efi)
</pre>
Nach der ID und dem Bezeichner folgt die Adressierung, wo dieser Bootloader zu finden ist. Die Bedeutung der Parameter im einzelnen:
*HD(...): Die Typisierung 'HD' nach EFI_DEVICE_PATH_PROTOCOL bedeutet, dass hier ein Bootloader-Eintrag des Typs '' 'Full UEFI native boot entry' '' verwendet wird. Im Gegensatz zu anderen Typen werden hier diese Parameter genau definiert:
**Bezeichnung der Festplatte und der Partition
**Pfad und Dateiname des verwendeten Bootloaders
Im konkreten Beispiel:
*2: Es handelt sich um die zweite Partition.
*96800: Der Startsektor der Partition in hexadezimaler Schreibweise (dezimal 616448). siehe hierzu auch die Partitionierungsdaten von ''gdisk''.
*31800: Die Größe der Partition in hexadezimaler Schreibweise (dezimal 202752 = 819200 - 616448). siehe hierzu auch die Partitionierungsdaten von ''gdisk''.
*78c4e591-a88a-44d3-80c1-930cc36f40ae: Die [[ESP|EFI system partition (ESP)]] (sda2) hat diese UUID
*File(\EFI\opensuse\grubx64.efi): Als Bootloader ist eine Datei zu verwenden, welche unter dem hier angegebenen Pfad zu finden ist.

Auf diesem Wege werden üblicherweise fest installierte Betriebssysteme im BootManager verankert - im Gegensatz zu flexiblen Boot-Devices wie DVD oder USB, bei denen andere Typen verwendet werden. In der Regel liegen dabei die jeweiligen Bootloader in der ESP.

==GRUB2==
Wie zuvor beschrieben, ist die Reihenfolge der Bootloader so: 'shim.efi' übergibt direkt an den nächsten Bootloader 'grubx64.efi', wohinter sich der im UEFI-Binärformat vorliegende erste Teil von [[GRUB2]] verbirgt (welcher ebenfalls signiert ist).

Dieser findet seine Konfiguration auf 'sda5' und auf Basis dieser Konfiguration wird dem Anwender ein Menü zur Auswahl des gewünschten Betriebssystems (OpenSUSE oder Windows) angeboten. Alle hier zur Auswahl stehenden Kernel müssen aufgrund der [[SecureBoot]]-Einstellung ebenfalls gültig signiert sein, ansonsten kommt es zu einer Laufzeit-Fehlermeldung.

Nachfolgend die dafür relevanten Teile der Konfiguration (/boot/grub2/grub.cfg).

===OpenSUSE===
<pre>
### BEGIN /etc/grub.d/10_linux ###
menuentry 'openSUSE 13.1' --class 'opensuse-13-1' --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-sim
ple-58d175a0-c60c-42fc-9ead-64485731d2c9' {
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='hd0,gpt5'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt5 --hint-efi=hd0,gpt5 --hint-baremetal=ahci0,gpt5 e464c3a4-a89f-42d4-b270-03a6555fb4be
else
search --no-floppy --fs-uuid --set=root e464c3a4-a89f-42d4-b270-03a6555fb4be
fi
echo 'Loading Linux 3.11.10-25-desktop ...'
linuxefi /vmlinuz-3.11.10-25-desktop root=/dev/mapper/system-opensuse131-root ro resume=/dev/system/swap splash=silent quiet showopts
echo 'Loading initial ramdisk ...'
initrdefi /initrd-3.11.10-25-desktop
}
</pre>
Erläuterungen:
*set root='hd0,gpt5': Als 'root device' wird die 5. Partition auf der ersten Festplatte gesetzt - also die Partition, welche nach /boot gemountet wird und auf der die zum Systemstart relevanten Dateien liegen (z.B. der Kernel). In weiteren Konfigurationselementen werden die betreffenden Einträge relativ zu diesem ''root device'' ausgewertet.
*linuxefi: Definition des zu ladenden linux-Kernels und Lage der root-Partition (in diesem Fall das Logical Volume 'system-opensuse131-root').
*initrdefi: Definition der zu verwendenden 'Initial RAM-Disk'

===Windows===
<pre>
### BEGIN /etc/grub.d/30_os-prober ###
menuentry 'Windows Boot Manager (on /dev/sda2)' --class windows --class os $menuentry_id_option 'osprober-efi-BA2C-5359' {
insmod part_gpt
insmod fat
set root='hd0,gpt2'
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 BA2C-5359
else
search --no-floppy --fs-uuid --set=root BA2C-5359
fi
chainloader /EFI/Microsoft/Boot/bootmgfw.efi
}
</pre>
Erläuterungen:
*chainloader: Hier wird das 'chainloader'-Verfahren verwendet, bei dem GRUB die Rolle des Bootloaders einfach an einen weiteren Bootloader weitergibt. In diesem Fall ist das der Boot-Loader von Windows 'bootmgfw.efi', welcher sich ebenfalls auf der EFI-Systempartition 'sda2' befindet.

=Anwendungsbeispiele=

==Boot-Reihenfolge dauerhaft verändern==
Die Reihenfolge der Bootloader soll verändert werden. Der zu ändernde Parameter heisst 'BootOrder'.

Ausgangslage: Erster Bootloader ist 'Boot0007* opensuse-secureboot' (shim)
<pre>
suse131-win10:~ # efibootmgr
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0007,0006,0009,0000,0001,0002,0003,0004,0005
Boot0000* EFI DVD/CDROM
Boot0001* EFI DVD/CDROM 1
Boot0002* EFI Floppy
Boot0003* EFI Floppy 1
Boot0004* EFI Hard Drive
Boot0005* EFI Internal Shell
Boot0006* opensuse
Boot0007* opensuse-secureboot
Boot0009* Windows Boot Manager
</pre>
Änderung: Bootloader 'Windows (Boot0009)*' soll zuerst starten:
<pre>
suse131-win10:~ # efibootmgr --bootorder 0009,0006,0007,0000,0001,0002,0003,0004,0005
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0009,0006,0007,0000,0001,0002,0003,0004,0005
Boot0000* EFI DVD/CDROM
Boot0001* EFI DVD/CDROM 1
Boot0002* EFI Floppy
Boot0003* EFI Floppy 1
Boot0004* EFI Hard Drive
Boot0005* EFI Internal Shell
Boot0006* opensuse
Boot0007* opensuse-secureboot
Boot0009* Windows Boot Manager
suse131-win10:~ # reboot
</pre>
In der Folge startet Windows direkt und die Einstellung bleibt auch persistent so erhalten.

==GRUB (shim) verschwunden, Wiederherstellung mittels Live-Distribution==
Der Eintrag für ''shim'' soll verschwinden, so dass ''GRUB2'' nicht mehr aufgerufen wird. So was könnte beispielsweise bei einer nachträglichen Installation oder Update von Windows passieren. Im Anschluss sollte der Eintrag über eine Live-Version wiederhergestellt werden.

Löschen des Eintrags:
<pre>
suse131-win10# efibootmgr --delete-bootnum --bootnum 0007
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0006,0009,0000,0001,0002,0003,0004,0005
Boot0000* EFI DVD/CDROM
Boot0001* EFI DVD/CDROM 1
Boot0002* EFI Floppy
Boot0003* EFI Floppy 1
Boot0004* EFI Hard Drive
Boot0005* EFI Internal Shell
Boot0006* opensuse
Boot0009* Windows Boot Manager
</pre>
Windows an die erste Stelle setzen:
<pre>
suse131-win10# efibootmgr --bootorder 0009,0006,0000,0001,0002,0003,0004,0005
BootCurrent: 0007
Timeout: 0 seconds
BootOrder: 0009,0006,0000,0001,0002,0003,0004,0005
Boot0000* EFI DVD/CDROM
Boot0001* EFI DVD/CDROM 1
Boot0002* EFI Floppy
Boot0003* EFI Floppy 1
Boot0004* EFI Hard Drive
Boot0005* EFI Internal Shell
Boot0006* opensuse
Boot0009* Windows Boot Manager
</pre>
Wie erwartet ist nach dem Reboot der Eintrag für ''shim'' verschwunden und Windows startet sofort.

Zur Reparatur wird der Start einer Live-Version simuliert durch Einbinden eines passenden ISOs im Start-Script der VM und dieses im Boot-Menu ausgewählt:
<pre>
CDROM="/home/gehrke/vm/iso/openSUSE-13.2-KDE-Live-x86_64.iso"
</pre>
Nach dem Start der Live-Version sieht die Situation so aus:
<pre>
linux:~ # blkid
/dev/cdrom: UUID="2014-10-27-15-28-42-00" LABEL="openSUSE 13.2 KDE Live" TYPE="udf" PTUUID="e28d2fda" PTTYPE="dos"
/dev/loop0: TYPE="squashfs"
/dev/ram1: UUID="c6fe4537-8620-4633-bf02-382db894210e" TYPE="ext3"
/dev/sda1: LABEL="Wiederherstellung" UUID="0ED62AE4D62ACC31" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="d96e3f2c-da75-4831-9e07-29c273d4a5a0"
/dev/sda2: UUID="BA2C-5359" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="78c4e591-a88a-44d3-80c1-930cc36f40ae"
/dev/sda4: UUID="20DE2F40DE2F0E1A" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="b08eb833-6fe9-434d-b614-41eccde5caf4"
/dev/sda5: UUID="e464c3a4-a89f-42d4-b270-03a6555fb4be" SEC_TYPE="ext2" TYPE="ext3" PARTLABEL="primary" PARTUUID="81434400-3aca-4935-be82-2838abec5e80"
/dev/sda6: UUID="b6Izp6-XsdX-nYON-dHpa-0nmj-lbpx-lJCfsb" TYPE="LVM2_member" PARTLABEL="primary" PARTUUID="b96d43f0-1f2d-45ab-bb28-e94c2736379a"
/dev/mapper/system-swap: UUID="5bff2383-88f9-4021-82fd-75ffd0204e58" TYPE="swap"
/dev/mapper/system-opsensuse131--root: UUID="58d175a0-c60c-42fc-9ead-64485731d2c9" TYPE="ext4"
/dev/sda3: PARTLABEL="Microsoft reserved partition" PARTUUID="345523d6-4fab-4dd5-a8d8-0f3dae793aca"
</pre>
<pre>
linux:~ # efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0009,0006,0000,0001,0002,0003,0004,0005
Boot0000* EFI DVD/CDROM ACPI(a0341d0,0)PCI(1,1)ATAPI(1,0,0)
Boot0001* EFI DVD/CDROM 1 ACPI(a0341d0,0)PCI(1,1)ATAPI(0,0,0)
Boot0002* EFI Floppy ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,0)
Boot0003* EFI Floppy 1 ACPI(a0341d0,0)PCI(1,0)ACPI(60441d0,1)
Boot0004* EFI Hard Drive ACPI(a0341d0,0)PCI(1,1)ATAPI(0,1,0)
Boot0005* EFI Internal Shell MM(b,900000,10fffff)
Boot0006* opensuse HD(2,96800,31800,78c4e591-a88a-44d3-80c1-930cc36f40ae)File(\EFI\opensuse\grubx64.efi)
Boot0009* Windows Boot Manager HD(2,96800,31800,78c4e591-a88a-44d3-80c1-930cc36f40ae)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.}...C................
</pre>
Zur Restaurierung wird der Eintrag für ''shim'' neu erstellt und als erster Eintrag in der Reihenfolge gesetzt:
<pre>
linux:~ # efibootmgr --create --disk /dev/sda --part 2 --label "opensuse-secureboot (re-constructed)" --loader \\EFI\\opensuse\\shim.efi
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0007,0009,0006,0000,0001,0002,0003,0004,0005
Boot0000* EFI DVD/CDROM
Boot0001* EFI DVD/CDROM 1
Boot0002* EFI Floppy
Boot0003* EFI Floppy 1
Boot0004* EFI Hard Drive
Boot0005* EFI Internal Shell
Boot0006* opensuse
Boot0009* Windows Boot Manager
Boot0007* opensuse-secureboot (re-constructed)
</pre>

<pre>
linux:~ # efibootmgr --bootorder 0007,0006,0009,0000,0001,0002,0003,0004,0005
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0007,0006,0009,0000,0001,0002,0003,0004,0005
Boot0000* EFI DVD/CDROM
Boot0001* EFI DVD/CDROM 1
Boot0002* EFI Floppy
Boot0003* EFI Floppy 1
Boot0004* EFI Hard Drive
Boot0005* EFI Internal Shell
Boot0006* opensuse
Boot0007* opensuse-secureboot (re-constructed)
Boot0009* Windows Boot Manager
</pre>
Das war scheinbar erfolgreich. Nach dem Reboot startet wie erhofft erst shim und dieser dann GRUB2, wo der User dann zwischen Linux und Windows auswählen kann.

Anmerkung: Ein ''chroot'' war an dieser Stelle nicht notwendig. Es ging in diesem Test auch nur um die Wiederherstellung eines verlorenen Eintrages. Im Ernstfall (nachträgliche Windows-Installation) hätten möglicherweise dazu auch noch die entsprechenden Loader auf die EFI-Partition kopiert werden müssen.

=Links=
*[http://forum.mosnis.de/viewtopic.php?f=42&p=237#p234 Tests und Experimente mit efibootmgr (Projektforum)]
*[http://linux.die.net/man/8/efibootmgr efibootmgr(8) - Linux man page]
*[https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/ UEFI boot: how does that actually work, then? (AdamW)]
*[http://wiki.ubuntuusers.de/efibootmgr efibootmgr (Wiki ubuntuusers.de)]
*[http://www.tianocore.org/ovmf/ OVMF (UEFI support for Virtual Machines)]

@@ Zeile 159: / Zeile 159: @@
 Wie zuvor beschrieben, ist die Reihenfolge der Bootloader so: 'shim.efi' übergibt direkt an den nächsten Bootloader 'grubx64.efi', wohinter sich der im UEFI-Binärformat vorliegende erste Teil von [[GRUB2]] verbirgt (welcher ebenfalls signiert ist).
-Dieser findet seine Konfiguration auf 'sda5' und auf Basis dieser Konfiguration wird dem Anwender ein Menü zur Auswahl des gewünschten Betriebssystems (OpenSUSE oder Windows) angeboten. Alle hier zur Auswahl stehenden Kernel müssen aufgrund der [[Secure Boot]]-Einstellung ebenfalls gültig signiert sein, ansonsten kommt es zu einer Laufzeit-Fehlermeldung.
+Dieser findet seine Konfiguration auf 'sda5' und auf Basis dieser Konfiguration wird dem Anwender ein Menü zur Auswahl des gewünschten Betriebssystems (openSUSE oder Windows) angeboten. Alle hier zur Auswahl stehenden Kernel müssen aufgrund der [[Secure Boot]]-Einstellung ebenfalls gültig signiert sein, ansonsten kommt es zu einer Laufzeit-Fehlermeldung.
 Nachfolgend die dafür relevanten Teile der Konfiguration (/boot/grub2/grub.cfg).
-===OpenSUSE===
+===openSUSE===
 <pre>
 ### BEGIN /etc/grub.d/10_linux ###

@@ Zeile 54: / Zeile 54: @@
 Im Folgenden soll die Anwendung dieses Werkzeuges anhand von Beispielen erläutert werden. Zum besseren Verständnis wird vorweg das Setup der Testmaschine beschrieben.
-Als Testsystem wurde eine virtuelle Maschine (VM) verwendet. Dabei wurde als UEFI-Implementierung [[OVMF]] eingesetzt. In dieser VM wurde eine klassische Dual-Boot-Installtion aufgesetzt, welche aus 'OpenSUSE 13.1' einerseits und 'Microsoft Windows10 (Technical Preview)' andererseits besteht. Als BootManager agiert [[GRUB2]]. Dabei wird UEFI im [[SecureBoot]]-Modus gefahren.
+Als Testsystem wurde eine virtuelle Maschine (VM) verwendet. Dabei wurde als UEFI-Implementierung [[OVMF]] eingesetzt. In dieser VM wurde eine klassische Dual-Boot-Installtion aufgesetzt, welche aus 'OpenSUSE 13.1' einerseits und 'Microsoft Windows10 (Technical Preview)' andererseits besteht. Als BootManager agiert [[GRUB2]]. Dabei wird UEFI im '[[Secure Boot]]'-Modus gefahren.
 ==Partitionierung==
@@ Zeile 124: / Zeile 124: @@
 Man erkennt, dass der Bootloader 'Boot0007* opensuse-secureboot' als aktiv markiert ist (BootCurrent: 0007). Dahinter verbirgt sich der signierte Bootloader [[shim]], welcher wie die anderen Bootloader auch auf einer hier genau definierten [[ESP|EFI system partition (ESP)]] liegen.
-''shim'' ist ein einfacher Pre-Boot-Loader, dessen Aufgabe es ist, den nächsten in der Bootreihenfolge stehenden Bootloader unter Berücksichtigung der Zertifikatskette ([[SecureBoot]]) zu starten. In diesem Beispiel ist der nächste Eintrag 'Boot0006* opensuse', welcher ebenfalls ein signierter Bootloader ist.
+''shim'' ist ein einfacher Pre-Boot-Loader, dessen Aufgabe es ist, den nächsten in der Bootreihenfolge stehenden Bootloader unter Berücksichtigung der Zertifikatskette ([[Secure Boot]]) zu starten. In diesem Beispiel ist der nächste Eintrag 'Boot0006* opensuse', welcher ebenfalls ein signierter Bootloader ist.
 Unter 'BootOrder' wird die Reihenfolge aufgezeigt, in welcher nach startbaren Devices gesucht wird.
@@ Zeile 159: / Zeile 159: @@
 Wie zuvor beschrieben, ist die Reihenfolge der Bootloader so: 'shim.efi' übergibt direkt an den nächsten Bootloader 'grubx64.efi', wohinter sich der im UEFI-Binärformat vorliegende erste Teil von [[GRUB2]] verbirgt (welcher ebenfalls signiert ist).
-Dieser findet seine Konfiguration auf 'sda5' und auf Basis dieser Konfiguration wird dem Anwender ein Menü zur Auswahl des gewünschten Betriebssystems (OpenSUSE oder Windows) angeboten. Alle hier zur Auswahl stehenden Kernel müssen aufgrund der [[SecureBoot]]-Einstellung ebenfalls gültig signiert sein, ansonsten kommt es zu einer Laufzeit-Fehlermeldung.
+Dieser findet seine Konfiguration auf 'sda5' und auf Basis dieser Konfiguration wird dem Anwender ein Menü zur Auswahl des gewünschten Betriebssystems (OpenSUSE oder Windows) angeboten. Alle hier zur Auswahl stehenden Kernel müssen aufgrund der [[Secure Boot]]-Einstellung ebenfalls gültig signiert sein, ansonsten kommt es zu einer Laufzeit-Fehlermeldung.
 Nachfolgend die dafür relevanten Teile der Konfiguration (/boot/grub2/grub.cfg).

← Nächstältere Version	Version vom 29. August 2015, 22:04 Uhr
(kein Unterschied)