[Bug 1766945] Re: (EFI on top of legacy install) choosing "replace" or "resize" options in partitioning may lead to an install failure

[Alan Mintaka]

Trying to install dual-boot ubuntu 18.0.4 with Windows 7

Error "The 'grub-efi-amd64-signed' package failed to install into /
target/.  Without the grub bootloader, the installed software will not
boot."

Note: used gparted to create/format partitions, 
/ (20MB) 
/home (380GB)
  
During install, set mount point of / partition to "/"
mount point of /home to "/home".  

Boot device was set to ATA ST2000DM001-1ER1 (/dev/stda), location of
Windows boot partition. That's the correct boot device for Windows,
anyway.

But installation failed after defining mount points, error message:

"...failed to install into /"
 target/."

(spacing and CR/LF as shown).

Re-ran gparted and saw that / partition mount point had been changed to
/target and /home partition mount point was now undefined (blank).

Don't know if the new mount points are supposed to be intermediate
during install.  If not, install is torching the mount points.  Maybe
related somehow to grub install error?

gparted details before install ("-" designates blank field):

Partition  File Sys  Mount Point  Label            Size        Used        Unused      Flags
/dev/sda1  ntfs      (blank)      System Reserved  100.00 MiB   26.91 MiB  73.09 MiB   boot
/dev/sda2  ntfs      (blank)      C(C:)            1.44 TiB    812.01 MiB  660.28 GiB    -
/dev/sda3  ext4      /            /                20.00         0.0  GiB   25.00 GiB    -
/dev/sda4  ext4      /home        /home            380.00 GiB    0.0  GiB  364.20 GiB    -


gparted details after install error:

Partition  File Sys  Mount Point  Label            Size        Used        Unused      Flags
/dev/sda1  ntfs        -          System Reserved  100.00 MiB   26.91 MiB  73.09 MiB   boot
/dev/sda2  ntfs        -          C(C:)            1.44 TiB    812.01 MiB  660.28 GiB    -
/dev/sda3  ext4      /target      (blank)          19.53 GiB     6.30 GiB  13.23 GiB     -
/dev/sda4  ext4        -          (blank)          371.09 GiB    6.89 GiB  364.20 GiB    -

System:
Dell XPS 8700
Intel Core i7-3770
HDD 2.0 TiB
Windows 7 Home Premium x64

Final note: Installed OK on Dell Alienware laptop 17 R3

Intel core i7 6700HQ
Windows 10 Home

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to partman-auto in Ubuntu.
https://bugs.launchpad.net/bugs/1766945

Title:
  (EFI on top of legacy install) choosing "replace" or "resize" options
  in partitioning may lead to an install failure

Status in partman-auto package in Ubuntu:
  Fix Released
Status in partman-efi package in Ubuntu:
  Fix Released
Status in ubiquity package in Ubuntu:
  Fix Released
Status in partman-auto source package in Bionic:
  Fix Released
Status in partman-efi source package in Bionic:
  Fix Released
Status in ubiquity source package in Bionic:
  Fix Released

Bug description:
  [Impact]

  If I have existing data on disk built by a previous version of Ubuntu
  (in BIOS (legacy) mode, or a previous Windows install, and no EFI
  system partition on disk; the installer presents three choices:

  - Replace $existing and reinstall.  (if a previous Ubuntu install was found)
  - Resize and install
  - Erase disk and install.

  The first two options will attempt to complete the installation in EFI
  mode (as they should) but do not create an EFI system partition, which
  is required as a place to put shim and grub on disk for booting. The
  installer will then crash / fail as grub-install fails to find the ESP
  when copying the bootloader.

  The last option works correctly, it creates the ESP as it erases the
  entire disks and proceeds with new partitioning.

  The proposed changes fix ESP creation for the replace and resize
  cases, additionally disabling the reuse-partition option as it would
  lead to unbootable systems without an existing ESP.

  [Test Case]

  A few valid cases to try, both for desktop and server, each of these
  on a clean disk:

   * In legacy BIOS mode, install Ubuntu (whole disk).
   * Switch to UEFI mode
   * Start the Ubuntu installer.
   * In partitioning, make sure the 'reuse existing partition' option is not visible (reuse, 'replace' should still be present).
   * Select resize and install.
   * Check if installation succeeds and system boots.

   * In legacy BIOS mode, install Ubuntu (whole disk).
   * Switch to UEFI mode
   * Start the Ubuntu installer.
   * In guided partitioning select the replace existing and install option.
   * Check if installation succeeds and system boots.

   * In legacy BIOS mode, install Ubuntu (manual partitioning, create 3 primary partitions, leave enough free space for another install).
   * Switch to UEFI mode
   * Start the Ubuntu installer.
   * In guided partitioning select the use biggest free space option.
   * Check if installation succeeds and system boots.

   * In UEFI mode start the Ubuntu installer.
   * Select a clean whole-disk install.
   * Check if installation succeeds and system boots.

  Additional random partitioning scheme dogfooding tests are welcome.

  [Regression Potential]

  The main change affects the recipes for -amd64-efi cases, so theoretically in the worst-case scenario there might be some problems when installing systems in UEFI mode with guided partitioning, like: wrong partitioning scheme present or the ESP not correctly created. But those regressions should be easily noticeable during testing.
  Another small regression potential is in invalid ESP counting and the users not getting the 'reuse partition' option even if the ESP is present. But that also should be covered through the tests.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1766945/+subscriptions