Ubuntu 20.04 → 24.04 Dist-Upgrade: LUKS2, GRUB, Secure Boot und systemd-boot

Sat, 21 Feb 2026 00:00:00 +0000

Diese Seite dokumentiert das Debugging eines fehlgeschlagenen Ubuntu-Release-Upgrade. Das System war danach nicht mehr bootbar. Die Ursachen lagen in einem Zusammenspiel aus LUKS2-Verschlüsselung, GRUB 2.12, Secure Boot und fehlenden Dotfiles — die sich gegenseitig verstärkten und zu einer langen Kette von Folgeproblemen führten.

Ausgangssituation

Xubuntu 20.04, LUKS2-verschlüsselte Root-Partition
Dual-Boot mit Windows auf derselben NVMe-SSD
Eine weitere verschlüsselte Partition (Veracrypt/exFAT) als gemeinsamer Datenspeicher, gemountet unter /home/user/data
Persönliche Dotfiles (xmonad, zsh, vim, etc.) liegen als Symlinks auf dieser Veracrypt-Partition
Neo2-Tastaturlayout, xmonad als Window Manager, Alacritty als Terminal

Phase 1: Fehlgeschlagenes Dist-Upgrade

do-release-upgrade von 20.04 → 22.04 gestartet. Das Upgrade blieb beim Paket ConTeXt MarkIV (Teil von TeXLive) hängen — ein sehr großes Paket das beim Post-Install-Script sehr lange läuft. Es wurde manuell abgebrochen.

Das System bootete danach nicht mehr. GRUB fiel direkt in die interaktive Kommandozeile (grub>) ohne ein Bootmenü anzuzeigen.

Phase 2: Chroot-Reparatur via Live-USB

Das System wurde von einem Live-USB gebootet. Die verschlüsselte Partition wurde manuell geöffnet und eine chroot-Umgebung eingerichtet:

cryptsetup luksOpen /dev/sdXY cryptroot
mount /dev/mapper/cryptroot /mnt
mount /dev/sdXZ /mnt/boot/efi          # EFI-Partition
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
mount --bind /run /mnt/run
mount --bind /sys/firmware/efi/efivars /mnt/sys/firmware/efi/efivars
chroot /mnt

Im chroot:

dpkg --configure -a und apt --fix-broken install reparierten kaputte Pakete
Der Kernel fehlte komplett (nur initrd vorhanden, kein vmlinuz): apt install --reinstall linux-image-generic
Das Upgrade wurde mit do-release-upgrade auf 22.04 und anschließend 24.04 abgeschlossen

Phase 3: GRUB + LUKS2 + Secure Boot — Das Kernproblem

Symptom

Nach dem Upgrade zeigte GRUB weiterhin keine Menüeinträge. Debugging in der GRUB-Kommandozeile:

grub> ls (hd1,gpt7)
# → "No known filesystem detected"

grub> insmod luks2
# → "file '/boot/grub/x86_64-efi/luks2.mod' not found"

Ursache

Das eigentliche Problem ist eine fundamentale Inkompatibilität:

Canonical’s vorsigniertes grubx64.efi enthält das luks2-Modul bewusst nicht.

GRUB 2.12 kann LUKS2 technisch entschlüsseln (sofern PBKDF2 statt Argon2 als Key-Derivation-Function genutzt wird), aber das von Ubuntu ausgelieferte, Secure-Boot-signierte EFI-Binary lässt dieses Modul absichtlich weg — es gilt noch als nicht vollständig stabil.

grub-install --modules="... luks2 ..." hat deshalb keinen Effekt: Mit Secure Boot aktiv nutzt grub-install immer das vorsignierte Image und ignoriert die --modules-Option.

Ein manuell mit grub-mkimage erstelltes Image mit luks2-Unterstützung wird von Secure Boot sofort abgelehnt:

Verification failed: (0x1A) Security Violation

Zusätzlich schlug grub-install im chroot grundsätzlich fehl, weil EFI-Variablen im chroot nicht beschreibbar sind (grub-efi/install_devices_failed: true in debconf-show grub-efi).

Optionen

Option	Aufwand	Nachteil
Secure Boot deaktivieren	gering	Secure Boot inaktiv
LUKS2 → LUKS1 konvertieren	gering	Kein Backup-Header mehr
Eigenen MOK-Schlüssel + selbst signiertes GRUB	hoch	Muss bei jedem GRUB-Update wiederholt werden
Wechsel zu systemd-boot	mittel	Konfigurationsaufwand einmalig

LUKS1 wurde abgelehnt, da LUKS2 einen Backup-Header mitbringt der sich bereits einmal als lebensrettend erwiesen hatte. Gewählt wurde systemd-boot.

Phase 4: Wechsel zu systemd-boot

Warum systemd-boot?

Secure Boot wird nativ unterstützt (das Binary ist von den Distributionen signiert)
LUKS wird nicht von systemd-boot selbst geöffnet — das übernimmt die initramfs beim Kernel-Start. Damit entfällt das LUKS2-Problem komplett
Dual Boot mit Windows funktioniert: systemd-boot erkennt den Windows-EFI-Eintrag automatisch
Kein shim als Vermittler nötig (anders als bei GRUB)

Installation

bootctl install --esp-path=/boot/efi

Kernel und initrd werden von kernel-install automatisch auf die EFI-Partition kopiert. Bei jedem Kernel-Update wird ein neuer Boot-Entry angelegt.

LUKS-Parameter

Der automatisch generierte Boot-Entry enthielt keine LUKS-Parameter. Diese werden dauerhaft in /etc/kernel/cmdline hinterlegt:

rd.luks.uuid=<UUID-der-LUKS-Partition> rd.luks.name=<UUID>=cryptroot root=/dev/mapper/cryptroot rw quiet splash

kernel-install add <version> /boot/vmlinuz-<version> regeneriert den Entry mit diesen Parametern. Zukünftige Kernel-Updates setzen die Parameter automatisch korrekt.

Secure Boot Problem

systemd-bootx64.efi war auf dem System nicht signiert — Ubuntu liefert kein .efi.signed-Paket für systemd-boot aus. Vorläufige Lösung: Secure Boot im BIOS deaktiviert.

Für eine spätere saubere Lösung mit aktivem Secure Boot:

# Eigenen Signing-Key generieren
openssl req -newkey rsa:4096 -nodes -keyout /root/mok.key \
  -new -x509 -sha256 -days 3650 \
  -subj "/CN=My Boot Signing Key/" -out /root/mok.crt

# systemd-boot signieren
sbsign --key /root/mok.key --cert /root/mok.crt \
  --output /boot/efi/EFI/systemd/systemd-bootx64.efi \
  /boot/efi/EFI/systemd/systemd-bootx64.efi

# Schlüssel bei Secure Boot registrieren
mokutil --import /root/mok.crt
# → Beim nächsten Boot einmalig im MOK-Manager bestätigen

EFI-Boot-Reihenfolge

Der alte GRUB-Eintrag wurde entfernt und systemd-boot als erster Eintrag gesetzt:

efibootmgr --delete-bootnum --bootnum XXXX   # alten Ubuntu/GRUB-Eintrag löschen
efibootmgr --bootorder 0001                  # Linux Boot Manager an erste Stelle

Phase 5: Veracrypt-Partition — Der eigentliche Mount-Fehler

Symptom

Die Veracrypt-Partition wurde beim Boot nicht gemountet. Das Journal zeigte:

mount: wrong fs type, bad option, bad superblock on /dev/mapper/data,
missing codepage or program, or other error

Das klang nach einem ernsthaften Problem — war es aber nicht.

Diagnose mit `-v`

cryptsetup open /dev/sdXY data \
  --type tcrypt --veracrypt \
  --key-file /home/user/.data.key -v
# → Error: device already exists

device already exists bedeutet: cryptsetup hatte die Partition bereits erfolgreich geöffnet. Das Problem lag allein beim anschließenden Mount-Vorgang.

Ursache: Ungültige fstab-Optionen für exFAT

Die /etc/fstab enthielt für die Partition:

/dev/mapper/data  /home/user/data  auto  permissions,users,nosuid,nodev,nofail,...

permissions ist keine gültige Mount-Option für exFAT-Dateisysteme und führt zu einem sofortigen Mount-Fehler. Die korrigierte Zeile:

/dev/mapper/data  /home/user/data  exfat  nofail,fmask=133,dmask=022,uid=1000,gid=1000  0  0

Phase 6: Keyboard-Layout-Chaos durch fehlende Dotfiles

Was passierte

Da die Veracrypt-Partition nicht gemountet war, fehlten alle Symlink-Ziele:

.xmonad/ → xmonad startete nicht, XFCE wurde als Fallback geladen
.zshrc → versuchte Dateien von der nicht gemounteten Partition zu laden
.vimrc → Symlink ins Leere
xkb/xmodmap-Konfiguration fehlte

XFCE initialisierte das Tastaturlayout ohne die benutzerspezifische xkb-Konfiguration. Das Ergebnis war ein BadKey (0xcf) als mod2-Modifier in X11 — sichtbar mit:

xmodmap -pm
# mod2  BadKey (0xcf)

Dieser ungültige Modifier-Eintrag aktivierte Layer-4-Sonderzeichen statt normaler Eingabe. Neo2-Layer-4 belegt die Zifferntasten mit Symbolen wie º, £, ¤ — was erklärt warum die Tastatur scheinbar komplett kaputt war.

Lösung

Nach korrektem Mount der Veracrypt-Partition startete xmonad mit den vorhandenen Dotfiles normal. Das Tastaturlayout funktionierte sofort ohne weiteren Eingriff, da die xmodmap-Konfiguration korrekt geladen wurde.

Zusammenfassung: Lessons Learned

LUKS2 + GRUB + Secure Boot ist auf Ubuntu derzeit nicht out-of-the-box möglich. Die Kombination erfordert entweder einen eigenen MOK-Schlüssel mit selbst gebautem GRUB-Image, die Konvertierung auf LUKS1, oder den Wechsel zu einem anderen Bootloader. systemd-boot ist hier die eleganteste Lösung da er LUKS der initramfs überlässt und Secure Boot nativ unterstützt.

Dotfiles auf verschlüsselten Partitionen sind ein zweischneidiges Schwert: Sie sind sicher, aber wenn die Partition beim Boot nicht verfügbar ist, bricht die gesamte Session-Initialisierung still und mit kryptischen Folgefehlern zusammen. Eine minimale Fallback-Konfiguration direkt im Home-Verzeichnis ist empfehlenswert.

cryptsetup -v ist unverzichtbar beim Debugging — ohne verbose Output sieht “device already exists” genauso aus wie ein echter Fehler.

Offene Punkte

Secure Boot wieder aktivieren via eigenem MOK-Schlüssel für systemd-boot
Alten /boot-fstab-Eintrag bereinigen
python-Symlink: sudo ln -s /usr/bin/python3 /usr/bin/python
Audio-Fehler (alsactl) aus dem Journal untersuchen

Ubuntu | Friedrich Wiemer

Ubuntu 20.04 → 24.04 Dist-Upgrade: LUKS2, GRUB, Secure Boot und systemd-boot

Ausgangssituation

Phase 1: Fehlgeschlagenes Dist-Upgrade

Phase 2: Chroot-Reparatur via Live-USB

Phase 3: GRUB + LUKS2 + Secure Boot — Das Kernproblem

Symptom

Ursache

Optionen

Phase 4: Wechsel zu systemd-boot

Warum systemd-boot?

Installation

LUKS-Parameter

Secure Boot Problem

EFI-Boot-Reihenfolge

Phase 5: Veracrypt-Partition — Der eigentliche Mount-Fehler

Symptom

Diagnose mit -v

Ursache: Ungültige fstab-Optionen für exFAT

Phase 6: Keyboard-Layout-Chaos durch fehlende Dotfiles

Was passierte

Lösung

Zusammenfassung: Lessons Learned

Offene Punkte

Diagnose mit `-v`