Efibootmgr: Unterschied zwischen den Versionen
Gehrke (Diskussion | Beiträge) K (interne Verlinkung: SecureBoot -> Secure Boot) |
Gehrke (Diskussion | Beiträge) K (Schreibweise openSUSE) |
||
| 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). | 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 ( | + | 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). | Nachfolgend die dafür relevanten Teile der Konfiguration (/boot/grub2/grub.cfg). | ||
| − | === | + | ===openSUSE=== |
<pre> | <pre> | ||
### BEGIN /etc/grub.d/10_linux ### | ### BEGIN /etc/grub.d/10_linux ### | ||
Aktuelle Version vom 4. September 2015, 05:36 Uhr
|
Dieser Artikel oder Teile davon wurden mit 'Review' markiert. Das bedeutet, dass größere Arbeiten am Inhalt des Artikels abgeschlossen sind und der Autor eine Korrekturlesung durch andere User zur Qualitätssicherung für angebracht hält.
Zu sichtende Teile: Gesamter Artikel Bitte hilf LinuxClubWiki, indem du den zu sichtenden Teil überprüfst und den Artikel gegebenenfalls überarbeitest! |
--Gehrke 17:40, 4. Mai 2015 (CEST)
Die 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 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.
Inhaltsverzeichnis
Usage
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)
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 'Secure Boot'-Modus gefahren.
Partitionierung
Sowohl Linux als auch Windows teilen sich eine Festplatte 'sda'.
- sda2: EFI system partition (ESP)
- sda4: Windows (NTFS)
- sda5: /boot (GRUB2)
- sda6: LVM mit LV für / und /swap
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
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
Boot-Konfiguration von EFI
Die aktuelle Boot-Konfiguration von EFI kann man von der linux-Kommandozeile aus wie folgt abfragen:
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................
Neben anderen Informationen werden hier alle verfügbaren 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 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 (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.
Der Zusammenhang wird deutlicher, wenn man sich die UUIDs ansieht:
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"
Zum besseren Verständnis soll beispielhaft dieser Eintrag näher erläutert werden:
Boot0006* opensuse HD(2,96800,31800,78c4e591-a88a-44d3-80c1-930cc36f40ae)File(\EFI\opensuse\grubx64.efi)
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 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 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
### 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
}
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
### 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
}
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)
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
Änderung: Bootloader 'Windows (Boot0009)*' soll zuerst starten:
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
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:
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
Windows an die erste Stelle setzen:
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
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:
CDROM="/home/gehrke/vm/iso/openSUSE-13.2-KDE-Live-x86_64.iso"
Nach dem Start der Live-Version sieht die Situation so aus:
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"
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................
Zur Restaurierung wird der Eintrag für shim neu erstellt und als erster Eintrag in der Reihenfolge gesetzt:
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)
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
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.
