0

So, I've been tasked to equip around 600 HP desktops with a version of Ubuntu 16.04.2 LTS.

I use CloneZilla to mirror the main HDD but some problems came up.

  1. When i got an HDD ready for use it would not boot. I countered this problem by mounting Boot-Repair on a USB. after applying the fix the Ubuntu Boot menu came up as it should.
  2. The second issue is that while booting you don't get to see the Ubuntu Splash Logo. Instead you get a black screen. As i found out thanks to this answer it's because the kernel boots faster than the Graphic Drivers. I applied the suggested fix and it worked exactly as i wanted.

And now for the real question. Is there a way to fix my boot logo issue simultaneously with the grub fix? Even tho the procedure of fixing the boot logo is not time consuming, applying it on 600 pc's can be time consuming.

Thanks in advance and sorry if my English gave you headache.

Edit: The fix from 1. is applied through a bootable USB on each pc after the HDD gets plugged in.

  • This might be what you are looking for https://askubuntu.com/questions/48535/how-to-customize-the-ubuntu-live-cd/157562#157562 (second answer) – M. Becerra May 10 '17 at 08:47

1 Answers1

0

Your first problem is most likely caused by the fact that modern EFI-based computers store the boot loader information in NVRAM. Thus, when you mirror a working installation to a new computer, unless you explicitly add an NVRAM entry, the computer won't know how to boot. Several possible solutions spring to mind:

  • Create the right boot entry -- If you use the target computer to mirror the disk, you can explicitly create a boot entry with efibootmgr. Chances are efibootmgr -c -l \\EFI\\ubuntu\\shimx64.efi -L ubuntu will do the trick, although you might need to add -d and/or -p options, depending on how your disk is laid out. (See the man page for efibootmgr for details on its options.) This is likely the best solution if you're using the target system to do the mirroring; but if you pull the disk from the target system and use another computer to mirror the disk, this solution won't work unless you're willing to do some cleanup work on the target computing using an emergency disk. This solution also requires that the EFI System Partition (ESP) be mirrored along with everything else.
  • Use the fallback filename -- Instead of booting EFI/ubuntu/shimx64.efi, which in turn launches EFI/ubuntu/grubx64.efi on the ESP, you can copy those files so that the system uses the fallback filename of EFI/BOOT/bootx64.efi on the ESP. That is, you'd do something like sudo cp -a /boot/efi/EFI/ubuntu /boot/efi/EFI/BOOT, followed by sudo mv /boot/efi/EFI/BOOT/shimx64.efi /boot/efi/EFI/BOOT/bootx64.efi. (This would be from a working, booted installation; you'd have to adjust the path if you made these changes in some sort of emergency environment.) EFIs try to boot using the fallback filename if no explicit NVRAM entry (as created by efibootmgr) exists, so doing this should get your cloned systems to boot. The problem is that updates to GRUB won't be properly installed without extra steps.
  • Install in BIOS/CSM/legacy mode -- Instead of installing in the native EFI/UEFI mode, you could install in BIOS/CSM/legacy mode. When the target computers are reconfigured to support this boot mode, they should then boot without requiring NVRAM entries to point to the correct boot loader. This approach may require more fiddling with the firmware settings on the target computers, though, so it may not be worth the hassle.

You might also do a combination of the first two approaches -- that is, copy Shim/GRUB to the fallback filename for a first boot, but configure the computer to launch a script to add an NVRAM entry to the EFI/ubuntu/shimx64.efi boot loader the first time it boots.

Rod Smith
  • 44,284
  • 7
  • 63
  • 105
  • Thank you very much for taking the time to answer! I found a way around this by adding the /etc/initramfs-tools/conf.d/splash (as shown into the solution i posted with my answer) into the main HDD and then started the cloning again. Boot logo is right there! – E. Chatzis May 11 '17 at 12:54
  • I have to say that this is an amazing answer. could i get more information on the second option? especially on the "The problem is that updates to GRUB won't be properly installed without extra steps." part. – E. Chatzis May 12 '17 at 12:29
  • When Canonical pushes out an update to GRUB, it will be downloaded and installed to its regular location (/boot/efi/EFI/grubx64.efi), but not to the fallback location to which you copy it. Thus, you'll miss out on whatever updates will eventually be released. This might not be important; but if there's something important, like a security bug that might bite you, you won't want to take this risk. You can re-copy the files, of course, but you'll need to either watch carefully for updates or set up a script to do it automatically. – Rod Smith May 13 '17 at 15:00