Restore GRUB2 after UEFI/BIOS switch and lost bootloader configuration

The focus keyword „RESTore GRUB2“ is central when a system fails to boot after a UEFI/BIOS change or due to loss of the bootloader configuration. This article provides administrators, system engineers and operators with a practical, step‑by‑step guide for diagnosis, repair and verification — including common causes, risks and fallback strategies.

Why does boot loss occur? Causes explained briefly

Before we get into the hands‑on procedures: it helps to know the common causes so repairs remain targeted. The three main categories are firmware changes, partitioning/ESP problems, and initramfs/decryption failures.

1. UEFI/BIOS mode switch

UEFI (Unified Extensible Firmware Interface) is the modern firmware interface; BIOS or Legacy refers to the older MBR‑based boot method. Switching from UEFI to Legacy or vice versa can invalidate firmware boot entries (NVRAM), because UEFI systems rely on an EFI System Partition (ESP) with .efi files, while Legacy GRUB expects the MBR or a BIOS‑boot partition.

2. Corrupted or wrong EFI System Partition (ESP)

The ESP is a small FAT32 partition with the type code EFI System (GPT ef00). If it has been deleted, overwritten with Windows or mounted incorrectly, the GRUB‑EFI binaries (/EFI/<Vendor>/grubx64.efi) will be missing and the system will not boot.

3. Initramfs, encrypted root or kernel mismatch

GRUB loads the kernel and the initramfs (initial RAM filesystem). If the initramfs does not include the correct modules for LVM/LUKS or file systems, the boot fails after GRUB. Likewise, a kernel upgrade without regenerating the initramfs for encrypted root volumes leads to systems that cannot be decrypted.

Preparation: prerequisites, risks and required tools

Before you intervene, check: Do you have a rescue environment (Live‑USB), access to the firmware setup, backups of the ESP and, if applicable, LUKS headers? Tools: a current live distribution with grub-install/grub‑efi, efibootmgr, lsblk, blkid, parted or gdisk, mount, chroot, and for RHEL/CentOS environments dracut.

Key risks:

• Further overwriting the ESP, which can render other operating systems (Windows) unusable.
• Missing LUKS header backups for encrypted roots — in that case RESToration is considerably more complex.
• Targeting the wrong device with grub-install (e.g. a partition instead of the whole disk) can damage the boot device.

Diagnosis: checking system state (Live‑USB)

Start from a Live‑USB (preferably the same architecture: x86_64). Mount drives read‑only for initial analysis.

Important inspection commands and what they mean

Partitions and device overview:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINT,LABEL

Partition types and GPT codes:

sudo parted -l

ESP/EFI marking and UUID:

sudo blkid | grep -i efi
# oder gezielt
sudo lsblk -f /dev/nvme0n1p1

EFI entries in firmware (NVRAM):

sudo efibootmgr -v

If efibootmgr fails: the firmware may be running in BIOS/Legacy mode or efivarfs is not mounted. Check /sys/firmware/efi/exists — if this directory exists the live environment is already running in UEFI mode.

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

Recovery scenarios: step‑by‑step

We distinguish the three most common practical cases and perform the necessary steps for each: (A) UEFI: reinstall GRUB‑EFI, (B) BIOS/Legacy: install GRUB into the MBR, (C) switch UEFI↔Legacy or NVRAM defective: removable fallback.

A. UEFI: Reinstall GRUB2 (standard case)

Goal: write the EFI binaries to the ESP, create or correct an NVRAM entry, generate grub.cfg.

1. Boot the live environment in UEFI mode (important for efibootmgr).
2. Mount root, /boot and the ESP. Replace /dev/sdXn with your device nodes.

sudo mount /dev/sdX2 /mnt            # root-Partition
sudo mount /dev/sdX1 /mnt/boot/efi    # EFI System Partition, FAT32
# Falls /boot eine eigene Partition hat:
# sudo mount /dev/sdX3 /mnt/boot
# Bind-Mounts für chroot
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo mount --bind /run /mnt/run

Chroot so that grub-install runs in the system context (important for distribution-specific paths).

sudo chroot /mnt /bin/bash
# innerhalb des chroots prüfen
mount | grep efi

Install GRUB for UEFI:

# Beispiel für x86_64-UEFI auf Debian/Ubuntu/Fedora
grub-install --target=x86_64-efi --efi-directory=/boot/efi 
  --bootloader-id=GRUB --recheck --no-nvram
# --no-nvram verhindert Änderungen am NVRAM; nutzen Sie es nur bei Bedarf

Why this works: grub-install creates the .efi binary on the ESP (e.g. /boot/efi/EFI/GRUB/grubx64.efi) and optionally creates an NVRAM entry. It can fail if the grub‑efi package is not installed or the architecture does not match (i386 vs x86_64).

Generate the configuration:

# Debian/Ubuntu
update-grub
# RedHat/CentOS
grub2-mkconfig -o /boot/grub2/grub.cfg

If efibootmgr cannot write the boot entry, install the emergency file as the „removable“ path (bootx64.efi):

cp /boot/efi/EFI/GRUB/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI
# BIOS/UEFI-Fallback für viele Firmware-Implementierungen

Exit the chroot and unmount cleanly:

exit
sudo umount -l /mnt/dev /mnt/proc /mnt/sys /mnt/run
sudo umount /mnt/boot/efi
sudo umount /mnt

B. Legacy BIOS: Install GRUB into the MBR

If the system should boot in legacy mode (e.g. older hardware), you must write GRUB traditionally into the MBR.

# Vorbereitungen wie oben: mount /mnt, chroot
# Install GRUB to MBR (example /dev/sda)
grub-install --target=i386-pc /dev/sda --recheck
grub-mkconfig -o /boot/grub/grub.cfg

Note: Modern GPT partition tables may require a small BIOS boot partition (type ef02 in gdisk) for GRUB‑Stage2. Without this partition, grub-install will fail on GPT disks if booting in BIOS mode is intended.

C. UEFI↔Legacy switch, NVRAM defective or limited firmware menu

Some firmwares no longer allow NVRAM entries (too many or defective). In such cases the removable boot path is useful: installed EFI binary under /EFI/BOOT/BOOTX64.EFI. This is robust, but may overwrite existing bootloaders of other operating systems.

# innerhalb des chroot
mkdir -p /boot/efi/EFI/BOOT
cp /boot/efi/EFI/GRUB/grubx64.efi /boot/efi/EFI/BOOT/BOOTX64.EFI

Special cases and troubleshooting

Restore GRUB2 for encrypted root (LUKS)

For a LUKS‑encrypted root (LUKS is the Linux Unified Key Setup) you must open the LUKS volume inside the chroot so that /mnt actually contains the correct root. Important: Have you backed up the LUKS header? Without the header a RESTore is very involved.

# LUKS-Container öffnen (im Live-System, vor dem Mounten)
sudo cryptsetup luksOpen /dev/sdX2 cryptroot
sudo mount /dev/mapper/cryptroot /mnt

After installing grub regenerate the Initramfs (Initramfs is the early RAM filesystem that provides modules for LVM/LUKS):

# Debian/Ubuntu
update-initramfs -u -k all
# RedHat/CentOS
dracut -f

If the wrong kernel‑initramfs combination is installed (e.g. an older kernel), the boot process after GRUB can fail at the initramfs stage.

Error: grub-install reports „cannot find EFI directory“ or „secure boot“

Causes and solutions:

• EFI partition not FAT32 or not mounted: mount it under /boot/efi.
• Secure Boot enabled: either temporarily disable Secure Boot or use signed binaries (shim). Shim is a small, signed program that can load unsigned grubx64.efi when it is enrolled in the MOK‑Store (Machine Owner Key).
• Missing package: on Debian/Ubuntu you need grub‑efi‑amd64 and efibootmgr; on RHEL‑based systems grub2‑efi‑x64.

efibootmgr does not write to NVRAM or entries disappear

Many reasons: firmware bugs, write protection of the NVRAM, or capacity limits. Check whether the firmware deletes entries. As an alternative: use the removable path or set the firmware boot order manually in the UEFI setup.

Validation: How to check whether the recovery was successful

Reboot the system and use the firmware boot menu to test the new entry. For verification on the running system:

# prüft ob System im UEFI-Modus gebootet hat
[ -d /sys/firmware/efi ] && echo "UEFI boot" || echo "Legacy boot"
# efibootmgr zeigt aktive Eintraege
sudo efibootmgr -v
# prüft gültige grub.cfg
sudo test -f /boot/grub/grub.cfg && echo "grub.cfg vorhanden"

Monitor system messages on the first boot (journalctl -b) and watch for steps that fail during root decryption or the mounting of LVM volumes.

Practical checklist: Quick recovery playbook

1. Prepare a live USB with the appropriate architecture (note UEFI/BIOS mode).
2. Important backups: secure ESP snapshot, LUKS header, Grub configuration.
3. Diagnostics: lsblk, parted, blkid, efibootmgr — check whether the ESP exists and is FAT32.
4. Mount, chroot and grub installation according to target mode (UEFI/BIOS).
5. Regenerate initramfs for LUKS/LVM/kernel changes.
6. If efibootmgr does not work: write removable EFI (BOOTX64.EFI).
7. Reboot and validation: firmware boot menu, journalctl -b, check LVM/LUKS status.

Typical pitfalls and how to avoid them

Error 1: mounting the wrong partition (Windows ESP instead of Linux ESP). Avoid: use UUIDs instead of device names (blkid provides UUIDs). Error 2: wrong architecture of the .efi file (i386 vs x86_64). Avoid: use a live image of the target architecture. Error 3: NVRAM full or unstable. Avoid: have the removable fallback ready.

Rollback strategy and prevention

Perform a backup action before any change:

# Back up ESP as image
sudo dd if=/dev/sdX1 of=esp-backup-$(date +%F).img bs=4M status=progress
# Back up LUKS header
sudo cryptsetup luksHeaderBackup /dev/sdX2 --header-backup-file luks-header-$(date +%F).bin

Emergency access: Keep a rescue console and an alternative boot option (e.g., network boot, PXE, or physical KVM) available. Document the original efibootmgr outputs so you can reconstruct entries if needed.

When reinstalling the bootloader won’t help

There are cases where GRUB recovery alone is not sufficient: hardware faults on the boot medium, missing LUKS headers, or a corrupted root filesystem. If disk errors are present, run SMART tests and filesystem checks first; only when physical integrity is ensured should you begin bootloader repairs.

# SMART test
sudo smartctl -a /dev/sda
# Filesystem check ext4 (only unmounted)
sudo fsck.ext4 -f /dev/sdX2

Brief notes on distribution differences

Distributions name paths differently: Debian/Ubuntu uses /boot/grub, RedHat/CentOS /boot/grub2 and different commands for generating the config (update-grub vs grub2-mkconfig). When working inside a chroot, pay attention to the distro-specific paths and installed packages.

Restoring GRUB2: automated recovery script and audit

In larger environments, a verifiable, idempotent recovery script is recommended that only performs diagnostics and mount preparation — the actual grub installation should be performed manually or approved via ticketing. The following example shows a safe validation block that detects the ESP and mode and generates messages for ticketing.

#!/bin/bash
set -euo pipefail
# Simple pre-checks before manual recovery actions
if [ -d /sys/firmware/efi ]; then
  echo "System already booted in UEFI mode"
else
  echo "Live environment is Legacy/BIOS mode"
fi
ESP=$(blkid -t PARTLABEL="EFI System" -o device || true)
if [ -z "$ESP" ]; then
  echo "No ESP found: blkid output:"; blkid | sed -n '1,200p'
  exit 2
fi
UUID=$(blkid -s UUID -o value "$ESP")
echo "ESP device: $ESP UUID: $UUID"
# create a small audit file for ticketing
mkdir -p /var/log/grub-recovery-audit
echo "$(date -Iseconds) - ESP:$ESP UUID:$UUID UEFI:$( [ -d /sys/firmware/efi ] && echo yes || echo no)" 
  >> /var/log/grub-recovery-audit/recovery.log

Why this is useful: The script does not change the system, produces reproducible diagnostic data and forces administrators to manually approve the sensitive grub installation steps.

Secure Boot, shim and MOK workflow

If Secure Boot is active, grub-efi can only run if the .efi binaries are signed or shim is used. Shim is a small bootloader that is recognized by the firmware and then loads unsigned GRUB binaries once a Machine Owner Key (MOK) has been registered in the firmware store.

# Import MOK (in the installed system or chroot)
sudo mokutil --import /path/to/public_key.der
# reboot and enroll the key in the MOK manager during boot

If you need to sign binaries yourself, use sbsign or sign-file (kernel/GRUB). Note: a faulty MOK workflow can completely prevent the system from booting; always test changes first in a VM.

Testing and rollout in an enterprise environment

Set up test lines: An automated validation run with qemu/kvm checks whether a newly created ESP image and a grubx64.efi boot in the firmware simulation. This reduces risk when rolling out to multiple servers.

# Example: quick boot test image with qemu
qemu-system-x86_64 -m 1024 -bios /usr/share/ovmf/OVMF.fd -hda test-disk.img -boot d

In large installations, recovery changes should be managed via configuration management and change control (e.g. Ansible Playbooks that perform only validating checks). Maintain a defined rollback window in case firmware differences show unforeseen effects after the update.

Monitoring, Alerts and Prevention

Automate early warnings: monitor the last successful boot time with an agent, check after kernel updates whether initramfs regeneration succeeded, and validate boot entries after firmware updates. A repository of ESP snapshots facilitates rapid recovery.

Conclusion: systematic, secure, documented

Restoring GRUB2 is reliably achievable if you proceed in a structured way: first diagnosis, then targeted repair for UEFI or BIOS, initramfs regeneration for an encrypted root, and finally validation. Back up ESP snapshots and LUKS headers before any intervention. For production environments, a defined recovery playbook, test automation, and regular checks of the firmware policy are recommended.

When creating internal documentation: record precise device UUIDs, firmware version, and the exact order of steps performed. This information saves time during recurring incidents and assists with root-cause analysis.

Further internal links (examples): Link here to policies for backups of encrypted drives, kernel upgrade policies, or your organization’s disaster recovery playbook to ensure a complete operational workflow.

For this topic, UEFI Bootloader Recovery and GRUB Install Guide are also important. The article places these aspects in context and shows what matters in day-to-day operations.