UEFI boot fails when cloning image to new machine

I have ten identical machines, and want to deploy the same Ubuntu 12.04 image on all of them. I've done a complete install on one of the machines, and cloned the disk using dd. The issue is that if I use dd to write this image to the disk of another machine, it will no longer boot. That is, the machine reports "no bootable devices found" on all machines except the one where I created the iamge.

I suspect that this may be due to something device- or machine-specific about the way the UEFI boot is set up, but I can't say for sure. I don't do anything out of the ordinary as far as I'm aware.

For what it's worth, running Boot-Repair on one of the clones does fix the problem and let the machine boot, but I'd rather not have to run that manually on every new machine I want to clone the image to. Also, this seems to tie the drive to that machine, so inserting a "fixed" drive into a machine other than the one Boot-Repair was run on will yield the "no bootable devices found" message again.

Clearly it must be possible to construct an image in such a way that the UEFI boot entries will work on any machines, as this is what the Ubuntu install image does, but I have no idea how it achieves that?

If it's of any help, here is the boot info file generated by Boot-Repair when it fixed the disk on a new machine.

3 Answers

Under EFI, boot loaders are stored as files in the EFI System Partition (ESP). Ordinarily, such files have names that are unique to the OS, such as EFI/ubuntu/grubx64.efi for Ubuntu. Because of this fact, boot loaders must be registered in the firmware's NVRAM. The Ubuntu installer does this when the OS is installed, but when you move the disk to another computer, its NVRAM has not been modified, so the computer won't boot. Using Boot Repair will install a fresh copy of GRUB and register it with the firmware, thus fixing the problem. My guess is that your firmware's own boot manager does a scan and registers the boot loader, too, but it could be that something else is going on.

One possible workaround to this problem is to copy GRUB from EFI/ubuntu/grubx64.efi to EFI/BOOT/bootx64.efi. The latter is a fallback name -- the computer boots from that name if it can't find any registered boot loader. Removable media also use that same filename, since obviously, an OS installation disk can't be pre-registered unless it uses some agreed-upon common name. It's possible that Ubuntu and/or Boot Repair copied GRUB to this name, too, that your firmware didn't initially detect it for some reason, and that using the firmware's boot manager caused it to notice this file's presence, thus explaining the bootability after you used that tool. In fact, this seems more likely than that your firmware scanned for Ubuntu's default boot loader filename.

Curiously, the problem resolved itself when I opened the UEFI boot manager (F2 during boot) and reset to factory defaults.

My guess is that I had at some point enabled "Quick boot" or some such feature which disabled the search for "unregistered" UEFI boot partitions. Running grub-update (which invokes efibootmgr) essentially registers GRUB with the UEFI boot manager so it doesn't have to search for it, but since this command has not yet been run on the cloned machines, efibootmgr hasn't been run, and therefore the GRUB installation won't be in the boot manager's list.

Jon Gjensget's answer helpfully says:

Running grub-update (which invokes efibootmgr) essentially registers GRUB with the UEFI boot manager

But then omits how to actually run efibootmgr. I don't want to have to unlock the encrypted disk, mount all the right things like /dev, /boot, /boot/efi. etc., chroot, and finally be able to run grub-update, if I can just run efibootmgr, especially since the disk is now in a known-good state (restored from backup) and I don't want to wait another two hours to re-image it if I mess the boot up.

Running cd /boot/efi/EFI; cp -r ubuntu BOOT as suggested in comments did not work for me, even though I am also running into the issue on an Intel NUC.

Boot-repair also didn't work for me: the repair button as shown in screenshots is not there, and in advanced options there isn't any option to just run efibootmgr, it looks like it's just a GUI button to run grub-update (and a lot of other tools like fsck) instead of actually fixing the boot by itself.

This is the command that worked for me (run from a live boot stick):

efibootmgr -c -g -d /dev/sda -p 1 -w -L "myboot" -l '\EFI\ubuntu\grubx64.efi'
efibootmgr # to verify it's in the boot options list
efibootmgr -n [ID HERE] # to make sure it boots that option next time

The -n [ID] did not turn out to be necessary, it booted that option every time after creating it (there were no other boot options that work anyway, which is why I'm confused why it doesn't just try to boot from the only possible boot option in the first place....).

The options used are:

• -c create new boot option
• -g force it to treat the disk as GPT (not sure if this is necessary, I didn't try it without this option)
• -d which device to use, in my case /dev/sda
• -p the partition number which contains your EFI boot folder and .efi boot file, in my case the device was /dev/sda1 (a FAT32 partition) so the partition number is 1
• -w "write unique signature to the MBR if needed" (don't know if this is needed)
• -L a name of your choosing, I chose a name that is unique to me so I can recognize it later
• -l path to your .efi file you want to use for booting, I assume for grub on x86_64 this is always \EFI\...\grubx64.efi and the ... depends on your distribution. You can find the right path on the partition (previously specified by -d and -p), and it's typically mounted in /boot/efi so you can look in /boot/efi/EFI what the directory name is where grubx64.efi is located.

Source: -- this is simply the first command in the thread. The replies give more suggestions, but the first command worked for me.