GRUB nach einem Windows-Update reparieren: erst UEFI prüfen

Wenn nach einem Windows-Update sofort Windows startet, ist GRUB meist noch vorhanden. Häufig hat sich nur die UEFI-Bootreihenfolge geändert. Dann steht „Windows Boot Manager“ vor dem Linux-Eintrag. Prüfe deshalb zuerst das Firmware-Bootmenü. Installiere den Bootloader erst neu, wenn der Linux-Eintrag fehlt oder seine Dateien beschädigt sind.

Diese Anleitung gilt für UEFI-Rechner mit Ubuntu, Linux Mint oder verwandten Systemen. Bei Legacy-BIOS, LUKS, LVM, RAID oder einer separaten /boot-Partition weichen die Mounts ab. Sichere wichtige Daten. Notiere die Ausgabe von lsblk, bevor Du schreibende Befehle ausführst.

Nur die Bootreihenfolge reparieren

Öffne das einmalige Bootmenü des Rechners. Häufig erreichst Du es über F12, F10, Esc oder eine Herstellertaste. Wähle „ubuntu“, „Linux Boot Manager“ oder den Namen Deiner Distribution. Startet Linux normal, prüfe:

sudo efibootmgr -v

Die Ausgabe zeigt Bootnummern und BootOrder. Setze die gewünschte Reihenfolge mit den echten Nummern, zum Beispiel:

sudo efibootmgr -o 0003,0000

Das Beispiel ist kein fester Wert. 0003 muss auf Deinem Rechner wirklich der Linux-Eintrag sein. Du kannst die Reihenfolge auch im UEFI-Setup ändern. Unser Artikel zur GRUB-Menüreihenfolge behandelt die Auswahl innerhalb von GRUB. Die UEFI-Reihenfolge liegt eine Ebene davor.

Fehlermeldung „SBAT self-check failed“

Startest Du den Linux-Eintrag und siehst statt GRUB die Meldungen „Verifying shim SBAT data failed: Security Policy Violation“ und „Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation“, liegt es nicht an der Bootreihenfolge. Ein Windows-Update hat eine SBAT-Richtlinie in die Firmware geschrieben. Sie sperrt ältere Versionen von Shim und GRUB mit bekannten Secure-Boot-Lücken. Deine Linux-Installation ist dabei nicht beschädigt, nur ihr Bootloader gilt als zu alt.

Dauerhaft hilft ein aktueller Bootloader. Boote dazu einen aktuellen Live-Stick und aktualisiere im chroot die Pakete shim-signed und grub-efi-amd64-signed, wie es die folgenden Abschnitte zeigen. Als Übergangslösung hat Microsoft einen zweiten Weg beschrieben:

1. Secure Boot im UEFI-Setup vorübergehend ausschalten und Linux starten.
2. Die SBAT-Richtlinie mit sudo mokutil --set-sbat-policy delete löschen und neu starten.
3. Linux aktualisieren, vor allem Shim und GRUB.
4. Secure Boot im UEFI-Setup wieder einschalten.
5. In Linux mit mokutil --sb-state prüfen, ob „SecureBoot enabled“ erscheint.

Lass Secure Boot nicht dauerhaft ausgeschaltet. Das Abschalten dient nur dazu, ein veraltetes System wieder zu starten und zu aktualisieren.

Live-System im UEFI-Modus starten

Erstelle einen aktuellen Live-Stick mit Ubuntu oder Mint und starte dessen UEFI-Eintrag. Ältere Sticks scheitern womöglich: Ihren Shim kann eine SBAT-Sperre blockieren, und eine Firmware, die nur noch die Zertifikate von 2023 kennt, startet Medien mit der alten Signatur nicht. Prüfe im Live-System:

test -d /sys/firmware/efi && echo UEFI || echo Legacy
lsblk -f
sudo fdisk -l

Für diese Reparatur muss „UEFI“ erscheinen. Die EFI-Systempartition ist meist FAT32, einige Hundert Megabyte groß und mit ESP markiert. Die Linux-Rootpartition nutzt meist ext4, kann aber in LUKS oder LVM liegen. Verlasse Dich nicht allein auf die Namen der Geräte. Die Reihenfolge von NVMe und SATA kann sich im Live-System ändern.

Prüfe hier außerdem, ob die Firmware die Zertifizierungsstelle kennt, mit der Microsoft neue Shim-Versionen signiert:

mokutil --db | grep 'Subject:'

In der Ausgabe muss „CN=Microsoft UEFI CA 2023“ stehen. Fehlt der Eintrag, spiele vor einer Neuinstallation von Shim zuerst die neuen Zertifikate ein: in Windows über Windows Update, sonst über ein Firmware-Update des Herstellers oder in einem laufenden Linux mit fwupd (sudo fwupdmgr refresh, dann sudo fwupdmgr update). Ein Shim, der nur die Signatur von 2023 trägt, startet bei aktivem Secure Boot sonst nicht.

Root- und EFI-Partition mounten

Im Beispiel ist /dev/nvme0n1p5 Linux-Root und /dev/nvme0n1p1 die EFI-Partition. Ersetze beide Werte:

sudo mount /dev/nvme0n1p5 /mnt
sudo mkdir -p /mnt/boot/efi
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
findmnt /mnt
findmnt /mnt/boot/efi

Gibt es eine separate /boot-Partition, mountest Du sie zuerst nach /mnt/boot. Danach folgt die ESP unter /mnt/boot/efi. Bei LUKS öffnest Du den Container, bei LVM aktivierst Du die Volume Group. Rate nicht: lsblk -f muss das Layout erklären. Eine eigene /home-Partition musst Du für die Reparatur nicht einhängen.

chroot vorbereiten

for i in /dev /dev/pts /proc /sys /run; do
  sudo mount --bind "$i" "/mnt$i"
done
sudo chroot /mnt

Du arbeitest jetzt mit dem installierten System als Root. Prüfe nochmals:

findmnt /
findmnt /boot/efi
cat /etc/os-release

Zeigt /boot/efi nicht die FAT32-ESP, verlasse den chroot und korrigiere die Mounts. Installierst Du GRUB in einen leeren Ordner auf der Rootpartition, entsteht kein brauchbarer UEFI-Eintrag.

GRUB unter Ubuntu oder Linux Mint neu installieren

Hat die Prüfung im Live-System „Microsoft UEFI CA 2023“ gezeigt, stelle zunächst sicher, dass die UEFI-Pakete vorhanden sind:

apt update
apt install --reinstall grub-efi-amd64-signed shim-signed
grub-install --target=x86_64-efi \
  --efi-directory=/boot/efi \
  --bootloader-id=ubuntu
update-grub

Für ARM64 und andere Architekturen gelten andere Pakete und Targets. Secure Boot verwendet signierte Komponenten. Entferne shim daher nicht blind. Die Bootloader-ID „ubuntu“ wird auch von Linux Mint häufig verwendet. Prüfe unter /boot/efi/EFI/, welche Ordner bereits existieren.

update-grub sucht Kernel und auch Windows. Moderne Distributionen können die automatische Suche mit os-prober standardmäßig einschränken. Ein fehlender Windows-Menüeintrag bedeutet nicht, dass Windows gelöscht ist.

chroot sauber verlassen

exit
for i in /run /sys /proc /dev/pts /dev; do
  sudo umount "/mnt$i"
done
sudo umount /mnt/boot/efi
sudo umount /mnt
sudo reboot

Entferne den Live-Stick. Öffne bei Bedarf einmalig das UEFI-Bootmenü und wähle den reparierten Linux-Eintrag. Prüfe nach dem Start sudo efibootmgr -v und starte sowohl Linux als auch Windows einmal.

Windows fehlt im GRUB-Menü

Prüfe zuerst, ob „Windows Boot Manager“ im UEFI-Menü vorhanden ist. Wenn ja, sind Windows und seine EFI-Dateien erreichbar. Für einen GRUB-Menüeintrag kann os-prober nötig sein:

sudo apt install os-prober
sudo os-prober
sudo update-grub

Manche Distributionen verlangen zusätzlich eine bewusste Aktivierung in /etc/default/grub. Nutze die Anleitung Deiner Version. Führe os-prober nicht auf unbekannten oder nicht vertrauenswürdigen Laufwerken aus.

Kernel statt GRUB als Ursache

Zeigt GRUB sein Menü, aber der neueste Kernel startet nicht, ist der Bootloader intakt. Wähle unter „Advanced options“ einen älteren Kernel. Unser Ratgeber erklärt einen Kernel-Downgrade und das Wiederherstellen des Bootmenüs. Lass die EFI-Installation in diesem Fall in Ruhe.

Typische Fehler

EFI variables are not supported

Das Live-System wurde wohl im Legacy-Modus gestartet oder efivarfs fehlt. Starte neu und wähle den UEFI-Eintrag des Sticks.

cannot find EFI directory

Die ESP ist nicht unter /mnt/boot/efi oder im chroot unter /boot/efi gemountet. Prüfe FAT32-Partition und Mountpunkt.

Nach jedem Windows-Update startet wieder Windows

Prüfe Firmware-Update, UEFI-Einstellungen und Bootreihenfolge. Manche Geräte setzen ihren bevorzugten Eintrag zurück. Ein Firmware-Passwort oder eine dokumentierte efibootmgr-Korrektur kann helfen. Automatische Skripte sollten die Reihenfolge nicht unbemerkt überschreiben.

Backup vor weiteren Experimenten

Wenn Partitionstabelle oder Dateisystem Warnungen zeigen, sichere Daten, bevor Du weitere Reparaturen versuchst. Ein Rettungsimage mit einem Werkzeug wie Clonezilla Live kann sinnvoll sein. Bei physisch auffälligem Datenträger zählt zuerst Datenrettung, nicht das schönste Bootmenü.

Legacy-BIOS ist ein anderer Ablauf

Auf einem echten BIOS/MBR-System wird GRUB meist in den Bootbereich des Laufwerks installiert, etwa mit grub-install /dev/sda. Übernimm diesen Befehl nicht aus einer UEFI-Anleitung. Bestimme zuerst den Modus der Firmware. Hybride und alte Dual-Boot-Systeme brauchen eine Prüfung ihres genauen Aufbaus.

Secure Boot und BitLocker beachten

Änderungen an Bootloader, Firmwareeinträgen und Secure-Boot-Zustand können eine BitLocker-Abfrage auslösen. Sichere den Recovery-Key vor der Reparatur über den vorgesehenen Microsoft- oder Organisationsweg. Deaktiviere Secure Boot nicht als ersten Versuch. Ubuntu und Linux Mint nutzen signierte Shim-/GRUB-Komponenten, wenn sie korrekt installiert sind.

Dazu kommt der Wechsel der Secure-Boot-Zertifikate. Microsoft ersetzt seine Zertifizierungsstellen von 2011 durch Nachfolger von 2023. Die Gültigkeit endet am 27.06.2026 für die Microsoft UEFI CA 2011, die den Shim von Ubuntu und Mint signiert, und am 19.10.2026 für die Windows Production PCA 2011, die den Windows-Bootmanager signiert. Bereits installierte Bootloader starten weiter, weil die Firmware das Ablaufdatum beim Start nicht prüft. Neue Shim-Versionen signiert Microsoft aber nur noch mit der Microsoft UEFI CA 2023. Halte deshalb die Reihenfolge ein: erst die neuen Zertifikate per Windows Update, Firmware-Update oder fwupd, dann das Shim-Update.

Wird ein Firmenrechner verwaltet, kann die IT Bootreihenfolge und Schlüsselrichtlinien erzwingen. Repariere ihn nicht außerhalb dieser Vorgaben. Ein eigener GRUB-Eintrag kann beim nächsten Managementlauf wieder entfernt werden.

EFI-Systempartition auf Fehler prüfen

Ist die FAT32-ESP voll oder beschädigt, scheitert die Installation trotz richtiger Mounts. Prüfe freien Platz und Verzeichnisse:

df -h /boot/efi
find /boot/efi/EFI -maxdepth 2 -type f -print

Lösche keine Hersteller-, Windows- oder Linux-Verzeichnisse auf Verdacht. Sichere die kleine Partition zuerst. Alte Bootloader-Verzeichnisse dürfen nur entfernt werden, wenn Du ihre Zuordnung sicher kennst. Für FAT32-Prüfungen arbeitest Du aus dem Live-System und mit ungemounteter ESP.

Reparatur protokollieren

Notiere Partitionen, UUIDs, ausgeführte Befehle und die neue efibootmgr-Ausgabe. Speichere keine Geheimnisse, aber genug Details für den nächsten Vorfall. Ändert Windows die Reihenfolge erneut, kannst Du das bekannte Firmwareproblem von einer beschädigten EFI-Datei unterscheiden.

Wann Du abbrechen solltest

Stoppe bei I/O-Fehlern, einer unklaren Partitionstabelle oder auffälligen SMART-Warnungen. Brich auch ab, wenn Root und ESP nicht eindeutig sind. Kopiere wichtige Daten im Live-System auf ein anderes Laufwerk. Eine Bootloader-Reparatur schreibt Metadaten. Bei sterbender Hardware ist sie daher nicht der richtige erste Schritt.

Fotografiere vorher die Einstellungen der Firmware. Notiere Secure-Boot-Zustand, SATA-Modus und vorhandene Boot-Einträge. So kannst Du unbeabsichtigte Änderungen erkennen und kontrolliert zurücknehmen.

Halte außerdem einen zweiten Rechner oder ein Smartphone für Dokumentation bereit, falls das reparierte System während der Arbeit nicht ins Internet kommt.

Fazit: Bootreihenfolge vor Neuinstallation

Nach einem Windows-Update reicht oft eine korrigierte UEFI-Bootreihenfolge. Fehlt der Linux-Eintrag wirklich, boote ein Live-System im UEFI-Modus. Mounte Root und ESP eindeutig und repariere die signierten GRUB-Pakete im chroot. Übernimm niemals blind grub-install /dev/sda aus einer alten BIOS-Anleitung für ein modernes UEFI-System.