How to Fix Your GRUB Bootloader After a Windows 11 Update?

If you updated Windows 11 and your Linux system disappeared — either the GRUB menu is gone, you’re dropped into a grub rescue> prompt, or you’re seeing a “Verifying shim SBAT data failed: Security Policy Violation” error — you are not alone. This is an ongoing, well-documented conflict between Windows Update and the GRUB2 bootloader used by most Linux distributions.

This guide covers the two distinct failure modes and their proven fixes, including Microsoft’s own resolution released in May 2025.

Understanding What Actually Happens

There are two separate problems that people often conflate. Knowing which one you have is the key to picking the right fix.

Problem 1 — NVRAM Boot Order Hijacking (the classic)

Your motherboard’s NVRAM stores a ranked list of boot entries. When Windows runs a major update, it pushes Windows Boot Manager back to the top — sometimes also writing duplicate entries with corrupted path strings that take priority over your existing Linux entry. Your Ubuntu files are untouched; Windows just took the first seat.

Symptom: Machine boots straight into Windows. No GRUB menu. No errors.

Problem 2 — SBAT / Secure Boot Policy Violation (the 2024 incident)

Microsoft’s August 2024 security patches updated the Secure Boot Advanced Targeting (SBAT) database inside UEFI firmware to revoke older, vulnerable GRUB shim loaders. On systems where dual-boot detection failed, the SBAT update was applied even though Linux was present — causing Linux to be rejected by Secure Boot at firmware level before GRUB even loads.

Symptom: A black screen prints “Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong.” The machine shuts off.

Jump to the fix that matches your situation:

Fix A — Reclaim the Boot Order (Windows Hijacked GRUB)

If your PC boots directly into Windows and you can log in normally, your Ubuntu installation is almost certainly intact. Windows simply won the NVRAM priority race.

Method A1 — One command inside Windows (fastest)

1. Right-click the Start button and choose Terminal (Admin) or Command Prompt (Admin).
2. Run the following command to redirect the Windows Boot Manager to Ubuntu’s shim loader:

   bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi

3. Restart. The GRUB menu should appear.

Method A2 — Fix boot order in UEFI firmware

1. Enter your UEFI/BIOS setup (typically F2, Del, or F12 at power-on).
2. Navigate to the Boot or Boot Order section.
3. Move the entry labelled ubuntu, GRUB, or your Linux drive to the top of the list.
4. Save and exit. GRUB should load on next boot.

Fix B — SBAT / Secure Boot Policy Violation

If you see the “Verifying shim SBAT data failed” message, your UEFI firmware is rejecting Linux’s bootloader due to the August 2024 SBAT update. There are two paths to fix this, in order of preference:

Method B1 — Install the May 2025 Windows Update (official fix)

Microsoft confirmed that Windows updates released May 13, 2025 and later resolve this issue. If your Windows installation can still boot:

1. Boot into Windows.
2. Go to Settings → Windows Update and install all pending updates.
3. Reboot. Linux should be unblocked automatically.

Method B2 — Remove the SBAT policy from Linux (if Windows won’t boot either)

If you can boot into Linux via a live USB, or if temporarily disabling Secure Boot lets you reach a terminal, run this command:

sudo mokutil --set-sbat-policy delete

Reboot, then re-enable Secure Boot in your UEFI settings. Linux should load normally.

Method B3 — Temporarily disable Secure Boot

As a short-term workaround only: enter UEFI firmware, disable Secure Boot, save, and reboot. Linux will boot. This is not recommended for long-term use as it reduces system security.

Fix C — Stuck at grub rescue> Prompt

The grub rescue> prompt means GRUB loaded its very first stage but could not find its configuration files or modules. This usually means GRUB’s core files are missing or the partition UUID has changed.

Quick manual boot from the rescue prompt

You can boot into Ubuntu manually from this prompt as a temporary fix, then reinstall GRUB properly from inside Ubuntu.

1. At the grub rescue> prompt, list available partitions:

   ls

2. Try each partition to find your Ubuntu root. Look for one with a /boot/grub directory:

   ls (hd0,gpt2)/boot/grub

   Replace hd0,gpt2 with whichever partition responds without an error.
3. Once found, set the prefix and root:

   set prefix=(hd0,gpt2)/boot/grub
   set root=(hd0,gpt2)
   insmod normal
   normal

4. GRUB’s normal menu should load. Boot into Ubuntu, then run Fix D below to make the repair permanent.

Fix D — Reinstall GRUB from a Live USB (Full Repair)

This is the most reliable repair for any GRUB problem. It rebuilds the bootloader from scratch using a Ubuntu live environment.

1. Boot from the Ubuntu USB. Choose “Try Ubuntu” (do not install).
2. Open a Terminal and identify your Ubuntu root partition:

   sudo fdisk -l

   Look for your Linux ext4 partition (e.g., /dev/sda3 or /dev/nvme0n1p3).
3. Mount your Ubuntu root partition and the EFI partition:

   sudo mount /dev/sda3 /mnt
   sudo mount /dev/sda1 /mnt/boot/efi

   Replace sda3 and sda1 with your actual partition names. Your EFI partition is typically the small FAT32 partition (100–500 MB).
4. Bind the virtual filesystems:

   sudo mount --bind /dev /mnt/dev
   sudo mount --bind /proc /mnt/proc
   sudo mount --bind /sys /mnt/sys
   sudo mount --bind /run /mnt/run

5. Chroot into your Ubuntu installation:

   sudo chroot /mnt

6. Reinstall GRUB to the EFI partition:

   grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu

7. Update GRUB configuration so it detects Windows:

   update-grub

8. Exit the chroot and reboot:

   exit
   sudo reboot

On reboot, remove the USB drive. Your GRUB menu should appear with both Ubuntu and Windows 11 listed.

Prevention — Stop This Happening Again

1. Run the bcdedit command proactively

After every successful recovery, run this in a Windows Admin terminal to anchor the boot path:

bcdedit /set {bootmgr} path \EFI\ubuntu\shimx64.efi

2. Disable Fast Startup in Windows

Fast Startup puts Windows into a hybrid hibernate state. On the next power-on, the UEFI firmware can misread the EFI partition, triggering boot conflicts. Disable it:

1. Open Control Panel → Power Options.
2. Click “Choose what the power buttons do”.
3. Click “Change settings that are currently unavailable”.
4. Uncheck “Turn on fast startup” and save.

3. Use separate physical drives (strongest protection)

If your machine has two storage drives, install Windows on one and Ubuntu on the other — each with its own EFI partition. Set the Ubuntu drive as the primary boot device in UEFI. Windows updates can then modify their own drive freely without touching GRUB at all.

4. Keep Windows updated (especially post-August 2024)

Counterintuitively, keeping Windows updated is now protective: the May 2025 Patch Tuesday fixed the SBAT detection logic that had been breaking Linux boots for nine months. Staying current means you get these corrections as they ship.

5. Consider switching to systemd-boot

Community evidence suggests that systemd-boot (the bootloader used by default on some distributions, and available on Ubuntu) is significantly less susceptible to Windows update interference than GRUB, because it interacts with NVRAM differently. For advanced users comfortable with manual bootloader configuration, it is worth investigating.

Quick-Reference: Match Your Symptom to Your Fix