How to Fix GRUB After a BIOS/UEFI Mismatch on an Ubuntu Server

A BIOS/UEFI GRUB mismatch happens when the GRUB bootloader is installed or maintained for one firmware mode (legacy BIOS, GRUB target i386-pc) while the server actually boots in the other (UEFI, GRUB target x86_64-efi), or when updates keep writing GRUB to a disk or EFI System Partition (ESP) that the firmware no longer uses. The Linux files are intact, but the server stops at the firmware, at a grub> prompt or at a missing-root error. The fix is to confirm which mode the server is meant to boot in, mount the installed system from a rescue environment, chroot into it and reinstall GRUB for that mode on the correct disk.

This guide covers x86-64 Ubuntu servers that boot with GRUB, on a Noiz VPS with full virtualisation (KVM) or on a dedicated or colocated server. Converting between BIOS and UEFI, repartitioning and other distributions are outside its scope. A container VPS (OpenVZ or LXC) has no bootloader of its own, so this guide does not apply to it.

Last reviewed: 13 October 2026, against the current GNU GRUB and Ubuntu releases. This guide is written for Noiz hosting and is kept current against GRUB and Ubuntu. It complements, and does not replace, the official documentation linked below.

Official Documentation Reference

• GNU GRUB: BIOS installation: embedding space on MBR disks and the BIOS Boot Partition on GPT disks.
• Ubuntu grub-install manual (Ubuntu 26.04 LTS): targets, ESP and Secure Boot options. Select your own release from the page header.
• Ubuntu Secure Boot: the signed shim, GRUB and kernel chain.
• Ubuntu efibootmgr manual (Ubuntu 26.04 LTS): UEFI boot entries, BootCurrent, BootOrder and BootNext.
• Ubuntu mount manual (Ubuntu 26.04 LTS) and Linux ext4 mount options: read-only mounts and journal replay.

Prerequisites

• Console access that works without the network. SSH cannot help when the failure happens before Linux starts. On a Noiz VPS, open the VNC console from your VPS panel (SolusVM or Virtualizor). On a dedicated or colocated server, use its out-of-band management console.
• A rescue environment of the same architecture, booted in the same firmware mode as the installed system if possible: Virtualizor rescue mode, or an Ubuntu ISO mounted as described in How to Manually Install an OS from ISO in SolusVM (boot it in its “try” or rescue mode, not the installer).
• A recent backup of your data. A copy of boot files is not a data backup.
• Root access and comfort at the command line. You need the disk identifiers explained in How to Find the UUID of a Disk or Partition on Linux.

If Noiz manages your server, do not change its boot configuration yourself: contact Noiz support.

Before writing anything, save the exact console error and a copy of /etc/fstab, /etc/default/grub and the output of the commands in step 1 somewhere off the server. Never format an ESP, force GRUB into a disk without proper embedding space, or write raw sectors as a generic repair. Run each step deliberately and stop on any unexpected error.

1. Identify the Boot Mode and Where Boot Fails

Four facts decide the repair:

• Firmware: whether the server is meant to boot in BIOS or UEFI mode, and which disk or UEFI boot entry it selects.
• Storage: the system disks, their partition table (GPT or MBR), the root filesystem, any separate /boot, and either the BIOS Boot Partition (BIOS on GPT) or the ESP (UEFI).
• GRUB: which GRUB platform packages are installed and which disks their updates write to.
• Kernel: whether the boot configuration points at the right kernel, root filesystem and initramfs.

If the installed system still boots, or once you are inside it in step 3, these checks are read-only:

if [ -d /sys/firmware/efi ]; then
    printf 'Current kernel booted through UEFI\n'
else
    printf 'Current kernel booted through BIOS (no EFI interface)\n'
fi
lsblk -e 7 -o NAME,PATH,SIZE,MODEL,SERIAL,TYPE,FSTYPE,PTTYPE,PARTTYPE,MOUNTPOINTS
findmnt --mountpoint /
findmnt --mountpoint /boot
findmnt --mountpoint /boot/efi
sudo blkid
dpkg-query -W -f='${binary:Package}\t${db:Status-Abbrev}\t${Version}\n' \
    grub-pc grub-pc-bin grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed shim-signed

If your rescue image rejects the MOUNTPOINTS column, use MOUNTPOINT instead. A missing mount or package returns an error; that is expected, because /boot need not be separate and not every package is required. The key line is which of grub-pc (BIOS) and grub-efi-amd64 (UEFI) is installed. Ubuntu allows only one of the two, and it decides which loader package updates reinstall. The -bin and -signed packages only supply files, so having them for the other platform is not a fault on its own. If the server boots in BIOS mode but grub-efi-amd64 is the installed one, or the other way round, updates are maintaining the wrong loader: that is the mismatch this guide repairs.

On UEFI, sudo efibootmgr -v lists the boot entries. Match each entry’s partition identifier and loader path to the real ESP, not just its name. Check Secure Boot in the firmware settings or with mokutil --sb-state; a missing tool or variable does not mean Secure Boot is off.

In a rescue environment, these checks describe the rescue system until you enter the chroot in step 3. Work out the installed system’s intended mode from your records, the firmware settings and the boot files on its disks.

Use the console error to locate the failure:

• No bootable device or loader found: check the firmware’s boot selection and the selected disk or ESP.
• grub> or grub rescue> prompt, or a missing module: check the GRUB platform, the configuration path and the boot filesystem.
• Kernel starts but cannot find root: check filesystem identifiers, storage drivers, RAID, LVM or encryption, and the initramfs.
• Linux starts but SSH fails: this is a networking or service problem, not GRUB.

If you cannot identify the disks with confidence, or a disk reports errors, stop before writing anything.

2. Mount the Installed System from Rescue

Skip to step 4 if you are working inside the running installed system with all its filesystems mounted. If the rescue system offers to repair boot automatically or to assemble and mount disks for you, decline until you have identified the target disks.

Map the disks through any RAID, LVM or encryption layers to the root and boot filesystems, and activate only what you need. Do not force-assemble or create arrays, or recreate encryption headers. Encrypted /boot, unusual filesystems and degraded storage need layout-specific recovery guidance.

Inspect read-only first

This example is for an ext4 root filesystem only. A plain ro mount of ext4 can still replay its journal, so the example uses ro,noload, which skips the replay but can show an inconsistent view after an unclean shutdown. Stop on filesystem errors.

RESCUE_ROOT='/mnt/recovered-system'
ROOT_DEVICE='/dev/REPLACE_WITH_VERIFIED_ROOT_FILESYSTEM'
sudo mkdir -p "$RESCUE_ROOT" &&
sudo mount -t ext4 -o ro,noload "$ROOT_DEVICE" "$RESCUE_ROOT" &&
findmnt --mountpoint "$RESCUE_ROOT" &&
cat "$RESCUE_ROOT/etc/os-release" "$RESCUE_ROOT/etc/fstab"

Confirm this is the right installation and compare the identifiers in its fstab with the lsblk and blkid output. Copy anything you want to preserve.

Remount with write access

Unmount the inspection mount, then mount root and the boot filesystems normally, parent first. Do not carry noload into the repair. Replace the placeholders with the devices you verified against fstab:

sudo umount -R "$RESCUE_ROOT"
sudo mount "$ROOT_DEVICE" "$RESCUE_ROOT"
# Only if /boot is a separate filesystem:
sudo mount /dev/REPLACE_WITH_VERIFIED_BOOT_FILESYSTEM "$RESCUE_ROOT/boot"
# Only for UEFI:
sudo mount /dev/REPLACE_WITH_VERIFIED_ESP "$RESCUE_ROOT/boot/efi"
findmnt --mountpoint "$RESCUE_ROOT/boot"
findmnt --mountpoint "$RESCUE_ROOT/boot/efi"

Mount any separate /usr as well. If /boot is separate but not mounted, the repair writes to an unused directory on the root filesystem and the server still fails to boot.

3. Enter the Installed System with chroot

Bind the rescue system’s runtime directories into the target. This subshell stops on the first failure:

(
    set -e
    for tree in dev proc sys run; do
        sudo mount --rbind "/$tree" "$RESCUE_ROOT/$tree"
        sudo mount --make-rslave "$RESCUE_ROOT/$tree"
    done
)

Continue only if every mount succeeded. Then enter the installed system:

sudo chroot "$RESCUE_ROOT" /bin/bash

You are now root inside the installed system, so the commands in step 4 have no sudo. Run the dpkg-query command from step 1 again: it now shows the installed system’s packages. /sys, uname -r and firmware variables still describe the rescue system. If packages must be downloaded, check that DNS works inside the chroot first.

4. Reinstall GRUB for the Intended Boot Mode

Follow only the branch that matches the mode you confirmed in step 1. Use the target disks, never the rescue disk.

For a BIOS installation

GRUB needs somewhere to put its core image. On GPT, that is a BIOS Boot Partition of the correct type (not the FAT ESP) holding no data; on MBR, it is the gap before the first partition. If neither exists, a layout change is a separate planned job: do not use --force or blocklists to get round it.

Check what the package manager would change, then install or reinstall the BIOS package:

apt-get -s install grub-pc
apt-get install --reinstall grub-pc

Read the simulated plan first: package installation can itself write the bootloader. Installing grub-pc removes grub-efi-amd64 if it is present, because only one of them can maintain the loader; the UEFI -bin and -signed packages can stay. When prompted, or later with dpkg-reconfigure grub-pc, select each whole system boot disk and nothing else (not partitions, RAID array devices, rescue media or data disks). Then install to each disk explicitly and check it:

BOOT_DISK='/dev/disk/by-id/REPLACE_WITH_VERIFIED_SYSTEM_DISK'
readlink -f "$BOOT_DISK"
test -b "$BOOT_DISK" &&
grub-install --target=i386-pc "$BOOT_DISK" &&
update-grub &&
grub-script-check /boot/grub/grub.cfg

Compare the resolved path, model, serial and size with your inventory before running grub-install. The i386-pc target is correct for BIOS even on 64-bit servers. Repeat for every boot disk in a mirror, because RAID does not copy boot code that sits outside the mirrored partitions. A clean grub-script-check only means the configuration’s syntax is valid.

For a UEFI installation

Confirm that the FAT ESP is mounted at /boot/efi (findmnt --mountpoint /boot/efi) and is the partition the firmware uses. EFI variables must be accessible, which means the rescue system itself must have booted in UEFI mode.

Signed boot chain (standard Ubuntu installation). Ubuntu installs the signed shim and GRUB on UEFI servers, and this is the repair to use whether or not Secure Boot is currently on. Check the plan, then reinstall the UEFI packages:

apt-get -s install grub-efi-amd64 shim-signed grub-efi-amd64-signed
apt-get install --reinstall grub-efi-amd64 shim-signed grub-efi-amd64-signed

Installing grub-efi-amd64 removes grub-pc if it is present, so that updates maintain the UEFI loader from now on.

Ubuntu’s package scripts rewrite the ESP only if GRUB was previously installed for UEFI on this system. If the server was until now maintained as BIOS, or the ESP still lacks the loader afterwards, install the signed loader explicitly:

findmnt --mountpoint /boot/efi &&
grub-install --target=x86_64-efi --efi-directory=/boot/efi \
    --bootloader-id=ubuntu --uefi-secure-boot --no-extra-removable &&
update-grub &&
grub-script-check /boot/grub/grub.cfg &&
efibootmgr -v

Never answer a Secure Boot refusal by using --force, swapping in an unsigned loader or turning validation off.

Unsigned GRUB (only if your boot policy is Secure Boot off). If the server is deliberately run with Secure Boot disabled and you want GRUB without shim, replace --uefi-secure-boot in the command above with --no-uefi-secure-boot. A rescue session with Secure Boot off does not tell you what the installed system’s policy is.

For either path, check that EFI/ubuntu on the correct ESP contains the loader files and that efibootmgr -v shows an entry pointing to them, near the front of BootOrder. --no-extra-removable leaves the fallback path EFI/BOOT/BOOTX64.EFI alone, because it may belong to another loader; change it only as a planned step. --no-nvram skips creating the boot entry and only works if an existing entry or the fallback path already reaches the repaired files. If the server has more than one ESP, update each one the firmware may use.

5. Leave Rescue and Verify the Boot

Before restarting, confirm that /boot/grub/grub.cfg refers to the intended root filesystem identifier, kernel and initramfs. Inside a chroot, uname -r shows the rescue kernel, so do not use it to choose a kernel for an initramfs rebuild. Keep a known-working older kernel installed.

Leave the chroot, then unmount everything under the target:

exit

sudo umount -R "$RESCUE_ROOT"

If a mount is busy, find what is using it rather than forcing it. Close only the RAID, LVM or encryption mappings you opened for this recovery.

Remove the rescue media (or turn rescue mode off in your VPS panel), boot from the intended disk or UEFI entry with the console open, and check:

• The firmware mode is the one you intended; on UEFI, efibootmgr -v shows BootCurrent on the expected entry.
• The running kernel, root and /boot mounts are the repaired installation’s.
• Your services start and your applications work.
• The saved GRUB install targets (step 6) match the route this boot used.

If the boot fails, return to rescue, record the new error and reverse only the change you made, against the same verified disk.

6. If the Server Fails to Boot Again After a Repair

If the server boots after a repair but fails again after the next update or restart, the usual cause is that the firmware boots a different disk or UEFI boot entry from the one GRUB updates maintain. Compare the route the working boot used with the route the failing boot used before reinstalling anything.

Possible cause	How to check
Firmware boots a different mode	[ -d /sys/firmware/efi ] on the working boot, plus the firmware’s boot mode setting.
Firmware boots a different disk or UEFI entry	efibootmgr -v (entry partition identifier and loader path) against lsblk serials and blkid PARTUUIDs. Entry names such as ubuntu are not unique.
A one-time choice hid the default	efibootmgr -v: compare BootCurrent with BootOrder and any BootNext.
Updates install GRUB to the wrong place	debconf-show grub-pc or debconf-show grub-efi-amd64 (the install_devices lines), and grep -i 'Installing for' /var/log/apt/term.log.
Updates write to an unmounted /boot or ESP	findmnt --mountpoint /boot and findmnt --mountpoint /boot/efi at update time, against /etc/fstab.
Loader reads stale configuration	Location and timestamp of the grub.cfg that loader reads, and the root and kernel it names.

A BootNext value applies to one boot and is then deleted, so a successful one-time boot menu choice does not prove the default works.

Fix the cause you can demonstrate: the saved install targets, the mount definitions, the firmware boot order, or a second disk that was never maintained. For example, if the active UEFI entry points to an old ESP, updating a different ESP cannot fix it. Keep other operating systems and recovery entries, and record each old and new setting so you can reverse that one change.

A server deliberately set up to boot in both modes can have only one of grub-pc and grub-efi-amd64 installed, so updates maintain only that path and you must reinstall the other loader yourself after GRUB updates. Do not remove packages or rewrite every disk just to simplify the package list.

To confirm the repair lasts:

1. Boot through the normal default, without the boot menu, and check mode, kernel, mounts and services.
2. Restart again the same way.
3. At the next GRUB or kernel update, check where it installed and verify the following boot.
4. If the server relies on redundant disks, test booting from each one separately, in a maintenance window with console access. A healthy array does not prove either disk can boot alone.

If the failure returns, compare the new error with your record of the working boot before writing anything again. For release upgrades, see How to Upgrade Ubuntu Server to a New Release over SSH Safely.

If Noiz manages your server, or you would rather have it repaired for you, contact Noiz support with the time of the failure, the exact console error and what changed just before it. Never include passwords or private keys in a ticket.