[Bug 1396379] Re: installer uses first EFI system partition found even when directed otherwise
Wire
1396379 at bugs.launchpad.net
Fri Aug 18 01:27:50 UTC 2023
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.
--
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
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
More information about the foundations-bugs
mailing list