installer uses first EFI system partition found even when directed otherwise

Bug #1396379 reported by francesco florian on 2014-11-25
114
This bug affects 26 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)
High
Unassigned

Bug Description

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

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

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

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

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

Phillip Susi (psusi) wrote :

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

Changed in grub2 (Ubuntu):
status: New → Invalid

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

Phillip Susi (psusi) wrote :

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

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

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

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

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

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
>

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

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

John S. Gruber (jsjgruber) wrote :

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

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

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

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

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

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

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

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

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

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

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

Ubfan (ubfan1) wrote :

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.

Phillip Susi (psusi) on 2018-06-21
description: updated

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

Daniel (danileon95) wrote :

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

Daniel (danileon95) wrote :

To clarify:

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

Phillip Susi (psusi) wrote :

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

Red (reduser) wrote :

Susi,

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

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

Please read the full thread(s) before commenting.

Sincerely,
Red

david lindsey (davidlindsey) wrote :

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

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

David

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

oldfred (oldfred) wrote :

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

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

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

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

oldfred (oldfred) wrote :

Just installed 18.04.1 to flash drive sdd.

Installer said this:

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

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

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

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

oldfred (oldfred) wrote :

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

Changed in ubiquity (Ubuntu):
status: Triaged → Confirmed

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

oldfred (oldfred) wrote :

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

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

aerobat (austrianized) wrote :

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

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

Gaurav Matta (gaurav-matta) wrote :

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

But still I believe this needs to be addressed

oldfred (oldfred) wrote :

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

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

Jonathan Amir (yoniamir) wrote :

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

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

Mark (1aunchpad-nct) wrote :

+1 to @yoniamir's comment.

Tom Reynolds (tomreyn) on 2019-06-14
tags: added: bionic
oldfred (oldfred) wrote :

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

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

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

Tom Reynolds (tomreyn) on 2019-07-11
tags: added: disco eoan rls-ee-incoming xenial
Changed in ubiquity (Ubuntu):
importance: Medium → High
Steve Langasek (vorlon) on 2019-07-11
tags: added: rls-ee-notfixing
removed: rls-ee-incoming
Evil Bots (evil-bots) wrote :

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

Daniel Bélisle (cdnhermit) wrote :

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

Shreyansh Chouhan (bk1603) wrote :

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

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

Char Aznable (char-aznable) wrote :

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

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

Duplicates of this bug

Other bug subscribers