A simple Ubuntu installation goes wrong when the bootloader ends up on a network card instead of the main drive. Here’s how to understand why it happens and the step-by-step methods to fix it for good.

I Installed Ubuntu on a Network Card. Now What?

I remember a 2 AM call for a P1 outage. A brand new database server, prod-db-01, had failed to come back online after a scheduled reboot. The junior on call was panicking, I was half asleep, and the monitoring dashboards were a sea of red. We spent nearly an hour troubleshooting hardware, convinced the brand new NVMe drive was dead. It wasn’t. The problem was dumber. The Ubuntu installer, in its infinite wisdom, had decided that the boot ROM on our shiny new 10GbE Mellanox card was the *perfect* place for the GRUB bootloader. The server was trying to PXE boot into oblivion instead of loading from its blazingly fast local storage. We’ve all been there. You follow the steps, everything looks fine, and then you’re left with an unbootable system and a deep sense of confusion.

So, What Actually Happened Here?

This isn’t as crazy as it sounds. It’s not like the OS is running *on* the NIC’s firmware. The root of the problem lies with the UEFI boot process and how modern installers detect bootable devices. Your server’s motherboard firmware (the modern replacement for BIOS) scans for any device that has an EFI System Partition (ESP). Modern network cards, especially those with iSCSI or PXE boot capabilities, can present their own small storage area to the system, which looks just like an ESP. The Ubuntu installer sees multiple ESPs—one on your NVMe drive and one on the NIC—and sometimes makes a poor choice. It installs the bootloader files (like grubx64.efi) onto the NIC’s partition, leaving your main drive without a way to boot itself.

When the machine reboots, the UEFI firmware looks at its boot order list, sees the NIC first (or the only valid entry), and tries to boot from the network. Chaos ensues.

The Fixes: From a Band-Aid to Surgery

Alright, let’s get you out of this mess. There are a few ways to tackle this, ranging from a quick fix that might not stick, to the proper, permanent solution.

Solution 1: The Quick and Dirty BIOS Fix

This is the fastest way to see if your OS is actually installed correctly on the main drive. It’s a band-aid, but it’s a useful diagnostic step.

1. Reboot the machine and hammer the key to enter the UEFI/BIOS setup (usually F2, F10, F12, or DEL).
2. Navigate to the “Boot” or “Boot Order” section.
3. You will likely see something like “Onboard NIC (PXE)” or a specific network card model at the top of the list.
4. Look for an entry that says “ubuntu” or one that points to your actual hard drive (e.g., “NVMe SSD PM981” or “SATA: Samsung 870 EVO”).
5. Move the correct drive entry to the very top of the boot priority list.
6. Save and exit.

If your machine boots into Ubuntu, congratulations! The OS is fine. The problem is just the boot order. However, this fix can sometimes be temporary. A firmware update or even a “load optimized defaults” action could reset this order and bring the problem right back.

Solution 2: The Permanent Fix (Using efibootmgr)

This is the right way to fix it from within your running OS. The efibootmgr tool is a command-line utility that lets you directly manipulate the UEFI boot manager’s entries. This is how you tell the firmware itself what the correct boot entry is and get rid of the wrong one.

First, boot into your system (using Solution 1 if you have to). Then, open a terminal and let’s get to work.

1. List the current boot entries. This command shows you what the firmware thinks the boot order is.

   sudo efibootmgr -v

   You’ll get an output something like this:

   BootCurrent: 0001
   Timeout: 1 seconds
   BootOrder: 0003,0001,0000
   Boot0000* ubuntu    HD(1,GPT,guid-goes-here,0x800,0x100000)/File(\EFI\ubuntu\shimx64.efi)
   Boot0001* UEFI: PXE IP4 Intel(R) I210 Gigabit Network Connection
   Boot0003* UEFI OS   HD(1,GPT,guid-goes-here,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)

   Notice how Boot0001 is the network card. The BootOrder shows it trying the mysterious 0003 first. Your goal is to make sure Boot0000 (the real Ubuntu entry) is the default and only necessary option.

2. Delete the incorrect entry. Let’s get rid of that network boot option. Use the number from the list (in this example, 0001 and 0003 look suspicious). The -b flag specifies the boot number and -B deletes it.

   sudo efibootmgr -b 0001 -B
   sudo efibootmgr -b 0003 -B

3. Set the correct boot order. Now, explicitly tell the firmware to only use the correct entry.

   sudo efibootmgr -o 0000

Reboot your machine. It should now boot directly into Ubuntu every single time, no questions asked. This change is written to the motherboard’s NVRAM and is permanent.

Pro Tip: Before deleting entries with efibootmgr, triple-check you are deleting the right one. Look at the device path in the verbose output. The correct entry should point to a GUID partition on your HD (Hard Drive), not a network device.

Solution 3: The ‘Nuclear’ Option (Reinstalling GRUB)

Sometimes, the system is so confused it won’t even boot using the BIOS trick, or maybe the bootloader files are genuinely in the wrong place. This is when we break out the live USB and perform surgery from the outside.

This is the most complex method, but it’s a guaranteed fix for a corrupted or misplaced bootloader.

1. Boot your machine from an Ubuntu Live USB stick (the same one you used for installation). Select “Try Ubuntu”.
2. Once at the desktop, open a terminal. We need to identify your partitions.

   lsblk

   Look for your main Linux partition (e.g., /dev/nvme0n1p2) and your EFI partition (e.g., /dev/nvme0n1p1).

3. Mount the partitions and chroot. We’re going to create a temporary environment that acts as if we’re running from your installed system.

   # Replace /dev/nvme0n1pX with your actual partition names
   sudo mount /dev/nvme0n1p2 /mnt
   sudo mount /dev/nvme0n1p1 /mnt/boot/efi
   sudo mount --bind /dev /mnt/dev
   sudo mount --bind /proc /mnt/proc
   sudo mount --bind /sys /mnt/sys
   sudo chroot /mnt

4. Reinstall GRUB. Now that you are “inside” your system, you can reinstall GRUB to the correct location. This command tells GRUB to install itself to the specified disk and create the necessary UEFI entries.

   # The target disk, NOT the partition
   grub-install /dev/nvme0n1

5. Update GRUB and exit.

   update-grub
   exit
   sudo umount -a
   sudo reboot

Remove the live USB, and your system should now boot correctly from the main drive. You’ve effectively wiped the old boot instructions and written new, correct ones pointing directly to the right disk.

So next time a server “won’t boot,” don’t immediately assume the hardware is toast. Take a breath, check the boot order, and remember that sometimes, the simplest explanation is the right one—even if it’s as weird as installing your OS to a network card.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions