Ubuntu Installer uses wrong bootloader location for USB UEFI installs

Status changed to 'Confirmed' because the bug affects multiple users.

This still happens with Ubuntu 16.04.1. I have a "Live CD" on a 4GB USB stick (which ends up being /dev/sdb), a valid Linux installation (Lubuntu) in the internal HDD (4 partitions, /dev/sda), and the laptop's BIOS has secure boot enabled. When trying to use "something else" and manually setting up the partitions on a new blank 32GB USB stick (/dev/sdc), the install proceeds as expected; but attempting to boot the HDD without the 32GB stick present results in the GRUB command-line prompt. I can only make a standalone bootable external UDB drive by first formatting the internal HDD (which indeed I ended up doing).

A third user is affected, see askubuntu.com/questions/771017

Debian says it is fixed in Debian Grub 2.02~beta2-19 Back in Jan 2015.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767037
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746662
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=708430

Those Debian bugs refer to the creation of the /EFI/Boot/bootx64.efi bootloader, implemented these days with the --removable qualifier on grub-install, and addressed in bug 1453980 for still ignoring the --uefi-secure-boot which should force the use of shimx64.efi instead of grubx64.efi.

This bug is the USB target install problem(s) of:

1) Ignoring user input on which device to install the bootloader,
(User inputs /dev/sdc, install uses /dev/sda instead).
This leaves the ESP of the USB target empty, so the device is unbootable.

2) The bootloader files improperly dumped into the ESP of internal disk, /dev/sda,
include a grub.cfg file which links back to the grub.cfg file on the USB target,
leaving the host system unbootable without the USB present.

Bug 1229488 in additional mentions the wrong nvram changes made to the host machine
when a USB install is done, changing the shim entry to grub, and leaving a
secure boot enabled host unbootable.

Even adding a "none" option for bootloader would be an improvement, since then
the host system would not be messed up.

This is the underlying problem which boot-repair addresses after the fact.

https://answers.launchpad.net/ubuntu/+question/662540
Is this what is happening to me here? This is pretty critical - Ubuntu is touching drives it is told not to.

How do I clean this up if I was affected? My EFI partition on my external drive is empty, internal one has grub.

I managed to clean up the damage
I used efibootmgr to delete the EFI boot entries on the Windows drive

I then booted an Ubuntu USB stick, followed Gentoo's guide for mounting and chrooting into the Ubuntu environment I needed to fix
https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base

I then did grub-install --target=x86_64-efi --efi-directory=/boot/efi, where /boot/efi had my external drive's EFI partition mounted up
https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Bootloader

I checked the drive with efibootmgr to make sure Grub installed right, it did.

This is a really critical bug for any desktop user...

Dylan, yes, your description at https://answers.launchpad.net/ubuntu/+question/662540 is an instance of this bug.

Your repair was OK, but a bit overkill. Specifically, a chroot was not really necessary, since the file-juggling could all be done without that. Of course, as this is a bug in ubiquity, no fix SHOULD be necessary; it should be fixed there....

I agree that this bug is critical. It happened to me as well with Ubuntu 17.10 and took me a while to clean up my disk.
I read afterwards that there are some options to the installer, like the --removable, but I think they are not relevant. I didn't know about these options when I decided to install Ubuntu, and the default, out of the box, "happy-path" for the user (me) presents an option to avoid touching the internal HDD but at the end it still touches it.
I can say in all fairness that I've lost my trust in Ubuntu because of this and I definitely won't try installing it again without a very strong assurance that this problem is for sure gone.

Okay I got hit with this "BUG" too, I was trying to do something very specific which was create a set of USB Keys for diagnosing a network issues between my two PC's. It's frustrating, caused many many hours of very angry stupid linux operating system comments.
Ubuntu was my first attempt at going back to Linux since I used a very old slackware install with Marvin the Martian on the front of the CD set and I must say this bug has really put me off trying it again.

me too.

Wanted to create a *portable* Linux Mint USB stick with encryption via LUKS. Installed grub to EFI of local system and not on USB stick itself. EFI of local system points to USB stick. Successfully boots to USB stick on this one system, wrecked my local EFI.

What a mess. I'm fortunate I even figured it out and ended up on this page, confirming I am not crazy.

Commenters on Linux forums, Stackexchange/Superuser, etc sent me down various rabbit holes for n00bs (probably because they observed I was attempting install with encryption). Fortunately I had enough Linux experience to finally narrow it down to finding this damn page.

And for the curious, I got the encryption working. On this one system. And my local EFI now has to be repaired. And my USB stick is useless until I repartition and start over.

* CRITICAL ISSUE *

Possible workaround: (instructions are for macs, but the idea of starting ubiquity with:

ubiquity --no-bootloader

might lead in a direction to a workaround for PCs. If you figure out a full solution, please post on this forum as I'm monitoring it and it looks like people are starting to find this bug report from Google after much agony).

https://medium.com/@mmiglier/ubuntu-installation-on-usb-stick-with-pure-efi-boot-mac-compatible-469ad33645c9

Guys, it's insane this has been going on for so long... Please, help us. On 18.04, Ubuntu installs the bootloader to the first EFI system partition it finds, even if I select a second disk with a second EFI system partition for the bootloader install.

Choose manual partitioning and mount the correct ESP in /boot/efi.

Phillip, that doesn’t work. I never perform automatic installs/partitioning, it’s always 100% manual. I selected the EFI system partition from the Windows drive and marked it as “Do not use partition”, selected the new EFI system partition I created for Ubuntu and marked it as “EFI system partition” (which is equivalent to what you said about mounting it to /boot/efi, and note that all partitions used by Ubuntu are on a drive that’s meant only for Ubuntu) and selected the proper drive (which contains the EFI system partition to be used) on the “Install bootloader to” dropdown. Therefore, manual partitioning does not solve the issue. It’s even more serious that Ubiquity ignores the fact I mark the incorret EFI system partition as “Do not use the partition” and messes everything up the same way.

Ohh, I see. I was thinking this was just about setting the install location for grub with the bar for that, which does nothing in EFI mode.

Just installed 18.10 to external SSD seen as sdc, but hd0 in UEFI/grub.
I unselected the ESP on sda, and selected external's ESP for efi partition. Also used combo box which I know currently does nothing with UEFI installs.

And it still overwrote my main working install's /EFI/ubuntu folder & /EFI/Boot folder with new files.
I thought 18.10 has some grub fixes?

Please note that this bug report is a duplicate of bug #1396379 ( https://bugs.launchpad.net/bugs/1396379 ). The last comment on that bug report as of this comment by me, Red, posted by "Tim Richardson (tim-richardson)" on 2018-07-14 has a potential work around that subscribers to this thread, and future visitors to this bug report, may appreciate

I have a laptop with 2 SSDs and want to install Windows and Ubuntu separately.
Windows is installed on the first SSD and runs well.
Now I need to install Ubuntu on second SSD.
Every time I try to install it: Ubuntu installs GRUB to the first disk, to existing EFI partition alongside Windows bootloader. I tried all possible disk choosing options, and it still uses existing ESP. And, yep, it broke my Windows bootloader.

Please pay attention to this bug, it's ancient!

This critical bug still exists in 22.04.1!

Enough said.