Ubuntu Installer uses wrong bootloader location for USB UEFI installs

Bug #1173457 reported by Ubfan on 2013-04-27
This bug affects 10 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)

Bug Description

On a secure boot pc (secure boot enabled, Ubuntu Desktop 12.10 64bit installed with Win 8), installing from live media Ubuntu 13.04 64 bit desktop to a target thumbdrive (pre partitioned with gpt, and a bootable FAT32 partition 1 of 250M labeled EFI) properly identifies the target's first partition as an "EFI bootable partition" (when "do something else" is selected), but the install
will then mount the ESP off the laptop's hard drive (at /target/boot/efi).
The install creates a grub.cfg file under /target/boot/efi/EFI/ubuntu pointing to the target's(uuid) /boot/grub/grub.cfg. This wrong grub.cfg will prevent the laptop from booting Ubuntu without the thumbdrive, throwing the boot into a grub prompt (since the configfile points to the usb and is no longer present).

The install should use the identified "EFI boot partition" on the target, so the target may boot when first in boot priority, and not touch the hard disk's EFI files. If for any reason a permanent installation is to be made to a USB device, simply select the hard disk's ESP instead of one on the target.

Launchpad Janitor (janitor) wrote :

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

Changed in ubiquity (Ubuntu):
status: New → Confirmed
Robert Munafo (mrob27) wrote :

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

Ubfan (ubfan1) on 2016-10-04
summary: - Ubuntu 13.04 Desktop 64 bit install uses wrong ESP for secure boot
- laptop
+ Ubuntu Installer uses wrong bootloader location for USB UEFI installs
Ubfan (ubfan1) wrote :

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.

Phillip Susi (psusi) on 2017-02-14
Changed in ubiquity (Ubuntu):
importance: Undecided → Critical
status: Confirmed → Triaged
Dylan Taft (dylanetaft) wrote :

Is this what is happening to me here? This is pretty critical - Ubuntu is touching drives it is told not to.

Dylan Taft (dylanetaft) wrote :

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

Dylan Taft (dylanetaft) wrote :

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

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

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

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

Rod Smith (rodsmith) wrote :

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....

Jonathan Amir (yoniamir) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.