UEFI and boot order

How it works

UEFI firmware reads a small FAT32 partition — the EFI system partition — and runs a bootloader from it. The list of entries lives in the motherboard's NVRAM, not on the disk.

efibootmgr -v

That shows every entry, the order, and which one is current. If this command says the system is not booted with UEFI, you are on legacy BIOS and the rest of this page applies differently.

Make every disk bootable

With a mirrored pair, the ESP is not mirrored by the array — it is a plain FAT32 partition on each disk. You have to maintain both:

grub-install /dev/sda && grub-install /dev/sdb

update-grub

On Debian and Ubuntu, dpkg-reconfigure grub-efi-amd64 lets you tick both disks so updates keep them in step.

Then add a boot entry for the second disk so the firmware will actually try it:

efibootmgr -c -d /dev/sdb -p 1 -L "debian-backup" -l '\EFI\debian\shimx64.efi'

Test it. Ask us to boot the machine with the first disk disconnected, once, during a window. An untested boot path is a theory, like an untested restore.

When it does not boot

Open the console first — remote KVM is included on every machine — and read what it actually says. The message separates the cases:

No bootable device

The firmware found nothing. Usually a lost NVRAM entry or a disk that dropped out.

GRUB rescue prompt

The bootloader started and could not find its configuration. Repairable from rescue mode.

Kernel panic

It booted. That is a different problem — see when the machine panics.

Dropped to an emergency shell

Almost always a bad /etc/fstab entry. See partitioning on why UUIDs matter.

Repairing from rescue mode

Boot the rescue system, mount your root and /boot and the ESP, chroot in, then reinstall GRUB on both disks and run update-grub. The full sequence is in rescue mode.

If the NVRAM entries are gone entirely — after a board replacement, say — recreate them with efibootmgr -c as above.

Secure Boot

Fine with stock distribution kernels, which are signed. It becomes a nuisance the moment you need an out-of-tree module — ZFS, a proprietary driver, anything DKMS builds — because unsigned modules will not load.

Either sign your modules with a machine owner key, or ask us to disable Secure Boot on your machine. Decide which before you build the system on top of it.

Ask us for the window

Boot testing means powering the machine down. That is a ticket and a time you choose — we do not reboot your machine to suit our schedule. See maintenance and notice.

---

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base