Getting *buntu 17.04 (or others) to respect my choices when installing to a external drive UEFI/secureboot system

Question

I'm trying to install Lubuntu or Kubuntu 17.04 to an external drive. I'm using a IODD 2451 booting an ISO, and installing to an emulated phyical drive backed by a VHD. For all intents and purposes - I'm installing from a livecd/dvd to a regular external hard drive that my firmware detects as a bootable device.

I am running a system with secureboot, and I don't want to turn it off.

Both these variants seem to either not give an option on where to install the bootloader, or ignore it, and don't seem to write the EFI boot files to a ESP partition they create.

While the IODD is a unusual piece of hardware, as far as my computer is concerned, however, these are a regular blueray drive (not important) and a bootable hard drive. It even boots off the drive, sees the other drive and does the install. Lubuntu's installer does not give me a choice of where to install my bootloader, and doesn't create a ESP partition. KDE does, so lets assume I'm using Kubuntu

Kubuntu is happy to create an ESP partition on my external drive. Then proceeds to install my bootloader and EFI boot files to the main drive in my system despite telling it to install to the external drive.

While in theory I could install to a VM then convert, I don't think any free vm software emulates a secureboot system.

So, how do I get either of these flavours of ubuntu to respect my choices and actually install to the drive I want it to without clobbering my other drive?

Answer 1

I'd never before heard of that hardware you're using. It looks like an interesting device, but I doubt if it's the source of your problems.

When installing in EFI/UEFI mode, the Ubuntu installer (Ubiquity) prompts for the location of the boot loader, but promptly ignores that information. There are several bugs related to this:

• https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1466367
• https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1173457
• https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379

I haven't checked Lubuntu and Kubuntu specifically, but I would expect them to have the same bug.

One workaround procedure is as follows:

1. Boot the installation medium into its "try before installing" mode.
2. Open a Terminal window.
3. Type ubiquity -b. The -b option tells Ubiquity to not install a boot loader at all.
4. Proceed with installation normally.
5. Manually install a boot loader. This can get tricky, though. There are several options for how to proceed:
   • You can install from the installation medium you've already booted or you can use a tool like my rEFInd boot manager on a USB flash drive or CD-R to boot into your disk-based installation on a one-time basis.
   • You can install GRUB 2 (Ubuntu's default) or something else.
   • You may need to adjust /etc/fstab or otherwise ensure that the ESP you want to use is mounted at /boot/efi.

Note that many (but not all) EFIs delete NVRAM boot entries that point to invalid boot loaders. Thus, if you install your Ubuntu boot loader to an external disk and then unplug that disk and boot, the boot loader entry may go away. The solution is to rename the boot loader path (EFI/ubuntu/ by default) to EFI/BOOT, and rename the boot loader itself to the fallback filename (EFI/BOOT/bootx64.efi). That filename will make an external disk bootable by specifying the disk in the firmware's boot menu. Alternatively, you could install rEFInd on the internal disk. rEFInd is more dynamic than GRUB; it actively scans all media for bootable images, so its options adapt on a boot-by-boot basis, and it won't be bothered by the appearance and disappearance of the external disk. You'll need to jump through some extra hoops to get rEFInd to work with Secure Boot, though, as described in its documentation.

As to VMs, there are EFI firmware images for QEMU that support Secure Boot. There are some links and instructions on using it here, among other places -- try a Web search if you have problems with the link I've provided. I don't know of anything pre-built for VirtualBox.