installer uses first EFI system partition found even when directed otherwise

Bug #1396379 reported by francesco florian
208
This bug affects 45 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
High
Unassigned

Bug Description

(k)ubuntu 14.04.1
package version: 2.02~beta2-9ubuntu1

i installed ubuntu on my external hard disk, where i also have a previously installed fedora system. i also have a windows
(efi-booted) system in the internal hard disk.

at install time via ubiquity i get all grub configuration files in the first EFI-labelled partition (i.e. /dev/sda2 in my case) instead of the one i selected (/dev/sdb1).
later i changed my fstab mounting /boot/efi on /dev/sdb1 and tried to reinstall grub package (apt-get install --reinstall grub-efi-amd64); now all grub configuration files are in the rigt place, but booting from the external hard disk still shows the fedora grub installation, while selectin the internal hard disk from the bios menu shows a submenu listing ubuntu and windows.
explicitly installing grub in the correct disk (grub-install /dev/sdb; grub-mkconfig -o /boot/efi/EFI/ubuntu/grub.cfg) has no effect, nor it has running efibootmgr (efibootmgr -c --disk /dev/sdb --part 1).

expected results: grub shoud have been installed in the disk/partition i chose;
actual results: ubuntu always chooses the first disk to install grub on.

Note that this is not just about the dummy grub install location selector that is not used in EFI mode, but configuring one partition as do not use, and the other as ESP in the manual partitioning screen.

Revision history for this message
Phillip Susi (psusi) wrote :

Grub gets installed to whatever you have mounted in /boot/efi as you noted. If you want to specify a particular partition to be mounted there then you should do so during installation. For it to work however, that partition must actually be an EFI type partition, not just an arbitrary data partition.

Changed in grub2 (Ubuntu):
status: New → Invalid
Revision history for this message
francesco florian (francesco-florian94) wrote : Re: [Bug 1396379] Re: grub2 does not install in the correct partition on efi system

i filed the bug exactly because i did so: i chose "efi system partition" in the
partition selection section; it was already formatted as FAT and labelled EFI,
but grub was installed in the wrong partition. (note: i'm quite sure i did the
right thing because the same partition and process works in fedora)
i also noted that after changing the fstab, grub configuration files are saved
in /boot/efi, but something else (i don't know what) in still installed in the
wrong disk, as the bios (uefi) says ubuntu is in the first disk, not the second
(the one where my /boot/efi is located).
thanks for you work
francesco florian

On Wednesday 26 November 2014 4:55:29 pm you wrote:
> Grub gets installed to whatever you have mounted in /boot/efi as you
> noted. If you want to specify a particular partition to be mounted
> there then you should do so during installation. For it to work
> however, that partition must actually be an EFI type partition, not just
> an arbitrary data partition.
>
>
> ** Changed in: grub2 (Ubuntu)
> Status: New => Invalid

Revision history for this message
Phillip Susi (psusi) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 11/26/2014 05:18 PM, francesco florian wrote:
> i filed the bug exactly because i did so: i chose "efi system
> partition" in the partition selection section; it was already
> formatted as FAT and labelled EFI, but grub was installed in the
> wrong partition. (note: i'm quite sure i did the right thing
> because the same partition and process works in fedora) i also
> noted that after changing the fstab, grub configuration files are
> saved in /boot/efi, but something else (i don't know what) in still
> installed in the wrong disk, as the bios (uefi) says ubuntu is in
> the first disk, not the second (the one where my /boot/efi is
> located). thanks for you work

Where did you set it to be mounted? You need to set its mount point
to /boot/efi. If you had done that during install, then you wouldn't
need to change /etc/fstab later.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJUe8BvAAoJENRVrw2cjl5RIQAH/0wOeOyXz6JI4menuZX0a6Id
7g3guJOYSXoh+1RCFLfPw7Hw5STZQjdci7VZLkUEi8DN0mTNtcUvYDgu/8xj49R+
COKly/wOvbUl9XtlGr7RPMLeBvoCPoSoqe3chNJonK1JWRb7Zj0NkTFIhrvHTepz
pBZNkhb1mCGs5i7tH5ejQn6to29Kl2KgR5cl2zcFhIB4pH2qtYKWlcZAOKUebfD0
24CF7Z+M7axdQCXNDj3Y0N4p1IK9W5k5R2OgM/Gm2y7d2mMUzHtdM2amDMhvwIIY
9ljl47/esYFhu4VdVHLcVfyPdV02aBotWoQgVp8EB1CXP2YqDemDgMf2UPbFsi4=
=0Lrr
-----END PGP SIGNATURE-----

Revision history for this message
francesco florian (francesco-florian94) wrote :

i set it as "efi system partition" (partition type); then i couldn't choose a
mount point. i assumed it had been automatically mounted on /boot/efi, but it
had not (i verified during installation using lsblk); instead an other
partition had been mounted on /boot/efi.
francesco florian

On Mon 01 Dec 2014 2:12:15 you wrote:
> On 11/26/2014 05:18 PM, francesco florian wrote:
> > i filed the bug exactly because i did so: i chose "efi system
> > partition" in the partition selection section; it was already
> > formatted as FAT and labelled EFI, but grub was installed in the
> > wrong partition. (note: i'm quite sure i did the right thing
> > because the same partition and process works in fedora) i also
> > noted that after changing the fstab, grub configuration files are
> > saved in /boot/efi, but something else (i don't know what) in still
> > installed in the wrong disk, as the bios (uefi) says ubuntu is in
> > the first disk, not the second (the one where my /boot/efi is
> > located). thanks for you work
>
> Where did you set it to be mounted? You need to set its mount point
> to /boot/efi. If you had done that during install, then you wouldn't
> need to change /etc/fstab later.

Revision history for this message
Phillip Susi (psusi) wrote : Re: grub2 does not install in the correct partition on efi system

So you already have an EFI system partition on /dev/sda, but in the partitioning screen of the installer, you chose to create another one on /dev/sdb with the intention of using that one, but it still used the one in /dev/sda?

Revision history for this message
francesco florian (francesco-florian94) wrote : Re: [Bug 1396379] Re: grub2 does not install in the correct partition on efi system

yes.
actually, i had already created it, in the installer i only selected it as
"efi system partition", but i don't think there is any real difference
francesco florian

On Thu, Dec 11, 2014 at 2:23 PM, Phillip Susi <email address hidden> wrote:
>
> So you already have an EFI system partition on /dev/sda, but in the
> partitioning screen of the installer, you chose to create another one on
> /dev/sdb with the intention of using that one, but it still used the one
> in /dev/sda?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1396379
>
> Title:
> grub2 does not install in the correct partition on efi system
>
> Status in grub2 package in Ubuntu:
> Invalid
>
> Bug description:
> (k)ubuntu 14.04.1
> package version: 2.02~beta2-9ubuntu1
>
> i installed ubuntu on my external hard disk, where i also have a
> previously installed fedora system. i also have a windows
> (efi-booted) system in the internal hard disk.
>
> at install time via ubiquity i get all grub configuration files in the
> first EFI-labelled partition (i.e. /dev/sda2 in my case) instead of the one
> i selected (/dev/sdb1).
> later i changed my fstab mounting /boot/efi on /dev/sdb1 and tried to
> reinstall grub package (apt-get install --reinstall grub-efi-amd64); now
> all grub configuration files are in the rigt place, but booting from the
> external hard disk still shows the fedora grub installation, while selectin
> the internal hard disk from the bios menu shows a submenu listing ubuntu
> and windows.
> explicitly installing grub in the correct disk (grub-install /dev/sdb;
> grub-mkconfig -o /boot/efi/EFI/ubuntu/grub.cfg) has no effect, nor it has
> running efibootmgr (efibootmgr -c --disk /dev/sdb --part 1).
>
> expected results: grub shoud have been installed in the disk/partition i
> chose;
> actual results: ubuntu always chooses the first disk to install grub on.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1396379/+subscriptions
>

Phillip Susi (psusi)
Changed in grub2 (Ubuntu):
status: Invalid → Triaged
importance: Undecided → Medium
affects: grub2 (Ubuntu) → ubiquity (Ubuntu)
summary: - grub2 does not install in the correct partition on efi system
+ installer uses first EFI system partition found even when directed
+ otherwise
Revision history for this message
Lukas (lukas-ribisch) wrote :

When using ubiquity to install a second Ubuntu on the same system, this effectively wipes out the first installation's boot loader, since grub-install will overwrite an existing bootloader in /EFI/ubuntu on the EFI system partition.

Revision history for this message
John S. Gruber (jsjgruber) wrote :

I had specifically selected the new efi partition on a removable drive as the place to install the boot loader, yet ubiquity ignored that and installed grub and a grub.cfg file on the computers non-removable hard disk. The newly installed efi/ubuntu/grub.cfg file specifies that the grub menu be loaded from the new removable Ubuntu file system.

This all works OK if the removable drive is not removed. If it is removed then grub (obviously) can't find the newly installed file system and will no longer look for the old one. The result is a "grub> " prompt and a failure to boot.

During the problematic install the old EFI partition was mounted on /boot/efi, as described above.

------------------------
If this has happened to a future reader of this bug report, you should be able to boot manually by reinstalling the removable drive, if available.

If it isn't available the grub prompt can be used to find and use the original installs grub menus and boot normally. The grub installed to EFI partitions is quite full featured.

Find the available drives by entering the 'ls' command. Most commonly you will need hd0. Use commands such as 'ls (hd0)' to display the partitions on the various drives, substituting for the '0'. Examine the partitions with the command 'ls (hd0,6)/boot/grub' to find the partition you had been booting Ubuntu from, substituting for the '0' and '6'.

Once found, load its menu with, for example, the command:

configfile (hd0,6)/boot/grub/grub.cfg

and then boot your original Ubuntu installation from your hard disk using the resulting menu.

By the way, drives are numbered starting with 0, partitions are numbered starting with 1.

Once you have been able to boot your old Ubuntu install you should reinstall grub to reinstall the EFI/ubuntu/grub.cfg file to the hard drive EFI partition. Then you should be back where you started (before using Ubiquity to install to the removable disk.)

Revision history for this message
Ubfan (ubfan1) wrote :

This appears to be a duplicate of 1173457.

Revision history for this message
Danilo Cominotti Marques (dcominottim) wrote :

This also happens on 18.04. Ubuntu installs the bootloader to the first EFI system partition it finds, even though I select a second disk with a second EFI system partition.

Revision history for this message
Danilo Cominotti Marques (dcominottim) wrote :

Some more info. 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 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)
description: updated
Revision history for this message
Tim Richardson (tim-richardson) wrote :

If you use gparted to disable your existing EFI partition prior to install, and if you have followed the advice to create a gpt partition table and an EFI partition, you can work around it.
After the install, use gparted to reflag your internal EFI partition.
This worked for me with Ubuntu 18.04 on a new Thinkpad t480 dual boot, with a new install to a thumb drive.
https://askubuntu.com/a/1056079/152287

Revision history for this message
Daniel (danileon95) wrote :

This just happened to me. I tried to put root on the SSD, but the bootloader on the HDD, so that GRUB isn't on the same drive as the Windows bootloader. It completely ignored my choice and installed GRUB on the SSD anyway.

Revision history for this message
Daniel (danileon95) wrote :

To clarify:

I installed Ubuntu in the manual mode. Manually selected the bootloader to be installed on sdb. Still installed it on sda.

Revision history for this message
Phillip Susi (psusi) wrote :

FYI, you can use manual partitioning and mount the ESP of your choice in /efi.

Revision history for this message
Red (reduser) wrote :

Susi,

It appears you aren't reading the full threads. Your solution does not work. This has been a bug for YEARS and needs to be fixed.

I posted a possible real solution or at least how to get started with a real solution above and on the other bug report for this same issue.

Please read the full thread(s) before commenting.

Sincerely,
Red

Revision history for this message
david lindsey (davidlindsey) wrote :

This just happened to me. I was super careful to select the correct drive as I had two USB drives plugged in (one with the installer, one the target of the install) on my Mac. Ubuntu was installed on the correct USB, but the boot loader went on the Mac. I can still boot into macOS by holding down Opt, but I can't boot off the USB stick on other machines because there's no boot loader.

Red, you posted your solution from a different account (tim-richardson), confused me at first.

David

Revision history for this message
Tim Richardson (tim-richardson) wrote :

Hi, I'm tim richardson, a different entity to Red.
I just tested my instructions twice and updated the notes to make sure they are reliable. There was one error which may have been signficant: I previously said to select the EFI partition as the location to install the boot loader during the ubuntu install. In fact, it should be the device, not a partition on the device.

No one has upvoted my answer or made any comment what-so-ever, however,it seems to work.

https://askubuntu.com/questions/16988/how-do-i-install-ubuntu-to-a-usb-key-without-using-startup-disk-creator/1056079#1056079

Revision history for this message
oldfred (oldfred) wrote :

Installed 19.04 to sdb drive (internal, but also flash drive as sdc) and it overwrote my /EFI/ubuntu folder on sda.

I changed combo box which never has done anything with UEFI installs, but it does then say during install that it is installing grub to sdb/external.
I clicked on ESP on sda, and said do not use. I clicked on ESP on sdb and said use as ESP.

Several years ago I installed Fedora, just to see grub differences, and it just installed to sdb when I told it to.

So it is Ubuntu's modifications to grub that make it not install to drive you really want.

Revision history for this message
oldfred (oldfred) wrote :

Just installed 18.04.1 to flash drive sdd.

Installer said this:

Dec 27 19:29:45 ubuntu grub-installer: info: Installing grub on '/dev/sdd'
Dec 27 19:29:45 ubuntu grub-installer: info: grub-install does not support --no-floppy
Dec 27 19:29:45 ubuntu grub-installer: info: Running chroot /target grub-install --force "/dev/sdd"
Dec 27 19:29:45 ubuntu grub-installer: Installing for x86_64-efi platform.
Dec 27 19:30:23 ubuntu grub-installer: Installation finished. No error reported.
Dec 27 19:30:23 ubuntu grub-installer: info: grub-install ran successfully

But again it actually installed to sda's ESP overwriting my main working install's boot on sda drive. ESP on sdd was empty.

From my main working install, once reconfigured grub.cfg to boot main install.

fred@bionic-z97:~$ ll /boot/efi/EFI/ubuntu
total 3728
drwxr-xr-x 3 root root 4096 Dec 27 15:52 ./
drwxr-xr-x 4 root root 4096 Sep 16 15:44 ../
-rwxr-xr-x 1 root root 108 Dec 27 13:30 BOOTX64.CSV*
drwxr-xr-x 2 root root 4096 Dec 27 13:14 fw/
-rwxr-xr-x 1 root root 71400 Dec 27 13:14 fwupx64.efi*
-rwxr-xr-x 1 root root 194 Dec 27 15:52 grub.cfg*
-rwxr-xr-x 1 root root 1116024 Dec 27 13:30 grubx64.efi*
-rwxr-xr-x 1 root root 1269496 Dec 27 13:30 mmx64.efi*
-rwxr-xr-x 1 root root 1334816 Dec 27 13:30 shimx64.efi*

Revision history for this message
oldfred (oldfred) wrote :

Still an issue in 19.04 Disco.
Just installed again to sdb and just like comment above, said it was installing to sdb's ESP, but overwrote my main working install's ESP on sda.
I cannot find any reference to installing to sda.
Installer sees sda as an ESP, but also sees sdb as ESP.

Changed in ubiquity (Ubuntu):
status: Triaged → Confirmed
Revision history for this message
Aleksas Pantechovskis (alex-pantec) wrote :

Seems to be the same bug as described here: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1591352

Revision history for this message
oldfred (oldfred) wrote :

Finally found work around.
Once installer started, I checked mount and mount target mounted ESP on sda. Unmounted that partition & mounted ESP on sdc.

ubuntu-mate@ubuntu-mate:~$ history
    1 mount
    2 sudo umount /target/boot/efi
    3 sudo mount /dev/sdc1 /target/boot/efi
    4 mount

Revision history for this message
aerobat (austrianized) wrote :

This bug is dangerous. I just bricked my company laptop because of it (and will have a very inconvenient talk with IT support)

As long as it is not fixed, there should at least be a warning in the installer - or the option to choose bootloader location greyed out)

Revision history for this message
Gaurav Matta (gaurav-matta) wrote :

oldfred method is working.
So while the system is busy formatting your drive change the mount partitions.

But still I believe this needs to be addressed

Revision history for this message
oldfred (oldfred) wrote :

Noted that target is not mounted until sometime after partitioning screen in Something Else. I unmounted & remounted after adding user & password, but before continuing after that screen.

Also install still used original ESP in fstab. I had to go back & change fstab from sda's ESP to external drive or any second drive's ESP to have correct entry in fstab.

Revision history for this message
Jonathan Amir (yoniamir) wrote :

Looking at the recent comments, I think you are taking this to the wrong direction. There is no point in discussing a workaround for this bug, because even knowledgeable users who know how to apply those workarounds won't know that they even need to look for a workaround before it is too late.

The installer is lying to the end-user, giving it a choice and then ignoring it, while severely harming the system. I think this bug should be critical, not medium (as its duplicate, bug 1173457).

Revision history for this message
Mark (1aunchpad-nct) wrote :

+1 to @yoniamir's comment.

Tom Reynolds (tomreyn)
tags: added: bionic
Revision history for this message
oldfred (oldfred) wrote :

Also applies to Cosmic, Disco & Eoan. Never been fixed.

Just installed Debian Buster to see how it handled grub. I did not select an ESP and it told me to go back and choose a partition as /efi/boot. I choose sdb's ESP and it installed without issue to ESP on sda, and did not overwrite my Ubuntu boot in sda. It did make Buster first in UEFI boot order, but my Ubuntu was second in UEFI boot order & Buster's grub2 os-prober found all my other install, so I could boot them.

Probably will use Debian's version of grub since it works, even to boot my Ubuntu.

Tom Reynolds (tomreyn)
tags: added: disco eoan rls-ee-incoming xenial
Changed in ubiquity (Ubuntu):
importance: Medium → High
Steve Langasek (vorlon)
tags: added: rls-ee-notfixing
removed: rls-ee-incoming
Revision history for this message
Evil Bots (evil-bots) wrote :

Confirming I just had this exact same issue in Disco Dingo (19.04) installation. Attached to my Windows SSD instead of my Ubuntu SSD

Revision history for this message
Daniel Bélisle (cdnhermit) wrote :

This is to confirm that the procedure mentioned by response #12 from Tim Richardson solve my problem of being able to install Ubuntu on an external drive without having its boot on my internal drive. This is perfect. Thank you Tim Richardson. and oldfred who mentioned this page.

Revision history for this message
Shreyansh Chouhan (bk1603) wrote :

I'd like to try and attempt fixing this issue if no one else is currently working on it.

Though this will be my first time contributing code to ubuntu so I might need some help :)

Revision history for this message
Char Aznable (char-aznable) wrote :

This happened to me and bricked my computer too. Also +1 to @yoniamir's comment.

Revision history for this message
walterav (walterav) wrote :

This still affects me on ubuntu-mate 19.10 amd64 also while selecting the option "erase disk" which only prompts you to select a "single disk" on which ubuntu will be installed even false summarizing that no other disks/partitions will be altered which is a lie! This happens in both UEFI and legacy bios mode installs.

With the Legacy BIOS install the damage could be worse since it will destroy MBR tables of any earlier SDA disk on which GRUB will install the bootloader resembling the old "Microsoft Windows XP installer" on which you'd better physically unplug any other disk on which you don't want the OS install to run.

Searching for a launchpad bugreport for the legacy part anyone?

Revision history for this message
Per-Inge (per-inge-hallin) wrote :

On computers with HDA or SDA drives it is possible to disconnect all drives except the installation drive to install grub on the wanted drive.
This is however not a practical solution with NVme drives.
As I want to use the development version of Ubuntu early this is normally the last installation and will provide the used grub. To have to use grub of the development version gives a high risk to crash the whole computer.
I suppose this also is the case when you want to use IOS, Fedora or Windows as your "master" version in a computer and clearly separate the different installations.

Revision history for this message
Danilo Cominotti Marques (dcominottim) wrote :

This really needs to be fixed for 20.04 LTS... It's such a major bug that hasn't been receiving any attention...

Revision history for this message
Reece (kupoinyourwindow) wrote :

I've just run into this bug on my 20.04 install, and I literally just do not know how to manually fix it.

Revision history for this message
Christian Nassau (nassau) wrote :

I think I have just been hit by that bug too: fresh install of (X)Ubuntu 20.04 on a new computer with a new SSD, which also happened to have an old HDD with an existing EFI boot paritition. I chose the "expert" option for the partitioning dialog in install and explicitly specified the new SSD as the intended boot device. The install used the existing EFI on the old HDD instead.

Recovering was not easy (with hindsight there might have been better options): I physically removed (!) the HDD, installed a 2nd copy of Ubuntu 20.04 on a new separate partition on the SSD, again in "expert mode". During installation I was warned that there was no EFI partition and the system would be unusable, so I manually created an EFI partition for /boot/efi on the SSD. I then replaced the relevant lines in /etc/fstab of the first attempt with the correct ones from the 2nd. After a succesful reboot into the fixed system I added the old HDD again and manually ran "apt-get --reinstall install grub-common os-prober grub-efi-amd64" to rescan the HDD for extra grub entries.

To prevent others from running into this problem it would make sense to add another warning to the "expert" install process: there already is a check for the existence of at least one EFI partition in the system - this check should also warn if the EFI partition is not on the device that the user has explicitly selected for the boot loader.

Revision history for this message
Tim Richardson (tim-richardson) wrote : Re: [Bug 1396379] Re: installer uses first EFI system partition found even when directed otherwise

Easiest workaround is to use gparted or similar to remove the EFI/boot flag
on existing EFI partitions before the install.

On Sun, 10 May 2020 at 19:55, Christian Nassau <email address hidden>
wrote:

> I think I have just been hit by that bug too: fresh install of (X)Ubuntu
> 20.04 on a new computer with a new SSD, which also happened to have an
> old HDD with an existing EFI boot paritition. I chose the "expert"
> option for the partitioning dialog in install and explicitly specified
> the new SSD as the intended boot device. The install used the existing
> EFI on the old HDD instead.
>
> Recovering was not easy (with hindsight there might have been better
> options): I physically removed (!) the HDD, installed a 2nd copy of
> Ubuntu 20.04 on a new separate partition on the SSD, again in "expert
> mode". During installation I was warned that there was no EFI partition
> and the system would be unusable, so I manually created an EFI partition
> for /boot/efi on the SSD. I then replaced the relevant lines in
> /etc/fstab of the first attempt with the correct ones from the 2nd.
> After a succesful reboot into the fixed system I added the old HDD again
> and manually ran "apt-get --reinstall install grub-common os-prober
> grub-efi-amd64" to rescan the HDD for extra grub entries.
>
> To prevent others from running into this problem it would make sense to
> add another warning to the "expert" install process: there already is a
> check for the existence of at least one EFI partition in the system -
> this check should also warn if the EFI partition is not on the device
> that the user has explicitly selected for the boot loader.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1396379
>
> Title:
> installer uses first EFI system partition found even when directed
> otherwise
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+subscriptions
>

--
Tim Richardson

Revision history for this message
Mark (1aunchpad-nct) wrote :

I find it unbelievable that this serious bug, which has been confirmed and given *high* importance, has still not been fixed nearly 6 years after it was reported. When it happens it really f***s up your system and recovering can be very painful.

Revision history for this message
Jonathan Amir (yoniamir) wrote :

A workaround is not relevant because the users that are hit by this bug don't know that they need a workaround until it is too late. I don't remember ever installing Linux and knowing beforehand that I need to apply a workaround to circumvent the installer.
I know I sound like a broken record (see my previous comment here), but the whole point of this bug is that the installer is lying to end-users. It presents an option to choose a boot device and then ignores that choice and severely damages the laptop.

Consider that not all users are highly technical and know how to use gparted or mount, or what are boot flags. All they want is Ubuntu on their usb flash drive. It can cause a great deal of aggravation to fix a bricked laptop (and potential loss of money too). It also definitely reduces those users trust and engagement with Ubuntu.

Personally, I don't think that adding more details to the installer like another warning message is an adequate solution. The solution has to be one of two things:
1) Fix the option to choose boot device correctly
2) or remove this option from the installer completely until you are ready to support it properly.

Revision history for this message
oldfred (oldfred) wrote :

Now also applies to Groovy.

Tried to install test version of Groovy into HDD. Did not want defaults in NVMe SSD changed, so during Something Else install changed combo box to sda, told it not to use ESP on NVMe drive, use ESP on sda. Also told it not to use swap and it did not use swap, but used ESP on NVMe drive.

At name & password screen had to change mount

/dev/sda8 on /target type ext4 (rw,relatime,errors=remount-ro)
/dev/nvme0n1p1 on /target/boot/efi type vfat (rw,relatime,fmask=0077,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
ubuntu@ubuntu:~$ sudo umount /dev/sda8
umount: /target: target is busy.
ubuntu@ubuntu:~$ sudo umount /dev/nvme0n1p1
ubuntu@ubuntu:~$ sudo mount /dev/sda1 /target/boot/efi

Revision history for this message
tea for one (markexhome) wrote :

I have also fallen foul of this bug after trying to install Ubuntu 20.10 on a second disk.
I agree with the sentiment in post 41 specifically:-

1) Fix the option to choose boot device correctly

Revision history for this message
Ket (ketasov514) wrote :

This bug has just killed my dual boot machine and I have no idea how to fix it without formatting and reinstalling everything from scratch! How this *critical bug* which was assigned High priority is open since 2014 is beyond my understanding.
The installation UI simply lies to the user - it tells you to choose the partition on which to install the boot loader and then disregards it completely and installs wherever it wants, that's really dangerous!

Revision history for this message
Ket (ketasov514) wrote :

Would like to add that I believe this bug's priority should be changed from High to Critical.

Revision history for this message
John S. Gruber (jsjgruber) wrote :

@ket I agree that this is frustrating.

You shouldn't have to reformat your disk to fix it, however. You should be able to plug in the device with your newly installed Ubuntu, boot up until you see the grub prompt asking you what system you want to boot, and then choose the old Ubuntu version on your hard disk.

The other alternative to reformatting is to boot from the install CD to make repairs.

Getting back to not having to plug in the old device involves changing a file on your hard disks efi partition, ubuntu/grub.cfg in order to point it back to the original disk partition you want to boot from.

Revision history for this message
Marco Paulo Martins Sousa (marcomsousa) wrote :

The same issue.

Ubuntu broke my Windows EFI system partition, installing Ubuntu EFI on it, despìte I have told Ubuntu to use the external drive.

*To fix the Windows EFI system partition:*

* Boot on Windows CMD using a Recovery Partition/USB Drive
** Windows Bootloader Recovery -> System Restore – > Troubleshoot-> Command Prompt
diskpart
list disk
list partition
list volume
sel disk 0 (Select the disk with the Windows EFI system partition)

Assign the drive letter K: to the hidden EFI volume:
select volume 1 (select the volument with the Windows EFI system partition)
assign letter K:
exit

cd /d K:\efi\microsoft\boot\
attrib BCD -s -h -r
ren BCD BCD.bak
bcdboot C:\Windows /l en-us /s k: /f ALL

*Don't use this commands, because this are only for MBR not UEFI mode:*
* bootrec /fixboot
* bootrec /scanos
* bootrec /rebuildbcd
* or even:
* bootrec /FixMbr

Revision history for this message
Robert Bernecky (bernecky) wrote :

I have lost about a month of my time with this bug!!
I thought I was doing something wrong with UUID or GPT vs MBR or ZFS or ...
It creamed my live benchmark system that I had spent considerable time
installing and customizing.

Just today, I stumbled onto this archaic bug report, which remains unfixed
after seven years!

Since my system has several nvme drives, I can't just unplug them to work
around the problem.

I agree that this bug is critical, not just "high".

Revision history for this message
Tim Richardson (tim-richardson) wrote :

You don't have to unplug them. The minimal workaround, and what I always
use, is before the install, unflag the EFI partitions of drives you don't
want to target. Somewhere in this bug report I have my tips on this, and I
also wrote it up here https://askubuntu.com/a/1056079/152287

On Sat, 30 Jan 2021 at 09:09, Robert Bernecky <email address hidden>
wrote:

> I have lost about a month of my time with this bug!!
> I thought I was doing something wrong with UUID or GPT vs MBR or ZFS or ...
> It creamed my live benchmark system that I had spent considerable time
> installing and customizing.
>
> Just today, I stumbled onto this archaic bug report, which remains unfixed
> after seven years!
>
> Since my system has several nvme drives, I can't just unplug them to work
> around the problem.
>
>
> I agree that this bug is critical, not just "high".
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1396379
>
> Title:
> installer uses first EFI system partition found even when directed
> otherwise
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+subscriptions
>

--
Tim Richardson

Revision history for this message
Angry Man (angryman123) wrote :

Just happened to me as well. Bricked my Windows install.

I wanted to try out Linux again to see where it's at in 2021. I decided to go with the most common distro thinking it wouldn't have bugs like this. Silly me.

Fix this. Pretty please with sugar on top.

Revision history for this message
Tobias Eiberle (utoppo) wrote :

I ran into the same issue. And I also think this bug is critical, not high. I would be very happy if this could be fixed as soon as possible.

Revision history for this message
Andrew Bauer (aendie) wrote :

This appears to be the problem I ran into with Ubuntu Desktop 20.10 as reported here:
https://askubuntu.com/questions/1321431/ubuntu-desktop-20-10-on-usb-flash-drive-boots-only-on-original-computer

If it is the same problem (and not a limitation with the latest [but old] ASUS N551VW BIOS) then please escalate this ABOVE CRITICAL.

I'm sure a lot more Windows 10 users would delight to have a bootable Ubuntu system on a USB Flash Drive (or an externally USB-connected SSD, e.g. in an ICY BOX) if the "Device for boot loader installation" set to /dev/sdb would really write something there. I also noticed a couple of error messages during booting - one was only a few seconds on the screen so I was not able to capture it. I will post what I have (in AskUbuntu) if it is of any assistance to you. My laptop works perfectly (error-free) with Windows 10.

Apparently the workaround is to remove Disk 0 (Windows 10 drive) from the laptop. I will give this a try though I doubt that the casual user would go so far as to unscrew the back cover of their laptop to remove their HD/SSD.

Tom Reynolds (tomreyn)
tags: added: focal
Revision history for this message
Tim Richardson (tim-richardson) wrote :

Note: you don't have to physically remove the internal drive. You simple
need to temporarily remove the boot flag from the EFI partition, do the
install and the turn on the boot flag again. Very easy. I document it here:
https://askubuntu.com/a/1056079/152287

On Sun, 7 Mar 2021 at 02:46, Andrew Bauer <email address hidden>
wrote:

> This appears to be the problem I ran into with Ubuntu Desktop 20.10 as
> reported here:
>
> https://askubuntu.com/questions/1321431/ubuntu-desktop-20-10-on-usb-flash-drive-boots-only-on-original-computer
>
> If it is the same problem (and not a limitation with the latest [but
> old] ASUS N551VW BIOS) then please escalate this ABOVE CRITICAL.
>
> I'm sure a lot more Windows 10 users would delight to have a bootable
> Ubuntu system on a USB Flash Drive (or an externally USB-connected SSD,
> e.g. in an ICY BOX) if the "Device for boot loader installation" set to
> /dev/sdb would really write something there. I also noticed a couple of
> error messages during booting - one was only a few seconds on the screen
> so I was not able to capture it. I will post what I have (in AskUbuntu)
> if it is of any assistance to you. My laptop works perfectly (error-
> free) with Windows 10.
>
> Apparently the workaround is to remove Disk 0 (Windows 10 drive) from
> the laptop. I will give this a try though I doubt that the casual user
> would go so far as to unscrew the back cover of their laptop to remove
> their HD/SSD.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1396379
>
> Title:
> installer uses first EFI system partition found even when directed
> otherwise
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+subscriptions
>

--
Tim Richardson

Olivier Robert (novhak)
tags: added: groovy
Revision history for this message
Olivier Robert (novhak) wrote :

k8s blah blah blah, but such a critical thing has been around for more than six years. I can imagine how it can undermine the credibility of Linux for newcomers...

Revision history for this message
oldfred (oldfred) wrote :

Just installed Hirsute as of April 18,2021.
hirsute-desktop-amd64.iso

Same issue.

I tried to use Ubiquity installer options to change where grub is installed and they did not work.

Used grub2's loopmount to boot ISO. It mounts isodevice to NVMe drive but installer, when it asks to remove mounts does not remove it. I have to manually unmount it.
Then it does not show mount of ESP on NVMe drive, but once past partitioning screen and saying not to use ESP on NVMe drive, it mounts ESP on NVMe drive.

I have to check mounts during install process, unmount isodevice and unmount incorrect ESP and mount correct ESP.
mount
sudo umount -lrf /dev/nvme0n1p5
lsblk -f
mount
sudo umount /dev/nvme0n1p1
sudo mount /dev/sda1 /target/boot/efi

Revision history for this message
K Dietrich (kdietrich) wrote :

Thanks to all you guys for the description of the problem and the suggested fix by changing the boot flag of the preexisting efi partition. I spent quite some timee trying to fix this, since I thought i might have done something wrong.

If I understand the problem correctly, Ubuntu has a bug for mor than 6 years, which breaks the system when a user wants two efi partitions to use dual boot with Windows. This would be the only installation method that would not be hampered with interferences by windows updates. And it is a problem which does not occur with Debian, on which ubuntu is based on.

This raises the question for me if repairing the ubuntu installation is the right choice for me. I just want an easy to use system without too much digging. I really have to think about whether I want to apply this workaround.

It also makes me a little less furious that Microsoft decided to just revert any changes on *their* efi partition during updates, when they notice tempering from other OS, since *other* OS might be a little bit careless by risking harm not only for their own installation but also for Windows.

Revision history for this message
Jonathan Bakert (jbakert) wrote :

I made a joke that when I scrolled down this would still happen ages later and here we are.

The single most important thing to a new user experience, heck, *any experience at all*, is the installation ease.

I can only wonder if the neglect of this issue is arising from contempt for those who use Windows.

Revision history for this message
Luiz Fernando (ryche.rising) wrote :

I sufer with this issue dor years, and it still haunts the hell out of me.
I'm tired of installing on special prepared hardware with no drives.
Please fix this asap.
Please with sugar on top!

Revision history for this message
martin (omgalvan-86) wrote :

This sounds like a massive, GIGANTIC bug which is corrupting people's boot setups. It's a wonder that it hasn't been fixed after SEVEN YEARS.

Revision history for this message
Tim Richardson (tim-richardson) wrote :

It doesn't corrupt boots. It's inconvenient.

On Wed, 1 Sept 2021, 15:31 martin, <email address hidden> wrote:

> This sounds like a massive, GIGANTIC bug which is corrupting people's
> boot setups. It's a wonder that it hasn't been fixed after SEVEN YEARS.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1396379
>
> Title:
> installer uses first EFI system partition found even when directed
> otherwise
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+subscriptions
>
>

Revision history for this message
Ben Fritz (fritzophrenic) wrote :

> It doesn't corrupt boots. It's inconvenient.

Yes, it does corrupt boot setups. I'm not sure how you can say it doesn't.

I mean I guess TECHNICALLY it "only" overwrites working boot setups, with non-working boot setups; it's not actually corrupting existing files with garbage data.

My encounter with this bug, several years ago now, was when I was trying to set up a USB stick my daughter could plug into her crappy notebook laptop to boot to Xubuntu, but leaving Windows installed on the laptop itself. I wanted it as dead-easy as possible. Boot with USB inserted: boots to Xubuntu (stored on the USB). Boot without USB: boots to Windows. Like a live USB, but a full install which we could keep up-to-date and with writable storage for files and a user profile and stuff.

I painstakingly partitioned the USB as needed, and selected the partition on the USB to install grub to.

Result: Windows bootloader on the laptop's eMMC storage replaced with grub configuration that can only boot with the USB inserted. Windows was no longer able to boot normally at all. I did eventually fix it and get it to the state I wanted. But initially, the Ubuntu installer absolutely ignored my explicit instructions and therefore completely broke a working setup. I'm pretty sure (my memory is fuzzy from several years ago) I needed to resort to restoring a full-disk backup image to fix the Windows install. Either that, or I used some sort of recovery tool to fix a nonfunctional EFI partition.

That's way beyond just being "inconvenient".

Revision history for this message
TJ (tj) wrote (last edit ):

This was just brought to my attention so I took a look at the source-code. Thanks to oldfred's comment #20 showing part of the installer log that helps isolate the source-code responsible.

It looks like this is a result of this code - written in 2006 - assuming a debconf entry that is empty and in consequence choosing a default device. Adding some debug prints into the code might confirm that and allow it to be fixed.

See specifically line 45 in grubinstaller.py (Python code)

https://git.launchpad.net/ubuntu/+source/ubiquity/tree/ubiquity/components/grubinstaller.py#n45

Calling misc.grub_default() from:

https://git.launchpad.net/ubuntu/+source/ubiquity/tree/ubiquity/misc.py#n370

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

Duplicates of this bug

Other bug subscribers