UEFI: blank drive incorrectly detected as existing BIOS-mode install

[Jason Gerard DeRose]

When doing a UEFI-mode install using the latest daily Vivid ISO (Thu Feb 5), Ubiquity incorrectly concludes that a blank drive contains an existing BIOS-mode install (see error in attached screenshot).

The resulting error dialog is also broken: none of the buttons do any thing when clicked: X (close button), "Go Back", "Continue".

You can seemingly move the install forward by clicking "Continue" in the main installer window, but things are still broken somewhere as grub isn't getting correctly installed (system is unbootable after the install completes).

[Phillip Susi (psusi)]

When you say blank, do you mean has no partition table, or has a partition table but no partitions? Can you show the output of parted -l?

[Jason Gerard DeRose (jderose)]

Totally blank... I'm using qemu-img to create a new, empty virtual disk before doing the install. So every sector should be 0x00 repeated.

I'm having trouble getting a terminal open to run parted. When I "try ubuntu without installed", i get some nautilus error and unity isn't starting correctly.

[Jason Gerard DeRose (jderose)]

Okay, just double checked with `parted -l`... the target drive is totally uninitialized:

Error: /dev/vda: unrecognised disk label
Model: Virtio Block Device (virtblk)
Disk: /dev/vda 17.2GB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

[Jason Gerard DeRose (jderose)]

I just tested the latest vivid *server* daily ISO in UEFI mode, and it installs fine. So seems the problem is likely in Ubiquity, not in the underlying debian installer.

[Phillip Susi (psusi)]

Strange... the message itself comes from the underlying d-i component partman-efi. The logic it uses to present the message is "are there no EFI system partitions, but there are any other existing partitions". I wonder... there was some other flawed partition logic like this that was triggering on the installation media itself, so I wonder if that is what is going on here. In other words, the blank disk isn't what is triggering the message at all, but rather the fact that it is seeing a partition on the usb flash stick you are installing from.

[Jason Gerard DeRose (jderose)]

ah, gotcha, that makes sense. i did cross my mind that perhaps it was looking at the wrong block device when deciding that an existing BIOS-mode install was present.

for what it's worth, this is a very recent regression. I did a successful UEFI-mode install using the Vivid daily ISO from about a week ago.

i'll try today's daily ISO shortly, see if this is still present.

[Jason Gerard DeRose (jderose)]

okay, latest daily is in a bit better shape: I still get this erroneous warning dialog, but now clicking "Continue" on the dialog works, and the install completes successfully (grub is installed correctly, system boots fine).

[Jason Gerard DeRose (jderose)]

er, scratch that... system isn't bootable. i ended up back in the live ISO without noticing it :P

[Phillip Susi (psusi)]

Well at least the ubiquity side is working then ;)

When you set up your virtual machine, are you configuring the iso as a hd or cdrom? If it shows up as /dev/sr0 instead of /dev/sd[abc] then I'll bet the warning goes away.

[Jason Gerard DeRose (jderose)]

I'm launching qemu with "-cdrom vivid-desktop-amd64.iso". I just double-checked from the "try without installing" live session, and the CDROM is already showing up as /dev/sr0.

[Jason Gerard DeRose (jderose)]

Same problem with the latest daily ISO (Tue Feb 10).

[Phillip Susi (psusi)]

So from what I can see, the underlying error message from partman-efi happens any time there is NOT an existing EFI system partition on the disk you are installing to, and ubiquity is broken because it displays the error message and waits a few seconds, then proceeds to the next screen, and if you didn't answer the message in that time, after it has moved to the next screen, the window displaying the message becomes broken and you no longer can click either to proceed or go back. partman-efi seems to be displaying the message because it asks parted to format an ext2 partition on the disk, which will later be formatted as fat32 and become an efi system partition, but at the time that partman-efi/init.d/efi runs, parted still reports the partition as ext2, so the script counts it as an existing non EFI system partition, and throws the warning.

So the bug appears to be in two places: both partman-efi should not be throwing the warning, and ubiquity fscks up when the warning is thrown.

[Jason Gerard DeRose (jderose)]

This bug is still present in the 18-Feb-2015 Vivid desktop amd64 daily ISO, but I imagine the fix just hasn't made it into the daily yet.

[Phillip Susi (psusi)]

It hasn't been fixed yet. The debian bug was closed as invalid since Debian isn't affected. The bug watch updater is just broken and can't tell the difference between fixed and invalid.

[Phillip Susi (psusi)]

FYI, the problem seems to be that ubiquity is running things in parallel and/or in the wrong order. Specifically, it is running the partman visual.d scripts first, which add the new partitions, and then the init.d scripts after, which detect the newly added partitions and thinks they are existing partitions of an existing bios mode install.

[Jason Gerard DeRose (jderose)]

gotcha, thanks! i misunderstood the status change :)

[Jason Gerard DeRose (jderose)]

I hadn't checked in on this for a bit... but for what it's worth, this bug is still present in the latest daily ISO (02-Mar-2015).

[Paulo Molina (polochamps2004)]

I can confirm this bug.
http://ubuntuforums.org/showthread.php?t=2268815

[Paulo Molina (polochamps2004)]

Still present on Beta 2.

[Caleb Howland (Menzador) (menzador)]

I tried working around this bug by using GParted to manually create the partitions needed, and ubi-partman dies in the "Something else" section of the installer (exit code 141). Apparently ubi-partman hates the world right now... :)

[DonnieD (donnied)]

Jep still present in Beta2. Installing to brand new SSD 850 EVO as in Bug #1437255

[G-philip (g-philip)]

If you choose not to download updates from the internet, it works anyway.

[Jason Gerard DeRose (jderose)]

@g-philip - in my testing, i've never chosen the "download updates while installing" option, yet uefi mode installs haven't worked for me since i originally filed this bug.

can you provide more details?

fyi, my testing has been done using a qemu/kvm virtual machine, but others have confirmed this bug on bare-metal uefi systems.

[Paulo Molina (polochamps2004)]

Again I can confirm the bug still exist on the 02-Apr-2015 build.
Updates checked or not still displays the "Force UEFI" message.

"ESP" is still the term used on the boot partition instead of the usual "EFI".

[david6 (andrew-dowden)]

For latest Vivid (daily build), it also suggests I have 'Secure Boot' disabled, and it needs to force 'UEFI mode'.

This is part of the same issue, and also results in NO Grub being installed (so wont boot). Live works fine.

[david6 (andrew-dowden)]

Attempting to install Vivid (15.04) Daily Build, on HP Stream 11 (Bay Trail notebook, with eMMC storage):

- Installed using USB drive, with UEFI-only image; (.ISO file 'restored' to USB drive, no SysLinux or MBR)
- Installer incorrectly concludes that the drive contains "an existing BIOS-mode install", and that Legacy-mode is enabled; (prompts to 'Force UEFI' mode)
- install appears to complete, but will NOT boot. (Even on restart, not recognised as (UEFI) bootable)

I have verified that (a.) the drive is NOT blank, and had contained 14.10 64-bit; and (b.) Secure-Boot mode is enabled (and Legacy disabled).

CONCLUSION:

This is more like the logic being REVERSED, than the original description of the issue (in 'Bug Description').

[Paulo Molina (polochamps2004)]

@david6

It may boot if you will follow the instructions here - http://ubuntuforums.org/showthread.php?t=2268815

[david6 (andrew-dowden)]

Which is copied from:

http://ubuntuforums.org/showthread.php?t=2223856&p=13025073#post13025073

I will try it out ..

[oldfred (oldfred)]

It is my understanding that ESP is the correct full Initials (name) for what we often just call the efi partition.

 EFI System Partition (ESP)
Ubuntu installers have referred to the ESP by the name "EFI boot partition,"

But use of boot partition has confused new users thinking that is Ubuntu's boot partition or they need another /boot partition or do not need a /boot partition when they may need one.

[Paulo Molina (polochamps2004)]

@david6

Yeah but without the last 2 commands if you would notice.

@Fred Palmer

If you're referring to my post http://ubuntuforums.org/showthread.php?t=2268815 then the reason I brought the "ESP" term is that I thought that it may help describe or it is related with the bug.

Thanks for the info btw.

[david6 (andrew-dowden)]

@polochamps2004

I've tried that 'fix', but I get error message for 'grub-install' command.

I need to manually create EFI partition as well ..

[Mathieu Trudel-Lapierre (cyphermox)]

I've been looking into this last night and this morning; fix for partman-auto is now in the queue for review by archive admins.

Looks like this was because efi recipes used "free" rather than explicitly setting the partition filesystem type to "fat32" or some value of FAT as per the UEFI spec; so for some reason this showed up as ext3 until the partition was properly formatted, which would have happened *after* the extra uefi warning, if it wasn't breaking things in other ways.

I'm splitting this into a separate bug for the Force UEFI warning which appears to be handled incorrectly and is worded in a confusing manner.

[Mathieu Trudel-Lapierre (cyphermox)]

Partman-auto fix has been approved, but it will still need ubiquity to include the changes.

partman-auto (125ubuntu2) vivid; urgency=medium

  * Use fat32 rather than free as a filesystem type for the efi partitions
    for amd64, arm64, i386; otherwise it's seen as an ext2 partition by
    partman-efi, which causes errors or missing settings. (LP: #1428877)

[Phillip Susi (psusi)]

I don't think you quite understand the problem Mathieu. Yes, partman-efi's init.d script sees the partition as ext3 instead of fat32 because it has not yet been formatted as fat. The problem is that the init.d scripts are supposed to have been run long before partman-auto creates the new partition in the first place, so it should see *no* partition.

[Phillip Susi (psusi)]

In other words, the init.d scripts are supposed to be the first ones run, so they can look at the state of the drive as it is when you first boot the installer. Instead, ubiquity is running the visual.d scripts first, so they decide to add an efi system partition, and then ubiquity runs the init.d scripts after that, so they see the ( partially created ) new partition.

[Phillip Susi (psusi)]

FYI, If you install with d-i instead of ubiquity, it does not run into this problem since it runs the scripts in the correct order, so I don't think it is appropriate to change partman-auto since that would change the way d-i works, and it isn't broken.

[Jason Gerard DeRose (jderose)]

Yup, I can confirm the above when it comes to the daily Vivid server ISOs... I regularly test them for UEFI installs, and at no time since I filed this bug have I encountered any problems when doing good ol' text-based d-i server installs.

[Mathieu Trudel-Lapierre (cyphermox)]

If you install in d-i mode, things still did work because it would be running one instance of parted_server, as far as I could tell, to complete all of its job. In ubiquity, parted is run multiple times, which explains why scripts appear to be running out of order.

[Phillip Susi (psusi)]

I'm not sure why you think they only "appear" to be running out of order. If the partman log shows the visual.d script being run before the init.d script, then it is. Stopping and restarting parted_server wouldn't cause log entries from a script run later to be inserted earlier in the log file.

[david6 (andrew-dowden)]

There is also an issue with installer creating the EFI partition on USB flash device, instead of target platform.

This is NOT obvious when default settings are used.

Will need to do further tests, to see if this can still occur ..

[david6 (andrew-dowden)]

Or using the EFI partition (on USB flash), in place of creating EFI partition on target ..

[Jason Gerard DeRose (jderose)]

I just did a UEFI-mode install in a kvm VM using the latest Vivid desktop ISO (16-Apr-2015), and it worked!

I booted the ISO with init=/sbin/upstart to work around the installer not being able to reboot after the install has finished, but otherwise things worked perfectly!

[Paulo Molina (polochamps2004)]

@Jason

Do you think the (16-Apr-2015) is already the RC?
Thanks

[david6 (andrew-dowden)]

I hope not, because it isn't fixed yet ..

The freeze was around 6 hours ago, and that build is nearly a day old.

( Here is Australia it is already mid-afternoon of Apr-17. )

[Jason Gerard DeRose (jderose)]

@Paulo: no, I didn't think that ISO was the RC, I was just checking in on the latest daily.

In case booting with Upstart was the variable, I just tested with systemd (with the same daily ISO), and this EFI partitioning bug (in terms of my original scenario) seems to be fixed. Although in the systemd case, I can't really confirm this nicely as I can't reboot the VM after the install finishes (my tooling uses the plain-jane KVM Gtk window, doesn't provide UI to force a reset). All I know for sure is that I'm at least not getting the original error message dialog when booting with systemd, which I was still getting with the ISO from the day before.

Grub may or not be getting installed correctly when booting with systemd. For what it's worth, when I tried to boot from this virtual disk after killing my kvm process, it didn't work, but there are many reason why this could happen as pulling the (virtual) plug in this way could easily leave the vm disk file in an inconsistent state. Or I could have just made a goof.

But when I tested earlier booting the ISO with Upstart, things definitely worked correctly. Grub was installed correctly and I could reboot into Ubuntu after the installation completed.

If this isn't the case for everyone in their specific scenario, keep in mind that I'm testing with:

1) A truly "blank" target drive (a freshly created qcow2 disk image containing the byte 0x00 repeated)

2) An OEM-mode install these last to times around (although previously I've tested normal installs, just in case this bug was specific to OEM-mode, and found no difference)

Plus, to get things fully working without a hard-reset, I booted the ISO with init=/sbin/upstart :D

Thanks!

[Jason Gerard DeRose (jderose)]

Oh, and to potentially avoid confusion, when I said I tested the "16-Apr-2015" daily ISO, I'm going by the dates that Apache is showing here:

http://cdimage.ubuntu.com/daily-live/current/

(Which for me at the moment is still "16-Apr-2015".)

[Jason Gerard DeRose (jderose)]

Hmm, and to absolutely avoid confusion:

$ sha1sum vivid-desktop-amd64.iso
e54c7cb9cc54613f44af84c7dce796a729b74c94 vivid-desktop-amd64.iso

:D

[david6 (andrew-dowden)]

Attempting to install Vivid (15.04) Daily Build, on HP Stream 11 (Bay Trail notebook, with 32GB eMMC storage). Device already has 14.10 64-bit present (standard auto-install: EFI, system, swap), and Secure-Boot mode is enabled.

http://cdimage.ubuntu.com/ubuntu/daily-live/pending/
  vivid-desktop-amd64.iso 17-Apr-2015 08:38

- Installed using 4GB USB drive, with UEFI-only image; (.ISO file 'restored' to USB drive, no SysLinux or MBR)
- Installer incorrectly prompts with warning that the install target contains "an existing BIOS-mode install", and that Legacy-mode is enabled; (prompts with option to continue in 'UEFI' mode)
- install appears to complete, and prompts for reboot; (identical behaviour as 14.10 install)
- reboot stops, device still power-on but screen blank (no backlight); (often occurs with 14.10 install, on HP Stream 11)
- force off, wait 5, power on. (boots normally)

However. now prompts with:
"Please enter passphrase for disk cryptswap1 on none!" (new behaviour !?)

Pressing <Enter> <Enter> gets through to normal login ..

CONCLUSION:

- primary issue may now be 'fixed';
- the 'force-UEFI' dialog/prompt is still an issue; (separate bug?)
- prompt for passphrase is well .. ODD.

[Phillip Susi (psusi)]

Mathieu, I think one thing you might check for that changing partman doesn't "fix" is this: choose manual partitioning, create an ext4 filesystem for root, and nothing else. I believe you will then get this pop up as it will see the one ext4 partition, and no ESP.

[Thomas Kregelin (tkr)]

My System: Dell XPS 13 (2015) (9343)

I had the same problem until now.

Today I tried to install again with desktop-amd64.iso of April 17, 2015.

This time it installed correctly and I could boot without any problems.

Installed in UEFI Mode, Secure boot off.

After one successful boot I enabled secure boot. No problems.

Seems to be fixed?!

[Paulo Molina (polochamps2004)]

@Thomas

Do you still get the "Force UEFI installation" message?
https://launchpadlibrarian.net/196734906/Screenshot%20from%202015-02-05%2012%3A13%3A29.png

[Thomas Kregelin (tkr)]

@Paulo

No, have not seen that message during install.

Had it before though, when I tested iso files of before 17 April 2015. Don't remember exactly of which dates those dailys were, however.

[Paulo Molina (polochamps2004)]

@Thomas

Thanks for confirming.

[david6 (andrew-dowden)]

@Paulo

This may relate to @Thomas stating "Installed in UEFI Mode, Secure boot off."

I've seen a number of sites trying to install on various ultra-books and tablets all say "must disable secure boot". As this is a component of proper use of UEFI (which should work), I have left it enabled.

[Phillip Susi (psusi)]

I tested my theory on today's daily image and it is true: creating a single root partition with no esp still triggers broken dialog, so the change to partman-auto is not a correct fix.

[Jason Gerard DeRose (jderose)]

Just tested the "truly blank drive" scenario on the 20150417.1 daily:

http://cdimage.ubuntu.com/ubuntu/daily-live/20150417.1/

(sha1sum 0f1bdbc623df6816f1d058277811d8191408aeb9)

And it worked okay (although from others it sounds like things definitely aren't fixed for all scenarios).

BTW, the reason I'm booting the ISO with init=/sbin/upstart is to work around this bug:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1445587

[david6 (andrew-dowden)]

Attempting to install Vivid (15.04) Daily Build, on HP Stream 11 (as above). Device had earlier (failed) attempt to install 15.04 64-bit present (standard auto-install: system, swap; but missing EFI), and Secure-Boot mode is enabled.

http://cdimage.ubuntu.com/ubuntu/daily-live/pending/
  vivid-desktop-amd64.iso 21-Apr-2015 08:34

Install halts (after choosing erase disk, and accepting auto-install for: system, swap, and esp partitions) with warning dialog: "The attempt to mount a file system with type vfat in MMC/SD card #1, partition #1 (mmcblk0p1) at /boot/efi failed. You may resume partitioning from the partition menu." <Go Back>/<Continue>

[david6 (andrew-dowden)]

Either option does nothing, and dialog is ignored by installer.

[david6 (andrew-dowden)]

Repeat of above, but with device has blank 32GB eMMC storage.

Chose to 'Erase disk and install Ubuntu', to create ESP, ext4, and swap ..

Appears to be installing ..

[david6 (andrew-dowden)]

Summary:

Install appears to complete, and prompts for reboot; (identical behaviour as 14.10 install)

- reboot pauses, device still power-on but screen blank (no backlight); (often occurs with 14.10 install, on HP Stream 11)
- then prompts to remove any install media, and press <Enter> ..
- However, screen is unstable with three 'Ubuntu' images overlayed, and other screen corruption / tearing / flicker ..
- force power off, wait 5, power on. (boots normally)

However. still prompts with:
"Please enter passphrase for disk cryptswap1 on none!" (seen earlier)
Pressing <Enter> gets through to normal login ..

[david6 (andrew-dowden)]

On next reboot, requires pressing <Enter> <Enter> to get through to normal login.

[Paulo Molina (polochamps2004)]

@david

You're using the latest April 21 image?

[Paulo Molina (polochamps2004)]

^
vivid-desktop-amd64.iso 21-Apr-2015 08:34

Ooops. Didn't noticed.

[Mathieu Trudel-Lapierre (cyphermox)]

I think we've established the most common cases for this are fixed; so I'll close this as Fix Released -- ubiquity will properly handle blank drives.

Fixes landed in:

 - partman-auto: https://launchpad.net/ubuntu/+source/partman-auto/125ubuntu2
 - ubiquity: https://launchpad.net/ubuntu/+source/ubiquity/2.21.22

One remaining issue will be to properly deal with "user errors", that is, running manual partitioning but not creating an EFI partition while booted in EFI mode.

Phillip, can you open up bugs for the issues you noticed so we can track them appropriately?

[Colin Watson (cjwatson)]

To add to what Mathieu said, Phillip, please do NOT open a separate bug about the allegation repeated several times earlier in this bug log that visual.d scripts are creating partitions. They do not do this, as you can see simply by inspecting those scripts for a few moments (they're all very short). All that visual.d scripts do is to inspect the current state of a partition and render textual versions of them for use in the UI. If you think that they are creating partitions, then you have entirely misread the log output somehow.

[Phillip Susi (psusi)]

Hi Colin, I thought the visual.d scripts present, *and manipulate* an in memory view of partitions, which are later checked by check.d, and then written to disk by commit.d. If it isn't visual.d, then what manipulates the partitions? The problem seems to be that ubiquity is running init.d -> visual.d ( which manipulates the in memory partition tables ), then runs init.d *again* and they aren't designed to be run a second time.

[david6 (andrew-dowden)]

This occurred again today.

Aborted from 14.10 (fully updated) after 'prompt to upgrade to vivid', which looked like it would take forever.

Restarted Notebook, to install 15.04 using USB of 'Ubuntu 15.04 Desktop (64-bit)' (release).

When prompted with 'non-UEFI' mode warning, I choose 'back' and removed ALL existing partitions, then powered off.

Then re-ran, with NO repeat of issue.

[Tr4sK (tr4sk)]

Hi, I just hit that bug on the last ubuntu 15.10
I'll reboot and try your solution.

[Evan (evancox10)]

Can also confirm this bug, or something similar is present in the latest 15.10 ISO downloaded from http://www.ubuntu.com/download/alternative-downloads (torrent) as of 3/10/2016. I'm installing within a Gen 2 Hyper-V machine to a completely blank vhdx. Tried to create 3 partitions for EFI boot, root / in btrfs, and a swap. Got the error exactly as described. Also experienced a couple crashes before that to even get that far!

[Evan (evancox10)]

After I got past that point, I also got an "Unable to install GRUB in /dev/sda: Executing 'grub-install /dev/sda' failed. This is a fatal error." Related? Not sure. Documentation on Ubuntu wiki on how to create and install to a btrfs hasn't been updated since 12.04

[david6 (andrew-dowden)]

This issue is present for current daily ISO for 16.04 LTS (Xenial Xerus).

Will test further ..

[david6 (andrew-dowden)]

Unable to re-produce.

Laptop had latest install of Win 10 Pro '1511', and I was installing 'beta' Xerus.

Erased ALL drive partitions, and re-installed. Did NOT recur.

[Evan (evancox10)]

Is this bug "open" or not? Not familiar with this bug tracker, but it looks like it was declared fixed, but it either wasn't or there's a regression.

[Erick Brunzell (lbsolost)]

If you're seeing this in Xenial I'd say it's a regression, so I'd file a new bug report and mention there that it seems to be a regression to this bug.

[Mark Tomlin (dygear)]

Reproduce able on an Intel NUC trying to install to SSD via the M.2 slot. Install from Ubuntu 15.10 Live CD installed to the SSD.
CRAZY this haven't been fixed yet. I'm not able to install at all. No matter what I do to the UEFI / BIOS settings.

[Martin Beeger (martin-beeger)]

I can reproduce this bug on Xenial Final Beta when installing to a 500Gb empty intel ssd.
I get stuck in the dialogue which should not appear at all.

[erio (eri0)]

The bug happens if at the beginning of the installation you choose to download updates while installing Ubuntu or if you select download third party software for graphics and Wi-Fi hardware, Flash, Mp3 and other media. Deselecting this dialog box allows the partition to occur without problems.

[Phillip Susi (psusi)]

So my earlier analysis on this bug was correct, as evidenced by the new bug #1547286. The real underlying problem is still that the init.d scripts are executing *after* the commit.d scripts have written the partitions to the disk, and they are not intended to. Matthie's attempt at fixing this worked around the problem by allowing the script to see the newly created ESP so it concludes that there is already an EFI booting OS installed on the disk and does not complain. This isn't really true, but it at least stops the warning. In the case of this new bug, no ESP was created, and so the init.d script still erroneously concludes that some non EFI booting OS is already installed and the broken message pops up and hangs the install.

[Buzzing Robot (buzzingrobot)]

Seeing thiis today in a MATE install (ISO date 20 April). UEFI install with correct partitioning. Both third-party and updates optons were *not* selected. "Debian in UEFI mode" displayed after partitioning and on top "Where Are You?" panel. Does not respond to clicks.

[Steven Almeroth (stavrosian)]

I removed a Windows partition and some other partitions during the install and when I clicked continue the Force UEFI Installation? box came up and I was unable to move forward or backward with either Continue or Go Back buttons.

Also, sorry, I think I accidentally changed the status of the Ubiquity bug from Triage to In Progress and I couldn't change it back. :/

[Martin Spacek (mspacek)]

This is an infuriating bug, but I've found a workaround, more or less described in a comment in a duplicate bug here:

https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1547286/comments/11

I'm installing Xubuntu 16.04 amd64 on a completely blank SSD on a brand new UEFI-enabled HP system. If I immediately create an EFI partition (say 200 MB) before the main partition, that doesn't fix the bug. I still get the broken "Force UEFI installation" dialog in the next step.

This is because, for some strange reason, the installer decides to set the EFI partition to ext4 instead of FAT32. You can see this in the space allocation graphic at the top of the manual partitioning dialog. So, instead of directly creating an EFI partition (during which you can't specify the file system type), I created a 200 MB FAT32 partition, then changed it to EFI with the "change..." button, and voila, I now have a FAT32 EFI partition. After allocating my root partition and hitting next, I no longer get the broken "Force UEFI installation" dialog, and installation proceeds smoothly.

[Martin Spacek (mspacek)]

Sorry, I forgot to mention above that I selected both "download updates while installing Ubuntu" and "download third party software for graphics and Wi-Fi hardware, Flash, Mp3 and other media."

[Evan (evancox10)]

Still present in public release of Ubuntu MATE 16.04, and presumably other Ubuntu versions as well.

What do we need to do to help this get fixed? This is, as Martin says, infuriating. It completely blocks you from installing Ubuntu in Hyper-V to a blank VHDX using EFI boot.

I tried the steps Martin posted, and I was able to get past that screen. Indeed, if you just select "EFI System Partition", it formats it as ext4, with no option available. Yet if you consult here the EFI spec v2.5, section 12.3, it states that "The file system supported by the Extensible Firmware Interface is based on the FAT file system," so ext4 would be inappropriate. Source:
http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf#page=536

Unfortunately, I later ran into problems installing GRUB2 and the process failed, so there is still something else to debug.

[Alberto Salvia Novella (es20490446e)]

Please:

1. Report to (http://bugs.debian.org/).
2. Paste the new report link here.
3. Set this bug status back to "confirmed".

Thank you.

[Evan (evancox10)]

Hi Alberto,
I have filed a report here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834373

[vygotski (social-i)]

For me, the error only occurred when I was installing from an empty ssd.
Formatting the ssd in gpt and creating one ext4 partition made the installer ask if I wanted to force UEFI ahead of the partitioning process. After that the installation works as usual.

[Caitlyn Martin (caitlynmmartin)]

The problem still exists in Yakkety. I am doing an install on an HP x2 Detachable 10-p010nr (the latest version). I attempted to basically wipe the SSD and do a custom install so that I could have multiple partitions. I got stuck at Force UEFI installation? and couldn't go back or continue. Please note that I am using the Ubuntu GNOME iso with the patched kernel for Intel Cherry Trail SOCs at: https://linuxiumcomau.blogspot.com/2016/10/running-ubuntu-on-intel-bay-trail-and.html I realize this is not an officially supported OS image.

[Caitlyn Martin (caitlynmmartin)]

OK, I've worked around the problem. First, I can confirm what vygotski reported: it only happens if you are installing to a blank SSD. I created my ESP (FAT32) partition first and made it larger (300 MB) and the rest of my custom install worked after that. Not a huge problem but it would be nice if it was at least documented somewhere.

[Nicolas Peifer (unknownprogrammer)]

Yeah, it happens when you have a brand new SSD and try to create the partions manually - it won't work. My workaround: I chose the first (default) installation option and let it create the partions. I aborted and rebooted when I had to select the timezone. Then I chose the manual partion mode and deleted all but the efi partion and created my partions - no strange pop-up :-)

[Richard at webbureau (6-richard-t)]

I encountered the same problem (first using Ubuntu 16.04.1, and then 16.04.2), but only on one of the three pc's I just built. The only differences between the one which showed the bug and the others, was that I used another motherboard in the one with the problematic install, and another brand of DDR4 Ram (same amoount of memory). All other components (120 GiB SSD, Intel I3 processor, socket 1151) were exactly the same and brand new.

I used these two motherboards and memory:
ASUS H170-PRO (problematic install),
and
ASUS H170M-PLUS (no problems).

Given that these two motherboards are likely almost the same, this given might help in solving the problem...

I worked around the problem by choosing the first installation option instead of 'something else'.

Hope this gives someone an idea about the source of the problem...

Differences between the motherboards according to Asus and setup utility:

H170M-Plus:
microATX,
Gigabit ethernet: Intel I219-V,
No ordinary PCI slots,
BIOS: 2002 x64; Build date: 09/20/2016; (ME FW version: 11.0.10.1002).

H170 PRO:
ATX,
Gigabit ethernet: Realtek 811H,
2 ordinary PCI slots,
BIOS: 2003 x64; Build date: 09/19/2016; (ME FW version: 11.0.10.1002).

[Ákos Laczkó (akos.laczko)]

I've experienced this problem as well on Ubuntu MATE 16.04.2 LTS, but managed to resolve it.

This issue seems to be related somehow to the existing partition table of the drive: even after manually creating a new GPT table in gparted (or KDE partition manager) I got stuck at this message, but if I created a new partition table for the blank drive inside "something else" the message did not show up (dispite the fact that it also creates a GPT table if I'm correct). I assume that's why the default install method worked for everybody here - this step must be included in that one as well.

Reproduced this three times (error and resolution as well). Hope this helps somehow to the devs.

[Mayou36 (mayou36)]

This problem is still around in 17.04! Really?

[Huan Zhang (victzhang)]

This problem still occurs in Ubuntu 17.04 installer.
If internet is connected before installation and using a blank disk, the "Force UEFI installation" box will pop up after a manual partition. The buttons ("Go Back" and "Continue") on the box do not work, and installation gets stuck here.
Reproducible on multiple machines. Have to disconnect Internet before running the installer.

[Gastón (givanse)]

Can confirm. Same UEFI error with hanged install due to unresponsive dialogue window.

 - Ubuntu Gnome 17.04
 - Brand new blank SSD

I was able to complete the install with the workaround described in:

> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1418706/comments/90
> I chose the first (default) installation option and let it create the partions. I aborted and rebooted when I had to select the timezone. Then I chose the manual partion mode and deleted all but the efi partion and created my partions

For the second (real) install I used:
 - encrypt
 - use lvm
 - something else

In my case this is the efi partition I got from the first (fake) install:
 - efi ~536 MB

I created two ext4 partitions for / and /home respectively; then selected "encrypt home folder". Mentioning it for thoroughness.

At all times, during the default (fake) install and the manual (real) install I had:
 - Ethernet connected
 - check for upgrades
 - install 3rd party

---

To be able to boot I had to go once more into the BIOS and enable the new UEFI SSD entry in the boot order list. That isn't related to the bug. It is more specific to my motherboard and chosen security settings. Still worth to mention.

[TJ (tj)]

Still affects 17.10; confirmed in a VM and on bare metal

[Kenrin Xamithan (kenrin)]

Just ran into this bug on 17.10. Can confirm if you let the installer partition for you then re-install afterwards with manual partitions it works.

Partitioning manually before installation does NOT work and still stuck on force UEFI message.

[David Klasinc (bigwhale)]

This is still present on 18.04 daily builds. I downloaded it just today and I can't get past the 'Force UEFI installation?' dialog.

[Niko Krause (nikokrause)]

Had the same problem on a brand new empty SSd. The above suggested solution worked for me:

> Formatting the ssd in gpt and creating one ext4 partition [with gparted] made the installer ask if I wanted to force UEFI ahead of the partitioning process.

[Phillip Susi (psusi)]

I think you misunderstand the point of this bug Niko. You did not need to create a partition on the drive to get the prompt; a completely blank drive would cause it, and it was not supposed to. This prompt has been completely removed in 18.04 however, so I guess that closes this issue.