---
title: "How to Fix GRUB After a BIOS/UEFI Mismatch on an Ubuntu Server"
description: "Fix an Ubuntu server that will not boot after a BIOS/UEFI GRUB mismatch: identify the boot mode, chroot from rescue and reinstall GRUB for the right target."
url: "https://docs.noiz.ie/linux/how-to-fix-grub-after-a-bios-uefi-mismatch-on-an-ubuntu-server/"
section: "How to Linux"
categories:
  - "Server Administration > Linux Basics"
tags:
  - "grub"
  - "boot"
  - "uefi"
  - "ubuntu"
  - "recovery"
  - "linux"
last_reviewed: "13 October 2026, against the current GNU GRUB and Ubuntu releases"
---

# 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](https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html): embedding space on MBR disks and the BIOS Boot Partition on GPT disks.
- [Ubuntu grub-install manual (Ubuntu 26.04 LTS)](https://manpages.ubuntu.com/manpages/resolute/man8/grub-install.8.html): targets, ESP and Secure Boot options. Select your own release from the page header.
- [Ubuntu Secure Boot](https://documentation.ubuntu.com/security/security-features/platform-protections/secure-boot/): the signed shim, GRUB and kernel chain.
- [Ubuntu efibootmgr manual (Ubuntu 26.04 LTS)](https://manpages.ubuntu.com/manpages/resolute/man8/efibootmgr.8.html): UEFI boot entries, `BootCurrent`, `BootOrder` and `BootNext`.
- [Ubuntu mount manual (Ubuntu 26.04 LTS)](https://manpages.ubuntu.com/manpages/resolute/man8/mount.8.html) and [Linux ext4 mount options](https://docs.kernel.org/admin-guide/ext4.html#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](/solusvm/how-to-access-your-vps-via-the-vnc-console-in-solusvm/) or [Virtualizor](/virtualizor/how-to-access-your-vps-via-the-vnc-console-in-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](/virtualizor/how-to-start-your-vps-in-rescue-mode-using-virtualizor/), or an Ubuntu ISO mounted as described in [How to Manually Install an OS from ISO in SolusVM](/solusvm/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](/server-administration/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](/getting-started/how-to-contact-noiz-for-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:

```bash
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.

```bash
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`:

```bash
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:

```bash
(
    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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
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:

```bash
exit
```

```bash
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](/linux/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](/getting-started/how-to-contact-noiz-for-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.

---
Source: https://docs.noiz.ie/linux/how-to-fix-grub-after-a-bios-uefi-mismatch-on-an-ubuntu-server/