Linux von BIOS- auf UEFI-Boot umstellen

Aus Knowledgebase
Wechseln zu: Navigation, Suche

Ohne zu wissen, was es mit EFI auf sich hat, ist das Umstellen von Linux von BIOS- auf EFI-Boot auf echter Serverhardware (die meistens minutenlang in der internen Firmware rumhängt) zeitraubend und frustrierend. In Kürze Erklärung und Wichtiges:

Grundlagen

(U)EFI ((Unified) Extensible Firmware Interface) ist mit neuerer Hardware unvermeidbar. Eigentlich ist das Thema sehr einfach: Es gibt keinen binären Bootblock mehr, sondern eine kleine FAT32-Partition zu Beginn der Boot-Disk (ggfs. HW-RAID-Array). Die Bootloader der verschiedenen Betriebssysteme erzeugen eine Verzeichnisstruktur, in welcher dann das eigentliche Startprogramm hinterlegt wird. Die Firmware sammelt beim Systemstart eine Liste der gefundenen ausführbaren Binaries (PE32+ executable) und bietet diese dann zum Start an (bzw. der Standardeintrag wird gestartet).

Fallstricke

  • Ohne Repartitionieren geht es nicht. Da die Umstellung auf EFI durch einem Hardwaretausch mit anschließender Kopie der vorhandenen Installation durchgeführt wird, ist das aber kein Beinbruch.
  • Der initiale Boot (CD, ISO-Image, PXE, USB-Stick, usw.) muss zwingend im EFI-Modus mit einem dementsprechend EFI-fähigen Bootmedium durchgeführt werden. Das Debian-Live-Image von Debian 8 oder älter ist nicht geeignet! Erst ab 9 gibt es EFI-Support, z. B. debian-live-9.6.0-amd64-xfce.iso. Ohne Boot im EFI-Modus sind die EFI-Hooks in der Firmware unsichtbar und Grub-EFI wird mit Fehlern um sich werfen.

Checkliste

  • Neues System vorbereiten (FW-Updates, BIOS-Settings, usw.),
  • Bootmedium vorbereiten (siehe oben),
  • Boot via EFI-Bootmenü von diesem Medium,
  • Ggfs. manuelle Netzwerkkonfiguration,
  • Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),
  • Vorbereiten der Platten für das OS:
    • Partitionieren (gdisk), dabei (eine) z. B. 100 MB große EFI-Partition(en) anlegen, Typ EF00,[1]
    • Ggfs. Erzeugen der gewünschten Arrays mit mdadm,
    • Dateisysteme erzeugen, dabei die EFI-Partition(en) mit einem FAT32-Dateisystem versehen, z. B.: mkfs.fat -F32 /dev/sda1,
    • Mounten des OS-Dateisystems nach z. B. /mnt, cd /mnt,
    • Kopieren der Installation vom Quellsystem, wie gehabt mit z. B. ssh srcsys "dump -0a -b 256 -f - /dev/sda1" |restore -r -b 256 -f -,
    • Vorbereitungen für chroot: mount -o bind /dev dev/,
  • chroot /mnt,
  • Nachmounten von Kernel-Pseudo-Dateisystemen: mount -t proc none /proc; mount -t sysfs none /sys,
  • Anpassen der /etc/fstab, dabei Eintragen der EFI-Partition(en),
  • Mounten der EFI-Partition(en),
  • Nachinstallation von benötigten Systemkomponenten (gdisk, mdadm, dosfstools),
  • Ggfs. schreiben der RAID-Konfiguration mit /usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf; update-initramfs -u,
  • Austauschen von Grub: apt-get install grub-efi-amd64 grub-efi-amd64-bin,
  • Löschen von altem Grub-PC-Kram: dpkg -P grub-pc grub-pc-bin,
  • Prüfen, ob /etc/default/grub existiert und falls nicht, nochmal vom Backup kopieren.

Grub-EFI erfordert keine Platte mehr als Parameter beim beim Grub-Install. Statt dessen wird als (leider benötigter Parameter) dummy übergeben.

grub-install dummy
  • Raus aus der chroot: exit,
  • Unmounten: umount boot/efi* dev proc sys; cd ..; umount mnt.

Nach einem Reboot muss die Installation dann wieder sauber hochkommen. Weitere Schritte wie Netzwerkkonfigurationsanpassungen an die neue Hardware sind nicht beschrieben.

Redundanz

Beim Booten kann dann statt einem möglicherweise wechselnden Gerät, eine Boot-Konfiguration aus dem genannten Verzeichnis eines beliebigen Gerätes gestartet werden. Vorbei sind die Tage, in denen in einem Software-RAID die erste Platte ausfällt, die zweite Platte dann an die erste Stelle rückt, der Bootblock ist aber nicht auf die erste Platte konfiguriert, sondern entweder überhaupt nicht[2] oder das BIOS kommt mit der neuen BIOS-ID (0x80 statt 0x81) nicht zurecht und verweigert den Boot.

EFI hat allerdings eine konzeptionelle Schwachstelle: Die Einfachhheit eine /boot-Partition per Software-RAID zu spiegeln ist nicht vorgesehen. Man kann sich was basteln über mdadm mit nicht persistentem Superblock (damit keine Daten überschrieben werden), aber das ist letztlich alles Gebastel.
Am Einfachsten ist es, manuell die Verzeichnisstruktur auf die zuvor manuell identisch partitionierten und in /boot/efi2, /boot/efi3, usw. gemounteten FAT32-Partitionen zu kopieren.

Für Debian muss eine Datei angelegt und als ausführbar markiert werden: /etc/grub.d/42_update-hook:

#!/bin/sh
# Dirty hack: If there are multiple FA32-mountpoints in /boot/efi, sync
#             contents manually to provide poor man's redundancy.
if mount -t vfat |awk '{print $3}' |grep -q '^/boot/efi$'; then
	cat /dev/null > /var/log/update-grub.log
	for MP in `mount -t vfat |awk '{print $3}' |grep -v '^/boot/efi$'`; do
		rsync -av --delete /boot/efi/ ${MP}/ >> /var/log/update-grub.log
	done
else
	echo "No EFI Mount Point detected." > /var/log/update-grub.log
fi

# --EOF--

Bei jedem Aufruf, der die Grub-Konfiguration neu erzeugt, wird somit auch die Struktur kopiert. Das beinhaltet auch Updates von Kernel und Grub selbst. Fire and forget.

Weblinks

Fußnoten

  1. Tatsächlich benötigt werden vom Grub-Loader einige 100 KBytes.
  2. Schlampiger Admin…
  3. Ob das EFI kompatible Images herstellt, ist derzeit nicht bekannt.