Efibootmgr

Aus Linupedia.org
Version vom 29. August 2015, 22:04 Uhr von Robi (Diskussion | Beiträge) (1 Version importiert: Übernahme der Wikiseiten aus der Arbeitsumgebung des NosNis Wiki)
Wechseln zu: Navigation, Suche
Höhe=24px 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.


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 SecureBoot-Modus gefahren.

Partitionierung

Sowohl Linux als auch Windows teilen sich eine Festplatte 'sda'. 

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 (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: 

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 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

### 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.

Links

Abgerufen von „https://linupedia.org/wiki/mediawiki/index.php?title=Efibootmgr&oldid=31997“