installer uses first EFI system partition found even when directed otherwise

Bug #1396379 reported by francesco florian
262
This bug affects 57 people
Affects Status Importance Assigned to Milestone
grub-efi-amd64-signed (Ubuntu)
Confirmed
Undecided
Unassigned
ubiquity (Ubuntu)
Confirmed
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

Revision history for this message
Alan Franzoni (alanfranz) wrote (last edit ):

This is still happening in Ubuntu 21.10, and the installer interface is very confusing.

I wanted to create an Ubuntu installer on an external drive, so I connected the Ubuntu 21.10 live USB to one port, and an USB SSD to another port.

When installing, I made sure to choose /dev/sdc (the usb ssd drive) as my target external device both for installing my system and for installing the bootloader (an explicit option in the modern installer).

In the end, ubuntu installed its uefi files on my internal nvme drive efi partition, making both my system and the external usb ssd non bootable.

My 2c:
this is serious. But if it can't be solved because it's too hard... just don't let the user select their bootloader device, and issue a "BIG FAT WARNING: YOUR MAIN EFI PARTITION - /dev/nvme0p1n1 - will be modified!" message. Then I can choose what to do.

I would expect such behaviour from Windows. Not from Ubuntu.

Revision history for this message
chester (chesteroni) wrote :

I just came across this bug after being forced to reinstall my main OS - I got my grub altered despite making no mistake when installing parallel ubuntu on different device.
I was using 20.04 LTS and I am extremely disappointed with the reason: old bug that made installer not trusted. Fortunately it was my private computer and I was able to make backup of all files so the restoration won't take more than hours.
For me this should not only be *critical* but fixed and backported into all supported editions, LTS including. It's very dangerous and time/money consuming error.

Revision history for this message
Marcin Łaboński (marlabonski) wrote :

Ever wondered why Ubuntu is middle of the pack distro on distrowatch nowadays? This is why.

Revision history for this message
Brady Dean (2bdkid) wrote (last edit ):

I believe the bug is in this function https://git.launchpad.net/ubuntu/+source/ubiquity/tree/ubiquity/plugins/ubi-partman.py?h=applied/ubuntu/impish#n797 (I may have selected the wrong branch here but the same code is present in the 21.10 live CD).

I reported #1591352 when I was in high school and since then I have gotten a degree in CS and started a career in SE. Over the last 6-7 years I have periodically seen comments on this bug report and it's crazy it hasn't been fixed yet.

In my debug log I submitted in 2016, it contains the line "No active iterator for grub device entry." which means it was unable to use the user's selected grub device entry. That function then goes on to select the current disk ID... and promptly bricks all of our systems.

I tested with 21.10 in a VM and the same thing still happens.

A GTK issue shouldn't brick our systems but here we are.

Revision history for this message
Brady Dean (2bdkid) wrote (last edit ):

I finally got ubiquity running in a debugger and it looks like the previous code I mentioned is working fine. Ubiquity is correctly setting the grub-installer/bootdev debconf value.

Revision history for this message
chester (chesteroni) wrote :

So, what is the actual reason of the bug if you verified it with 21.10 but you also checked that it's setting a correct value?

Revision history for this message
Brady Dean (2bdkid) wrote :

Ubiquity invokes the grub-installer bash script to perform the actual boot loader install stuff - it reads the the grub-installer/bootdev debconf value to know where to install the bootloader.

There is some logic in there to find a default boot device which I suspect is how it's picking the first partition of the first drive in the machine, but I'm not very good at debugging shell scripts so I couldn't find a reason as to why it would be using that logic in the first place since grub-installer/bootdev is already set correctly.

tags: added: desktop-lts-wishlist
Revision history for this message
Stooovie (jfiala) wrote :

Still unfixed in May 2022, just came up with Zorin OS 16.

Revision history for this message
Andrew Byrd (andrewbyrd) wrote :
Download full text (3.6 KiB)

I encountered this last week installing Ubuntu 22.04. I booted from USB install media and installed to a second attached USB storage device. I created an EFI system partition on the install target device, and specifically selected this EFI system partition in the GUI as the place to install the bootloader. However the bootloader was instead installed to the EFI system partition of the machine's internal SSD.

I reproduced the process running ubiquity from a terminal with the debug flag. The section of the logs that appears relevant is reproduced below. The logs show it fetching the debconf value and running "grub-install /dev/sdd1", which correctly reflects the partition I selected in the UI.

Based on documentation and various forum discussions I'm reading, my impression is that the device is specified as a parameter to the grub-install command (as Ubiquity seems to be doing here) for MBR installs and EFI installs work differently, requiring the target EFI system partition to be mounted on /boot/efi. Is this correct, and it possible Ubiquity is missing some unmount/remount steps here?

debconf (developer): <-- METAGET grub-installer/progress/step_bootdev description
debconf (developer): --> 1 Determining GRUB boot device...
May 7 21:22:29 debconf (filter): --> 0 OK
May 7 21:22:29 debconf (filter): <-- FGET grub-installer/bootdev seen
debconf (developer): <-- FGET grub-installer/bootdev seen
debconf (developer): --> 0 true
May 7 21:22:29 debconf (filter): <-- GET grub-installer/bootdev
debconf (developer): <-- GET grub-installer/bootdev
debconf (developer): --> 1 /dev/sdd1
May 7 21:22:29 debconf (filter): <-- PROGRESS STEP 1
May 7 21:22:29 debconf (filter): widget found for grub-installer/progress/title
May 7 21:22:29 debconf (filter): --> 0 OK
May 7 21:22:29 debconf (filter): <-- SUBST grub-installer/progress/step_install_loader BOOTDEV /dev/sdd1
debconf (developer): <-- SUBST grub-installer/progress/step_install_loader BOOTDEV /dev/sdd1
debconf (developer): --> 0
May 7 21:22:29 debconf (filter): <-- PROGRESS INFO grub-installer/progress/step_install_loader
May 7 21:22:29 debconf (filter): widget found for grub-installer/progress/title
debconf (developer): <-- METAGET grub-installer/progress/step_install_loader description
debconf (developer): --> 1 Running "grub-install /dev/sdd1"...
May 7 21:22:29 debconf (filter): --> 0 OK
May 7 21:22:29 debconf (filter): <-- INPUT low grub-installer/force-efi-extra-removable
debconf (developer): <-- METAGET grub-installer/force-efi-extra-removable Type
debconf (developer): --> 1 boolean
debconf (developer): <-- INPUT low grub-installer/force-efi-extra-removable
debconf (developer): --> 30 question skipped
May 7 21:22:29 debconf (filter): <-- GO
debconf (developer): <-- GO
debconf (developer): --> 0 ok
May 7 21:22:29 debconf (filter): <-- GET grub-installer/force-efi-extra-removable
debconf (developer): <-- GET grub-installer/force-efi-extra-removable
debconf (developer): --> 1 false
May 7 21:22:32 debconf (filter): <-- GET grub-installer/make_active
debconf (developer): <-- GET grub-installer/make_active
debconf (developer): --> 1 true
May 7 21:22:32 debconf (filter): <-- PROGRESS STEP ...

Read more...

Revision history for this message
Shane O'Sullivan (hitsuji) wrote :

The bug also affects grub-efi-amd64-signed and grub-efi-amd64-bin

So if you follow the above workarounds you still get effected by the bug eventually when one of these packages update.

Revision history for this message
Vlad Tudorache (tudorache-vlad) wrote (last edit ):

I've encountered this bug today (2022-05-20) on Debian 11 and Ubuntu 22.04. Configuration:
Samsung SSD 500 GB as /dev/sda
- EFI System Partition
- MSR
- NTFS (C:)
- Recovery
Toshiba HDD 2 TB as /dev/sdb
- 1,9 TB NTFS (D:)
- 512 MB (/dev/sdb2 -> /boot/efi)
- 2 GB swap (/dev/sdb3)
- 64 GB ext4 (/dev/sdb4 -> /)
It seems that even after selecting /dev/sdb2 as /boot/efi mount point to avoid tampering with the Windows boot loader's location, the installer mounts /dev/sda1 as the EFI partition. So the bug is still there and, for me, it happens also on Debian. This isn't a big problem for me, I've built the PC myself, I know how to use efibootmgr. What about a non-technical user?
Is it really a GRUB bug? Or it's an error of an early step of the installer which happens to be used also by the Ubuntu's installer (should they have some common parts)?

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

Vlad the installer is modifying the wrong EFI partition.

On Fri, May 20, 2022 at 5:00 PM Vlad Tudorache <email address hidden>
wrote:

> I've encountered this bug today (2022-05-20) on Debian 11 and Ubuntu
> 22.04. Configuration:
> Samsung SSD 500 GB as /dev/sda
> - EFI System Partition
> - MSR
> - NTFS (C:)
> - Recovery
> Toshiba HDD 2 TB as /dev/sdb
> - 1,9 TB NTFS (D:)
> - 512 MB (/dev/sdb2 -> /boot/efi)
> - 2 GB swap (/dev/sdb3)
> - 64 GB ext4 (/dev/sdb4 -> /)
> It seems that even after selecting /dev/sdb2 as /boot/efi mount point to
> avoid tampering with the Windows boot loader's location, the installer
> mounts /dev/sda1 as the EFI partition. So the bug is still there and, for
> me, it happens also on Debian. This isn't a big problem for me, I've built
> the PC myself, I know how to use efibootmgr. What about a non-technical
> user?
> Is it really a GRUB bug? Or it's an error of an early step of the
> installer which happens to be used also by the Ubuntu's installer (should
> they have some common parts)?
>
> --
> 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
>
> Status in grub-efi-amd64-signed package in Ubuntu:
> New
> Status in ubiquity package in Ubuntu:
> Confirmed
>
> 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.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/grub-efi-amd64-signed/+bug/1396379/+subscriptions
>
>

Revision history for this message
Lord Enum (lordenum) wrote :
Download full text (3.1 KiB)

So, I thought I'd take a quick look at this bug and why it's not been fixed yet:

There's 3 parts to explore, Ubiquity itself, it's script to handle installing grub (grub-installer) and grub-install itself.

Starting with grub-install itself, it does do something a little unexpected (to me at least) when installing to efi. When running grub-install /dev/sdb the variable that stores /dev/sdb internally is called install_device and when installing efi, that is ignored - as you can see in this code:
https://github.com/phil-opp/x86_64-grub/blob/54ad4ba67db8fd1e38068e49d3d94b88138046f8/util/grub-install.c#L1007 (<--- just the first version that came up in a search, but I assume it's the same in all grub-install.c versions)

So, grub-install relies on /boot or /boot/efi having the fat32 esp partition mounted to it. Looking through the grub-installer it does not do the mounting of /boot/efi itself - but it is correctly parsing the grub partition selected in Ubiquity to grub-install (which grub-install will not use (as explained above)). Ubiquity does the mounting - (it creates /target when installing and then mounts the esp partition to /target/boot/efi)

From a quick look I believe Ubiquity creates the /boot/efi mount via writing a fstab into /target/etc as part of the install process. Long story short, I believe this is handled by
https://git.launchpad.net/ubuntu/+source/ubiquity/tree/d-i/source/partman-efi/fstab.d/efi?h=applied/ubuntu/jammy
^ as you can see, this just searches for the first esp partition it can find, writes the fstab to mount it to /boot/efi and then finishes. Hence we get our problem that it's always the first esp partition that gets written to.

Because this is so convoluted, a fix is not immediately obvious. My own fix is to modify grub-installer so that, just before running grub-install, it checks if the destination is removable (i.e. a USB stick or similar) and, if it is, adds the --removable + --no-nvram flag, unmounts the /target/boot/efi Ubiquity set up and remounts it based on the boot device that will be passed to grub-install. The modification to the grub-installer script (located at /usr/shar/grub-installer) looks like:

if [ -n "$bootremovable" ]; then
   grub_install_params="$grub_install_params --removable --no-nvram"
   umount "$ROOT/boot/efi"
   bootdev_actual="$(fdisk -l | grep "$bootdev" | grep "EFI System" | cut -d' ' -f1)"
   mount "$bootdev_actual" "$ROOT/boot/efi"
fi

As this is my first ever attempt at writing anything in a shell script, this is probably highly naive, but does work, should not have a negative impact to other normal installs (as it only affects installing to removables) and would stop anyone else from screwing up their Windows partition when newbies think about trying out a Ubuntu based distribution on a USB stick and find out, when they next reboot, that instead of booting to Windows they get a grub prompt (typing exit in that prompt does at least allow them to boot Windows - but still, not a pleasant experience).

Attached is a diff that adds this against the version at: https://git.launchpad.net/ubuntu/+source/ubiquity/plain/d-i/source/grub-installer/grub-installer?h=applied/ubuntu/jamm...

Read more...

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in grub-efi-amd64-signed (Ubuntu):
status: New → Confirmed
Revision history for this message
oldfred (oldfred) wrote :

Similarly I manually remount ESP during install, see post #23 above.

Years ago I did use both Debian and Fedora to see if grub installed to sdb. When I chose sdb, grub installed to sdb with those distributions.
So That narrowed it down to some code in Ubiquity.

I am regularly in Ubuntu forums & AskUbuntu and it seems like every day I or multiple other knowledgeable users have to help someone resolve grub installed to first drive when they want it on second or an external drive.

Revision history for this message
Maxim (jestercore) wrote :

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!

tags: added: rls-ll-incoming
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers