[Bug 1926039] Re: Ubuntu Desktop 20.04.2 Installer Clobbers Alternate Drive EFI System Parition

Steve Langasek 1926039 at bugs.launchpad.net
Mon Apr 26 20:22:29 UTC 2021


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 a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
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



More information about the foundations-bugs mailing list