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.

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.