[Bug 1396379] Re: installer uses first EFI system partition found even when directed otherwise
Ubfan
1396379 at bugs.launchpad.net
Tue Nov 8 23:26:59 UTC 2022
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 a member of Ubuntu
Foundations Bugs, which is 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
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
More information about the foundations-bugs
mailing list