Skip to content

Instantly share code, notes, and snippets.

@CTXz
Last active June 17, 2025 10:40
Show Gist options
  • Save CTXz/382fcf1204794f114417951c1bf69968 to your computer and use it in GitHub Desktop.
Save CTXz/382fcf1204794f114417951c1bf69968 to your computer and use it in GitHub Desktop.

Fixing GRUB on Mainboards That Only Recognize the Windows Boot Manager

We recently encountered an issue at work where an MSI mainboard refused to accept any GRUB installation. Specifically, the firmware would only list “Windows Boot Manager” in the boot menu, ignoring all other entries. To work around this, we deleted the original Windows Boot Manager entry and created a new one pointing to Ubuntu’s GRUB bootloader instead of Microsoft’s loader. This gist documents the steps we took to implement that workaround.

The Problem

The problematic device was a custom-built PC with a fairly recent MSI mainboard (13th Gen Intel). It had two NVMe drives: one with Windows, and the other with Ubuntu. Ubuntu was installed using the automatic "Install alongside Windows" option. Normally, this option produces a working GRUB setup that automatically detects other operating systems using os-prober. In this case, however, the system booted straight into Windows after installation.

At first, this seemed like an easy fix: just change the boot priority in the UEFI settings from “Windows Boot Manager” to the newly created “Ubuntu” entry, right?

This is where the actual issue revealed itself. The UEFI firmware didn’t list an Ubuntu entry at all. It was completely unaware of GRUB.

You see, when Ubuntu installs GRUB in UEFI mode, it performs two actions:

  1. It installs GRUB to the EFI System Partition (ESP), typically under EFI/ubuntu/.
  2. It creates a new boot entry in the firmware’s NVRAM using efibootmgr, pointing to the GRUB binary in EFI/ubuntu/.

You can list all existing EFI boot entries using:

sudo efibootmgr -v

This command shows detailed information stored in the system’s UEFI firmware, including boot order and the loader paths associated with each entry.

Here’s an example output:

BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0001,0000

Boot0000* Windows Boot Manager
  HD(1,GPT,b25a9f38-...,0x800,0x82000)/File(\EFI\Microsoft\Boot\bootmgfw.efi)

Boot0001* Ubuntu
  HD(1,GPT,b25a9f38-...,0x800,0x82000)/File(\EFI\ubuntu\shimx64.efi)

Each entry consists of:

  • An identifier (Boot0000, Boot0001, etc.)
  • A label shown in the firmware menu (e.g., Windows Boot Manager, Ubuntu)
  • The device path to the EFI binary that will be executed

BootCurrent indicates which entry was used to boot the system.

BootOrder defines the order in which the firmware tries the entries at startup.

In the example above, we can see a Windows Boot Manager entry that points to the Windows bootloader (\EFI\Microsoft\Boot\bootmgfw.efi), and a Ubuntu entry that points to GRUB via \EFI\ubuntu\shimx64.efi. Normally, any boot entry listed here should also appear in the UEFI firmware’s boot menu. However, on this particular MSI mainboard, that wasn’t the case. Instead, the firmware only displays entries named Windows Boot Manager. All other boot entries are ignored and hidden from the firmware interface.

The Solution

To resolve this issue, we need to hijack the existing Windows Boot Manager entry by redirecting it to GRUB instead of the original Windows bootloader. This ensures that the firmware continues to display a valid boot entry but actually launches Ubuntu through GRUB. To perform this modification, boot into a Ubuntu live USB stick.

Verify that ESP contains GRUB

Before applying the workaround, make sure your EFI System Partition (ESP) actually contains the GRUB bootloader files. You can verify this by mounting the ESP and checking for the presence of the ubuntu directory and related files.

First, identify your ESP using:

lsblk -f

Look for a small FAT32 partition (typically 100–300 MB) with the boot or esp label. Assuming it's /dev/nvme0n1p1, mount it with:

sudo mount /dev/nvme0n1p1 /mnt

Then check if GRUB is installed:

ls /mnt/EFI/ubuntu

You should see files such as shimx64.efi, grubx64.efi, and possibly grub.cfg. If these files are present, GRUB has been correctly installed to the ESP. If the directory is missing or empty, you’ll need to reinstall GRUB before continuing (guide to be added).

Step 1: Delete the Original Windows Boot Manager Entry

First, remove the existing Windows Boot Manager entry using efibootmgr. Run:

sudo efibootmgr --delete-bootnum --bootnum <BootNumber>

Replace <BootNumber> with the identifier of the current Windows Boot Manager entry, such as 0000. You can find this number by running:

sudo efibootmgr -v

Step 2: Create a New Boot Entry That Points to GRUB

Now, create a new EFI boot entry with the label Windows Boot Manager, but configure it to launch GRUB instead of the original Windows loader. Use the following command:

sudo efibootmgr --create \
     --disk /dev/<ESP_DEVICE> \
     --part <PARTITION_NUMBER> \
     --label "Windows Boot Manager" \
     --loader '\EFI\ubuntu\shimx64.efi'

Replace:

  • <ESP_DEVICE> with the disk that contains your EFI System Partition (e.g., /dev/nvme0n1 or /dev/sda)
  • <PARTITION_NUMBER> with the partition number of the ESP (e.g., 1)

You can determine both by running:

lsblk -f

This command sets up a new boot entry named Windows Boot Manager that actually launches GRUB.

Step 3: Reboot

At last, reboot your system. Hopefully it will now boot into GRUB!

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