Probleme mit UEFI lösen

Aus Siduction Wiki DE
Wechseln zu: Navigation, Suche

UEFI, das Unified Extensible Firmware Interface ist bei vielen Anwendern unbeliebt. Diese Abneigung ist teils berechtigt, da wenig über die Vorteile von UEFI bekannt ist, es sich andererseits aber oft genug störrisch zeigt, wenn es um die Installation unter dem neuen Standard geht. Neben den klicki-bunten BIOS bietet UEFI in der 2. Ausarbeitung der Spezifikation aber auch Vorteile. Dazu zählt beispielsweise die Möglichkeit, Firmware (einschliesslich des BIOS selbst) aus dem laufenden System heraus automatisch oder manuell zu aktualisieren.

Auf der anderen Seite spuckt diese Spezifikation dem Anwender auch oft genug in die Suppe. Wie bereits seit vielen Jahren bei lieblosen Implementierungen von BIOS bei Notebooks durch die Hersteller lässt auch die UEFI-Spezifikation genug Raum für Schandtaten seitens der Hardwarebranche, die in den seltensten Fällen auf Linux Rücksicht nimmt. Hier soll nun ein Problemfall geklärt werden, der dem siduction Team in letzter Zeit mehrmals unterkam. Dabei hat nicht nur Acer bei einem günstigen Aspire ES1-311 Notebook gepatzt sondern auch MSI bei einem Skylake-Mainboard und - völlig unverständlich - Intel mit einem NUC; war doch Intel an der Ausarbeitung von UEFI maßgeblich beteiliegt.

Hier der Fall: Die Installation von siduction mit UEFI funktioniert einwandfrei, jedoch wird nach Abziehen des USB-Sticks und Reboot kein Bootmanager-Eintrag gefunden, um das System zu booten. Schaut man dann ins installierte System, stellt man fest, dass die Firmware das Gerät nicht als bootfähigen EFI-Datenträger erkennt (zu erkennen an einem leeren /boot/efi/EFI/debian/) oder im einfachsten Fall die Bootreihenfolge nicht stimmt. Steckt man jedoch den USB-Stick wieder an, kann man, anstelle das Live-Systems und nach Auswahl eines UEFI-Booteintrags auch das soeben installierte System booten. Dieser Wiki-Eintrag holt für UEFI-Neulinge etwas weiter aus und schildert auch die Vorbereitungen und die Installation sowie der Behebung der Probleme, die, je nach verwendeter Hardware auftreten können. Mit der "richtigen" Hardware kann eine UEFI-Install aber auch völlig schmerzfrei sein.

Vorbereitung der Installation

Zuerst muss nach dem Umstellen auf UEFI im BIOS eine UEFI-Partition angelegt werden, die mindestens 100 MByte, aber auch gerne 500 MByte umfassen darf und die mit FAT32 zu formatieren ist. Diese Partition wird als ESP oder EFI-System-Partition bezeichnet. Dieser weisen wir mit gdisk den Datentyp ef00 zu. Gdisk deshalb, da wir mit dem Parti­tionierungs­schema namens GUID Partition Table (GPT) arbeiten. Die Spezifikation hierzu ist Teil des UEFI-Standards. Zusätzlich erstellen wir weitere benötigte Partitionen, ebenfalls mit GPT.

Bei der Überprüfung sollte der Eintrag ähnlich diesem aussehen:

gdisk -l /dev/sda

GPT fdisk (gdisk) version 1.0.1

Partition table scan:

 MBR: protective
 BSD: not present
 APM: not present
 GPT: present

Found valid GPT with protective MBR; using GPT.

Disk /dev/sda: 976773168 sectors, 465.8 GiB

Logical sector size: 512 bytes

Disk identifier (GUID): 9A4A1128-0F2F-481B-9516-1F0F9984F33E

Partition table holds up to 128 entries

First usable sector is 34, last usable sector is 976773134

Partitions will be aligned on 2048-sector boundaries

Total free space is 409602029 sectors (195.3 GiB)

Number Start (sector) End (sector) Size Code Name

  1            2048         1026047   500.0 MiB   EF00
  2         1026048        41986047   19.5 GiB    8300

Vorarbeit im Installer

Im Installer gilt es eine Einstellung vorzunehmen, ohne die eine UEFI-Install nicht gelingen wird. Wir gehen im Beispiel davon aus, dass /dev/sda1 die UEFI-Partition ist und /dev/sda2 Root beheimaten wird. Nachdem wir im Installer /dev/sda2 als Rootpartition festgelegt haben, wechseln wir auf die nächste Seite des Installers, die mit Mountpoint-Definitionen überschrieben ist. Hier müssen wir nun einen Mountpoint definieren, der derzeit noch nicht vorgegeben ist. Dazu klicken wir auf ""Freitext"" und geben darüber /boot/efi ein, nachdem wir links /dev/sda1 ausgewählt haben. Über ""Einfügen"" legen wir den Mountpoint fest. Das sieht dann so aus:

Efi-Mountpoint erstellen

Danach kann die Installation normal weitergeführt werden. Wenn der Rechner nach Neustart und Abziehen des Installations-Sticks problemlos booted, ist alles gut gegangen und die Hardware ist UEFI-standardkonform. Ist das nicht der Fall, müssen wir eine Changed Root (chroot) öffnen und nachschauen, was schief gelaufen ist.

Problemanalyse in der Chroot

Eine chroot in der Live-Umgebung ist schnell aufgesetzt. Nachdem wir mit su - Rootrechte erreicht haben, müssen dazu folgende Devices eingebunden werden:

root@siduction:~# mount /dev/sda2 /mnt/
root@siduction:~# mount /dev/sda1 /mnt/boot/efi/
root@siduction:~# mount --bind /proc /mnt/proc
root@siduction:~# mount --bind /run /mnt/run
root@siduction:~# mount --bind /sys /mnt/sys
root@siduction:~# mount --bind /dev /mnt/dev
root@siduction:~# mount --bind /dev/pts /mnt/dev/pts
root@siduction:~# chroot /mnt /bin/bash

Danach befinden wir uns in der Installation, die wir vorhin vorgenommen. Als erstes schauen wir nach, ob sich in der ESP Daten befinden oder ob es ein leeres Verzeichnis ist. Dazu dient uns der Befehl evibootmgr -v. Wenn die Ausgabe ähnlich der im Screenshot aussieht, ist das die halbe Miete, denn die ESP enthält gültige Daten

Ausgabe von efibootmgr -v