Hi Steve, thanks for responding to my report.
What I mean by clobber is that an existing ESP file BOOTx64.efi is
overwritten on a drive that is *not* the target for the installation.
I had used the 20.10 desktop installer previously with this same HW config
and did not see this effect, but in that case I chose "Do something else"
and arranged the target by hand.
Where things went awry was when I went to install another version of Ubuntu
20.04.2 LTS and accepted the installer's proposal to "Reinstall over
existing option" (forgive me if my memory isn't exact on Ubiquity wording
but I hope you get the gist). This resulted in unexpected change to the
non-target drive.
FURTHER VIEWS
I am not savvy on all the ins-and-outs of OS installation mgmt, what may
necessitate mucking with contents of a foreign ESP, nor why, how this may
be justified, but the end-user experience in my case was that a drive
unrelated to the requested installation was targeted and had a key boot
file overwritten so that when the installation was complete I no longer had
access (at boot) to the existing OS on the non-target drive.
When googling for similar experiences, there is a significant history of
Windows users who want to dual-boot who end up trapped and what lore is
required to get a Windows installer to re-construct the ESP after grub. I
also note that even in Linux lore, grub is a dark art :)
In my case I am playing with OpenCore, which maybe is an edge case not
considered by Ubiquity. I will add that IMO, in age of UEFI, boot mgmt
needs to be de-mystified and that Ubiquity designers could help everyone
with this by being a little less helpful in the installer and getting users
to pay attention to this historically arcane aspect of system config.
Thanks for reaching out to clarify and let me know if I can do anything
else to assist investigation.
/wire
On Mon, Apr 26, 2021 at 1:30 PM Steve Langasek <1926...@bugs.launchpad.net>
wrote:
> What exactly do you mean when you say "clobbers"? The intended behavior
> is for ubiquity to reuse an existing ESP that it detects rather than
> unnecessarily creating a second one. The word "clobber" to me implies
> that it has deleted the existing contents of the ESP; that should not
> happen and would be a bug.
>
> But the fact that the detected existing ESP is on a different drive than
> the Ubuntu root partition is not obviously disqualifying for us to reuse
> that ESP. The ESP does not have to be on the same disk as the root
> partition, and it's not an obvious requirement that disks be independent
> from one another in the system.
>
> ** Changed in: ubiquity (Ubuntu)
>Status: New => Incomplete
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1926039
>
> Title:
> Ubuntu Desktop 20.04.2 Installer Clobbers Alternate Drive EFI System
> Parition
>
> Status in ubiquity package in Ubuntu:
> Incomplete
>
> Bug description:
> SITUATION
>
> System with two drives and two existing OS installations:
> Drive 1) Ubuntu Desktop 20.10
> Drive 2) OpenCore
>
> Re-installing Ubuntu Desktop (20.04.2 LTS) on Drive-1 overwrites the
> EFI System Partition on Drove=2 when it has not been selected as the
> install target.
>
> BEHAVIOR
>
> • The Ubuntu installer properly identifies Drive-1 as an existing
> Ubuntu installation and offers to replace the installation.
>
> • Accepting the offer of replacement installation progresses normally,
> but when installation is complete, the existing other OS on Drive-2
> drive is no longer bootable.
>
> • Examining the non-target Drive-2 shows the EFI System Partition
> EFI/BOOT folder has been overwritten with Ubuntu grub-specific files,
> including the replacement of the non-target EFI/BOOT/BOOTx64.efi
> OpenCore loader by a grub loader and addition of other grub boot
> support files. Replacing the polluted ESP on Drive-2 restores access
> to the other OS.
>
> The non-target Drive-2 should not have been touched. For many users,
> this behavior will appear to be the destruction of the non-target
> drive with total data loss. BIOS boot options will report only grub
> boot capability with no way to restore other OS function and they will
> have no idea how restore the ESP and find their data.
>
> This behavior makes trying Ubuntu a total disaster for new users and a
> good scare for experienced users.
>
> Affected system: Ubuntu Desktop 20.04.2 LTS installing to an existing
> Ubuntu Desktop 20.10.
> Target drive-1 is SATA, single-boot Ubuntu 20.10
> Non-target drive-2 is NVMe, OpenCore
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1926039/+subscriptions
>
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1926039
Title:
Ubuntu Desktop 20.04.2 Installer Clobbers
