UEFI

Wiki ‹ Installation von Debian ‹ UEFI

Diskussion 164592

Diskussion 168013

Diskussion 168051

Getestet: Dieser Hinweis soll dir dabei helfen, zu entscheiden, ob dieser Artikel auf deinem System funktionieren wird oder nicht. Solltest du feststellen, dass dieser Artikel bei einer ungetestet Version funktioniert, kannst du das gerne hier korrigieren oder im Forum anmerken. Dieser Artikel wurde für Debian Stretch 9.0 getestet.

UEFI (Unified Extensible Firmware Interface)

Was ist UEFI?

Das BIOS (Basic Input/Output System) stellt rudimentären Zugriff auf den Bildschirm und Lese-/Schreibzugriff auf die Sektoren der Festplatten, SSDs, CD-ROMs u.s.w. zur Verfügung, was insbesondere beim Booten des PC eine zentrale Rolle spielt. Außerhalb des Bootprozesses spielt das BIOS jedoch keine Rolle mehr, denn ist das Betriebssystem geladen, übernehmen die dort mitgelieferten Treiber diese Aufgabe.

UEFI (Unified Extensible Firmware Interface) ist der Nachfolger des antiquierten BIOS und stellt einen neuen, standardisierten Satz an Funktionen in der Firmware für den Bootprozess bereit, ferner wird durch UEFI die Firmware um neue Funktionalitäten erweitert, wie z.B. einem standardisiertem Prozess für das Firmwareupdate.

Zeitgleich mit UEFI wurde auch ein neues Partitionsschema namens GPT (GUID Partition Table) eingeführt, welches ein Nachfolger für das Partitionsshema "MSDOS" (Partitionstabelle am Ende des MBR) darstellt. GPT wird nicht hier, sondern in einem separaten Wiki-Artikel beschrieben: GPT (Man beachte aber die Hinweise zu GPT im Abschnitt über die Parallelinstallation von Debian zu MS-Windows.)

Warum UEFI?

Wählt man im BIOS eine Festplatte zum Booten aus, lädt das BIOS die ersten 440 Bytes des ersten Sektors der Festplatte (Master Boot Record oder kurz MBR) und führt sie aus. Dieser Code kann dann mit Hilfe der vom BIOS zur Verfügung gestellten Funktionen ein Bootmenü auf dem Bildschirm anzeigen und Betriebssysteme booten.

Diese Vorgehensweise hat mehrere Nachteile:

1. 440 Bytes sind nicht sehr viel.
   Zu MS-DOS-Zeiten hatte es gereicht, um MS-DOS zu starten, aber funktionsreichere Bootloader wie GRUB bieten viele Konfigurationsmöglichkeiten, unterstützen sehr viele Dateisysteme (FAT, ext2/3/4, xfs, btrfs, …) und bieten weitere Funktionen, sodass 440 Bytes nicht mehr ausreichend sind, um in jedem Falle die benötigten Dateien nachladen zu können. Deswegen verwenden Bootloader wie GRUB zusätzlich die unbenutzten Sektoren zwischen dem MBR und der ersten Partition und sind so zwar nicht mehr auf 440 Bytes limitiert, aber stattdessen auf eine Größe, die von der Partitionierung abhängig ist.
2. Es gilt das Highlander-Prinzip »Es kann nur einen geben!«, sprich: Es kann nur einen Bootcode im MBR geben.
   Jede Betriebssysteminstallation schreibt seinen Bootcode in den MBR und überschreibt damit bereits vorhandenen Bootcode anderer, ebenfalls installierter Betriebssysteme.
3. Mit Hilfe des BIOS kann man nur auf die ersten 2TB einer Festplatte zugreifen.
   Bootcode wie GRUB kann also nur auf Dateien zugreifen, die sich innerhalb der ersten 2TB der Festplatte befinden.
4. Auch ein Virus könnte sich in die ersten 440 Bytes des MBR schreiben und sich so in den Bootprozess einklinken.
   Die Hersteller haben deswegen mit verschiedenen Techniken gearbeitet (oft als „Virenschutz“ oder „MBR Schutz“ angepriesen), die aber nur bedingt brauchbar waren, insbesondere, da sie nicht zwischen gutem Code (Betriebssysteminstallation) und bösem Code (Virus) unterscheiden konnten und meist einfach nur eine Änderung des Codes im MBR verhinder haben.

Diesen Schwachstellen begegnet UEFI:

1. Anstelle von 440 Bytes Bootcode gibt es eine spezielle Partition im FAT32-Format, die sogenannte EFI System Partition (ESP), auf der der Bootloader von Betriebsystemen in Form von Dateien mit der Endung .efi gespeichert wird.
   UEFI kann also Partitionstabellen auf Datenträgern (im MSDOS- oder GPT-Partitionsformat) lesen und interpretieren, um die ESP auf der Platte ausfindig zu machen, und es kann das Dateisystem lesen.
   So kann das UEFI den von Betriebssysteminstallationen hinterlegten Bootcode laden und ausführen und der Bootloader kann auch ohne Tricks wie das Nutzen (vermeintlich) ungenutzter Sektoren größer als 440 Bytes sein.
2. Der Bootcode der Betriebssysteme liegt in Dateien unterschiedlicher Pfade bzw. Dateinamen.
   Diese Pfade tragen die Betriebssysteme bei der Installation in Form von Booteinträgen in das NVRAM ein, und verknüpfen sie mit Namen wie etwa "Windows Boot Manager" oder "Debian". Somit können mehrere Bootloader in der ESP hinterlegt werden, die das UEFI meist beim Drücken der Taste F12 beim Booten als Bootmenü präsentiert. (Im Gegensatz zum BIOS, das nichts von Partitionstabellen, Partitionen oder gar den installierten Betriebssystemen wusste und daher nur eine Liste der Datenträger bieten konnte.)
   Zusätzlich zu den Booteinträgen im NVRAM gibt es auch noch einen speziellen Pfad von dem normalerweise auch ohne entsprechenden Booteintrag gebootet werden kann, den sogenannten „Removable Media Path“, der auf den üblichen 64 Bit-Systemen zum Beispiel »EFI/BOOT/BOOTX64.EFI« lautet.
3. Die 2TB-Beschränkung wurde aufgehoben. Ferner bestehen die meisten UEFI aus 64-Bit Code (und nicht mehr aus 16-Bit-Code wie beim BIOS).
4. Es wurde das Feature „Secure Boot“ eingeführt, welches nur Bootloader lädt, die signiert sind und deren Signatur vom UEFI selbst überprüft werden kann. „Secure Boot“ ist bei der Auslieferung des PC eingeschaltet, kann aber in der Regel ausgeschaltet werden.

Legacy-Modus bzw. CSM (Compatibility Support Module)

Bei einer aktuellen PC-Firmware mit UEFI kann man auch den sog. "Legacy-Modus" oder "CSM" oder "MBR" in den Einstellungen der Firmware aktivieren und erhält so die Möglichkeit, auch zusätzlich von Datenträgern mit Bootcode im MBR zu booten. Ferner erhält das im "Legacy"-Modus gebootete Betriebssystem keinen Zugriff auf die UEFI-Funktionalitäten, verhält sich also aus Betriebssystemsicht so wie ein BIOS (ohne UEFI).

„Legacy“ bzw. „CSM“ ist in der Regel bei der Auslieferung des PC ausgeschaltet.

Die Installation von Debian (im UEFI-Modus)

Da Debian noch kein „Secure Boot“ unterstützt, muß es vor der Installation von Debian in den Einstellungen der Firmware deaktiviert werden. (Stand: Debian 9) Sieht das UEFI des eigenen PC diese Möglichkeit nicht vor (was zum Glück die Ausnahme und nicht die Regel ist), kann aktuell kein Debian installiert werden, man muß stattdessen auf andere Linux-Distributionen wie Fedora oder CentOS ausweichen, die mit einer Signatur von Microsoft signiert sind und so im Gegensatz zu Debian „Secure Boot“ unterstützen.

Aktuelle Installations-ISOs von Debian unterstützen sowohl die Installation von Debian auf älteren Rechnern mit BIOS (bzw. auf aktuellen Rechnern mit UEFI im Legacy-Modus), als auch die Installation im UEFI-Modus.

Bei der Verwendung von einem USB-Stick als Installationsmedium ist es deswegen wichtig, ein Tool zum Kopieren des ISO auf den USB-Stick zu wählen, welches keine Modifikationen an dem Image vornimmt.

Unter Linux empfielt sich hierfür dd, zum Beispiel (mit USB-Stick auf /dev/sdb):

root@debian:~# dd if=debian-9.3.0-amd64-netinst.iso of=/dev/sdb bs=1M

Unter Windows kann das Tool Win32DiskImager verwendet werden.

Tools wie "Unetbootin" oder "Rufus" hingegen bieten die Möglichkeit, das Image auf dem USB-Datenträger modifiziert abzulegen und sind daher nur für versiertere Anwender bzw. Experten geeignet. Außerdem stellen sie durch ihre erweiterten Möglichkeiten eine potentielle Fehlerquelle beim Erstellen des Installations-USB-Sticks dar.

Weitere Hinweise zur Erstellung eines Debian-Installationssticks erhält man auf den Seiten des Debian-Projektes.

Hinweis: Ist bei dem UEFI die Unterstützung von "Legacy" aktiviert, bietet das Bootmenü der Firmware den Debian-Installations-USB-Stick zweimal an, einmal als "UEFI" und einmal als "Legacy".

Die Wahl des Eintrages im Bootmenü bestimmt, ob der Stick im UEFI-Modus oder im Legacy-Modus gebootet wird. (Wie eindeutig diese als "UEFI" oder "Legacy" gekennzeichnet sind gibt der Hersteller des UEFI vor und ist von UEFI zu UEFI unterschiedlich. Im Zweifelsfalle deaktiviert man vor der Installation die Unterstützung des "Legacy"-Bootmechanismus.)

Die Wahl des Bootmenüeintrags gibt auch den weiteren Installationsverlauf vor, d.h. wird der Stick im UEFI-Modus gebootet, wird Debian den Bootcode in die ESP eintragen, "Debian" als Booteintrag in das NVRAM schreiben sowie die ESP für den späteren Betrieb als /boot/efi in die /etc/fstab einbinden.
Wird der Stick hingegen im Legacy-Modus gebootet, wird Debian den Bootcode in den MBR schreiben, wie bei einer Installation auf einem älteren PC mit BIOS. Ein so installiertes Debian kann auch später nur gebootet werden, wenn "Legacy" bzw. "CSM" in der Firmware aktiviert ist.

Ein Beispiel, aufgenommen von einem Laptop des Herstellers Dell:

Hier sind die Booteinträge im Bootmenü der Firmware in "LEGACY BOOT" und "UEFI BOOT" unterteilt. Der Debian-Installationsstick wird in beiden Kategorien angeboten, als "LEGACY BOOT: USB Storage Device" und "UEFI BOOT: UEFI: JetFlashTranscend 4GB 1100, Partition 1". (Die Einträge "Fedora" und "Windows Boot Manager" unter "UEFI BOOT:" weisen auf ein bereits auf diesem Rechner im UEFI-Modus installiertes Fedora und MS-Windows hin.)

Ist bereits ein (beliebiges) Betriebssystem im UEFI-Modus installiert, kann Debian ohne weiteres ebenfalls im UEFI-Modus installiert werden (natürlich nachdem man Platz für Debian geschaffen hat). (Unter MS Windows kann man das mittlerweile mit Bordmitteln im laufenden Windows-System erledigen.)

Der Installer erkennt eine bereits existierende ESP (EFI-System-Partition) automatisch und bindet sie als "EFI-System-Partition" unter /boot/efi ein.

Ist die Platte leer, kann man Debian 9 über die geführte Partitionierung geradeaus installieren. Der Debian-Installer legt hierbei automatisch eine 0.5GB große ESP an.

Möchte man die manuelle Partionierung verwenden, muss man entweder im Installer eine ESP anlegen, oder aber eine vorher angelegte ESP als „EFI-System-Partition“ (=»/boot/efi«) einbinden.

Installation von Debian in Virtualbox (im UEFI-Modus)

Ist in VirtualBox "EFI aktivieren (nur spezielle Gäste)" für die virtuelle Maschine aktiviert, erfolgt die Installation von Debian 9 reibungslos, es startet auch nach der Installation.

Wird VirtualBox allerdings beendet und neu gestartet, bootet die Debian-VM nicht mehr. Grund ist, daß das VirtualBox (U)EFI nicht vollständig implementiert ist, konkret merkt es sich im NVRAM der virtuellen Maschine angelegte Einträge im Bootmenü nicht dauerhaft, sondern sucht stattdessen lediglich in der ESP nach bekannten OS-Bootloadern, wobei es denjenigen von Debian nicht kennt. (Das dürfte wohl mit "nur spezielle Gäste" gemeint sein, zu denen Debian nicht zählt.)

Temporäre Abhilfe: Beim Booten der virtuellen Maschine im "Boot Maintenance Manager" den Punkt "Boot from File" auswählen, anschließend die Datei EFI/debian/grubx64.efi. Dann bootet Debian.

Dauerhafte Abhilfe: Ein Startskript startup.nsh mit dem Inhalt

FS0:\EFI\debian\grubx64.efi

in der "UEFI Interactive Shell" von VirtualBox anlegen, in der man bei einem Bootversuch automatisch landet. Siehe auch Ask Ubuntu: "virtualbox machine boots to efi shell"

Fazit: In einer virtuellen Maschine installiert man Debian am besten wie gewohnt ohne "EFI aktivieren" und sieht dieses Feature als experimentell an. Zum Üben von "UEFI" taugt VirtualBox folglich nur sehr bedingt, man bekommt Probleme, die man auf einer realen Hardware (hoffentlich) nicht haben wird.

Installation von Debian parallel zu MS-Windows 7/8/10

Microsoft hat Installationen von MS-Windows einer Beschränkung unterzogen, die keine technische Notwendigkeit hat: Ein installiertes MS-Windows bootet nur dann im UEFI-Modus, wenn das Bootmedium das Partitionsschema GPT aufweist. Umgekehrt bootet es nur dann im Legacy-Modus, wenn das Bootmedium das Partitionsschema MSDOS aufweist.

Dies hat zur Folge, daß man Debian am besten im gleichen Modus installiert wie zuvor MS-Windows installiert wurde, also entweder mit UEFI+GPT oder Legacy+MSDOS, denn dann und nur dann kann Debian MS-Windows wie gewohnt in sein Boot-Menü aufnehmen.

Ein MS-Windows 8 oder 10 im Auslieferungszustand des PC wird immer im UEFI-Modus installiert sein (und somit auch ein GPT-Partitionsschema aufweisen), da Microsoft diese Installationsart den Herstellern vorgibt.

Ob ein MS-Windows im UEFI-Modus läuft oder nicht, kann man mit Hilfe der beiliegenden Anwendung msinfo32.exe herausfinden. Unter „Systemübersicht, BIOS-Modus“ steht im UEFI-Modus die Bezeichnung „UEFI“, im Legacy-Modus hingegen die Bezeichnung „Vorgängerversion“.

Alternativ kann man auch ein Linux-Live-System von CD-ROM oder USB booten, um mittels

root@debian:~# fdisk -l /dev/sda

nachzuschauen, ob MS-Windows auf einer Platte mit MSDOS- oder GPT-Partitionsschema installiert ist. Hier als Beispiel ein im UEFI-Modus installiertes MS-Windows:

root@debian:~# fdisk -l /dev/sda
Festplatte /dev/sda: 931,5 GiB, 1000204886016 Bytes, 1953525168 Sektoren
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes
E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes
Festplattenbezeichnungstyp: gpt
Festplattenbezeichner: 7021256F-6577-4ED3-8281-5682A4ED5D2D

Gerät         Anfang       Ende   Sektoren  Größe Typ
/dev/sda1       2048    1026047    1024000   500M EFI-System
/dev/sda2    1026048    1288191     262144   128M Microsoft reserviert
/dev/sda3    1288192  226847154  225558963 107,6G Microsoft Basisdaten
/dev/sda4  226848768  228673535    1824768   891M Windows-Wiederherstellungsumgebung
/dev/sda5  228673536  250068991   21395456  10,2G Windows-Wiederherstellungsumgebung

Man sieht, daß das Partitionsschema (hier als "Festplattenbezeichnungstyp" bezeichnet) GPT ist und eine ESP (hier als "EFI-System" bezeichnet) beinhaltet.

Bootreihenfolge

Während man früher im BIOS-Setup die Bootreihenfolge der Datenträger festlegen konnte, kann man nun im UEFI die Bootreihenfolge der Betriebssysteme der Datenträger festlegen.

Ferner hat das UEFI eine Schnittstelle für Anwendungen, um diese Reihenfolge lesen und auch verändern zu können. Unter Linux gibt es für diesen Zweck die Kommandozeilenanwendung efibootmgr, so listet zum Beispiel

root@debian:~# efibootmgr -v

die Reihenfolge und listet die Einträge.

Beispielausgabe:

root@debian:~# efibootmgr -v
BootCurrent: 0002
Timeout: 0 seconds
BootOrder: 0002,0000,0003,0004,0006,0007
Boot0000* Windows Boot Manager	HD(1,GPT,32034744-2326-4a7c-b28c-974c1cdf5b46,0x800,0xfa000)/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.}....z...............
Boot0001* Linux-Firmware-Updater \fwupx64.efi	HD(1,GPT,32034744-2326-4a7c-b28c-974c1cdf5b46,0x800,0xfa000)/File(\EFI\fedora\shim.efi)\.f.w.u.p.x.6.4...e.f.i...
Boot0002* Debian	PciRoot(0x0)/Pci(0x17,0x0)/Sata(2,65535,0)/HD(1,GPT,32034744-2326-4a7c-b28c-974c1cdf5b46,0x800,0xfa000)/File(\EFI\debian\grubx64.efi)
Boot0003  Diskette Drive	BBS(Floppy,Diskette Drive,0x0)..BO
Boot0004  Internal HDD	BBS(HD,P2: Samsung SSD 850 EVO M.2 1T,0x0)..BO
Boot0006  CD/DVD/CD-RW Drive	BBS(CDROM,CD/DVD/CD-RW Drive,0x0)..BO
Boot0007  Onboard NIC	BBS(Network,Onboard NIC,0x0)..BO

Firmware-Update

UEFI bietet eine standardisierte Schnittstelle zum Firmwareupdate des UEFI. Die Firmware wird hierfür auf der ESP abgelegt und dem UEFI bekannt gemacht, beim nächsten Booten hat man dann die Möglichkeit, dieses Update einzuspielen.

Unter Linux wird diese Funktionalität von dem "GNOME Software Center" und dem Kommandozeilentool "fwupdmgr" aus dem Paket fwupd bereitgestellt. Der Hersteller des PC muß hierfür die Firmware über den Linux Vendor Firmware Service (LVFS) verteilen.

Dell tut dies zum Beispiel:

root@debian:~# fwupdmgr get-updates
Firmwareaktualisierungen für Latitude E7470 TPM 2.0 verfügbar:
GUID:                    ba6efd02-40f2-53d7-ac3e-b381aac1a6a9
Kennung:                 com.dell.uefi22d63f4.firmware
Version aktualisieren:   1.3.1.0
Update Remote ID:        lvfs
Prüfsumme aktualisieren:SHA1(1b6af0a6946181fae71388858674243bf59d2bea)
Ort aktualisieren:       https://fwupd.org/downloads/a1a6e10beb96281fa78c62a7d967c8c3a1cf7430-DellTpm2.0_Fw1.3.1.0.cab
No upgrades for device, current is 0.1.18.5: 0.1.18.5=same, 0.1.16.4=older, 0.1.15.4=older, 0.1.13.4=older, 0.1.11.3=older

root@debian:~# fwupdmgr update
Downloading 1.3.1.0 for Latitude E7470 TPM 2.0...
Fetching firmware https://fwupd.org/downloads/a1a6e10beb96281fa78c62a7d967c8c3a1cf7430-DellTpm2.0_Fw1.3.1.0.cab
Downloading…           [***************************************]
Updating 1.3.1.0 on Latitude E7470 TPM 2.0...
Entpacken …            [***************************************]
Authenticating…        [***************************************]
Einplanen …            [***************************************]
No upgrades for device, current is 0.1.18.5: 0.1.18.5=same, 0.1.16.4=older, 0.1.15.4=older, 0.1.13.4=older, 0.1.11.3=older

UEFI hat einen schlechten Ruf, warum?

Dies hat im wesentlichen drei Gründe:

• Die ersten UEFI-Implementationen seitens der Hersteller waren mangelhaft. Manche Hersteller haben ihr UEFI gerade so implementiert, daß Windows 8 booten kann. Bestenfalls wurde noch RHEL 6 erkannt und konnte gebootet werden, damit die Hardware für den Einsatz mit RHEL (RedHat Enterprise Linux) zertifiziert werden konnte. Selbst wenn das UEFI andere Bootloader akzeptiert hatte, war die Ausführung ein Risiko und konnte unschöne Nebeneffekte haben. Manche UEFI-Implementationen haben zum Beispiel zur Folge gehabt, daß sich der GRUB-Bootloader bei jedem Booten immer wieder ins UEFI eingetragen hatte, bis die Anzahl der Bootloader im UEFI überschritten war. Durch einen weiteren Fehler im UEFI hatte das UEFI als Folge das Booten des Rechners ganz verweigert, ebenso konnte man nicht mehr in das Konfigurationsmenü des UEFI.
• Die ersten UEFI-Implementationen haben den alten Bootprozess (Bootcode im MBR) nicht mehr unterstützt und/oder "Secure Boot" war nicht abschaltbar. So konnte man seine mit YUMI erstellten USB-Sticks nicht mehr booten usw. Linux war nicht installierbar, zumindest solange kein Linux "Secure Boot" unterstützt hat.
• Das Thema UEFI wird mit vielen anderen Themen vermischt. Dadurch bekommt der Anwender den Eindruck, es hätte sich sehr viel geändert, und die Zusammenhänge werden dem Anwender nicht klar. Als Beispiel ist das neuere Partitionierungsschema GPT zu nennen, welches ein Nachfolger des MBR-Partitionsschema ist. Hinzu kommt, das oftmals Einschränkungen seitens MS-Windows fälschlicherweise für generelle Einschränkungen von UEFI gedeutet werden.

Problembehandlung

Fehlermeldung "Scheinbar existieren andere Betriebssysteme" bei der Installation von Debian

Kann der Debian-Installer keinen geeigneten Ort für die Installation des Bootloaders GRUB finden, meldet er den irreführenden Fehler "Scheinbar existieren andere Betriebssysteme".

Wurde die Debian-Installation im UEFI-Modus gestartet, und gibt es vor der Installation von Debian keine ESP, wohl aber andere Partitionen, meckert der Installer dies so an. Man kann ihm dann mitteilen, dass man trotzdem mit der Installation fortfahren möchte und das Problem über die manuelle Partitionierung lösen. Bindet man hierbei eine existierende oder neu angelegte FAT32-Partition als „EFI-System-Partition“ ein, setzt der Installer für diese Partition automatisch die ESP-Markierung und alles wird gut.

Gibt es keine ESP, und bindet man auch keine vorhandene (oder neu angelegte) Partition als "EFI-System-Partition" ein, meckert der Installer erneut beim Abschließen der manuellen Partitionierung. Ignoriert man auch diese Meldung, und fährt trotzdem fort, schlägt die Installation von GRUB naturgemäß fehl, denn es gibt keine ESP, in der sich GRUB installieren könnte. Hier kann man dann entweder zur Partitionierung zurückkehren, oder trotzdem fortfahren. Bei letzterem bekommt man allerdings naturgemäß keine bootfähige Debian-Installation.

Ist man sich hingegen sicher, eine ESP auf dem System zu haben (etwa, weil bereits MS-Windows im UEFI-Modus installiert auf der Platte ist), ist höchste Vorsicht geboten, wenn man diese Meldung bekommt. Wahrscheinlich hat man die Debian-Installation im Legacy/CSM-Modus gestartet, und da der Platz nach dem MBR bereits mit der GPT belegt ist, kann der Debian-Installer GRUB dort nicht installieren, sondern benötigt extra Platz in Form einer eigenen GRUB-Partition. Die Abhilfe ist in diesem Falle, die Installation abzubrechen und die Installation erneut im UEFI-Modus zu starten. Möchte man sichergehen, daß man Debian im UEFI-Modus installiert, schaltet man ab besten vor der Installation im UEFI die Unterstützung von Legacy/CSSM am besten ab. (Bootet anschließend die Debian-Installation nicht, hat man den USB-Stick falsch erstellt.)

Ich mag GRUB nicht und möchte lieber LILO oder EXTLINUX als Bootloader einsetzen. Geht das?

Nein, weder LILO noch EXTLINUX stellen ihren Bootloader als EFI-Modul bereit.

Die Entwicklung einer (U)EFI Variante von LILO namens ELILO wurde zwar ca. 2000 begonnen, die Entwicklung wurde aber 2014 eingestellt.

Nach der Installation von Debian habe ich neben meinen Partitionen noch eine zusätzliche FAT32-Partition. Was ist das?

Das ist vermutlich die "EFI System Partition". Sie zu löschen wäre keine gute Idee ;-)

Nach der Installation von Debian habe ich keine ESP -oder- efibootmgr liefert die Fehlermeldung "EFI variables are not supported on this system."

Dann hat man die Installation von Debian nicht im UEFI-Modus gestartet und sich Debian folglich nicht im UEFI-Modus installiert. Es ist notwendig, bei der Bootauswahl der Firmware den korrekten Eintrag zu wählen.

Um diesen Eintrag zu bekommen, ist es notwendig, den USB-Stick korrekt zu erstellen. Eine mögliche Fehlerquelle ist hier insbesondere die Verwendung von Tools wie "Unetbootin", "Rufus" oder "YUMI" bzw. deren Fehlbedienung. Am besten hält man sich an die von Debian bereitgestellte Anleitung zum Erstellen des USB-Sticks. [5]

Nach der Installation von Debian habe ich keinen "Windows"-Eintrag im GRUB-Bootmenü, ich kann lediglich Debian booten

Vermutlich wurde Debian nicht im gleichen Modus ("Legacy" oder "UEFI") installiert wie MS-Windows.

Eine erste Diagnose liefern folgende Kommandos:

• Existiert die Datei /sys/firmware/efi? Wenn sie nicht existiert, wurde Debian im Legacy-Modus installiert.
• Ist das Partitionsschema "GPT"? Habe ich eine ESP? Dies kann mit

  root@debian:~# fdisk -l /dev/sda
  

  überprüft werden.
• Wer hat sich auf der ESP verewigt, sind dort Debian und Microsoft zu finden? Dies kann mit

  root@debian:~# ls /boot/efi/EFI
  

  überprüft werden. Beispielausgabe:

  root@debian:~# ls /boot/efi/EFI
  Boot debian dell Microsoft
  

• Wer hat sich in die UEFI-Boottabelle eingetragen und wie ist dort die Bootreihenfolge? Dies kann mit

  root@debian:~# efibootmgr -v
  

  überprüft werden.
• Findet Debian das MS-Windows auf der Platte? Dies kann mit

  root@debian:~# os-prober
  

  überprüft werden.

Nach einem Update von MS-Windows bekomme ich kein GRUB-Bootmenü mehr, sondern es bootet direkt MS-Windows

Es kann vorkommen, daß MS-Windows bei einem größeren Update kackfrech die UEFI-Bootreihenfolge zu seinen Gunsten ändert. Dies kann man im UEFI-Setup wieder zurückändern, wenn der Hersteller des UEFI diese Möglichkeit vorsieht.

Ansonsten bringt folgender Befehl unter MS-Windows Abhilfe:

bcdedit /set {bootmgr} path \EFI\debian\grubx64.efi

Alternativ kann man auch ein Live-Linux von USB im UEFI-Modus booten und von dort mit "efibootmgr" die Bootreihenfolge zu Gunsten von Debian zurückändern.

Restauration des Bootloaders GRUB

Da andere Betriebssysteminstallationen den Bootloader GRUB in der ESP nicht überschreiben, gibt es in der Regel keinen Grund für eine Restauration. Stattdessen sollte man nachschauen, ob nicht nur die Bootreihenfolge des UEFI verändert wurde.

Sollte dennoch die Restauration von GRUB notwendig sein, zum Beispiel weil man aus Versehen eine für das Booten von Debian relevante Datei aus der ESP gelöscht hat, sei auf den Wiki-Artikel Grub_reparieren verwiesen:

root@debian:~# apt-get install --reinstall grub-efi
root@debian:~# grub-install /dev/sda
root@debian:~# update-grub

Nach der Installation von Debian bootet Debian, aber nachdem ich den Rechner ausgeschaltet habe, bootet wieder MS-Windows bzw. wenn ich ins das UEFI-Bootmenü gehe, existiert dort kein Booteintrag für Debian

Das ist ein Indiz für ein fehlerhaft implementiertes UEFI, vermutlich ist es eine ältere Variante, die lediglich zum Booten von MS-Windows (und ggf. RHEL 6) ausgelegt wurde.

Eine mögliche Abhilfe wäre, Debian im "Legacy"-Modus zu installieren. Sollte das UEFI diese Möglichkeit nicht vorsehen, könnte man versuchen, rEFInd als EFI-Bootmanager zu installieren. Sollte auch dies scheitern, kann man versuchen, das Verzeichnis EFI/debian auf der ESP nach EFI/redhat umzubenennen, ferner die Datei grubx64.efi in diesem Verzeichnis nach grub.efi. Mit etwas Glück akzeptiert UEFI diesen Bootloader als RHEL6 Bootloader.

Ich habe interesserhalber mal "efibootmgr -v" aufgerufen und finde dort den Booteintrag "Debian" mehrfach. Ist das ein Problem?

JA!

Vermutlich handelt es sich um einen bekannten Fehler in einigen älteren UEFI-Implementationen, die zur Folge haben, daß pro Bootvorgang ein neuer Booteintrag erzeugt wird, solange, bis das UEFI der Meinung ist, die Boottabelle sei voll und anschließend den Dienst einstellt.

Abhilfe: Als erstes mit

root@debian:~# efibootmgr --remove-dups

alle doppelten Einträge löschen. Dann nachschauen, ob es ein Firmwareupdate für den PC gibt und überprüfen, ob dann das Problem behoben ist. Wenn nicht, muß Debian zwingend im "Legacy-Modus" installiert werden.

Ich habe ein im UEFI-Modus installiertes MS-Windows, habe aber Debian im Legacy-Modus installiert. Ist das ein Problem?

Nein, denn man kann über das UEFI-Bootmenü wählen, ob man MS-Windows oder Debian booten möchte. Es ist aber so kein Eintrag "Windows" im GRUB-Bootmenü von Debian möglich.