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

[Mathieu Trudel-Lapierre]

[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.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Gil0224 (gi44-0224)]

Affected by the same bug, I solved the point adding a small EFI (200M) partition before the OS / as

Dr_SE (test911turbo) wrote on 2017-03-06: (comment #14) here: https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1252255

In my case problem now solved: On installation, do not forget to create a EFI System Partition (ESP), if it doesn't already exist.

1.- Live USB Stick, install Ubuntu
2.- on partitioning, select "something else"
3.- create EFI System Partition (ESP):
      - on the 1st 100 G of the disk
      - size > 100 M (recommended 200 M)
      - "primary partition"
      - type: "EFI"
4.- everything else as usual.

Now it works fine with my old /home partition.

[experimancer (experimancer)]

Just guessing but could the above fix this bug as well; https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1767508 ?

[experimancer (experimancer)]

No, th fix #3 does not work, nor the GRUB or EFI boot loader setup fail, Ubuntu 18.04 can not be installed with this, the bug is still there.

[GERARDO GUIDARELLI (k+ulu42)]

I realized the issue on my end shortly after the bug report… yep accidentally booted the efi bootloader instead of the normal one.. tried installing again after booting the proper disc selection and worked … thanks for the feedback..

________________________________
From: <email address hidden> <email address hidden> on behalf of experimancer <email address hidden>
Sent: Friday, April 27, 2018 7:52:47 PM
To: <email address hidden>
Subject: [Bug 1766945] Re: (EFI on top of legacy install) choosing "replace" or "resize" options in partitioning may lead to an install failure

No, th fix #3 does not work, nor the GRUB or EFI boot loader setup fail,
Ubuntu 18.04 can not be installed with this, the bug is still there.

--
You received this bug notification because you are subscribed to a
duplicate bug report (1767260).
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-efi package in Ubuntu:
  Confirmed
Status in ubiquity package in Ubuntu:
  Confirmed

Bug description:
  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.

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

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-efi - 71ubuntu3

---------------
partman-efi (71ubuntu3) cosmic; urgency=medium

  * Save the number of ESPs found to /var/lib/partman/efi_esp_count for
    partman-auto. (LP: #1766945)

 -- Łukasz 'sil2100' Zemczak <email address hidden> Wed, 27 Jun 2018 16:41:25 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-auto - 134ubuntu9

---------------
partman-auto (134ubuntu9) cosmic; urgency=medium

  * recipes-amd64-efi/*: remove the restriction of the ESP partition that only
    allowed it being created when the partition table was GPT. This basically
    fixes cases where the ESP wasn't created if the previous installation was
    in BIOS legacy mode. (LP: #1766945)
  * automatically_partition/reuse/choices: do not offer reusing of a partition
    in EFI mode if there is no ESP present. Only works when a newer
    partman-efi is available.

 -- Łukasz 'sil2100' Zemczak <email address hidden> Fri, 22 Jun 2018 16:57:39 +0200

[Łukasz Zemczak (sil2100)]

Only thing left is refreshing the partman-* parts in ubiquity + SRUing all the changes into bionic.

[Łukasz Zemczak (sil2100)]

Uploaded to bionic Unapproved, waiting for SRU team review. Please note that the ubiquity upload will follow later. Also, most probably, the ubiquity upload will include the fixes for both this bug and LP: #1778848 - since both are being SRUed at the same time (due to the point release being so near) and both require the fixes being pulled into ubiquity.

[Brian Murray (brian-murray)]

Hello Mathieu, or anyone else affected,

Accepted partman-auto into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/partman-auto/134ubuntu8.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Brian Murray (brian-murray)]

Hello Mathieu, or anyone else affected,

Accepted partman-efi into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/partman-efi/71ubuntu2.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Łukasz Zemczak (sil2100)]

Uploaded ubiquity with the new -proposed packages updated. That is necessary for the fixes to work on desktop.

[Steve Langasek (vorlon)]

Hello Mathieu, or anyone else affected,

Accepted ubiquity into bionic-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/ubiquity/18.04.14.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-bionic to verification-done-bionic. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-bionic. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Łukasz Zemczak (sil2100)]

Checked daily-build iso logs and confirmed partman-auto 134ubuntu8.1 and partman-efi 71ubuntu2.1 are included in the images [1].

 * Installed system on BIOS, full disk, switched to EFI
 * Confirmed no re-use partition options being present
 * Performed resize disk and use freed space
 * Confirmed that the ESP is to be created alongside the new partition
 * Rebooted and confirmed the system is bootable

 * Installed system on BIOS, full disk, switched to EFI
 * Performed replace partition and install
 * Confirmed that the ESP is to be created alongside the new partition
 * Rebooted and confirmed the system is bootable

 * Installed system on BIOS, created 3 partitions, switched to EFI
 * Performed use biggest free space and install
 * Confirmed that the ESP is to be created alongside the existing partitions
 * Rebooted and confirmed the system is bootable

[1] http://people.canonical.com/~ubuntu-archive/cd-build-logs/ubuntu-server/bionic/daily-20180703.log

[Łukasz Zemczak (sil2100)]

That was for ubuntu-server (tested using bionic 20180703 on kvm).

[Łukasz Zemczak (sil2100)]

Tests for ubuntu-desktop (tested using bionic 20180702 on kvm as well). Remark: I performed all these tests with enabled download of updates during installation due to the fact that otherwise the installer was crashing because of some missing grub packages (unrelated to this bug). This is fixed in the archive (binaries were waiting in Unapproved). To make sure this is fixed without downloading updates I will perform a sanity test afterwards using the latest bionic daily image.

Confirmed in the livefs manifest that the image contains the right ubiquity with all the changes (18.04.14.3) [1].

 * Installed system on BIOS, full disk, switched to EFI
 * Confirmed no re-use partition options being present
 * Peformed install Ubuntu alongside existing Ubuntu (resize) and install (minimal)
   - This caused a prompt for resize
 * Confirmed that the ESP is to be created alongside the new partition
 * Rebooted and confirmed the system is bootable

 * Installed system on BIOS, full disk, switched to EFI
 * Peformed erase Ubuntu and reinstall (minimal)
 * Confirmed that the ESP is to be created alongside the new partition
 * Rebooted and confirmed the system is bootable

 * Installed system on BIOS, created 3 primary partitions, switched to EFI
 * Peformed install Ubuntu alongside existing Ubuntu and install (minimal)
 * Confirmed that the ESP is to be created alongside the new partition
 * Rebooted and confirmed the system is bootable

 * Booted into EFI
 * Performed a whole disk install on a clean partition
 * Confirmed that the ESP is to be created alongside the new partition
 * Rebooted and confirmed the system is bootable

[1] https://launchpadlibrarian.net/376783670/livecd.ubuntu.manifest

[Łukasz Zemczak (sil2100)]

I did a sanity-test install using ubuntu desktop daily-live 20180704. I first prepared a server-installed BIOS whole-disk installation, then switched to UEFI and started the installation using the aforementioned image. I have then selected the option to erase the partition and reinstall, saw the ESP created and confirmed that the installed system was bootable.

I think all required tests have been performed and therefore the partman-auto, partman-efi and ubiquity changes have all been tested (since ubiquity 18.04.14.3 includes both the correct partman-auto and partman-efi -proposed versions).

Anyone affected - please use the remaining SRU aging time to perform your own validation by using the latest bionic daily images. Thank you!

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-auto - 134ubuntu8.1

---------------
partman-auto (134ubuntu8.1) bionic; urgency=medium

  * recipes-amd64-efi/*: remove the restriction of the ESP partition that only
    allowed it being created when the partition table was GPT. This basically
    fixes cases where the ESP wasn't created if the previous installation was
    in BIOS legacy mode. (LP: #1766945)
  * automatically_partition/reuse/choices: do not offer reusing of a partition
    in EFI mode if there is no ESP present. Only works when a newer
    partman-efi is available.

 -- Łukasz 'sil2100' Zemczak <email address hidden> Fri, 22 Jun 2018 16:57:39 +0200

[Steve Langasek (vorlon)]

The verification of the Stable Release Update for partman-auto has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 18.04.14.3

---------------
ubiquity (18.04.14.3) bionic; urgency=medium

  * Automatic update of included source packages: grub-installer
    1.128ubuntu8.18.04.1, partman-auto 134ubuntu8.1, partman-efi
    71ubuntu2.1. (LP: #1766945, LP: #1778848)

 -- Łukasz 'sil2100' Zemczak <email address hidden> Fri, 29 Jun 2018 09:47:18 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package partman-efi - 71ubuntu2.1

---------------
partman-efi (71ubuntu2.1) bionic; urgency=medium

  * Save the number of ESPs found to /var/lib/partman/efi_esp_count for
    partman-auto. (LP: #1766945)

 -- Łukasz 'sil2100' Zemczak <email address hidden> Wed, 27 Jun 2018 16:41:25 +0200

[sudodus (nio-wiklund)]

Re: https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1781628

I zsynced the Lubuntu bionic-desktop-amd64.iso and received the daily iso file dated 2018-07-14.

I can confirm that it works to install Lubuntu in UEFI mode into my Intel NUC from this current daily iso file.

There is no need to swap off before starting the installer.

[Rajdeep Majumder (majumder.rajdeep)]

I tried to install it failed on hp pavillion n109tu

[Guilherme Steinmuller Pimentel (guilhermesp)]

it is still faling with http://releases.ubuntu.com/bionic/ in a asus laptop

[Guilherme Steinmuller Pimentel (guilhermesp)]

[SOLVED] actually solved by creating an EFI partition. So ignore the above comment.

[Rajdeep Majumder (majumder.rajdeep)]

Dears,

Same for me [SOLVED] , created efi partition and convert the existing mbr
partition to gpt by gparted utilities and after that i am able to install
windows 8.1 alongside ubuntu 18.04 dual boot.

Thanks for your response,
Rajdeep

On Fri 17 Aug, 2018 4:51 pm Guilherme Steinmuller Pimentel, <
<email address hidden>> wrote:

> [SOLVED] actually solved by creating an EFI partition. So ignore the
> above comment.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> 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...

[Mohammed Abdelaty Ali (mhmd-ali)]

I wany fix this problem

[riaz (riaz007)]

failed to install grub loader

[Saurav sagar (ss26690)]

how to fix grub2 installation error

[carto ardiyanto (blacknine)]

tis can't insttalation the grub

[gorski (gorski-hotmail)]

Crash on bi-mode BIOS/UEFI PC, grub2 failed to install, so it all collapsed before it finished installing...

Previously I managed to install 16.4 and then upgraded to 18.04 with similar warnings about hybrid BIOS/UEFI system...

However, when I installed D. Richter's GRUB CUSTOMIZER there was no problem whatsoever in dual booting!

Please, add it to the installation files and peace, hopefully...

https://launchpad.net/~danielrichter2007/+archive/ubuntu/grub-customizer/+index?field.series_filter=yakkety

or

https://launchpad.net/~danielrichter2007/+archive/ubuntu/grub-customizer/+index?field.series_filter=yakkety

or

sudo add-apt-repository ppa:danielrichter2007/grub-customizer
sudo apt-get update
sudo apt-get install grub-customizer

I wish I knew how to edit my USB installation stick but I am from Humanities...

Thanx!

[Mathieu Trudel-Lapierre (cyphermox)]

Please do not assign yourselves on this bug.

Assignment only needs to happen if you're going to work on it, and this is closed as Fix Released.

[kero Adel (kero3adel)]

grub file

[techo nuxnet (nuxnet)]

for many time i try to install Ubuntu 18.04 (dualboot) on my own notebook (ASUS) beside primary OS (Microsoft Windows 10 Enterprise). my stuck is just only on installing grub2 package.. i've read all documentation, report, tutorial from many resources (forum, article, web video, etc). there some job/work to using Linux (which mean i prefer to ubuntu) for first time.

[Erdenebat Ganchuluun (gerdenebat10)]

 i can't install 18.04

[khashayar (ahrabi)]

yes

[Alan Mintaka (botutboankhbonef)]

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

[Rendy Widjaya (raswijaya)]

we install ubuntu 18.04 why craze

[Anisur Rahman (anis378)]

Can you send me a video tutorial for this bug

[mohbobe (mohbobe)]

Hello I want fix this

[Yuv (yuv)]

TLDR: the Xubuntu 18.04.1 installer does not recognize an NTFS EFI partition. Then the process takes it course and fails.

Longer story. I recently staged two dual boot machines from scratch. The only difference between them was the EFI partition.

Case 1:
* Laptop came with Windows 10 pre-installed
* Resized Windows partition
* Booted with USB. Xubuntu installer offered choice of installing along existing Windows system and everything worked like a charm. KUDOS TO THE DEVELOPERS OF THE XUBUNTU INSTALLER.

Case 2:
* Restaged desktop that had a Windows 10 digital license on blank SSD
* Resized Windows partition
* Booted with USB. Xubuntu installer did not offer choice of installing along existing Windows system
* STOPPED. Compared the two cases and found the difference: the fresh Windows 10 install (using 1809 media) set the desktop up with an NTFS EFI partition (at least so says gparted).
* Rebooted with USB. In Xubuntu installer chose "Something else", selected the free space on the disk to create a new partition and let the installer go
* The installer failed when trying to install grub-efi

I will still make some attempts at fixing this, and will post here if I find something new.

[markj mc torrs (markjhplaptop)]

grub failed to install please email me on how to fix it asap im reviving my laptop since it was ruin by windows 10

[abdalla bebo (fahd)]

i have problem in setup

[Radhika Ajie (radhika17)]

bug load

[Stephen Erbert (erbert2000)]

This bug is not fixed. My options, nearly a year after being first reported, seem to be either erase the entire disk, or install something other than ubuntu. Installing over an older ubuntu doesn't work, and installing alongside other installs doesn't work, and "something else" doesn't work. It also destroyed my ability to log into old versions, except a 2014 version sitting on a different disk. It seems that ubuntu will simply never be ready for the masses, and I'm not a tech idiot, I'm just also not a grub wizard.

[fireguyfu (fireguyfu)]

This bug is not fixed.

[Raja Ehtasham Ul Haq (raja3233)]

will feel batter if this problem will be fixed

[abdalla bebo (fahd)]

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