GRUB Problems and Fixes: grub rescue, os-prober and Live USB Reinstall

A grub rescue> prompt means GRUB started but could not load its normal module, usually because its prefix points at the wrong disk or partition. You can often boot once by setting prefix and root by hand, then fix the cause for good by booting a live USB, entering the installed system with chroot, reinstalling GRUB and regenerating its configuration.

The exact commands depend on three things: whether the machine boots with UEFI or legacy BIOS, which distribution family you run, and whether Secure Boot is on. This guide covers the boot problems people actually hit, with commands taken from the GNU GRUB manual and the Debian, Ubuntu, Fedora and Arch documentation, and ends with the GRUB security history that explains why distributions now revoke old GRUB builds.

Key takeaways

• grub rescue> is a tiny shell with only insmod, ls, set and unset. Find the partition holding /boot/grub, set prefix and root, then run insmod normal and normal.
• Windows missing from the menu is usually deliberate: grub-mkconfig no longer runs os-prober unless you set GRUB_DISABLE_OS_PROBER=false.
• update-grub (Debian, Ubuntu), grub2-mkconfig (Fedora, RHEL) and grub-mkconfig (Arch) do the same job with different names and paths.
• On UEFI, Fedora says not to run grub2-install; reinstall the signed shim and GRUB packages instead.
• A live USB repair is always: mount, bind mount, chroot, reinstall, regenerate, reboot. Boot the USB in the same mode as the installed system.
• BootHole (CVE-2020-10713, 29 July 2020) and later GRUB CVE batches are why shim and GRUB carry SBAT generation numbers, and why old rescue media may refuse to boot.

First, work out which world you are in

Most GRUB advice goes wrong because it mixes BIOS and UEFI instructions. From any running Linux session, including a live USB, this tells you how that session booted:

[ -d /sys/firmware/efi ] && echo "UEFI boot" || echo "Legacy BIOS boot"

The Debian wiki uses the same test. It reports how the live USB booted, not how the installed system boots, so pick the firmware menu entry with a "UEFI:" prefix when repairing a UEFI install. The Arch wiki warns that otherwise efibootmgr will not be able to add the GRUB boot entry.

The Arch wiki notes that a device path passed to grub-install on UEFI is ignored, because UEFI loaders do not use MBR boot code. That explains many failed fixes: the BIOS command runs on a UEFI machine, appears to succeed, and changes nothing.

What does the grub rescue> prompt mean and how do you boot from it?

The GNU GRUB manual (version 2.14, dated 8 January 2026) describes the normal start sequence. GRUB sets prefix to a value baked into the core image by grub-install, sets root to match, loads the normal module from that prefix, and runs normal, which reads grub.cfg and shows the menu. According to the manual, landing in the rescue shell usually means GRUB could not load the normal module.

Typical causes are a /boot partition that was moved, resized or reformatted; disk numbering that changed after adding or removing a drive; and another installer overwriting boot code. On UEFI, the Arch wiki adds a missing grub.cfg and a change to the boot partition hard coded into grubx64.efi.

Per the manual, only insmod, ls, set and unset are normally available in rescue mode.

Booting once from the rescue shell

These steps only set variables in memory. Nothing is written to disk.

1. See where GRUB is looking, then list the disks it can see:

grub rescue> set
grub rescue> ls
(hd0) (hd0,gpt1) (hd0,gpt2) (hd0,gpt3) (hd1) (hd1,msdos1)

GRUB numbers disks in firmware order, not Linux order. The manual warns that /dev/sda may not be the disk your firmware boots from.

2. Probe partitions until one shows grub.cfg and a platform directory such as i386-pc or x86_64-efi:

grub rescue> ls (hd0,gpt2)/boot/grub

3. Set prefix and root, load normal and start it:

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

With a separate /boot partition, drop /boot from the path, as in the manual's own example set prefix=(hd0,1)/grub.

When the menu appears, boot normally and then reinstall GRUB. The manual is blunt that any problem leaving you in the rescue shell probably means GRUB was not installed correctly, so a reinstall is the real fix.

When normal will not load

The Arch wiki shows how to load the Linux loader module and start a kernel by hand:

grub rescue> insmod linux
grub rescue> set root=(hd0,5)
grub rescue> linux /boot/vmlinuz-linux root=/dev/sda5
grub rescue> initrd /boot/initramfs-linux.img
grub rescue> boot

Use your distribution's kernel and initramfs file names. The root= value uses Linux device names, a different scheme from GRUB's (hd0,5).

One Secure Boot caveat: the Arch wiki notes that newer GRUB builds refuse to insmod modules not embedded in the signed EFI binary, failing with error: prohibited by secure boot policy. Distribution signed images embed the common modules, but this is why some old rescue tricks no longer work.

How do you find and set the right root and prefix?

Once you are in Linux, or in a chroot, be precise instead of guessing:

lsblk -f            # filesystems, labels, UUIDs, mount points
findmnt /boot
findmnt /boot/efi

Two habits make GRUB less fragile. First, use UUIDs, not device names. The GRUB manual recommends UUIDs or labels over drive ordering, and the Arch wiki notes that grub-mkconfig already uses the root filesystem UUID by default. Hand written entries should use search --fs-uuid --set=root followed by the UUID. Second, on BIOS, install to the whole disk. The manual says installing to the whole disk device is normally more reliable, because a filesystem can move blocks under a core image stored in a partition, and a partition install is ignored when GRUB is already in the MBR.

Why did Windows disappear from the GRUB menu (GRUB_DISABLE_OS_PROBER)?

grub-mkconfig can call os-prober, which scans other partitions for operating systems and writes menu entries for them. The GNU GRUB manual says this feature is off by default because automatic and silent execution of os-prober, and creating boot entries from its data, is a potential attack vector. The default changed with GRUB 2.06, released on 8 June 2021, so distributions that moved to 2.06 or later started producing menus without Windows.

To bring Windows back:

1. Install os-prober (sudo apt install os-prober, sudo dnf install os-prober or sudo pacman -S os-prober).
2. Add this line to /etc/default/grub:

GRUB_DISABLE_OS_PROBER=false

3. Mount the partition holding the other system's boot files. For a UEFI Windows install, that is the ESP containing bootmgfw.efi. The Arch wiki says the mount point does not matter, and that os-prober may need fuse3 installed.
4. Regenerate the config (next section) and look for a line reporting Windows Boot Manager.

The Arch wiki adds two warnings: os-prober may not work properly inside a chroot, so regenerate again after booting the installed system; and the other partitions must be mounted every time you regenerate. If you would rather keep os-prober off, write a static chainload entry in /etc/grub.d/40_custom, as the Arch wiki's dual booting section shows.

update-grub vs grub2-mkconfig vs grub-mkconfig: which on which distro?

All three build grub.cfg from /etc/default/grub and the scripts in /etc/grub.d/. Upstream ships grub-mkconfig; Debian and Ubuntu provide update-grub; Fedora and the RHEL family prefix the tools with grub2- and use a different directory.

Three notes. The Fedora wiki says that on Fedora 34 and later, /boot/efi/EFI/fedora/grub.cfg is only a small stub that forwards to /boot/grub2/grub.cfg, so old guides that write a full config to the ESP path date from Fedora 33 and earlier. The same page says "Do not use the grub2-install command on UEFI systems." And on Arch, the wiki says to rerun grub-mkconfig after installing or removing a kernel; Debian, Ubuntu and Fedora do that through package hooks.

Before you touch the bootloader: what to back up

Every repair below writes to the ESP, the MBR or firmware NVRAM, and a mistake can strand other operating systems on the same disk. Write these backups to a separate USB stick, not the disk you are repairing, and check each device path against your own lsblk output first.

lsblk -f > /media/backup/lsblk.txt
sudo blkid > /media/backup/blkid.txt
sudo efibootmgr --verbose > /media/backup/efibootmgr.txt     # UEFI only
sudo cp -a /boot/efi /media/backup/esp-copy                    # the whole ESP
sudo cp -a /etc/default/grub /etc/grub.d /media/backup/

# Legacy BIOS only: save the first MiB of the boot disk
sudo dd if=/dev/sdX of=/media/backup/sdX-first-1MiB.img bs=1M count=1

Warning: in the dd line, if= is the disk you read and of= is a file on the backup stick. Swapping them overwrites your boot disk. Read it twice before pressing Enter.

Also find the recovery key for any disk encryption first. A BitLocker volume may ask for its key after boot changes, and a LUKS volume needs its passphrase before you can chroot.

How do you reinstall GRUB from a live USB?

The procedure has the same shape everywhere:

1. Boot a live USB in the same mode (UEFI or BIOS) as the installed system.
2. Identify the root partition, any separate /boot, and the ESP.
3. Mount them under /mnt.
4. Bind mount the kernel's virtual filesystems.
5. chroot into /mnt.
6. Reinstall GRUB and regenerate the config.
7. Exit, unmount with sudo umount -R /mnt, and reboot.

Identify the partitions every time

lsblk -o NAME,SIZE,FSTYPE,LABEL,PARTTYPENAME,MOUNTPOINTS

The ESP is small, vfat, with partition type "EFI System". Root is the large ext4, xfs or btrfs partition. NVMe partitions look like /dev/nvme0n1p1 and the whole disk is /dev/nvme0n1. If unsure, mount a candidate read only and read its /etc/fstab, which lists the UUIDs of root, /boot and the ESP:

sudo mount -o ro /dev/nvme0n1p3 /mnt && cat /mnt/etc/fstab; sudo umount /mnt

Every device name below is a placeholder. Substitute your own after checking.

Debian and Ubuntu, UEFI

This follows the Debian wiki's GrubEFIReinstall procedure. Ubuntu uses the same grub-install and update-grub tools.

Warning: grub-install overwrites GRUB files on the ESP and changes firmware boot entries. Confirm that the partition you mount at /mnt/boot/efi is the vfat ESP and the one at /mnt is the Linux root.

sudo mount /dev/nvme0n1p2 /mnt
# only if /boot is separate: sudo mount /dev/nvme0n1pX /mnt/boot
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt

# inside the chroot
apt-get install --reinstall grub-efi-amd64 shim-signed   # Ubuntu: also grub-efi-amd64-signed
grub-install
update-grub
efibootmgr --verbose | grep -i -E "debian|ubuntu"
exit

The Debian wiki adds two checks. If /sys/firmware/efi/efivars is empty, reboot the live system with the kernel option efi=runtime and run mount -t efivarfs none /sys/firmware/efi/efivars. If the live environment uses BusyBox, its mount lacks -B, so use mount -o bind.

Ubuntu's security documentation explains why the package names matter: a shim signed by Microsoft and a GRUB signed by Canonical ship in the main archive as shim-signed and grub-efi-amd64-signed (grub-efi-arm64-signed on arm64). Reinstalling them puts correctly signed binaries back on the ESP.

Debian and Ubuntu, legacy BIOS

Warning: grub-install /dev/sdX writes boot code to the start of that whole disk. On a multi disk machine, choose the disk the firmware boots from, or you can make another system unbootable.

sudo mount /dev/sda2 /mnt
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
sudo chroot /mnt
grub-install /dev/sda        # the whole disk, never /dev/sda2
update-grub
exit

Fedora and RHEL family, UEFI

Fedora reinstalls packages instead of running grub2-install.

Warning: these commands delete GRUB configuration before reinstalling. Confirm that /mnt/boot/efi is the vfat ESP and /mnt is the Fedora root, and keep your ESP backup.

sudo mount /dev/nvme0n1p3 /mnt          # add -o subvol=<name> if root is a btrfs subvolume
sudo mount /dev/nvme0n1p2 /mnt/boot
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do sudo mount -B $i /mnt$i; done
sudo cp /etc/resolv.conf /mnt/etc/resolv.conf   # so dnf can reach mirrors
sudo chroot /mnt

# inside the chroot
rm /boot/grub2/grub.cfg
# Fedora 33 and earlier only: rm /boot/efi/EFI/fedora/grub.cfg
dnf reinstall shim-* grub2-efi-* grub2-common
grub2-mkconfig -o /boot/grub2/grub.cfg
exit

The package list and the UEFI warning come from the Fedora wiki's GRUB 2 page, which also notes that installer rescue mode mounts the system at /mnt/sysimage, after which chroot /mnt/sysimage gets you to the same point. On legacy BIOS, the same page uses grub2-install /dev/sda: the device node without a partition number. The same whole disk warning applies.

Arch, UEFI and BIOS

The Arch live ISO includes arch-chroot, which the Arch wiki describes as a wrapper that mounts /dev, /proc and the other API filesystems for you.

Warning: grub-install writes to the ESP on UEFI and to the whole disk on BIOS. Check every device against lsblk -f.

mount /dev/nvme0n1p2 /mnt
mount /dev/nvme0n1p1 /mnt/boot      # or /mnt/efi, wherever fstab mounts the ESP
arch-chroot /mnt

# UEFI
grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
# BIOS instead:
# grub-install --target=i386-pc /dev/nvme0n1

grub-mkconfig -o /boot/grub/grub.cfg
exit

If you chroot by hand, the Arch wiki says to bind /sys/firmware/efi/efivars on UEFI, or grub-install reports that UEFI variables are not supported. It also lists common errors: without --target, grub-install prints source_dir does not exist, and an ESP that "doesn't look like an EFI partition" is most likely not FAT32.

How do you fix a missing EFI boot entry (efibootmgr)?

Sometimes GRUB is fine on the ESP but the firmware has forgotten how to start it. The Arch wiki notes that a UEFI firmware update might delete existing boot entries. Look first:

sudo efibootmgr --verbose

A working entry points at a file such as \EFI\ubuntu\shimx64.efi, \EFI\fedora\shimx64.efi or \EFI\GRUB\grubx64.efi.

Warning: efibootmgr --create and --delete-bootnum change firmware NVRAM. Deleting the wrong entry, such as Windows Boot Manager, removes that system from the firmware menu. Save the efibootmgr --verbose output first.

Find the ESP's disk and partition number with findmnt /boot/efi (for example /dev/nvme0n1p1 means disk /dev/nvme0n1, partition 1), then create the entry. On Secure Boot systems point at the shim, not GRUB:

sudo efibootmgr --create --disk /dev/nvme0n1 --part 1 \
  --loader '\EFI\ubuntu\shimx64.efi' --label 'ubuntu' --unicode

# put it first, using the numbers from your own output
sudo efibootmgr --bootorder 0003,0000,0001 --unicode

These forms follow the Arch wiki's UEFI page.

Some firmware only boots a file at a fixed path. The Arch wiki names MSI boards and recommends the fallback path:

sudo grub-install --target=x86_64-efi --efi-directory=/boot/efi --removable

That installs GRUB as EFI/BOOT/BOOTX64.EFI. The Debian wiki describes the same fix and the debconf option grub2/force_efi_extra_removable, and warns that it permanently overwrites the fallback loader, which may be undesirable on dual boot systems. Back up that file before replacing it. The Arch wiki also flags firmware settings such as a "Boot Order Lock" that block efibootmgr entirely.

How do you recover from a bad kernel or initramfs?

If the GRUB menu appears and the failure comes after you choose an entry, GRUB did its job. The kernel or initramfs is the problem.

1. Boot the previous kernel. Open "Advanced options" (Debian, Ubuntu, Arch) or pick an older entry (Fedora). If that works, the newest kernel or its initramfs is at fault.
2. Edit the entry for one boot. Press e on a menu entry, remove quiet splash to see messages, then press Ctrl+X or F10. Nothing is saved.
3. Rebuild the initramfs, from the older kernel or a live USB chroot:

sudo update-initramfs -u -k all     # Debian and Ubuntu
sudo dracut --regenerate-all --force   # Fedora and RHEL
sudo mkinitcpio -P                  # Arch

The dracut man page documents --regenerate-all as rebuilding all images for the kernels found on the system, with --force to overwrite. The Arch wiki documents mkinitcpio -P for all presets. Regenerate the GRUB config afterwards.

4. Remove or hold the bad kernel once you are booted on a good one, and keep at least two working kernels installed.

Common GRUB error messages and what they usually mean

Why do Secure Boot systems need a signed shim and GRUB?

Secure Boot only runs binaries signed by keys the firmware trusts. Ubuntu's security documentation lays out the chain: most x86 hardware ships with Microsoft certificates in firmware; the firmware validates shim, which Microsoft signs; shim carries an embedded trust database with the distribution's certificate and uses it to validate GRUB and the kernel. If any stage fails, boot stops. The same page notes that "initrd images aren't validated", so a corrupt initramfs fails as a boot error, not a signature error, and that Machine Owner Keys (MOKs) enrolled through MokManager are how locally built kernel modules get trusted.

The GNU GRUB manual covers the GRUB side: a shim_lock verifier built into the core image registers when Secure Boot is on, modules outside the core image and kernels must be signed, and commands such as iorw and memrw are disabled by GRUB's lockdown mechanism. So an unsigned grubx64.efi you built yourself will not start under Secure Boot. Use the distribution's signed packages, enrol and sign with your own key, or, as the Arch wiki suggests when a Secure Boot change leaves a system unbootable, turn Secure Boot off in firmware as a temporary step.

What was BootHole and how did distributions respond?

BootHole, July 2020

BootHole is CVE-2020-10713, disclosed on 29 July 2020 under coordinated disclosure. The original disclosure describes it as a buffer overflow in how GRUB2 parsed grub.cfg, a file that sits outside the signed binary, letting someone who already had administrator rights run code during boot with Secure Boot on. The researchers scored it 8.2 (High) and said virtually every Linux distribution was affected, and that any system trusting the Microsoft UEFI CA was exposed, including Windows machines. Red Hat rated the same CVE Moderate; vendors weigh the need for prior administrator access differently.

Ubuntu's USN-4432-1, published the same day, fixed eight GRUB 2 CVEs together (CVE-2020-10713, CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705, CVE-2020-15706 and CVE-2020-15707) and said full mitigation also needed a firmware revocation list (dbx) update. Red Hat listed shim, fwupd, fwupdate, the kernel and dbxtool alongside grub2.

The rollout was rough. The researchers reported on 30 July that some bootloader updates were causing failed reboots, and Red Hat advised against its first shim build because it could hang systems before the GRUB menu. The disclosure also warned that applying dbx revocations before updating shim and GRUB could stop the OS from loading, and that recovery media could stop booting.

2021: a second batch and SBAT

Red Hat's RHSB-2021-003, published 1 March 2021, centred on CVE-2020-14372 (the acpi command could load crafted ACPI tables under Secure Boot) and six related issues: CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225 and CVE-2021-20233. Ubuntu shipped fixes for six of these in USN-4992-1 on 18 June 2021.

This is when SBAT (Secure Boot Advanced Targeting) arrived. The shim project's SBAT document explains why: BootHole alone added 3 certificates and 150 image hashes to the x64 dbx, about a third of the typical 32 kB of revocation storage, and hash revocation could not scale. SBAT embeds a .sbat section with a component name and generation number in each boot binary. When a class of bugs is fixed, the minimum generation rises, and shim refuses any GRUB below it. The minimums live in a UEFI variable, SbatLevel, which the document says cannot be rolled back. Red Hat says SBAT replaces the dbxtool process, so signing keys need not be rotated for each event. The GRUB manual documents the --sbat option to grub-mkimage, and the Arch wiki notes shim will refuse a grubx64.efi with no SBAT section.

February 2025: 21 CVEs at once

On 18 February 2025, Jan Setje-Eilers of Oracle posted "GRUB CVE disclosures" to the oss-security list, covering 21 CVEs from CVE-2024-45774 to CVE-2025-1125. Most were in filesystem drivers (BFS, tar, UFS, HFS, HFS+, squashfs, ReiserFS, JFS, romfs and UDF); others were in the JPEG reader, gettext handling, several commands and network boot config lookup. Fixes were published with the disclosure, and the post said a shim release would publish updated SBAT revocations for older GRUB versions.

Distribution tracking is still moving. Ubuntu's page for CVE-2024-45774 rates it Medium (CVSS 6.7), says the Secure Boot fixes land in grub2-unsigned, and when we checked on 23 October 2026 still listed several releases as "Needs evaluation" for grub2-signed. Check your distribution's tracker for the current state. Further GRUB advisories appeared between 2021 and 2025, and the pattern repeats: a batch of parsing bugs, new shim and GRUB packages, then an SBAT bump that eventually stops old boot media.

What this means for repairs: keep current live media, update shim and GRUB packages before any firmware revocation update, and treat grub.cfg as sensitive, since BootHole showed the unsigned config is part of the attack surface.

Common mistakes

• Running grub-install /dev/sda on UEFI. The device argument is ignored. Use --efi-directory.
• Booting the live USB in BIOS mode to repair a UEFI install. efibootmgr cannot write entries. Use the "UEFI:" menu entry.
• Running grub2-install on Fedora UEFI. Reinstall the shim and grub2-efi packages instead.
• Overwriting Fedora's ESP stub with a full config on Fedora 34 or later.
• Forgetting the efivars bind mount inside the chroot.
• Installing GRUB to a partition on BIOS, or to the wrong disk on a multi disk machine.
• Re-enabling os-prober and then unmounting Windows before the next regeneration.
• Replacing a dual boot machine's fallback BOOTX64.EFI without a backup.
• Blaming GRUB for a kernel panic that happens after the menu.
• Relying on a years old rescue USB that revocations may now block.

Where Safeguard fits, honestly

Most of this post is outside what Safeguard does. Safeguard does not inspect firmware, manage devices, check Secure Boot state or repair boot loaders. If a laptop is sitting at grub rescue>, the steps above fix it.

The honest link is narrower. GRUB, shim, os-prober and the kernel are packages inside OS, virtual machine and appliance images. When a GRUB batch like February 2025 lands, the question is which of your images ship an affected grub2 or shim build. Where those images are described by an SBOM, Safeguard can analyse it (safeguard scan --sbom <file>), match components against vulnerability databases, and show which projects contain a given component and version. Most application container images carry no GRUB at all, so this applies to VM and appliance images, not the boot chain on a physical machine.

Fix it without waiting for upstream

GRUB itself is fixed by your distribution, and the steps above cover that. But a machine rebuilt from a live USB pulls every project dependency again, and the images you ship carry open source components whose fixes you do control, so these habits still matter after a boot repair.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

How do I get out of grub rescue mode?

Run ls to find the partition containing /boot/grub, then set prefix=(hdX,Y)/boot/grub, set root=(hdX,Y), insmod normal and normal. That boots once. Reinstall GRUB afterwards to fix it permanently.

Why does my PC go to grub rescue after installing Windows?

Windows setup can overwrite boot code or change partitions, leaving GRUB pointing at files that moved. Boot once from the rescue shell or a live USB, reinstall GRUB, and enable os-prober so Windows appears in the menu.

Why is Windows not showing in the GRUB menu?

Since GRUB 2.06, os-prober does not run unless /etc/default/grub contains GRUB_DISABLE_OS_PROBER=false. Add it, mount the Windows ESP, and regenerate the config.

Is update-grub the same as grub-mkconfig?

They do the same job. Debian and Ubuntu provide update-grub; Arch calls grub-mkconfig -o /boot/grub/grub.cfg directly; Fedora and RHEL use grub2-mkconfig -o /boot/grub2/grub.cfg.

How do I reinstall GRUB from a live USB on Ubuntu?

Boot the USB in UEFI mode, mount root at /mnt and the ESP at /mnt/boot/efi, bind mount /dev, /dev/pts, /proc, /sys, /sys/firmware/efi/efivars and /run, chroot, reinstall shim-signed and grub-efi-amd64-signed, run grub-install and update-grub, then reboot.

Should I use grub2-install on Fedora?

Only on legacy BIOS, against the whole disk. On UEFI, Fedora's documentation says not to; reinstall shim-*, grub2-efi-* and grub2-common with dnf instead.

What is BootHole and am I still affected?

BootHole (CVE-2020-10713) was a GRUB2 config parsing flaw disclosed on 29 July 2020 that let an attacker with administrator rights bypass Secure Boot. Supported distributions shipped fixed GRUB and shim packages long ago. A fully updated system is covered; old installer media may not be.

Why will my old Linux USB not boot anymore?

After BootHole, vulnerable shim and GRUB builds were revoked, first by dbx hashes and later by SBAT generation numbers. A patched machine can refuse an old USB's boot loader. Download current media.

See how Safeguard would help

None of these demos repair a boot loader. They show how Safeguard handles the software you rebuild on top of one.

The first demo is a real Safeguard CLI session: asked to fix a lodash CVE, the assistant reads the finding, asks before each command, edits package.json, runs npm install and npm test with approval, and pushes nothing. After a live USB rebuild, the same flow brings a project's dependencies back to fixed versions without relying on memory.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code, then scans from the terminal. On a freshly rebuilt workstation, that gets dependency inventory and vulnerability checks running again from your own hardware.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. If you track OS or appliance images by SBOM, the same connection lets you ask which projects contain a given grub2 or shim version when the next GRUB advisory lands.

Click through it at your own pace, or open it full screen.

To try the CLI, download Safeguard and follow the CLI documentation. For the boot chain itself, read how Secure Boot links to the software supply chain and the difference between Secure Boot, Trusted Boot and Measured Boot. For rebuilding machines without a network, see how the local runner and offline mode work.

Quick check

Sources

• GNU GRUB Manual 2.14
• Arch Wiki: GRUB
• Arch Wiki: Chroot
• Arch Wiki: Unified Extensible Firmware Interface
• Arch Wiki: mkinitcpio
• Debian Wiki: GrubEFIReinstall
• Fedora Project Wiki: GRUB 2
• Ubuntu security documentation: UEFI Secure Boot
• Ubuntu USN-4432-1: GRUB 2 vulnerabilities
• Ubuntu USN-4992-1: GRUB 2 vulnerabilities
• Ubuntu CVE tracker: CVE-2024-45774
• NVD: CVE-2020-10713 (BootHole)
• Red Hat: Boot Hole vulnerability in GRUB 2
• Red Hat RHSB-2021-003: ACPI Secure Boot vulnerability in GRUB 2
• shim: SBAT.md
• oss-security: GRUB CVE disclosures, 18 February 2025
• grub-devel: GRUB 2.06 release announcement
• man7.org: dracut(8)

Last reviewed: 23 October 2026. Boot loader packages and revocations change often; check your distribution's documentation and security tracker before running any command above.