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.

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.