Ubuntu Installer uses wrong bootloader location for USB UEFI installs

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

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 :

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.

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

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.

Chasse Court (falloutboy) wrote :

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.

Red (reduser) wrote :

me too.

Red (reduser) wrote :

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 *

Red (reduser) wrote :

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.

Phillip Susi (psusi) wrote :

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.

Phillip Susi (psusi) wrote :

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.

Fred Palmer (oldfred) wrote :

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?

Red (reduser) wrote :

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

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.