QVINTVS · SCRIBET

Bootfähiger UEFI-USB-Stick

In diesem Artikel wird ein USB-Stick so behandelt, dass ein UEFI-System von ihm booten kann, ohne dass der Legacy-Mode dafür benötigt wird.

I. Hintergrund

1. Booten mit BIOS und mit UEFI

Es dürfte sich mittlerweile herumgesprochen haben, dass die traditionelle und noch aus dem letzten Jahrtausend stammende Methode, x86-PCs zu booten, BIOS („Basic Input/Output System“), nicht mehr dem Stand der Technik entspricht. Auch wenn man gelegentlich noch PCs mit BIOS antrifft — vornehmlich Desktop-PCs —, werden neue Rechner grundsätzlich mit der Nachfolgetechnologie UEFI („Unified Extensible Firmware Interface“) ausgestattet.

Zu Unrecht hat UEFI sich im Laufe seiner noch jungen Geschichte einen Ruf als recht kompliziert erwiesen. Dafür dürfte es im wesentlichen zwei Gründe geben:

  1. Junge UEFI-Implementationen der Computer-Hersteller hatten teils fatale Firmware-Bugs, die bis zur Unbrauchbarkeit des Geräts führen konnten.
  2. Nach Jahrzehnten mit BIOS war man einfach an die umständliche Funktionsweise von BIOS gewöhnt.

Jeder, der sich einmal intensiver mit dem Boot-Prozeß von PCs beschäftigt hat, kann den Ablauf herunterbeten:

  1. POST
  2. BIOS führt den MBR der MSDOS-Partitionstabelle aus
  3. Der MBR-Code lädt anderen Code nach, weil der MBR („Master Boot Record“) mit seinen 440 Byte einfach zu klein ist. Dazu wird üblicherweise die mit der Bootmarkierung versehene Partition benutzt.
  4. Der nunmehr vollständige Bootloader zeigt entweder ein Auswahlmenü an, oder er sucht die als Standard konfigurierte Partition heraus.
  5. Darauf wiederum startet er den Kernel des Zielsystems mit der konfigurierten Kernel-Kommandozeile. Insbesondere lädt der Bootloader das konfigurierte Initramfs so, dass der Kernel es findet.
  6. Der Kernel entpackt das initramfs in den Arbeitsspeicher.
  7. Der Kernel führt /init im initramfs aus.
  8. Das initramfs kümmert sich um alle frühen Vorgänge, etwa das Nachfragen des Passworts für eine verschlüsselte Root-Partition.
  9. Das initramfs bindet das Root-Dateisystem unter /mnt/new_root ein.
  10. Das initramfs führt switch_root /mnt/new_root aus, was letztlich ein exec /mnt/new_root/init ist.
  11. Das Haupt-Init (/init auf der Root-Partition) führt den Rest des Bootvorgangs durch.

Die Schritte 6-11 sind für UEFI identisch, da dort die Kontrolle bereits beim Linux-Kernel liegt. Ansonsten sieht der UEFI-Boot-Boot-Prozeß wie folgt aus:

  1. POST
  2. UEFI liest die konfigurierten Boot-Einträge aus dem NVRAM (ein kleiner persistenter Speicher unmittelbar auf der Hauptplatine)
  3. UEFI bindet die Partition ein, auf der sich die Zielanwendung befindet (das wird in der Regel die sog. „EFI-System-Partition“ sein).
  4. UEFI startet die Zielanwendung mit den konfigurierten Parametern.
  5. Ist die Zielanwendung der Linux-Kernel, geht es weiter wie oben ab Schritt 6.

Der UEFI-Boot-Prozeß bietet somit zwei wesentliche Vorteile gegenüber dem alten BIOS-Boot-Prozeß. Zunächst einmal entfällt die anachronistische Benutzung eines 440 Byte großen MBR. Der MBR spielt für UEFI schlicht keine Rolle mehr und wird vollständig ignoriert. Zum anderen entfällt die Notwendigkeit eines Bootloaders, denn UEFI kümmert sich selbst um die Verwaltung der startbaren Betriebssystem bzw. UEFI-Anwendungen. Es ist, einen aktuellen Kernel vorausgesetzt, nicht mehr nötig, GRUB oder einen sonstigen Bootloader zu benutzen, wenn man ein UEFI-System installiert hat, da UEFI sozusagen ab Werk dualboot-fähig ist. Für Leute, die neben Linux noch ein Windows installiert haben, entfällt damit das bekannte Ärgernis, dass Windows gelegentlich den MBR überschreibt und einen Bootloader (den ntldr) installiert, der nur Windows selbst laden kann.

Gute UEFI-Implementationen enthalten im Setup-Screen (also dem, was man früher landläufig als „das BIOS“ bezeichnete, nämlich der Benutzeroberfläche für die Konfiguration) einen Editor zur Bearbeitung der im NVRAM hinterlegten Boot-Einträge.

2. MSDOS- und GPT-Partitionstabellen

Nicht unmittelbar mit UEFI verbunden, aber praktisch immer zusammen mit ihm anzutreffen ist die Verwendung einer GPT-Partitionstabelle statt der herkömmlichen MSDOS-Partitionstabelle. Wie die Begrifflichkeit schon vermuten läßt, ist die MSDOS-Partitionstabelle ebenfalls nicht mehr zeitgemäß und ihre Beschränkungen, wie etwa die Begrenzung auf maximal vier primäre Partitionen oder eine maximale Partitionsgröße von 2 TiB, stellen mittlerweile ein ernsthaftes Hindernis da. Obwohl nicht zwingend, unterstützten die meisten UEFI-Implementationen wohl ausschließlich GPT-Partitionstabellen, sofern nicht der BIOS-Kompatibilitätsmodus („Legacy Mode“) eingeschaltet wird.

3. UEFI-Anwendungen

UEFI kann im Gegensatz zu BIOS auch Anwendungen „booten“ und nicht bloß Betriebssysteme. So werden von Herstellern gelegentlich besondere Diagnose-Tools in Form dieser sog. „UEFI-Anwendungen“ mitgeliefert, die sich dann als .efi-Dateien auf der EFI-System-Partition wiederfinden und für die „Boot-Einträge“ im NVRAM hinterlegt sind.

Eine besondere Anwendung ist die „UEFI Shell“. Dabei handelt es sich um eine minimale Shell (also eine echte, interaktive Kommandozeile), die unmittelbar im UEFI läuft und kein Betriebssystem benötigt. Das Ganze ist recht sperrig und vom (Un-)Komfortnieveau wohl in etwa mit der GRUB Shell zu vergleichen, erfüllt aber seinen Zweck, der insbesondere darin besteht, den fehlenden Editor schlechter UEFI-Implementationen zu kompensieren. Oft wird nämlich gerade von den Herstellern billigerer Laptops der Aufwand gescheut, den technisch relativ komplexen Editor zur Bearbeitung der Boot-Einträge im NVRAM mitzuliefern. Die UEFI Shell ermöglicht nun einen Zugriff auf und die Veränderung von Boot-Einträgen im NVRAM. Eine Implementation der UEFI Shell stellt etwa Tianocore zur Verfügung, manche Hersteller liefern auch selbst eine Shell-Implementation mit.

Der Linux-Kernel selbst ist seit einiger Zeit eine funktionsfähige UEFI-Anwendung, was es ermögicht, ihn direkt von UEFI starten zu lassen und einen separaten Bootloader überflüssig macht. Diese Funktionalität nennt sich EFISTUB.

II. USB-Stick mit UEFI

Die Zeiten, in denen man einen USB-Stick umständlich mit MBR und Bootloader versehen mußte, sind mit UEFI vorbei. Es ist allerdings recht traurig anzusehen, dass die von den Linux-Distributionen üblicherweise verteilten ISO-Dateien nicht immer wirklich UEFI-kompatibel sind. Im Folgenden stelle ich daher den grundsätzlichen Weg vor, mit dem man einen USB-Stick so präparieren kann, dass er an einem ausschließlich UEFI unterstütztenden System bootet. Beispielhaft wird ein ArchLinux auf dem USB-Stick installiert; ersetzt man den Arch-spezifischen Installationsteil durch den der anderen Linux-Distributionen, sollte die Logik aber genauso fort gelten. Die Schritte 5 und 6 sind dann entsprechend anzupassen.

1. Warum nicht BIOS-Kompatibilitätsmodus?

Natürlich mag man sich fragen, warum ich nicht einfach den BIOS-Kompatibilitätsmodus benutze. Dafür gibt es zwei Gründe. Zum einen habe ich selbst bereits einen PC erlebt, der schlicht keinen Kompatibilitätsmodus hatte und in diesem Sinne UEFI-only war. Zum anderen können die Installer der verschienen Linux-Distributionen keine UEFI-Installation vornehmen, wenn die Live-Umgebung nicht bereits im UEFI-Modus gebootet wurde. Das hängt damit zusammen, daß im Kompatibilitätsmodus dem laufenden System nun einmal vorgegaukelt wird, es laufe auf einem BIOS-System. Eine Linux-Installation, die von einem im Kompatibilitätsmodus gestarteten Live-System durchgeführt wird, wird daher nur für BIOS-Systeme installiert und kann nicht von UEFI aus gebootet werden. Der technische Grund dafür ist, daß der Kernel das efivars-Dateisystem unter /sys im Kompatibilitätsmodus nicht zur Verfügung stellt (bzw. nicht zur Verfügung stellen kann).

2. Voraussetzungen

Zunächst muss ein Root-Tarball der zu installierenden Linux-Distribution aquiriert werden. Die ISO-Installationsmedien sind nicht hinreichend, da diese üblicherweise mit squashfs erstellt werden und nicht ohne weiteres entpackbar sind. ArchLinux bietet dafür die „bootstrap“-Tarballs an, die neben den ISO-Dateien auf dem Server liegen.

Im Übrigen werden ein USB-Stick, fdisk, mkfs.vfat und mkfs.ext4 benötigt. Auch muss ein Linux-Kernel zur Verfügung stehen, der EFISTUB unterstützt, was bei allen aktuellen Linux-Distributionen der Fall sein dürfte. Es empfiehlt sich, einen Kernel zu verwenden, der möglichst generisch ist und mit vielen Modulen kompiliert wurde, um an jedem möglichen System die optimalen Module laden zu können.

3. Nomenklatur

Der USB-Stick wird im folgenden als /dev/sdb geführt.

4. Formatierung des USB-Sticks

Der USB-Stick wird mit einer GPT-Partitionstabelle versehen und dann in eine EFI-System-Partition und die eigentlichen Hauptpartition für die Linux-Distribution aufgeteilt.

# fdisk /dev/sdb

Willkommen bei fdisk (util-linux 2.26.2).
Änderungen werden vorerst nur im Speicher vorgenommen, bis Sie sich
entscheiden, sie zu schreiben.
Seien Sie vorsichtig, bevor Sie den Schreibbefehl anwenden.


Befehl (m für Hilfe): g
Eine neue GPT-Festplattenbezeichnung wurde erstellt (GUID: [nicht gezeigt]).

Befehl (m für Hilfe): n
Partitionsnummer (1-128, Vorgabe 1): 
Erster Sektor (2048-15564766, Vorgabe 2048): 
Letzter Sektor, +Sektoren oder +Größe{K,M,G,T,P} (2048-15564766, Vorgabe 15564766): +128M

Eine neue Partition 1 des Typs »Linux filesystem« und der Größe 128 MiB wurde erstellt.

Befehl (m für Hilfe): t
Partition 1 ausgewählt
Hexadezimalcode (geben Sie L ein, um alle Codes aufzulisten): 1
Partitionstyp von »Linux filesystem« nach »EFI System« geändert.

Befehl (m für Hilfe): n
Partitionsnummer (2-128, Vorgabe 2): 
Erster Sektor (264192-15564766, Vorgabe 264192): 
Letzter Sektor, +Sektoren oder +Größe{K,M,G,T,P} (264192-15564766, Vorgabe 15564766): 

Eine neue Partition 2 des Typs »Linux filesystem« und der Größe 7,3 GiB wurde erstellt.

Befehl (m für Hilfe): p
Festplatte /dev/sdb: 7,4 GiB, 7969177600 Bytes, 15564800 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: [nicht gezeigt]

Gerät      Anfang     Ende Sektoren Größe Typ
/dev/sdb1    2048   264191   262144  128M EFI-System
/dev/sdb2  264192 15564766 15300575  7,3G Linux-Dateisystem

Befehl (m für Hilfe): w
Die Partitionstabelle wurde verändert.
ioctl() wird aufgerufen, um die Partitionstabelle neu einzulesen.
Festplatten werden synchronisiert.

Die Partitionen müssen noch mit den eigentlichen Dateisystemen formatiert werden. Die EFI-System-Partition ist für maximale Kompatibilität mit allen EFI-Implementationen mit FAT32 zu formatieren, die Linux-Haupt-Partition dagegen wie üblich mit ext4.

# mkfs.vfat -n EFI /dev/sdb1 
mkfs.fat 3.0.28 (2015-05-16)

# mkfs.ext4 -L Linux /dev/sdb2
mke2fs 1.42.13 (17-May-2015)
Ein Dateisystems mit 1912571 (4k) Blöcken und 478608 Inodes wird erzeugt.
UUID des Dateisystems: ca5bd7f3-b9e9-4c20-986d-13542c9ac832
Superblock-Sicherungskopien gespeichert in den Blöcken: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632

beim Anfordern von Speicher für die Gruppentabellen: erledigt
Inode-Tabellen werden geschrieben: erledigt
Das Journal (32768 Blöcke) wird angelegt: erledgt
Die Superblöcke und die Informationen über die Dateisystemnutzung werden
geschrieben: erledigt

5. Bootstrap-System

ArchLinux bietet ein Chroot an, aus dem heraus man ein ArchLinux installieren kann. Das klingt etwas verworren, ist aber eigentlich gar nicht so schwierig. Den dafür erforderlichen Bootstrap-Tarball findet man neben den ISO-Dateien auf den Spiegelservern. Er wird wie folgt vorbereitet:

# cd /tmp
# tar -xf archlinux-bootstrap-*.tar.gz
# cd root.x86_64
# cp /etc/resolv.conf etc
# emacs etc/pacman.d/mirrorlist #<<< Mirrors entsprechend anpassen
# mount --bind /dev /tmp/root.x86_64/dev
# mount -t proc proc /tmp/root.x86_64/proc
# mount -t sysfs sysfs /tmp/root.x86_64/sys
# chroot /tmp/root.x86_64 /bin/bash
# pacman-key --init
# pacman-key --populate archlinux

6. Arch-Linux-Installation

Das Bootstrap-Chroot verhält sich im Prinzip wie ein ArchLinux-Live-Medium. Dementsprechend bindet man zunächst den USB-Stick in das chroot ein, in dem folgende Befehle außerhalb des Chroots (etwa in einem separaten Termina-Fenster) ausgeführt werden:

# mount /dev/sdb2 /tmp/root.x86_64/mnt
# mkdir -p /tmp/root/x86_64/boot/efi
# mount /dev/sdb1 /tmp/root/x86_64/mnt/boot/efi

Dies bindet den USB-Stick unterhalb des Chroots ein. Ebenfalls eingebunden wird die EFI-System-Partition, da darauf später der Kernel platziert werden muß.

Jetzt kann eine ArchLinux-Installation nach Gusto durchgeführt werden, wofür das bekannte pacstrap zur Verfügung steht. In der ArchLinux-Installationsanleitung kann man mit dem Schritt Installation weitermachen. Das Skript genfstab funktioniert im Chroot allerdings nicht richtig; die Datei /mnt/etc/fstab muß daher von Hand angelegt werden und unbedingt mit den UUIDs der Partionen auf dem USB-Stick versehen werden, da der Identifier, den der USB-Stick bekommt, vom Zielsystem abhängig ist.

Es ist unbedingt darauf zu achten, das ext4-Kernelmodul in das initramfs aufzunehmen, da aufgrund der ungewöhnlichen Schachtelung von Chroots mkinitcpio möglicherweise nicht selbst erkennt, daß dieses erforderlich sein wird. Dazu /etc/mkinitcpio.conf bearbeiten und ext4 in die Variable MODULES aufnehmen:

MODULES="ext4"

Auf einen Bootloader kann verzichtet werden, da der Stick nur für UEFI gedacht ist; wer mag, kann einen BIOS-Bootloader installieren und so einen Stick erstellen, der sowohl unter UEFI als auch unter BIOS bootfähig ist. Danach das initramfs neu bauen:

# mkinitcpio -p linux

7. Auf UEFI vorbereiten

Innerhalb von /boot liegen jetzt der Kernel und das initramfs. Dort werden sie von UEFI aber nicht gefunden, vielmehr müssen sie auf die EFI-System-Partition kopiert werden:

# cd /boot
# mkdir -p efi/EFI/Arch
# cp vmlinuz-linux efi/EFI/Arch/VMLINUZ.EFI
# cp initramfs-linux.img efi/EFI/Arch/initramfs.img

Damit sind die Arbeiten am USB-Stick grundsätzlich abgeschlossen.

UEFI kennt eine sog. Standardanwendung, die gestartet wird, wenn im UEFI-Boot-Menü nicht eine besondere Anwendung, sondern ein ganzes Gerät als Startziel ausgewählt wird. Diese Standardanwendung sucht es auf der EFI-System-Partition in EFI/BOOT/BOOTX64.EFI. An und für sich wäre es ideal, wenn man dort den Linux-Kernel platzierte, denn dann müßte man sich nicht weiter mit den verschiedenen mehr oder minder ähnlichen, herstellerspezifischen UEFI-Boot-Menüs herumschlagen, da bei Auswahl des USB-Sticks als Startgerät sogleich der Linux-Kernel anliefe. Jedoch können die Kernels gängiger Linux-Distributionen nicht ohne initramfs starten, weil selbst die wichtigsten Module, wie insbesondere das Modul für das Dateisystem ext4, nicht statisch in den Kernel einkompiliert sind, sondern als separate Dateien vorliegen, die – wie bei ArchLinux durch mkinitcpio – bei Bedarf in das initramfs eingebunden werden. Theoretisch besteht die Möglichkeit aber, sofern man bereit ist, einen eigenen Kernel zu kompilieren, bei dem man das Modul für ext4 fest einbaut. Dann wäre der Kernel in der Lage, das Root-Dateisystem auch ohne initramfs einzubinden und könnte weitere Kernel-Module von da nachladen.

Da der Prozeß der Kompilierung des Linux-Kernels selbst nicht unbedingt trivial ist, soll hier darauf verzichtet werden. Die UEFI-Standardanwendung kann man sich aber auf andere Weise zu nutze machen, indem man dort eine UEFI-Shell ablegt, sodaß man selbst dann eine zur Verfügung hat, wenn der UEFI-Hersteller keine in seine Implementierung eingebaut hat. Eine vorkompilierte UEFI-Shell gibt es etwa von Tianocore. In einem separaten Terminalfenster kann man sie so als UEFI-Standardanwendung auf dem Stick installieren:

# cd /tmp/root.x86_64/mnt/boot/efi/EFI
# mkdir BOOT
# cd BOOT
# wget https://github.com/tianocore/edk2/raw/master/ShellBinPkg/UefiShell/X64/Shell.efi -O BOOTX64.EFI

8. Aufräumen

Jetzt können sämtliche Chroots verlassen und der USB-Stick ausgehängt werden.

# exit
# exit
# umount -Rv /tmp/root.x86_64/mnt

9. Ausprobieren

Der USB-Stick kann nunmehr abgezogen und ausprobiert werden. Am Zielsystem einstecken und den Startprozeß so unterbrechen, daß das Boot-Menü erscheint (oft F8 oder F12). Im Bootmenü den USB-Stick auswählen. Läuft alles gut, dann wird die zuletzt installierte UEFI-Shell gestartet und es bietet sich etwa folgendes Bild:

UEFI Interactive Shell v2.0

Mapping table
  FS1: Alias(s):HD1aaa:;BLK4:
    PciRoot(0x0)([nicht gezeigt]/HD(1,GPT,[nicht gezeigt])

  FS0: Alias(s): HD0bbb:;BLK1:
    PciRoot(0x0)/[nicht gezeigt]/USB(0x1,0x0)/HD(1,GPT,[nicht gezeigt])

Press ESC in 0 seconds to skip startup.nsh or any other key to continue.
Shell>

In dieser UEFI-Shell kann man nun einen Boot-Eintrag für das Arch-Linux auf dem USB-Stick anlegen. Darauf sollte, wie eingangs erwähnt, aber nur zurückgegriffen werden, wenn das UEFI-Setup des Computers keine Möglichkeit bietet, neue Boot-Einträge im NVRAM abzulegen, denn die UEFI-Shell ist eine sperrige Angelegeneit.

Zunächst ist dazu der Bezeichner des USB-Sticks festzustellen. Die von der UEFI-Shell beim Start ausgegebene Mapping-Tabelle (die später auch neu mithilfe des Befehls map angezeigt werden kann) enthält im obigen Beispielsfall zwei Einträge, FS1 und FS0. Aus den dort angezeigten Informationen ergibt sich, daß FS0 irgendwas mit „USB“ ist – also höchstwahrscheinlich der USB-Stick. FS1 dagegen ist etwas mit „HD“, also die verbaute Festplatte im Rechner. Da der USB-Stick das Medium mit dem Arch-Kernel ist, kann ist „FS0“ der Bezeichner, der für die weiteren Befehle benötigt wird.

Danach ist der nächste freie Booteintrag zu ermitteln. Dazu dient das folgende Kommando:

Shell> bcfg boot dump -b
Option 00. Variable: Boot0001
  Desc     - Some Linux
  [nicht gezeigt]
Option 01. Variable: Boot0000
  Desc     - EFI Shell
  [nicht gezeigt]
Option 02. Variable: Boot0008
  Desc     - Vendor Diagnostics
  [nicht gezeigt]

Wie man erkennt, sind die Boot-Einträge im NVRAM nicht geordnet und Lücken sind nicht selten. Die hinter „Variable: Boot“ angegebene Zahl gibt die Nummer des Booteintrags an. Hier ist der nächste freie Eintrag 2 (genauer: 0002, aber das ist unerheblich). Damit sind jetzt alle für den neuen Boot-Eintrag wichtigen Parameter bekannt. Ein neuer Boot-Eintrag kann jetzt wie folgt angelegt werden:

Shell> bcfg boot add 2 fs0:\EFI\Arch\VMLINUZ.EFI "Arch USB"
Target = 0002.
bcfg: Add Boot0002 as 2.

Die 2 ist der freie Boot-Eintrag, fs0 ist die Bezeichnung des USB-Sticks in der UEFI-Shell, "Arch USB" ist der Name des Eintrags, wie er im Boot-Menü angezeigt wird und \EFI\Arch\VMLINUZ.EFI ist der Ort, wo sich der Kernel auf der EFI-System-Partition befindet, wobei Backslashes als Verzeichnistrenner dienen (also wie unter Windows).

Dieser Eintrag würde den Linux-Kernel ohne Kernel-Optionen starten. Das würde sehr rasch zu einer Kernelpanik führen, da der generische Linux-Kernel der meisten Linux-Distributionen, auch von ArchLinux, nicht darauf ausgelegt ist. Vielmehr müssen die Kernel-Optionen separat angegeben werden, indem der soeben angelegte Boot-Eintrag noch einmal bearbeitet wird:

Shell> bcfg boot -opt 2 "root=/dev/sdb2 rootfstype=ext4 rw initrd=\EFI\Arch\initramfs.img"

2 ist wie gehabt die Nummer des Booteintrags, danach folgen die Kernel-Parameter. Das ist ganz ähnlich der Art und Weise, wie klassische BIOS-Bootloader konfiguriert wurden und tatsächlich sind die Parameter dieselben (gestartet wird ja auch hier lediglich Linux). Wer zu Selbstquälarei neigt, kann auch gern die vollständige UUID des Dateisystems abtippen und als Root-Dateisystem angeben, allerdings dürfte dies bei der eigentlich nur kurzzeitigen Benutzung als Live-USB-Stick nur von untergeordneter Wichtigkeit sein. Besonderes Augenmerk verdient noch die Angabe des initramfs: Der Wert der Option initrd in diesem Kontext bezieht sich stets auf die EFI-System-Partition.

Scheinbar schlägt das obige Kommando unter neuen UEFI-Shells (>=2.1) mit der Fehlermeldung „Invalid Argument“ fehl. Es wird aber sicherlich ein ähnliches Kommando geben, mit dem die Boot-Optionen sich bearbeiten lassen. Zumindest mit meiner UEFI-Shell Version 2.0 funktioniert es aber wie es soll.

Danach durch Druck auf den Ausschaltknopf den Rechner abschalten und danach wieder einschalten. Denn neuen Boot-Eintrag auswählen und fertig. Am Ende sollte ein Login-Prompt stehen, an dem man sich mit den bei der Installation vergebenen Login-Daten anmelden können sollte.

10. Boot-Eintrag löschen

Das Live-System ist mit UEFI gebootet worden, weshalb nunmehr alle UEFI-spezifischen Funktionen des Kernels zur Verfügung stehen und von der Userland-Werkzeugen genutzt werden können. So sind die Kommandos efivars und efibootmgr jetzt einsatzfähig. Möchte man den – vermutlich ohnehin nur temporären Zwecken dienenden – Boot-Eintrag für den USB-Stick wieder aus dem NVRAM entfernen, so geschieht das wie folgt.

Zunächst läßt man sich alle Boot-Einträge anzeigen:

# efibootmgr -v
BootCurrent: 0001
Timeout: 0 seconds
BootOrder 0001,0000,0002
Boot0000: EFI Shell HD(1,GPT,[nicht gezeigt])
Boot0001: Some Linux HD(1,GPT,[nicht gezeigt])
Boot0002: Arch USB  PciRoot(0x0)/[nicht gezeigt]/USB(0,0)/HD(1,GPT,[nicht gezeigt]/File(\EFI\Arch\VMLINUZ.EFI)r.o.o.t.=./.d.e.v./.s.d.b.2. .r.o.o.t.f.s.t.y.p.e.=.e.x.t.4. .r.w. .i.n.i.t.r.d.=.\.E.F.I.\.A.r.c.h.\.i.n.i.t.r.a.m.f.s...i.m.g...
Boot0008: Vendor Diagnostics [nicht gezeigt]

Da ist der zuvor angelegte Eintrag, und er hat nach wie vor die Nummer 2. Weg damit:

# efibootmgr -b 2 -B
BootCurrent: 0001
Timeout: 0 seconds
BootOrder 0001,0000
Boot0000: EFI Shell HD(1,GPT,[nicht gezeigt])
Boot0001: Some Linux HD(1,GPT,[nicht gezeigt])
Boot0008: Vendor Diagnostics [nicht gezeigt]

Damit ist der Eintrag wieder weg.

III. Fazit

Eigentlich handelt es sich bei der Erstellung eines unter UEFI bootfähigen USB-Sticks um eine Betriebssysteminstallation auf dem USB-Stick als Hauptplatte. Einzig anders ist, daß kein Bootloader installiert wird, sondern die UEFI-Shell, und in dieser anschließend auf jedem Zielsystem ein Boot-Eintrag für den USB-Stick anzulegen ist. Diese Arbeit könnte entfallen, wenn man bereit ist, einen Linux-Kernel zu kompilieren, in den das Modul für das Dateisystem ext4 statisch einkompiliert ist.

Valete.