how to upgrade grub | LawnHelpful.com

Figuring out how to upgrade grub can feel intimidating, especially when one wrong command might leave your system unable to boot. The good news is that it's usually a straightforward process once you understand your setup and follow the right steps for your specific situation.

GRUB 2 (Grand Unified Bootloader version 2) has been the standard Linux bootloader for over a decade, and the current stable upstream release sits at version 2.12 as of 2025. With that version came meaningful improvements in LUKS2 encryption support, better btrfs and zfs handling, and more reliable UEFI firmware interaction. Whether you're patching a security fix, enabling a new kernel feature, or chasing a bug that's been nagging you, upgrading GRUB is worth doing when the time is right.

Image source: Bing (Web (fair-use with source credit))

Image 1: GRUB 2 boot menu on an Arch Linux system showing multiple kernel entries.

Quick Answer

Check your boot mode first: UEFI and Legacy BIOS require completely different commands. On Ubuntu and Debian, sudo apt upgrade grub2-common handles the package, then run sudo update-grub. On Fedora and RHEL, use sudo dnf upgrade grub2-efi (UEFI) or grub2-pc (BIOS).

Always verify your GRUB version afterward with grub-install --version. If your system won't boot after the upgrade, a live USB and chroot recovery will fix it in under 15 minutes.

Why You Might Need to Upgrade GRUB (and When You Don't)

You don't need to upgrade GRUB every time your package manager offers it. Most Linux distros ship a GRUB version that works fine for years. Upgrading only makes sense when you have a specific reason.

Reasons it's worth upgrading:

A security vulnerability has been patched in a newer GRUB release (infrequent but serious when it happens)
You're running an encrypted LUKS2 setup and need Argon2 support that your current GRUB lacks
You've upgraded your kernel and GRUB now needs to regenerate its configuration to detect it
You've switched from Legacy BIOS to UEFI and need the EFI-capable GRUB build
You're running btrfs or zfs as your root filesystem and hitting GRUB bugs in older versions

Reasons to skip it:

Your system boots fine and you're not using any features that require an update
You're on a long-term support distribution where the backported security fixes are already applied
You're mid-project on a production server and can't afford any boot risk
The new version adds features you'll never use

Most Ubuntu 24.04 and Debian 12 users are already on GRUB 2.12, so there's nothing to chase. Fedora 39 and RHEL 9 users may still be on 2.06 and could benefit from upgrading through official repos when it becomes available.

How to Check Your Current GRUB Version and Boot Mode

Before you touch anything, get your bearings. Two pieces of information determine the entire upgrade path: what version you're running right now, and whether your system boots through UEFI or Legacy BIOS.

Check your GRUB version:

grub-install --version

This returns something like grub-install (GRUB) 2.06 or 2.12. That single number tells you whether an upgrade is even worthwhile.

If you're on an older Ubuntu or Debian variant, the package may be named differently. Try:

dpkg -l | grep grub

This shows every GRUB-related package and its installed version. It's especially useful when you need to know which exact packages to upgrade.

Check your boot mode:

ls /sys/firmware/efi

If that directory exists, you're booted in UEFI mode. If it returns "No such file or directory," you're on Legacy BIOS. This distinction is critical because UEFI requires the grub-efi package and a target install flag of x86_64-efi, while Legacy BIOS uses the grub-pc package with target i386-pc.

You can also use efibootmgr to see your UEFI boot entries:

efibootmgr -v

This shows every boot option registered in your firmware, including the GRUB entry and its disk path. If efibootmgr isn't found, you're almost certainly on Legacy BIOS.

Identify your boot disk:

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT

Look for the partition mounted at /boot or /boot/efi. Note which disk it lives on (usually /dev/sda or /dev/nvme0n1). Installing GRUB to the wrong disk is one of the most common mistakes, and it's entirely avoidable with this one command.

The Two Paths: UEFI vs Legacy BIOS — Why It Changes Everything

This is where most guides fall short. They give you a single set of commands and hope your system matches. It won't always, and the consequences of guessing wrong range from a non-functional bootloader to a system that boots straight into Windows and ignores Linux entirely.

UEFI systems store the GRUB binary as a file on the EFI System Partition (ESP), a small FAT32 partition usually 100 to 550 MB in size. The firmware reads this file directly. When you upgrade GRUB on UEFI, you're replacing that file and updating the NVRAM boot entry that points to it.

Factor	UEFI	Legacy BIOS
GRUB package name	`grub-efi-amd64` (Debian/Ubuntu), `grub2-efi-x64` (Fedora)	`grub-pc` (Debian/Ubuntu), `grub2-pc` (Fedora)
Install target flag	`--target=x86_64-efi`	`--target=i386-pc`
Where GRUB lives	EFI System Partition (FAT32)	Master Boot Record + /boot
Secure Boot interaction	Must use signed shim + GRUB	Not applicable
Recovery complexity	Moderate (need to mount ESP)	Moderate (need to reinstall to MBR)

Upgrading GRUB on Debian/Ubuntu-Based Systems

Ubuntu and Debian make this about as painless as it gets. The package manager handles the binary update, and a wrapper script regenerates your configuration.

Step 1: Update your package list and upgrade GRUB.

sudo apt update
sudo apt upgrade grub2-common grub-efi-amd64

If you're on Legacy BIOS, swap grub-efi-amd64 for grub-pc. The grub2-common package contains the shared files and scripts that both variants depend on.

Step 2: Regenerate the GRUB configuration.

sudo update-grub

This is a wrapper around grub-mkconfig -o /boot/grub/grub.cfg. It scans your installed kernels, runs OS-Prober to find other operating systems, and writes a fresh grub.cfg. If you've customized /etc/default/grub (changed the timeout, default entry, or added kernel parameters), this is when those changes take effect.

Step 3: Reinstall GRUB to the boot device (only if needed).

If the package upgrade alone didn't update the bootloader binary on disk, run:

sudo grub-install /dev/sda

Replace /dev/sda with your actual boot disk. On UEFI systems, you can also specify the EFI directory explicitly:

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

Step 4: Verify.

grub-install --version

Confirm the version number matches what you expected. Then reboot and check that the GRUB menu appears and all your entries work.

A note on Ubuntu's GRUB packaging: Ubuntu sometimes holds back GRUB updates in their repositories even when a newer version exists upstream. If you need a version that Ubuntu hasn't packaged yet, you'd have to compile from source, which is a separate process entirely and not recommended unless you have a specific upstream bug fix you need.

Upgrading GRUB on Fedora, RHEL, and openSUSE

Fedora and RHEL use a slightly different package naming scheme, and the upgrade process reflects that.

Fedora (UEFI):

sudo dnf upgrade grub2-efi-x64 grub2-efi-x64-modules
sudo grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
sudo grub2-install /dev/sda

Fedora (Legacy BIOS):

sudo dnf upgrade grub2-pc grub2-pc-modules
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo grub2-install /dev/sda

Notice the config file path difference. On UEFI Fedora systems, grub.cfg lives inside the EFI System Partition at /boot/efi/EFI/fedora/grub.cfg. On Legacy BIOS, it's at /boot/grub2/grub.cfg.

Getting this path wrong means GRUB can't find its configuration at boot, and you'll end up at the grub> rescue prompt.

RHEL and CentOS Stream follow the same pattern as Fedora. RHEL 9 ships GRUB 2.06, and Red Hat backports security fixes rather than bumping the major version. If you're on RHEL, you'll rarely need to do anything beyond sudo dnf upgrade grub2-efi-x64.

openSUSE uses grub2 as the package name across the board:

sudo zypper update grub2 grub2-i386-pc grub2-x86_64-efi
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

openSUSE's YaST tool can also handle GRUB configuration through a graphical interface if you prefer not to edit files directly. But the command-line approach gives you more control and is easier to document for recovery purposes.

One thing worth knowing: Fedora's GRUB configuration is more tightly integrated with Btrfs snapshots if you're using the default filesystem layout. After upgrading GRUB on a Btrfs-based Fedora system, verify that the snapshot entries in the GRUB menu still point to valid subvolumes. A broken snapshot entry won't prevent booting, but it defeats one of Fedora's best recovery features.

Upgrading GRUB on Arch and Rolling-Release Distros

Arch Linux tracks upstream GRUB releases closely, so you'll usually get version 2.12 or newer within weeks of its release. The upgrade is a single pacman command.

sudo pacman -Syu grub

Because Arch is a rolling release, this command also pulls in any other pending updates. If you want to update only GRUB and nothing else (rare, but sometimes necessary on production systems), use:

sudo pacman -S grub

After the package updates, regenerate the configuration:

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

Then reinstall the bootloader to disk. For UEFI:

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

For Legacy BIOS:

sudo grub-install --target=i386-pc /dev/sda

Arch's GRUB setup defaults to installing the EFI binary into /boot rather than a separate /boot/efi partition. If your ESP is mounted elsewhere, adjust the --efi-directory flag accordingly. The Arch Wiki's GRUB page documents several ESP mount configurations worth checking if your layout differs from the default.

Manjaro, EndeavourOS, and other Arch derivatives follow the same commands. Some of them ship update-grub as a convenience wrapper, but grub-mkconfig -o /boot/grub/grub.cfg works everywhere and removes any ambiguity about which config file is being written.

Reinstalling GRUB from a Live USB When Your System Won't Boot

Image source: Bing (Web (fair-use with source credit))

Sometimes the upgrade goes wrong. Maybe the new GRUB binary can't find your root partition. Maybe a Windows update overwrote the EFI boot entry.

Maybe you installed to the wrong disk. Whatever the cause, you're staring at a grub rescue> prompt or a black screen.

The fix is a chroot recovery from a live USB. It works on every major distribution.

Step 1: Boot from a live USB.

Use any Linux live USB that matches your installed distribution's architecture (64-bit for modern systems). Ubuntu, Fedora, and Arch ISOs all work. Boot into the live environment, not the installer.

Step 2: Identify and mount your partitions.

sudo fdisk -l

Find your root partition and your boot partition (if separate). Then mount them:

sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi   # UEFI systems only

If you have a separate /boot partition, mount it at /mnt/boot before mounting the ESP.

Step 3: Bind-mount the virtual filesystems.

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

These give the chroot environment access to hardware devices, process information, and kernel interfaces.

Step 4: Chroot into your installed system.

sudo chroot /mnt

Your prompt changes. You're now operating inside your installed system, not the live environment.

Step 5: Reinstall and reconfigure GRUB.

For UEFI:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=ubuntu
grub-mkconfig -o /boot/grub/grub.cfg

For Legacy BIOS:

grub-install --target=i386-pc /dev/sda
grub-mkconfig -o /boot/grub/grub.cfg

Step 6: Exit and reboot.

exit
sudo umount -R /mnt
sudo reboot

Remove the live USB when prompted. Your system should boot normally.

Image 3: A Linux live USB boot menu showing options to try or install the distribution.

If you're on an encrypted LUKS setup, add one extra step before the chroot: open the encrypted volume with cryptsetup open /dev/sda2 cryptroot, then mount /dev/mapper/cryptroot at /mnt. The chroot will then have access to your encrypted root and can reinstall GRUB normally.

Dual-Boot Specifics: Keeping Windows and Other OS Entries Alive

Dual-boot setups add a layer of fragility to any GRUB upgrade. Windows updates are notorious for resetting the UEFI boot order or overwriting the EFI boot entry entirely. Linux kernel updates can sometimes cause OS-Prober to stop detecting Windows.

Before upgrading GRUB on a dual-boot system, do two things:

Disable Windows Fast Startup (in Windows Power Options). This feature leaves the NTFS partition in a hibernated state, which can prevent Linux from mounting it and cause OS-Prober to skip it.
Back up your current grub.cfg so you can compare entries afterward:

sudo cp /boot/grub/grub.cfg /boot/grub/grub.cfg.backup

If Windows disappears from the GRUB menu after the upgrade:

First, check whether OS-Prober is enabled. On Ubuntu and Debian, it's often disabled by default. Edit /etc/default/grub and make sure this line is either absent or commented out:

#GRUB_DISABLE_OS_PROBER=false

Set it to false (meaning "don't disable it"), then regenerate the config:

sudo update-grub

On Fedora, OS-Prober is usually enabled by default through the grub2-tools-minimal package. If Windows still doesn't appear, manually verify that the Windows EFI partition is mounted and readable:

sudo ls /boot/efi/EFI/Microsoft/Boot/

If that directory exists with files inside it, the partition is fine and the issue is OS-Prober configuration. If it's empty or missing, Windows may have corrupted its own EFI entry, and you'll need to repair it from a Windows recovery disk first.

For Linux + Linux dual boots, each distribution's GRUB installation can overwrite the other's. The standard practice is to let one distribution "own" GRUB and use os-prober to chainload the other. If you reinstall GRUB on the secondary distribution, it becomes the primary bootloader, and you'll need to update its configuration to detect the first distribution.

Image source: Bing (Web (fair-use with source credit))

Image 4: A disk partitioning layout showing separate partitions for Linux and Windows in a dual-boot configuration.

Secure Boot Complications and How to Handle Them

Secure Boot adds a verification layer between your firmware and GRUB. The firmware checks that GRUB is signed by a trusted key before executing it. This means a standard GRUB upgrade can fail silently if the new binary isn't properly signed.

How to tell if Secure Boot is active:

mokutil --sb-state

If it returns "SecureBoot enabled," you're dealing with Secure Boot constraints.

The standard chain on most distributions is:

Firmware → Microsoft UEFI CA → Shim (signed bootloader) → GRUB → Linux kernel

Shim is a small signed bootloader that acts as a bridge between Microsoft's keys (which most firmware trusts by default) and GRUB. When you upgrade GRUB on a Secure Boot system, you're replacing the GRUB binary that Shim loads. As long as that binary is signed with a key that Shim trusts (usually the distribution's own key), everything works.

If GRUB fails to load after an upgrade on a Secure Boot system:

The new binary may not be signed, or the signature may not match what Shim expects. On Ubuntu and Fedora, the signed GRUB packages are grub-efi-amd64-signed and grub2-efi-x64 (which includes signed binaries by default). Make sure you're upgrading the signed variant, not the unsigned one.

If you've compiled GRUB from source, you'll need to sign it yourself using a Machine Owner Key (MOK) and enroll that key in your firmware through mokutil. This is an advanced process documented in the Arch Wiki and on the GNU GRUB manual's Secure Boot section.

When all else fails and you need to boot immediately:

You can temporarily disable Secure Boot in your firmware settings. This lets any GRUB binary load without signature verification. It's a reasonable troubleshooting step, but don't leave it disabled permanently if you rely on Secure Boot as a security boundary.

Common Mistakes That Break Your Bootloader

Most GRUB failures after an upgrade come down to a handful of repeatable errors. Here's what goes wrong and how to avoid it.

Installing to the wrong disk.

grub-install /dev/sdb when your system boots from /dev/sda writes the bootloader to a disk the firmware will never check. Always verify your boot disk with lsblk or efibootmgr -v before running grub-install.

Forgetting to regenerate grub.cfg.

Upgrading the GRUB package updates the bootloader binary, but your configuration file still points to old kernel versions and settings. Without running grub-mkconfig or update-grub, you'll boot into a stale menu or miss new kernel entries entirely.

Mixing UEFI and Legacy targets.

Running grub-install --target=i386-pc on a UEFI system (or vice versa) creates a bootloader that your firmware can't execute. Check your boot mode first and match the target flag.

Not mounting the EFI System Partition.

On UEFI systems, grub-install needs write access to the ESP. If it's not mounted at /boot/efi (or wherever your distribution expects it), the install will fail or write to the wrong location.

Overwriting custom menu entries.

If you've added manual entries to /boot/grub/custom.cfg or directly edited grub.cfg, a grub-mkconfig run will overwrite them. Put custom entries in /etc/grub.d/40_custom instead, which grub-mkconfig incorporates into the generated config without overwriting.

Ignoring the initramfs.

GRUB loads the kernel and initramfs together. If you've upgraded your kernel but the initramfs hasn't been regenerated, GRUB will hand off to a kernel that can't mount your root filesystem. On Debian and Ubuntu, run sudo update-initramfs -u.

On Fedora, run sudo dracut --regenerate-all --force.

How to Verify the Upgrade Worked and Roll Back If Needed

After rebooting, confirm the new GRUB version is actually running. From a terminal:

grub-install --version

Compare this to the version you expected. If it hasn't changed, the package didn't update properly, or your distribution is holding it back.

You can also check the GRUB environment block for boot count and default entry state:

grub-editenv list

If the system boots but something's wrong with entries or configuration, compare against your backup:

diff /boot/grub/grub.cfg /boot/grub/grub.cfg.backup

To roll back on Debian or Ubuntu, pin the previous GRUB package version:

sudo apt install grub2-common=2.06-3ubuntu1

Replace the version string with whatever apt reports as the previous install. On Fedora, use sudo dnf downgrade grub2-efi-x64. Arch users can pull older packages from the package cache at /var/cache/pacman/pkg/.

Frequently Asked Questions

Will updating GRUB delete my custom menu entries?

Only if you edited grub.cfg directly. Place custom entries in /etc/grub.d/40_custom and they survive regeneration.

How do I know if I need to upgrade GRUB?

Check your current version with grub-install --version. Compare it against what your distribution's package manager offers. Upgrade only if the newer version fixes a specific problem you're experiencing.

Is it safe to update GRUB remotely on a server?

It's risky. Have console access (IPMI, iLO, or a cloud provider's recovery console) ready. A failed GRUB update on a headless server without physical access means a support ticket or a trip to the data center.

Do I need to update GRUB when I update the kernel?

No, but you should regenerate the configuration with grub-mkconfig or update-grub so the new kernel appears in the boot menu.

Can I upgrade GRUB from the GRUB command line?

No. The grub> rescue prompt doesn't have write access to your system partitions. You need to boot into a working OS or use a live USB to upgrade and reinstall GRUB properly.