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

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

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.

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

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.

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

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

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

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

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.

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!

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!

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

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!

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

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

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

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!

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

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.

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

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

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.

I tried to install it failed on hp pavillion n109tu

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

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

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

I wany fix this problem

failed to install grub loader

how to fix grub2 installation error

tis can't insttalation the grub

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!

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.

grub file

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.

 i can't install 18.04

yes

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

we install ubuntu 18.04 why craze

Can you send me a video tutorial for this bug

Hello I want fix this

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.

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

i have problem in setup

bug load

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.

This bug is not fixed.

will feel batter if this problem will be fixed

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

ubuntu installation crashed during installation of gurb2

very bad bug

i getting problem for installing ubntu

ubuntu is installing error that is crub error.

my pc is not install grub

I have a multi-partition legacy (BIOS) system. About a year ago, when prompted by software loader, I upgraded from 16 LTS to 18.04 LTS Performed several updates after that (as prompted) but something went wrong with a systemd file (but system still worked well for many months). Recently, I was prompted to do a partial update and it completed happy but, next time I re-booted (selected version through Grub as always have) and got a bunch of red exclamation points and something about software frozen and system would not complete boot. On Dec 13, 2019 I downloaded image of 18.04 from main Ubuntu page and created bootable USB. This allowed me to create my user account and password in order to back up my user data, but the "refreshed" 18.04.3 image still will not boot up via the original Grub (only runs with the newly-created boot USB plugged in). Downloaded the 19.04 image on 12/15 from the primary Ubuntu page, over-wrote the bootable USB, and tried to install it over top of 18.04.3 image and get complaints about EFI boot will not work (of course, since my hardware is BIOS and not EFI). Someone here suggested creating a 200 MB EFI partition anyway and that will be my next step. At the moment the installer shows first a partition for /sda (I take this to be the location of the original boot software), followed by an ext4 partition named /sda4 (where an old mythbuntu resides), followed by an ext4 partition /sda6 (where the 18.04 or 19.04 image is loaded, followed by /sda5 partition designated swap.

So, this bug is DEFINITELY NOT fixed.

I am a software engineer and would like to learn more about booting Ubuntu. Can anyone suggest a good place in the Ubuntu document archive to begin familiarization?

grub-efi-amd64-signed fail

Hello!

I am having the same issue. I have Windows 10 installed, and wanted to have Ubuntu as well. I followed the steps described on Ubuntu forums, however it cannot install Ubuntu because it requires an EFI partition, which is not possible to me since I have a legacy BIOS and that cannot be changed to UEFI.

Last time I tried to "force" install Ubuntu, I ended up not being able to boot in any of the OS's.

During the manual partitioning, I thought that creating a specific "/boot" partition would be enough to solve the problem, but it was not, unfortunately.

Thanks!

Hello,

Here's my experience this issue and the solution which worked for me (though, it would be great if someone would resolve it in a more straight-forward matter):

Needed to convert a Windows 7 Ultimate machine to a dual-boot with ubuntu 18.04.3.
The machine was set based on legacy bios, Windows 7 Ultimate installed on an MBR disk, while there was a second (physical) HD for data, formatted as GPT.
Booting ubuntu bootable USB, it did so as UEFI.

1.
Used ubuntu to create a bootable USB (using the default "Startup Disc Creator").
Made some space on the OS HD for /root, and some more on the DATA HD for /home.
Then encountered the "No EFI system partition was found, the system will likely not be able to boot successfully and the installation may fail", which indeed reported failure.

2.
Upon reboot, Windows started with no grub menu.
Then using the same bootable USB, installed [Boot-Repair](https://help.ubuntu.com/community/Boot-Repair) and followed the instructions. Some of the commands resulted in errors, yet GRUB was installed successfully. Boot-Repair generated the following report: http://paste.ubuntu.com/p/c3f9zHjzfq/

3.
Then GRUB did not show up and ubuntu started.
Following ["Dual boot pc boots directly to ubuntu instead of showing grub menu"] (https://askubuntu.com/a/750123/44517)

verified grub was installed using:
`grub-install --version`

edit grub to comment out (add "#") to the line including: "hidden"
`sudo -H gedit /etc/default/grub`

resulting in it now reading:
# GRUB_TIMEOUT_STYLE=hidden

And updating grub:
`sudo update-grub`

Now the system is up and running, starting with a GRUB menu allowing to choose between ubuntu and Win7 .

Found on the web another solution, which I did not try:
It was suggested that deleting the "efi" folder from the bootable USB would allow an ubuntu installation alongside the windows one, in legacy bios mode, without issues.

Intending to set up dual boot Win7 Home Premium and Wasta-Linux I also received the message "No EFI system partition was found, the system will likely not be able to boot successfully and the installation may fail". As there is no EFI system on my laptop (at least as far as this technically limited novice can tell), it's unclear how to proceed. Suggestions welcome.

Plz kindly fix it as soon as possible. Will be thankful

shows grub2 installation failure...Xubuntu dual boot with windows embedded system

i was trying to install on manua

Attempting to install 16.04LTS on an older (2012) ASUS K55V laptop.
No other OS on the computer.
Complete erasure of old disk image
GRUB install failed (twice) and brought me here.

Will attempt the ">100GB EFI partition" solution mentioned above and see if that helps.
Otherwise it might be time to go to 18.04 or 18.10

16.04 LTS is supported until April 2020 (maintenance), so it's recommended to use 18.04 LTS (18.10 not being LTS and short in support, see : https://ubuntu.com/about/release-cycle ).

This bug does not apply to fresh installs (although it may be related) while wiping the disk, see initial post.
Make sure to check your BIOS settings (EFI/non-EFI, boot sector protection) and please post a new full bug report with full details if you have issues ( I suggest on 18.04 LTS).
Thank you.

please solve this issue

It is alright
Stop send me emails

On Sat, 2 May, 2020, 6:45 pm Le Nguyen Nhut Truong, <
<email address hidden>> wrote:

> ** Changed in: ubiquity (Ubuntu Bionic)
> Assignee: Łukasz Zemczak (sil2100) => (unassigned)
>
> --
> 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 Ubuntu installer.
> * Select a clean whole-disk install.
> * Check if installation succeeds and system boots.
>
> Additional random partitioning scheme dogfooding tests are welcome.
>
> [R...

I got bit.

I attempted a new install of the latest (as of 2021-08-01) 18.04 (5.xx kernel as I recall) onto a 19GB partition (/dev/sdf2) on one disk while specifying the bootloader location be onto a different disk (/dev/sda) with an existing, working, boot-efi partition (/dev/sda1).

I had done this same os install successfully onto a 7GB partition on a 3rd disk (/dev/sdc2) just before.

On the 19GB install, a fatal error occurred suggesting it was unable to write to do the final grub install onto /dev/sda.