Monday, April 29, 2024
 Popular · Latest · Hot · Upcoming
10
rated 0 times [  10] [ 0]  / answers: 1 / hits: 29072  / 3 Years ago, thu, august 19, 2021, 10:24:07

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.


More From » boot

 Answers
7

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.


[#28300] Saturday, August 21, 2021, 3 Years  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.
exceeeelh

Total Points: 21
Total Questions: 109
Total Answers: 120

Location: Marshall Islands
Member since Wed, Jan 5, 2022
2 Years ago
exceeeelh questions
Sun, Nov 20, 22, 17:08, 1 Year ago
Sat, Jan 1, 22, 08:04, 2 Years ago
Wed, May 12, 21, 05:11, 3 Years ago
;