Solving Common Boot Issues in GRUB2: A Practical Troubleshooting Guide

A broken bootloader is one of the most stressful things that can happen to a Linux user. One reboot after a kernel update, and suddenly you're staring at a black screen or a cryptic GRUB rescue prompt instead of your desktop. The good news: GRUB2 failures are almost always recoverable, and most fixes follow a predictable pattern once you know what to look for.

What Is GRUB2 and Why Does It Fail?

GRUB2 (Grand Unified Bootloader version 2) is the default bootloader for most Linux distributions. It sits between your firmware and the operating system, loading the Linux kernel and initramfs into memory so the system can start. Without a working GRUB2, your machine can't boot — even if the OS itself is perfectly intact.

Failures happen for a handful of predictable reasons:

  • Disk changes — replacing a drive or repartitioning updates UUIDs, which GRUB2 uses to locate partitions. If /boot/grub/grub.cfg still references the old UUID, the bootloader can't find the filesystem.
  • Failed or interrupted kernel updates — a package manager crash mid-update can leave an incomplete initramfs or a misconfigured grub.cfg.
  • Overwritten MBR or EFI partition — installing Windows after Linux, or certain disk utilities, can wipe the bootloader from the Master Boot Record or GPT partition table.
  • Corrupted configuration file — manual edits to grub.cfg that introduce syntax errors will prevent GRUB2 from parsing its own config.

GRUB2 is not the same as legacy GRUB (version 1). The configuration syntax, file locations, and recovery procedures differ significantly, so make sure you're following GRUB2-specific instructions.

Identifying the Error: What GRUB2 Is Telling You

The error message or screen state you see at boot tells you exactly how far GRUB2 got before failing — and that determines your recovery path.

Three common failure states:

  • GRUB rescue shell (grub rescue>) — GRUB2 loaded its core image but couldn't find or read /boot/grub/grub.cfg. This is actually the most recoverable state, because you still have a command line.
  • Blank or black screen — the bootloader didn't load at all. Usually means the MBR or EFI boot entry is missing or corrupted. Requires a live USB.
  • GRUB menu missing an OS entry — GRUB2 boots fine but doesn't list your kernel or a dual-boot OS. The config file needs to be regenerated.

The error error: unknown filesystem specifically means GRUB2 found a partition but can't read its filesystem — often because the UUID in grub.cfg no longer matches the actual partition after a disk change.

Fixing GRUB2 from the Rescue Shell

If you see the grub rescue> prompt, you can often boot your system without any external media. The goal is to manually point GRUB2 at the correct partition and load the normal module.

First, list available partitions to find your boot partition:

grub rescue> ls

This returns something like (hd0) (hd0,msdos1) (hd0,msdos2). Try each partition to find the one containing /boot:

grub rescue> ls (hd0,msdos1)/

When you see familiar Linux directories (boot, etc, home), you've found the right partition. Now set the root and prefix:

grub rescue> set root=(hd0,msdos1)
grub rescue> set prefix=(hd0,msdos1)/boot/grub

Load the normal module and hand off to the standard GRUB2 environment:

grub rescue> insmod normal
grub rescue> normal

If the GRUB menu appears, select your OS and boot. Once inside the system, immediately run update-grub to make the fix permanent — otherwise you'll face the same rescue prompt on the next reboot.

Reinstalling GRUB2 Using a Live USB

When the rescue shell isn't available — blank screen, no GRUB prompt at all — you need bootable rescue media. Boot from a Linux live USB of the same or a compatible distribution, then follow these steps.

First, identify your root partition using lsblk or fdisk -l. Then mount it:

sudo mount /dev/sda2 /mnt

If /boot is a separate partition, mount it too:

sudo mount /dev/sda1 /mnt/boot

Bind the virtual filesystems so the chroot environment works correctly:

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

Now chroot into your system:

sudo chroot /mnt

From inside the chroot, reinstall GRUB2 to the correct disk (not partition — the whole disk):

grub-install /dev/sda

Then regenerate the configuration file:

update-grub

Exit the chroot, unmount everything, and reboot. This procedure restores a fully working bootloader in the vast majority of cases.

Regenerating grub.cfg After a Kernel Update or Disk Change

If your system boots but shows the wrong kernel version or is missing OS entries, the fix is regenerating /boot/grub/grub.cfg. Never edit grub.cfg directly — it's auto-generated and your changes will be overwritten.

On Debian/Ubuntu-based systems:

sudo update-grub

On Fedora, RHEL, and Arch-based systems, use grub-mkconfig directly:

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

Both commands do the same thing: scan for installed kernels, detect other operating systems, and write a fresh grub.cfg. After a disk replacement, the new drive will have different UUIDs. Run blkid to confirm the new UUID, then update /etc/fstab before regenerating grub.cfg — otherwise the new config will reference a UUID that doesn't exist.

If a Windows entry disappeared after a Linux update, install the os-prober package and re-run update-grub. Some distributions disable os-prober by default; check /etc/default/grub for the line GRUB_DISABLE_OS_PROBER=true and remove or comment it out.

UEFI-Specific GRUB2 Issues

On UEFI systems, GRUB2 behaves differently from BIOS/MBR setups. The bootloader lives on a dedicated EFI System Partition (ESP) — typically formatted as FAT32 and mounted at /boot/efi — rather than in the MBR.

When reinstalling GRUB2 on a UEFI system, the command changes:

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

Make sure the ESP is mounted before running this. Inside a chroot from a live USB, you'll also need to mount it:

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

A common UEFI-specific problem is a missing or invalid boot entry in the firmware. After running grub-install, verify the entry was created:

efibootmgr -v

If your system has Secure Boot enabled, a manually reinstalled GRUB2 may be blocked unless you're using a signed bootloader from your distribution. Disabling Secure Boot temporarily in the UEFI firmware settings is often the fastest path to recovery, after which you can re-enable it once the system is stable.

Preventing GRUB2 Boot Problems

Most GRUB2 failures are preventable with a few habits that take almost no extra time.

  • Keep a bootable USB ready. A live USB of your distribution is the single most useful recovery tool you can have. Store one somewhere accessible.
  • Test kernel updates before rebooting production systems. On servers, use GRUB_DEFAULT=saved and GRUB_SAVEDEFAULT=true in /etc/default/grub so you can select the previous kernel from the menu if the new one fails.
  • Update /etc/fstab and grub.cfg together whenever you replace a disk or change partition layout. UUID mismatches are the leading cause of post-migration boot failures.
  • Set a reasonable GRUB_TIMEOUT (5–10 seconds) in /etc/default/grub. A timeout of 0 hides the menu entirely, which makes recovery much harder if something goes wrong.
  • After any manual GRUB2 change, always run update-grub to validate the configuration before rebooting.

Frequently Asked Questions

What does "error: unknown filesystem" mean in GRUB2?

It means GRUB2 found a partition but can't read its filesystem. This usually happens after a disk replacement where the UUID in grub.cfg no longer matches the new drive. Boot from a live USB, update /etc/fstab with the correct UUID from blkid, then reinstall and regenerate grub.cfg.

How do I access the GRUB2 rescue shell?

The rescue shell appears automatically when GRUB2 can't find its configuration file. If you want to access the standard GRUB command line from the boot menu, press c at the GRUB menu screen. From the rescue prompt, you can run ls, set, and insmod commands to manually boot the system.

Can I fix GRUB2 without a live USB?

Yes, if you can reach the grub rescue> prompt. Use ls to find your boot partition, set the root and prefix manually, load the normal module, and boot. Once inside the OS, run update-grub to make the fix permanent. A blank screen with no GRUB prompt at all typically requires external rescue media.

Why did GRUB2 stop showing my Windows entry after a Linux update?

Most likely, os-prober is disabled or wasn't run. Install the os-prober package, check that GRUB_DISABLE_OS_PROBER is not set to true in /etc/default/grub, then run sudo update-grub. GRUB2 will re-scan for other operating systems and add the Windows entry back.

What is the difference between grub-install and update-grub?

grub-install writes the GRUB2 bootloader code to the MBR or EFI partition — it installs the bootloader itself. update-grub (or grub-mkconfig) generates the /boot/grub/grub.cfg configuration file that tells GRUB2 which kernels and OSes to list. After a full reinstall, you need both: grub-install first, then update-grub.

{{HOMEPAGE_LINKS}}