Skip to content

Instantly share code, notes, and snippets.

@yorickdowne
Created May 13, 2026 06:47
Show Gist options
  • Select an option

  • Save yorickdowne/0d5e7daf8e69925f8acfc6af6b5aecac to your computer and use it in GitHub Desktop.

Select an option

Save yorickdowne/0d5e7daf8e69925f8acfc6af6b5aecac to your computer and use it in GitHub Desktop.
Handling multiple EFI partitions during Debian upgrade

The issue

Some custom installations of Debian may have more than one EFI System Partition, ESP. Debian only upgrades the ESP mounted to /boot/efi when switching Debian major versions, which can lead to boot failures. OVH for example deployed Debian on mdadm raid this way, until the 12th of November 2025, when they switched to raid1 ESP for fresh Debian 13 installations.

If yours is a standard Debian install, you have one ESP and a Debian upgrade will work without issue.

If you or your provider installed Debian with multiple ESPs, read on for a way to handle this.

Workaround

In an mdadm two-disk setup with two EFI partitions, only one of the two EFI partitions is being updated to a new grub version, the one mounted to /boot/efi.

On reboot, if the ESP (EFI System Partition) still on the old grub version ends up as the primary boot EFI, you'll get dumped into BIOS or EFI shell. This is a "longstanding hole in grub-efi" according to maintainers.

If you do end up in BIOS, launch EFI shell. Then look at fs0: and fs1:, and choose the one with the newer shimx64.efi (SecureBoot) or grubx64.efi (no SecureBoot), and execute that. The 2.14 grubx64.efi is around 2.8M in size, 2.12 is around 2.6M, and 2.06 around 4M.

To verify whether the second EFI partition was updated:

Run lsblk, see the partition mounted to /boot/efi, e.g. nvme0n1p1. There'll be a matching partition on the second drive, also vfat or fat32 or fat16, e.g. nvme1n1p1.

Caution You may have multiple ESP partitions because you have more than one Debian installed. Only upgrade the grub version on the ESP partitions that belong to this copy of Debian! If you use signed versions of grub-efi, then there is a file where you can check: The UUID of the partition that holds /boot/grub is linked in <ESP-partition>/EFI/debian/grub.cfg. Verify the entry in grub.cfg against the UUID of that partition.

There is no guarantee that /boot/efi is mounted on the first drive, it might be mounted to any drive. Identify the EFI partitions on all drives, and inspect them. This example assumes two drives; adjust likewise for 3 and more drives.

Mount it

sudo mkdir -p /mnt/second-efi
sudo mount /dev/<second-efi-partition> /mnt/second-efi

Look at what the boot entry is called. It should be debian. Make a note.

ls /boot/efi/EFI

Install binutils sudo apt install binutils

Check EFI strings on both, assuming debian here, adjust to where yours actually is:

strings /boot/efi/EFI/debian/grubx64.efi | grep -i grub | tail -6
strings /mnt/second-efi/EFI/debian/grubx64.efi | grep -i grub | tail -6

If both show the same grub version, move on to reboot.

If one of them is old, continue here.

A healthy grub looked like this on my system:

grub_diskfilter_read_node
grub,5,Free Software Foundation,grub,2.12,https://www.gnu.org/software/grub/
grub.debian,5,Debian,grub2,2.12-9+deb13u1,https://tracker.debian.org/pkg/grub2
grub.debian13,1,Debian,grub2,2.12-9+deb13u1,https://tracker.debian.org/pkg/grub2
grub.peimage,2,Canonical,grub2,2.12-9+deb13u1,https://salsa.debian.org/grub-team/grub/-/blob/master/debian/patches/secure-boot/efi-use-peimage-shim.patch
&Debian Secure Boot Signer 2022 - grub20

An old grub that hadn't been updated looked like this on my system:

        source $prefix/grub.cfg
        source $cmdpath/grub.cfg
normal (memdisk)/grub.cfg
grub,4,Free Software Foundation,grub,2.06,https://www.gnu.org/software/grub/
grub.debian,4,Debian,grub2,2.06-13+deb12u1,https://tracker.debian.org/pkg/grub2
&Debian Secure Boot Signer 2022 - grub20

Be very sure where your grubx64.efi is. The next command will always succeed, but if the --bootloader-id is wrong, it'll just create another entry that never gets used. I am assuming debian here. The correct --bootloader-id is in /etc/default/grub as GRUB_DISTRIBUTOR. Also be careful of the target: This is for x64 Intel/AMD. Adjust for ARM64.

Also be very sure of which EFI directory has the old grub. It should be /mnt/second-efi, but verify and set --efi-directory to the old one.

case "$(dpkg --print-architecture)" in \
  amd64) efi_target="x86_64-efi" ;; \
  arm64) efi_target="arm64-efi" ;; \
  *) \
    echo "Unsupported architecture" \
    ;; \
esac
sudo grub-install --target=$efi_target --efi-directory=/mnt/second-efi --bootloader-id=debian --recheck

Verify once more on both. I am again assuming debian

strings /boot/efi/EFI/debian/grubx64.efi | grep -i grub | tail -6
strings /mnt/second-efi/EFI/debian/grubx64.efi | grep -i grub | tail -6

Both entries should now show the new grub version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment