Ubuntu Desktop 20.04.2 Installer Clobbers Alternate Drive EFI System Parition

[Wire]

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

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1926039/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

[Steve Langasek (vorlon)]

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.

[Wire (c-o-pr)]

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 <email address hidden>
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
> EF...

[Launchpad Janitor (janitor)]

[Expired for ubiquity (Ubuntu) because there has been no activity for 60 days.]