Score:2

cloned Ubuntu 20.10 installation on same hardware fails at boot

in flag

I have more than 100 units of the same HW I need to prepare for our product delivery. All of them are the very same HW (celeron N platform, 32GB SSD) and come with a standard Ubuntu 20.10 installation which needs to be customized for our specific product. I did all the customization on a single unit I would like to keep as a "master" setup to be spread on all the unit. I dumped an image of this "master" installation through Rufus on a windows 10 machine and tried to prepare the cloned units. The issue here is that the cloned SSD only boots on the "master" unit, but it will not boot on a different one. I got a message stating "... Select proper boot device ...Insert boor media in selected boot device and press a key". I should be a EFI related setup, which actually I do not know in details. I tried to copy the file this way cp /boot/efi/EFI/ubuntu/grubx64.efi /boot/efi/EFI/BOOT/bootx64.efi (which in my installation is actually all capitals BOOTX64.EFI), as I got it should be used as recovery when main boot file is not found. But this did not work. How can I create an usable portable Ubuntu 20.10 image for this massive installation?

pLumo avatar
in flag
You know that 20.10 support will end in 3 weeks from now?
Maurizio Santovito avatar
in flag
ok, granted. Does the newest Ubuntu release not having cloning issues like the one I'm describing above?
sudodus avatar
jp flag
If you want a long life, I recommend that you use Ubuntu 20.04.x LTS (Long Time Support for 5 years). - Maybe there is some crucial difference between your computers, that make a cloned copy fail in the other computers. Or are you installing Ubuntu **Server**? It is setting up the wired network in a non-portable way, and there may be other things that prevent cloning.
C.S.Cameron avatar
cn flag
Rufus would be very slow flashing just one image at a time, Etcher will do multiple images at once. Etcher also has a Linux version. I have had problems using old versions of Rufus, best to use the latest version.
C.S.Cameron avatar
cn flag
I understand that you can also check the image using MD5SUM, but have not tried the following method: http://www.geekmungus.co.uk/linux-and-nagios/usingmd5sumtoverifyaddimagewiththeoriginal
Score:1
jp flag

My experience is that an installed Ubuntu desktop system (in a portable drive) can boot in many pc computers, not only with identical hardware. as long as there are no proprietary drivers (e.g. for graphics and wifi). And hence, cloned systems will work too (in other computers).

But there are some things to check.

  • Cloning works correctly when the target drive is at least as big as the source drive (not one single byte smaller). Please notice that two drives with the same nominal size (e.g. 32 GB) may contain different numbers of bytes.

    • If the target drive is slightly smaller, you can work around the problem by leaving enough unallocated drive space near the tail end of the drive.
  • If there is a GUID partition table, GPT, and the target drive size is different, you must fix the backup partition table, which should be located at the tail end of the drive. You can do that with gdisk or easier with gpt-fix.


  • Ubuntu Server is setting up the wired network in a non-portable way, and there may be other things that prevent cloning.
Maurizio Santovito avatar
in flag
Thanks for the answer, sudodus.
Maurizio Santovito avatar
in flag
Both the source and the target SSD are identical units, same manifacturer, same product, same everything, as the PC it is connected to. Same product. This is why I need to have a master image to be spread everywhere. But I'm stuck in not being able to run the image on a different unit of the same product. The only alternative we have so far is to manually install Ubuntu on each PC and repeat every customization steps. doable but not efficient at all. I guess I'm stuck with UEFI configuration I do not know, as I'm not familiar on how UEFI boot work, I'm afraid
sudodus avatar
jp flag
Maybe you created the master system with another drive connected, and that drive was seen as the first drive, and the EFI system partition was located there. Hence the master drive contains no EFI system partition. - If you unplug, disconnect or otherwise disable the internal drive, and install your Ubuntu again, things should work better. See [this link](https://askubuntu.com/questions/16988/how-do-i-install-ubuntu-to-a-usb-key-without-using-startup-disk-creator/942312#942312)
sudodus avatar
jp flag
I think even 'identical units' of SSD may contain different number of bytes. Please check it for example with `lsblk -bdo name,size`
Maurizio Santovito avatar
in flag
I checked, they have the very same size. Moreover, I can boot the cloned disk if connected to the PC used for the master installation. But when I move it to a different PC (of the same product, so it is the same HW, same RAM, same platform, same everything), the boot does not take place with the error in the description I wrote.
sudodus avatar
jp flag
Again, maybe you created the master system with another drive connected, and that drive was seen as the first drive, and the EFI system partition was located there. **Hence [maybe] the master drive contains no EFI system partition.** - If you unplug, disconnect or otherwise disable the internal drive, and install your Ubuntu again, things should work better. See [this link](https://askubuntu.com/questions/16988/how-do-i-install-ubuntu-to-a-usb-key-without-using-startup-disk-creator/942312#942312).
sudodus avatar
jp flag
Please check the partition table in the computer, where the cloned copy works and the cloned copy is connected: `lsblk -o name,size,fstype,label`; Edit the original question to add the output of this command. Indent each line 4 spaces in order to render it as `code`. (Otherwise it will be difficult to read.)
sudodus avatar
jp flag
Please notice also, that you should never boot a computer with two cloned drives connected at the same time. It is OK to connect a cloned copy after the boot process, when you have reached the desktop environment. - The reason is that the two clones have the same UUIDs on the file systems, and the booted system cannot tell them apart and may mix part of one drive with [another] part of the other drive, and this can cause severe corruption.
Score:1
cn flag

Duplicating a Ubuntu System for Distribution

Ref: How to Duplicate a Ubuntu System for Distribution?

Once you have created the running Ubuntu OS with everything you want, use Gnome-Disks to create an image file of it, (.img).

enter image description here

Use balenaEtcher, https://www.balena.io/etcher/, to flash the Ubuntu image file to the new hardware. Etcher will flash an image file to multiple SSD's at the same time.

enter image description here

Use the settings icon in the upper right hand corner of the window to select Unsafe mode for flashing to large drives.

enter image description here

When cloning images, all the OS partitions have the same UUID. GParted has an option for creating new UUID's if desired.

Maurizio Santovito avatar
in flag
thanks C.S.Cameron, I do not need to have different UUID, I just need the cloned disk can boot when moved on a PC which is identical to the one used to create the .img file. So far this is prevented by EFI boot procedure, at least this is the only explanation I can find for that. I've used Rufus a lot cloning lot of with Debian Buster systems, so I never expected such a difference in Ubuntu releases. If Balena etcher (which I know as well) will prevent such difficulties in Ubuntu SSD cloning, then I can easily use it
Maurizio Santovito avatar
in flag
Actually the reason was the UEFI boot was not properly configured in the BIOS. Anyway this procedure actually worked
Score:1
in flag

Actually the reasn for a boot failure on cloned disk was that the UEFI feature was misconfigured on the BIOS. I reconfigured it properly and it boots. Thanks anyone who commented in this very helpful and reactive community.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.