Troubleshoot a Linux Bootloader (GRUB, systemd-boot)

A broken bootloader is one of the more alarming failures a Linux system can throw at you — the machine posts, then drops you into a blank screen or a GRUB rescue prompt. This guide walks through diagnosing and repairing both GRUB and systemd-boot across modern distros, with particular attention to EFI systems, BLS (Boot Loader Specification) entries, and dual-boot setups. You'll need a live USB of your distribution handy for most of the repair steps.

Know What You're Working With

Before touching anything, identify which bootloader is installed and whether your system uses UEFI or legacy BIOS. Almost every machine from 2012 onwards uses UEFI.

# From a running system or live environment
efibootmgr -v

If efibootmgr returns entries, you're on UEFI. If it errors with "EFI variables are not supported", you're on legacy BIOS. Knowing this matters because GRUB has separate code paths for each, and systemd-boot only works on UEFI.

# Check which bootloader owns the EFI System Partition
ls /boot/efi/EFI/

You'll typically see directories like ubuntu, fedora, BOOT, or systemd. Multiple directories indicate a dual-boot or multi-boot setup.

Mount Your System from a Live Environment

For most repairs you need to chroot into the installed system. Boot from a live USB, open a terminal, then follow these steps.

Identify your partitions

lsblk -o NAME,FSTYPE,SIZE,MOUNTPOINT,LABEL
fdisk -l

Look for your EFI System Partition (type EFI System, usually 100–600 MB, FAT32) and your root partition. Common device names are /dev/sda, /dev/nvme0n1, etc.

Mount and chroot

# Adjust /dev/sdaX and /dev/sdaY to match your setup
mount /dev/sdaX /mnt              # root partition
mount /dev/sdaY /mnt/boot/efi     # EFI System Partition

# Bind-mount virtual filesystems
for fs in dev dev/pts proc sys sys/firmware/efi/efivars run; do
  mount --bind /$fs /mnt/$fs
done

chroot /mnt

If your distro uses a separate /boot partition, mount that too before /boot/efi. On Btrfs systems, you may need to specify the correct subvolume with -o subvol=@.

Repairing GRUB

Reinstall GRUB on UEFI

This covers the most common case: GRUB is present but its EFI binary is missing or corrupt, or the NVRAM entry was wiped (often happens after a firmware update or Windows "fast startup" interference).

# Debian / Ubuntu
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
update-grub

# Fedora / RHEL / Rocky
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=fedora
grub2-mkconfig -o /boot/grub2/grub.cfg

# Arch Linux
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
grub-mkconfig -o /boot/grub/grub.cfg

After running grub-install, verify the new EFI entry appeared:

efibootmgr -v | grep -i grub

Reinstall GRUB on legacy BIOS (MBR)

# Replace /dev/sda with your actual disk — NOT a partition (no number)
grub-install /dev/sda
update-grub   # Debian/Ubuntu
# or: grub2-mkconfig -o /boot/grub2/grub.cfg  (Fedora/RHEL)

Regenerate grub.cfg without reinstalling

If GRUB itself boots but doesn't show your OS (common after adding a new kernel or OS), just regenerate the config:

# Debian / Ubuntu
update-grub

# Fedora / RHEL / Rocky (UEFI path)
grub2-mkconfig -o /boot/grub2/grub.cfg

# Arch
grub-mkconfig -o /boot/grub/grub.cfg

Fixing dual-boot: Windows entry missing

Ensure os-prober is installed and not disabled. On many distros its auto-detection was disabled by default starting around 2021 to prevent false positives in container environments.

# Debian/Ubuntu
apt install os-prober

# Fedora
dnf install os-prober

# Enable os-prober in GRUB config
echo 'GRUB_DISABLE_OS_PROBER=false' >> /etc/default/grub
update-grub   # or grub2-mkconfig as appropriate

Also confirm Windows's EFI files are intact at /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi. If they're missing, Windows's own recovery media is the right tool to restore them.

Repairing systemd-boot

systemd-boot is used by default on Fedora (since F37) and optionally on Arch and Ubuntu. Its configuration lives entirely on the EFI System Partition, which makes it simpler to inspect and repair.

Reinstall the bootloader

# From inside the chroot
bootctl install

# If the EFI partition is mounted at a non-standard path
bootctl --esp-path=/boot/efi install

Inspect and fix BLS entries

systemd-boot uses the Boot Loader Specification (BLS). Each kernel gets a plain-text file in /boot/loader/entries/. Missing or malformed entries are the most common cause of a blank boot menu.

ls /boot/loader/entries/
cat /boot/loader/entries/*.conf  # inspect one

A valid BLS entry looks like this (values will differ on your system):

title   Fedora Linux 40 (Workstation)
version 6.8.5-301.fc40.x86_64
machine-id a1b2c3d4e5f6...
linux   /vmlinuz-6.8.5-301.fc40.x86_64
initrd  /initramfs-6.8.5-301.fc40.x86_64.img
options root=UUID=xxxx-xxxx ro quiet

If entries are missing entirely, on Fedora/RHEL you can regenerate them via kernel-install:

# Fedora / RHEL — reinstall all kernels into BLS
for kver in $(ls /lib/modules); do
  kernel-install add $kver /lib/modules/$kver/vmlinuz
done

On Arch with mkinitcpio, regenerate all initramfs images and entries:

mkinitcpio -P

Update systemd-boot after a systemd upgrade

The bootloader binary on the ESP can become out of sync with the installed systemd version. This sometimes causes a version mismatch warning or boot failure:

bootctl update
bootctl status   # confirm versions match

Fallback Boot Entries and Secure Boot

Both bootloaders write a fallback binary to /boot/efi/EFI/BOOT/BOOTX64.EFI. If your NVRAM entries are lost (common on some consumer motherboards after a CMOS clear), the firmware falls back to this path. Verify it exists:

ls -lh /boot/efi/EFI/BOOT/BOOTX64.EFI

If it's missing, copy your bootloader's EFI binary there manually:

# For GRUB
cp /boot/efi/EFI/ubuntu/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

# For systemd-boot
cp /boot/efi/EFI/systemd/systemd-bootx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

If Secure Boot is enabled and your distro uses signed binaries (Ubuntu, Fedora, RHEL do; vanilla Arch does not), a manually copied unsigned binary will be rejected. Stick to grub-install or bootctl install which handle signing automatically via shim.

Verify the Repair

# Check EFI boot order and entries
efibootmgr -v

# For systemd-boot: confirm status and entries
bootctl status

# For GRUB: look for syntax errors in generated config
grub2-script-check /boot/grub2/grub.cfg   # Fedora/RHEL
grub-script-check /boot/grub/grub.cfg     # Arch / Debian

Exit the chroot, unmount cleanly, and reboot:

exit
umount -R /mnt
reboot

Troubleshooting Common Errors

• "error: no such partition" at GRUB rescue prompt — GRUB's stored root UUID no longer matches. Boot live, chroot, and run update-grub / grub2-mkconfig to regenerate the config with current UUIDs.
• systemd-boot shows no menu entries — BLS entry files are missing or the loader/entries directory is on the wrong partition. Confirm your /boot or ESP is mounted and re-run kernel-install or mkinitcpio -P.
• EFI variables not writable (chroot) — You forgot to bind-mount /sys/firmware/efi/efivars. Re-mount it before running grub-install or bootctl.
• Windows boots directly, ignoring Linux bootloader — Windows reset the EFI boot order. Run efibootmgr --bootorder XXXX,YYYY (using your Linux entry's ID first) to fix the order, or set it in your UEFI firmware menu.
• Secure Boot error after copying EFI binary manually — Use the distro's signed binary via the official install commands, not a manual copy. On Fedora/RHEL check that shim-x64 and grub2-efi-x64 packages are installed.