installer uses first EFI system partition found even when directed otherwise

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.

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

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

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.

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?

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
>

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.

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

This appears to be a duplicate of 1173457.

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.

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.

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

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.

To clarify:

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

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

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

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

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

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.

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*

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.

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

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

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)

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

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.

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

+1 to @yoniamir's comment.

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.

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

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.

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 :)

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

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?

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.

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

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

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.

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

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.

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.

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

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

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!

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

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

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

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

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.

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.

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.

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

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

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

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.

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.

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!

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.

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

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

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

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.

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.

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

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.

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.

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?

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.

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

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

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.

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)?

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

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

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

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.

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

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

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
https://iso.qa.ubuntu.com/qatracker/reports/bugs/1396379

Wrecked my system last week
Ubuntu installer makes no sense of what it is doing, and doesn't have a simple option to install to a specific drive and partition and warn if it is going to clobber something else

This bug doesn't clobber anything. So if that happened, it's a different
bug.

On Sun, 6 Nov 2022 at 07:20, Mm <email address hidden> wrote:

> Wrecked my system last week
> Ubuntu installer makes no sense of what it is doing, and doesn't have a
> simple option to install to a specific drive and partition and warn if it
> is going to clobber something else
>
> --
> 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/grub-efi-amd64-signed/+bug/1396379/+subscriptions
>
>

--
Tim Richardson

Grub gets rewritten, with a dependency upon the target's root, so if the target is a removable USB, and you remove it, (think a 32GB USB stick you want to give to a friend), grub files get removed too, and your host system no longer boots. (and of course your target USB does not boot either) That's a critical bug according to https://wiki.ubuntu.com/Bugs/Importance:

Critical: A bug that has a severe impact on a large portion of Ubuntu users

    Causes data corruption
    Crashes the entire operating system
        For example, if the system fails to boot, or X fails to start, on various makes and models of computer
    Renders the system temporarily or permanently unusable

It's a quibble to say the bug didn't clobbered the system when the user removes the removable target, after the installer ignores the explicit grub target location.

I hope this bug gets fixed, but my experience of it in your scenario is
merely that the host system has a grub entry which doesn't boot if the the
USB stick is not present but which doesn't affect existing entries, and
meanwhile the USB stick has no functional EFI partitions so it can't be
used as a boot device.

On Mon, 7 Nov 2022, 03:55 Ubfan, <email address hidden> wrote:

> Grub gets rewritten, with a dependency upon the target's root, so if the
> target is a removable USB, and you remove it, (think a 32GB USB stick
> you want to give to a friend), grub files get removed too, and your host
> system no longer boots. (and of course your target USB does not boot
> either) That's a critical bug according to
> https://wiki.ubuntu.com/Bugs/Importance:
>
> Critical: A bug that has a severe impact on a large portion of Ubuntu
> users
>
> Causes data corruption
> Crashes the entire operating system
> For example, if the system fails to boot, or X fails to start, on
> various makes and models of computer
> Renders the system temporarily or permanently unusable
>
> It's a quibble to say the bug didn't clobbered the system when the user
> removes the removable target, after the installer ignores the explicit
> grub target location.
>
> --
> 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/grub-efi-amd64-signed/+bug/1396379/+subscriptions
>
>

Tim, I'll refer you to my earlier response to you on this exact same question 1 year ago: https://bugs.launchpad.net/ubuntu/+source/grub-efi-amd64-signed/+bug/1396379/comments/61

This bug DOES clobber boot setups.

In my specific example, I was trying to leave the laptop untouched. The Windows bootloader would remain untouched on the laptop built-in storage. I would change BIOS settings to prefer USB boot, and install Ubuntu to a USB stick. The GRUB setup on the USB stick would ONLY have Ubuntu configured. Intended end result: boot with USB plugged in, system acts like it only has Ubuntu and boots immediately into Ubuntu. Boot without USB: system acts like it only has Windows installed and boots directly to Windows with no delay.

Actual result: Windows bootloader overwritten with a grub config containing only Ubuntu. Windows is completely unable to boot. Ubuntu is completely unable to boot unless the USB is plugged in.

I see no way to spin this as not clobbering data.

I was able to recover in the end, I can't remember how, probably I used Windows repair on bootable Windows install media. Years later, now, the laptop actually has Xubuntu installed directly with no trace of Windows at all. But at the time it was infuriating. I "ruined" my kid's laptop trying to do things in a way I perceived as minimal risk, double- and triple-checking the installer settings to make absolutely certain I wasn't touching the main laptop storage.

Admittedly, clobber means different things to different people, but 100% of
people who UEFI boot off an sda, and try an Ubuntu install to a USB target,
and specify the target's EFI as the bootloader location, (without taking the
corrective measures detailed in the bug or askubuntu question 16988), will be
faced with a grub prompt at reboot after removal of the USB target. Of these,
98%+ will be in a state of panic or near panic.

For those people: DON'T PANIC.
A Window only machine, or a dual boot with Windows can ALWAYS use the EFI menu
to boot Windows. This avoids grub completely.The EFI menu is invoked by some
machine specific key at power-up to allow a choice of device or OS to boot)
The key may be listed on the initial splash screen at power-up, but usually
one of these: ESC, F1, F10, F12, DEL.

Any OS (think Ubuntu) on the host depending upon grub to boot is stuck behind
the grub prompt without the USB target present. All caused by using the USB
target's UUID instead of the host's root UUID in the EFI partition's three line
stub file ...EFI/ubuntu/grub.cfg. If you know the partition number x for the
OS root, simply type:
configfile (hd0,x)/boot/grub/grub.cfg
and get back to a grub menu, boot the host, then do two things:
1)Fix your target -- simply copy the host's EFI files to
the USB target's EFI to make the USB bootable. You don't need
the ...EFI/Microsoft... files, but they don't hurt anything.
2)Fix the host -- run:
sudo grub-install /dev/sda

Leaving the USB in place will work, for awhile. The grub menu is produced from
the USB's /boot/grub/grub.cfg file. If you boot the host OS, updates may
change kernels, and the host's grub.cfg, but not the USB target's grub.cfg
file. If you don't notice your running kernel is not the latest kernel in this
situation, eventually the USB grub.cfg may be too obsolete to contain any
kernel left on the host, you can no longer boot, and you have joined the
"Update Broke My Machine" queue. Boot the USB before this happens and at least
run update-grub if you don't actually update a kernel. This will keep the
USB's grub.cfg file current.

Thanks Ubfan, that is helpful so next time it happens to Ben or someone
else, if they are lucky enough to find this bug report they know what to
do. It is normal for a machine to have multiple EFI entries, and Windows is
ok with that.If you see Grub, you have selected to boot into Linux. All you
have to do is instead choose to boot into Windows via the EFI options.
Supporting multiple boots is part of the design of EFI. So the bug of the
installer does not render Windows unbootable. But it is very annoying none
the less.

On Wed, 9 Nov 2022 at 10:35, Ubfan <email address hidden> wrote:

> Admittedly, clobber means different things to different people, but 100% of
> people who UEFI boot off an sda, and try an Ubuntu install to a USB target,
> and specify the target's EFI as the bootloader location, (without taking
> the
> corrective measures detailed in the bug or askubuntu question 16988), will
> be
> faced with a grub prompt at reboot after removal of the USB target. Of
> these,
> 98%+ will be in a state of panic or near panic.
>
> For those people: DON'T PANIC.
> A Window only machine, or a dual boot with Windows can ALWAYS use the EFI
> menu
> to boot Windows. This avoids grub completely.The EFI menu is invoked by
> some
> machine specific key at power-up to allow a choice of device or OS to boot)
> The key may be listed on the initial splash screen at power-up, but usually
> one of these: ESC, F1, F10, F12, DEL.
>
> Any OS (think Ubuntu) on the host depending upon grub to boot is stuck
> behind
> the grub prompt without the USB target present. All caused by using the USB
> target's UUID instead of the host's root UUID in the EFI partition's three
> line
> stub file ...EFI/ubuntu/grub.cfg. If you know the partition number x for
> the
> OS root, simply type:
> configfile (hd0,x)/boot/grub/grub.cfg
> and get back to a grub menu, boot the host, then do two things:
> 1)Fix your target -- simply copy the host's EFI files to
> the USB target's EFI to make the USB bootable. You don't need
> the ...EFI/Microsoft... files, but they don't hurt anything.
> 2)Fix the host -- run:
> sudo grub-install /dev/sda
>
> Leaving the USB in place will work, for awhile. The grub menu is produced
> from
> the USB's /boot/grub/grub.cfg file. If you boot the host OS, updates may
> change kernels, and the host's grub.cfg, but not the USB target's grub.cfg
> file. If you don't notice your running kernel is not the latest kernel in
> this
> situation, eventually the USB grub.cfg may be too obsolete to contain any
> kernel left on the host, you can no longer boot, and you have joined the
> "Update Broke My Machine" queue. Boot the USB before this happens and at
> least
> run update-grub if you don't actually update a kernel. This will keep the
> USB's grub.cfg file current.
>
> --
> 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/grub-efi-amd64-signed/+bug/1396379/+subscriptions
>
>

--
Tim Richar...

I can't believe that you are downplaying the severity of this, arguing about what clobber means, and going (again) into the technical details of how grub works.

It is the user experience that matters, not the technical details. Please think about the non-technical end-users. For them, their machine is bricked. They might not even know that they can boot the machine with the usb drive in it. Even if they knew, this is not an acceptable proposition.

Even if the technical help is available for them, in the form of a friend, a colleague, a local repair lab or even a google search, how many hours or days, work-time and money will they lose before their machine is back to normal? (https://bugs.launchpad.net/ubuntu/+source/grub-efi-amd64-signed/+bug/1396379/comments/41)

Has anyone found precisely the line of code where the ESP is mounted? #75 found a partman script that creates the fstab for it, but where is that called from by ubiquity?

I'm not downplaying the severity, I am being accurate about it. Bugs are
given severity ratings so that good priority decisions are made. I can't
fix this bug in any practical way, but the least we can do is keep the bug
report accurate.
It is an annoying and bad user experience for a fairly niche instance. That
is bad. But this bug does not cause actual data loss, and we should not say
that it does when it doesn't. I don't think falsely inflating the severity
of bugs to try to get attention is healthy, although I agree it is
tempting. So now you know my motivation for intervening with this
non-technical content. No more such discussion from me, you either agree or
not about that opinion, and you apparently already agree with my technical
assessment.

On Thu, 10 Nov 2022 at 08:25, Brady Dean <email address hidden> wrote:

> Has anyone found precisely the line of code where the ESP is mounted?
> #17 found a partman script that mounts it, but where is that called from
> by ubiquity?
>
> --
> 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/grub-efi-amd64-signed/+bug/1396379/+subscriptions
>
>

--
Tim Richardson

This bug is not an Ubuntu installer problem or a Debian installer problem. It is 100% a Grub problem. Unbelievable it has gone on this long.

You can recreate this problem in other ways than the OS installers:
From an installed distro of your choice, simply create an ESP and a Linux partition on a thumb drive. Create the file systems and mount the partitions. Then debootstrap your distro to the thumb drive. Chroot into it, customize the hell out of it. Finally apt-get install the EFI version of grub, run grub-install (carefully using the switches to install to the ESP on the thumb drive). Exit the chroot. Although everything looks like it worked, it didn't. Remove the thumb drive, and if you reboot your host computer you created the thumb drive with you'll notice that your boot sector has been overwritten.

The issue is that the wrong partition is mounted to /target/boot/efi, right? grub-install doesn't mount that, ubiquity does.

Look at the attached screenshot from here (in the zip file) https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1591352. When that screenshot was taken grub has not even been installed yet, it was still copying the filesystem.

/dev/sdb is the intended target to install ubuntu, but /dev/sda2 (windows esp) is mounted to /target/boot/efi. grub (the actual bootloader) is installed to /dev/sdb, but when the /boot files are copied the efi directory ends up on the wrong partition.

For whatever reason this borks window's esp and sda isn't bootable anymore, and if sda isn't present then sdb isn't bootable because it's missing the efi directory.

Brady, you are correct. The wrong partition is mounted.

On Thu, 10 Nov 2022 at 14:25, Brady Dean <email address hidden> wrote:

> The issue is that the wrong partition is mounted to /target/boot/efi,
> right? grub-install doesn't mount that, ubiquity does.
>
> Look at the attached screenshot from here (in the zip file)
> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1591352. When
> that screenshot was taken grub has not even been installed yet, it was
> still copying the filesystem.
>
> /dev/sdb is the intended target to install ubuntu, but /dev/sda2
> (windows esp) is mounted to /target/boot/efi. grub (the actual
> bootloader) is installed to /dev/sdb, but when the /boot files are
> copied the efi directory ends up on the wrong partition.
>
> --
> 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/grub-efi-amd64-signed/+bug/1396379/+subscriptions
>
>

--
Tim Richardson

and to Brian's point, it has never happened to me with Fedora.

On Thu, 10 Nov 2022 at 15:32, Tim Richardson <email address hidden> wrote:

> Brady, you are correct. The wrong partition is mounted.
>
> On Thu, 10 Nov 2022 at 14:25, Brady Dean <email address hidden>
> wrote:
>
>> The issue is that the wrong partition is mounted to /target/boot/efi,
>> right? grub-install doesn't mount that, ubiquity does.
>>
>> Look at the attached screenshot from here (in the zip file)
>> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1591352. When
>> that screenshot was taken grub has not even been installed yet, it was
>> still copying the filesystem.
>>
>> /dev/sdb is the intended target to install ubuntu, but /dev/sda2
>> (windows esp) is mounted to /target/boot/efi. grub (the actual
>> bootloader) is installed to /dev/sdb, but when the /boot files are
>> copied the efi directory ends up on the wrong partition.
>>
>> --
>> 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/grub-efi-amd64-signed/+bug/1396379/+subscriptions
>>
>>
>
> --
> Tim Richardson
>

--
Tim Richardson

I think comment #75 is onto something. d-i/source/partman-efi/fstab.d/efi first looks for a partman-auto/disk question and will use the device it specifies to look for an efi partition, otherwise it uses the first one it can find from any device. I can't find anywhere where ubiquity is setting that question, so a quick fix may be to have ubiquity set it. It should be given the same value as the grub-installer/bootdev question.

I have reproduced the issue in a VM by creating vda and vdb, and then selecting use entire disk and selecting vdb for install which is the easiest way to reproduce.

I will try to see if the proposed patch helps later.

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

Milestone ubuntu-22.04.2 sounds encouraging after all these years.

I just ran into this problem again today in 22.04.1.

Would certainly appreciate if this could be fixed. Not only is it inconvenient, but when using Bitlocker for full-disk encryption on the Windows drive, recovery is needed afterwards to get access to Windows again.

The bug broke my Windows EFI partition when trying to dual boot Ubuntu 22.04.1. A fix would be highly appreciated.

Also, sorry for messing up the status in ubiquity. I cannot revert it to triaged.

Is this issue the same as https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/704763? That issue seems to have a patch.

It does not seem like much work of the Desktop team has gone into this bug during the past 9 years and no one seems to be working on it right now - so it's probably not wrong to reset the status to *confirmed*.

--

Bug 704763 discusses multiple installation scenarios, but most seems to be about BIOS booting off a boot sector, based on this quote "[..] the installer STILL overwrote the boot loader of my computer's INTERNAL hard-drive (the one containing Windows Vista) with GRUB".

Comments there refer to UEFI specific bug 1512589, however that is about debian-installer based automated (preseed) installations, and installation method no longer supported.

So both reports differ from THIS bug 1396379, which is about the UEFI booted Ubuntu Desktop installer always installing the boot loader to the first EFI System Partition (ESP) it finds, even if a different installation target for the boot loader was selected by the user.

Since Ubuntu 23.04 will apparently be using a new installer, does this mean that this bug will not affect Ubuntu 23.04?

@Imamul Islam (mii-1989)

Ubuntu 23.04 DESKTOP is expected to have 2x ISOs, the primary using the new desktop installer, the secondary ISO using the legacy ubiquity installer. You can see that in the iso.qa.ubuntu.com lunar site (http://iso.qa.ubuntu.com/qatracker/milestones/441/builds where the LEGACY testcase will point to a different ISO)

Even if the primary ISO is not impacted; the legacy/ISO installer will likely still be impacted.

Note: I've had little experience with this issue; the only time I could re-create it was when I wrote the ISO to thumb-drive in specific ways & thus was impacted it... ie. a user can trigger this bug report via using specific ISO writes rather than the documented ISO procedures.. I don't doubt real users experienced it using the documented ISO write procedures; but I could not re-create it on the hardware I have access to.

@Chris Guiver (guiverc)

The issue shows up when you have another OS installed on a different drive. Let's say I have Windows installed on /dev/sda, and /dev/sda1 is Windows' EFI partition. I want to install Ubuntu on /dev/sdb, and I want /dev/sdb1 to be Ubuntu's EFI partition. Even after directing the installer to install the EFI on /dev/sdb1, Ubuntu's current installer installs the EFI on /dev/sda1, because it's the first EFI partition it can find.

Does this bug affect Ubuntu 23.04's new installer?

I tested this in 23.04 new installer. It worked, hooray. This is what I did.
Using virtmanager (qemu) on a 22.04 host, I downloaded the 23.04 ISO and created two virtual storage devices (drives).
I installed 23.04 on one of them, using the advanced configuration option to make it a UEFI VM (it's legacy BIOS by default). I did a standard automatic install, rebooted and it works: this is a normal one-drive Ubuntu install. There were two partitions, including 1 GB UEFI partion mounted at /boot/efi exactly as you would expect.

Then I added the second drive to the VM, got it to boot off the install ISO again, and did another install. I went to manual partitioning. I selected the new, second drive as the boot device. The installer immediately created 1 GB vfat partition on the second drive, mounted at /boot/efi and selected it for formatting, which was encouraging.
I formatted the reaming space as ext4 and mounted it to /, and then installed.

The new efi partition was populated. I made the second drive the boot drive and booted from it (you can also activate a boot menu and choose it). There is definitely a working EFI install on the second drive, and grub menu offers the original install as a secondary boot option, which is what I would expect to see.
Also, when I reconfigure grub on the first install to show the grub menu, there is no hint of the second install, which is proof to me that the original EFI partition was untouched by the second install.

Now that the installer in the 23.04 ISO works, are we
sure there are ongoing efforts to fix the 22.04 installer?

Also, @tim-richardson, if I may ask, you've stated here and on AskUbuntu
that it's possible to disable non-target ESPs so that the 22.04 (and previous)
installer won't see them or act on them, by using Gparted to
un-check the boot/efi flags.

Oldfred has stated that he has never gotten that to work, at least when
doing it from inside the "Try Ubuntu" of the installer. I tried it from within the
installer, and also in the Gparted in an internal drive/20.04 OS, but that
method does not work for me at all.

Is there something more to how you're doing this that I may have missed?
(Apologies if this is the wrong place to be asking this question.)

If I and many others are ever going to get the LTS jammy installed, we'll have to use either a correctly functioning installer, or oldfred's workaround method in message #55, though I'd need to understand details of that workaround more than I do now.

I'd like to install the LTS release (jammy) but if the workarounds are such a hurdle,
maybe the easier thing to do is install 23.04 until the next LTS is released.
It'd be the first time I've ever used a non-LTS, because I hate bothering with
frequent new installs and yet again re-configuring my environment.

Hi rj (~watchpocket),
you changed the status of this bug report, filed against Ubiquity (the old Ubuntu Desktop installer), as "fix released".

My understanding is that this issue remains present in the old Desktop installer (which is still the default Desktop installer on older, supported, Ubuntu releases, and is still available as an alternative Desktop installer in 23.04).

Do you know otherwise (I may have missed your statement declaring so)?
If your change was in error, then would you kindly undo it?

In case you meant to comment on the new Desktop installer's issue tracker: This is located at https://github.com/canonical/ubuntu-desktop-installer/issues

Has anyone actually tested the one-line fix in the patch listed under "Related branches" - there's a single line added to a python (script) file.

As it is a python script it is possible to patch that file directly on the installer medium once started when it is running in the copy-on-write file-system of the Try Ubuntu workflow.

The line to add is:

   self.preseed('partman-auto/disk', self.ui.get_grub_choice())

with the correct indentation (must match the surrounding indentation - spaces if spaces, tabs if tabs)

On a running host that file is:

$ dpkg -S ubi-partman.py
ubiquity: /usr/lib/ubiquity/plugins/ubi-partman.py

Or apply the patch file directly with something like:

$ wget -O /tmp/efisp.diff https://code.launchpad.net/~2bdkid/ubuntu/+source/ubiquity/+git/ubiquity/+merge/432828/+preview-diff/992168/+files/preview.diff
$ cd /usr/lib
$ sudo patch -p1 < /tmp/efisp.diff
can't find file to patch at input line 5
...
File to patch:
Skip this patch? [y]
Skipping patch
1 out of 1 hunk ignored
patching file ubiquity/plugins/ubi-partman.py
Hunk #1 succeeded at 3545 (offset -1 lines).

Since the patch also adds to the changelog file and that doesn't exist in the same location the first 'hunk' in the patch will cause warnings to be reported. Press [Enter] when asked "File to patch:" and then answer [y] to "Skip this patch?"

I've tested this in a virtual machine with 2 storage volumes where both have EFI-SP partitions and file-systems, and in the first I mocked up a windows boot entry, but that wasn't enough to fool the installer into thinking there is an existing OS to install alongside - as a result it only offers to "Erase..." or "Something else" so I cannot be sure the same issue would be triggered.

The patch (diff) shows the change to the code:

diff --git a/ubiquity/plugins/ubi-partman.py b/ubiquity/plugins/ubi-partman.py
index 8059446..9620555 100644
--- a/ubiquity/plugins/ubi-partman.py
+++ b/ubiquity/plugins/ubi-partman.py
@@ -3546,6 +3546,7 @@ class Page(plugin.Plugin):
     def ok_handler(self):
         if self.install_bootloader and not self.is_bootdev_preseeded():
             self.preseed('grub-installer/bootdev', self.ui.get_grub_choice())
+ self.preseed('partman-auto/disk', self.ui.get_grub_choice())

         if self.current_question.endswith('automatically_partition'):
             (autopartition_choice, self.extra_choice, method) = \

> Hi rj, you changed the status of this bug report, filed against Ubiquity (the old Ubuntu Desktop installer), as "fix released".

The status change was made in error, my apologies. I seem to be unable to reverse it. (When I click on "Fix released", all the entries in the "Change status to" drop-down are grayed-out. I'm unable to select any of them.) Can someone tell me how I'd change it, should such a thing happen again?

Set back to "confirmed" per above discussion.

my fix is simply to use gparted to remove the boot flag before starting the
installer, and the setting it back when the install is finished. It always
works for me.

On Fri, 5 May 2023 at 00:16, Dan Bungert <email address hidden> wrote:

> Set back to "confirmed" per above discussion.
>
> ** Changed in: ubiquity (Ubuntu)
> Status: Fix Released => Confirmed
>
> --
> 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/grub-efi-amd64-signed/+bug/1396379/+subscriptions
>
>

--
Tim Richardson

Xiao Wang:
If you put the created Ubuntu device back where it was when you created it
you should be able to boot using it for the very beginning of the booting
sequence.

If you can do that you should get a "grub menu" and it should contain a
Windows entry. It may appear very briefly, however.

As you boot quickly and repeatedly press the down arrow button on your
keyboard and you may be able to get the grub menu to stay up so you can
choose its windows entry.

I hope this works for you.

On Sun, Jul 16, 2023 at 2:50 PM Xiao Wang <email address hidden>
wrote:

> Another question, Would anyone know if I could replace Ubiquity (the old
> Ubuntu Desktop installer) to the new one, if I try to make a custom live
> usb of 22.04 LTS using Cubic (Custom Ubuntu ISO Creator)?
>
> --
> 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:
> Confirmed
> Status in ubiquity package in Ubuntu:
> Confirmed
> Status in grub-efi-amd64-signed source package in Jammy:
> Confirmed
> Status in ubiquity source package in Jammy:
> 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
>
>

This "bug" has plagued me for years.

Ubuntu installers (inc dist updaters) routinely overwrite EFI contents on SATA drives that have nothing to do with the Ubuntu target drive for which an update installer is running.

Previously, I reported a case where a fresh install of Ubuntu would overwrite the EFI of an NVMe drive unrelated to the target of the installation (SATA).

But this this this comment pertains to distribution upgrades writing the EFI of the first SATA port on the first controller, even if the Ubuntu installation in on another drive.

This is wrong in two ways

1) Grub is updated on the wrong drive

2) The drive upon which grub is installed might be removed by the user who has no reason to believe that there is a dependency,

3) Any existing bootloader on the unrelated drive, say OpenCore, is overwritten, MEANING DATA LOSS, i.e., "clobbered" by the Ubuntu installer.

If the user has installed Ubuntu on a specific drive, then runs an upgrade, it's obvious that the user's intent cannot be construed to include any other drive than the current install. If the user wishes to make arranges to use another drive for booting, that's the user's business. If Ubuntu wants to help with that, great! But Ubuntu should not be borking drives it has not received instructions to touch.

There is no sane argument that overwriting data on a drive unrelated to the specific installation being updated is not data loss. And because the data are in a location unrelated to the installation and overwritten, then by definition the situation is SEVERE, because the data are unrelated in any way shape or form to the intentions of the user, and the user is given no information as to the change. The user simply finds his configuration is wrecked to the point that he may not be able to operate his device.

The proper behavior is to not touch config on any other device than the target. If the user has not given explicit permission to overwrite configuration on a drive unrelated to the Ubuntu installation, that drive's configuration should not be modified.

If Ubuntu upgrade insists that changing config on another drive is required, the user should be prompted, and given the opportunity to make another arrangement, even if its as simple as cancelling the upgrade.

If Ubuntu detects multiple devices as suitable for grub and offers an option to chose, and maybe a hint, that's helpful. Liberally, the user's intention to modify grub on the EFI of the same drive as the upgrade target is implied, but if the updater applies some intelligence to help guide the user, so much so the better.