Focal installer uses EFI System partition on incorrect disk

[Jakob Lell]

I just wanted to try out the upcoming Ubuntu 20.04 release (for testing/finding bugs) using the latest daily build. For the testing system I decided to install it on an external USB thumb drive (while the laptop also contains an internal NVMe SSD with an Ubuntu 19.10 installation). I kept the default value for all settings in the installer (no custom partitioning) and only selected the external USB drive as target device of the installation. The installer correctly creates the "EFI System" partition (/dev/sdb1) and the root partition (/dev/sdb2) on the target device. However, the "EFI System" partition (/dev/sdb1) turns out to be a completely empty FAT32 partition after finishing the installation, which makes the target device non-bootable. Instead, the installer places its EFI files on the internal SSD (/dev/nvme0n1p1). When booting from the internal SSD (and not from the external USB drive selected as installation target), the newly installed system boots up and mounts /dev/nvme0n1p1 to /boot/efi/.

This behavior has two unintended consequences:
1. The target device selected in the installer does not contain a full/bootable installation. I planned to use this installation on an external USB drive for testing the new Ubuntu release on several different computers. This is not possible if the EFI files required for booting are stored on the internal SSD of one laptop.
2. The existing operation system on the internal SSD (which was not selected as target device for the installation) is rendered into a non-bootable state. There is no user interaction/confirmation about that and since I selected another device as installation target, the installer should not even touch the internal SSD.

Affected ISO image:
Download URL: http://cdimage.ubuntu.com/daily-live/current/focal-desktop-amd64.iso
Modification timestamp on server: 2020-03-24 09:40 (Still the latest version as of 2020-03-28)
SHA256: 63c716eaf768c9d0faea36550a898fb82ba52ac52cd65ca0c04682b799b239eb

I am happy to help with resolving this issue by retesting with an updated ISO image or providing additional information/debug logs if required.

[Dimitri John Ledkov (xnox)]

I'm going to mark it as duplicate of the sorting/ordering bug that we have in ubiquity when multiple drives exist.

Long story short, when there are more than one drive visible, we pick the wrong disk to install bootloader to, if the target drive doesn't happen to sort first.