Booting installer in EFI mode with existing bios mode hd crashes

Your disk is currently partitioned to boot in bios mode, but you booted the installer in EFI mode. A warning message prompted you that this could be a problem and recommended performing a bios mode install instead, but you chose not to. You either need to perform the bios mode install, or partition the disk using GPT and set up an EFI system partition to install in EFI mode. This will be done for you if you choose the "use entire disk" guided install option.

Actually, the disk was completely blank when I started. I wanted to have a btrfs partition instead of a ext4 partition, so I chose to set it up manually.

I don't think the bug is invalid, because there are two problems with the EFI warning message:

1. Go back didn't work when I clicked on it. So I was forced to continue spending the next ten minutes installing, even though grub-install was guaranteed to fail, making the exercise completely pointless and frustrating.

2. The warning message is next to useless, because it doesn't actually say that you need to set up an EFI partition. It just says there 'could be a problem', which implies that there might not be a problem, but we know there is guaranteed to be a problem.

Is it possible to change the warning message so that it tells you that you also need to create an EFI partition (is 200MB the recommended size?) for it to work in EFI mode? This would make the installer a lot more user-friendly (and have saved me a lot of time).

I could have sworn there was already a bug about the poorly worded message, but can't find it now, so I'll reassign this one.

Looks like the string is translated. Is that a concern?

If we're going to break string freeze and diverge from Debian, could we at least drop the word "Debian" here? s/install Debian/install/

(That change is also appropriate to forward upstream, AFAICS)

Also, I don't find the new text particularly clear either and would not recommend breaking string freeze for it, with or without the dropping of the word "Debian". Can we workshop this further (perhaps together with Debian) before committing to anything?

Also also, why in the world do we have to *warn* the user about creating an ESP partition? This should be a FATAL ERROR in the setup of a UEFI-installed system, and d-i should refuse to proceed with the installation without one!

I'll reject this from the queue given Steve's concern. You can talk about it out of band and accept that if appropriate, or upload a new version.

That's not the point; the system is also warning you that proceeding with the install is potentially breaking your setup if there is a pre-existing partition.

In the past Steve McIntyre changed the code to avoid having this message show up when dealing with a blank disk; plus further updates fixed false-positive issues. We're sufficiently up to date with Debian w.r.t partman-efi already. I think more than changing the text, we need to fix the logic to make absolutely sure it doesn't trigger on blank disks.

As for non-blank disks, perhaps it would be best to fail to install in that case -- the system will surely not boot in UEFI mode, and other bits will fail (such as installing grub-efi).

Here is the current message:

 Force UEFI installation?

 This machine's firmware has started the installer in UEFI mode but
 it looks like there may be existing operating systems already
 installed using "BIOS compatibility mode". If you
 continue to install Debian in UEFI mode, it might be difficult to
 reboot the machine into any BIOS-mode operating systems later.

 If you wish to install in UEFI mode and don't care about
 keeping the ability to boot one of the existing systems, you have the
 option to force that here. If you wish to keep the option to boot an
 existing operating system, you should choose NOT to force UEFI
 installation here.

And here is what has proposed in the prior upload that was rejected from the queue last cycle:

 Force UEFI installation?

 This machine's firmware has started the installer in UEFI mode but
 it looks like there may be existing operating systems already
 installed using "BIOS compatibility mode". Furthermore, it appears there
 is no EFI System Partition (ESP) on your system. If you continue to install
 Debian in UEFI mode and do not create an ESP, it might be difficult to
 reboot the machine into any operating system later.
 .
 If you decide to force installation in UEFI mode, be sure to create an EFI
 System Partition to make sure your system will be able to boot after install.
 .
 If you wish to keep the option to boot an existing operating system, then
 you should not force installation in UEFI mode.

I understand UEFI fairly well, and both messages are completely unclear to me. What does it mean to "force" UEFI installation on a system that has no ESP? If I am being told to "be sure to create an ESP", is clicking 'ok' going to give me an opportunity to repartition? Or is it going to proceed with an installation without creating an ESP, therefore requiring me to repartition outside of the installer in order to make the system bootable? Or is it going to *automatically* create an ESP for me if I say "yes" to "force", thus making the "be sure to create [...]" message an irrelevant lie? And why are we telling users that they may not be able to boot other OSes in BIOS mode once they create an ESP? If we've detected other OSes, they should be added to our own grub config with os-prober. If we haven't, we shouldn't be printing scary messages about OSes that don't exist.

Someone needs to understand the answers to these questions, and clean up the warning prompt to match.

It should be understood that when fixed, this message also needs to stand alone. The user has two choices before them, "yes, force" and "no, don't force". The system must not assume that the user remembers anything about what was done before in the installer, or knows what will come next when picking either of those two options, except what the message tells them.

It's also possible that the real bug here is in this message ever being shown to the user at all. But someone needs to dig into the code and see it in context of the installer (both ubiquity and d-i) to make that determination.

After experimenting with possible scenarios with the current partman-efi (2 systems on kvm - first one installed in BIOS mode, second in UEFI), I currently propose two courses of action:

1) Removing the warning prompt completely and always continuing in UEFI mode. During my testing on bionic it seemed that there was no risk in continuing in UEFI mode, even when BIOS mode OSes were present they were still bootable and visible in grub. Maybe I missed some test case? What use-case could tempt the user to not continue the install in UEFI since that's the mode we're in right now? Maybe just a warning, without any choices, would be enough?

2) Reformat the warning message and default to continuing in UEFI mode. I'm not an expert here, but to me currently it feels like the more risky solution is to not to force the EFI install. If the system is running in UEFI mode and the user selects 'cancel', in the end he/she will not have a bootable system anymore without switching to BIOS or creating the ESP manually. To me that doesn't sound like a very good default. Or am I misunderstanding something from the testing I did?

I'd generally prefer 1), but I'll defer to people with more experience in UEFI and partman-efi.

Go for it; the confusion from this message is greater than the benefit to the very tiny set of users who might run into issues this is meant to catch.

ie. automated partitioning will already DTRT; and people who write their own partitions and don't add an ESP are presumed to already know what they are doing.

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

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

  * Do not ask the user about forcing UEFI installation if there are BIOS
    compatibility mode installed systems as those will still be bootable from
    grub if we proceed in UEFI mode. (LP: #1668148)
  * debian/partman-efi.templates: remove the partman-efi/non_efi_system
    template as we no longer need it.

 -- Łukasz 'sil2100' Zemczak <email address hidden> Wed, 28 Mar 2018 18:16:17 +0200

No, no no. This change is a bad release regression and must be reverted and bionic respun.

The point of this was to make the message less confusing, not to remove it. By removing it and always trying to install grub-efi, it FAILS TO INSTALL because of the lack of an EFI system partition.

We are absolutely not reverting this. The message was dropped because it was USELESS to an end user.

The reason the user is *presented* the message is because there are bugs in ubiquity, which is giving the user guided installation options which will NEVER work.

We are fixing this in ubiquity for 18.04.1, by fixing the guided installation options to work if possible, and to be hidden if not.

The message allowed the user to switch to a bios mode install of grub instead of trying to continue with EFI mode, which would fail, and crash the install. Now there is no way to avoid the installation failure and it 100% crashes.

Removing the message is one thing, but the default choice of action is absolutely the wrong one.

The question allowed a user who is also a mind reader and knew what the options meant (since the actual text of the message was useless for understanding this) to switch to a bios mode install.

The fact that this message was shown at all, ever, was a bug elsewhere in the installer. This will be fixed so that we never again hit the path where this message was previously shown.

Therefore there is no value in reintroducing this opaque message.

Please pay attention:

The choice that lead to a bios mode install was the correct one that worked. Choosing to use efi mode is the one that failed and crashed the install. Now it always uses efi mode, and so always crashes the install. It must be changed to take the bios mode install instead.

Again, removing the choice is not the issue; auto choosing the efi mode instead of bios mode is the problem.

See bug #1770966 for someone complaining that they are no longer able to install Ubuntu because this question was removed ( and the automatic choice made to stick with an efi mode install instead of switching to bios mode ).

Also see the hundreds of apport reports that have been filed since 18.04 was released with people booting the installer in EFI mode with an existing bios mode install, and crashing because grub-efi can't be installed without an EFI system partition.

I spent days trying unsuccessfully to do a clean install of 18.04 onto a system with an existing version of Linux. Each time the installer would appear to be working properly, only to bomb out with an error after half an hour.

Eventually I gave up, REFORMATTED MY HARD DRIVE and was able to get the install to complete.

It makes me really frustrated to learn that the installer used to detect my exact situation and warn about it and now just blindly goes down a path that cannot succeed.

I agree 100% that it's a bad idea to present users with a choice that they have no hope of making correctly.

But I also agree 100% with Phillip that if the installer can detect that it has been booted in EFI mode and that it's trying to install onto a hard drive with an existing BIOS mode install... just proceeding with the EFI install is the wrong thing to do.

See https://bugs.launchpad.net/bugs/1770966 for the literally hundreds of people that were caused pain by this change.

I've been using Linux since the mid 1990s and using Ubuntu since 2006.

This upgrade from 17.10 to 18.04 was really unpleasant. It's among the worst Ubuntu upgrade experiences I've ever had... and the only one in which I've lost data. For an LTS release, that's simply not acceptable.

I linked the wrong bug; sorry.

https://bugs.launchpad.net/bugs/1767703 is the one to view the carnage in the aftermath of this change.

I have this problem to and my setup is a bit different and i do not see a similar setup mentioned here.

My disc is GPT partitioned, UEFI is disabled and i boot/install in BIOS mode but Ubuntu (Lubuntu) is the only OS installed. That is because off a BCM4312 wireless chip which i need compile a module for, no binary available. Short off getting that compiled driver signed i must disable UEFI and use BIOS mode.

Disc is partitioned; / , swap , /home , no bios-grub or EFI partition.

Four attempts to install 18.04 all failed. Problem as noted above. Installed 16.04 no problem other than install media does boot as UEFI and the messages 16.04 installer gives are a bit succinct! but going back one stage does fix and install works good.

During the 18.04 install attempts NO warning messages received.

Best Wishes Chris

On Sun, Jul 08, 2018 at 09:58:23PM -0000, Chris Chambers wrote:
> I have this problem to and my setup is a bit different and i do not see
> a similar setup mentioned here.

> My disc is GPT partitioned, UEFI is disabled and i boot/install in BIOS
> mode but Ubuntu (Lubuntu) is the only OS installed. That is because off
> a BCM4312 wireless chip which i need compile a module for, no binary
> available. Short off getting that compiled driver signed i must disable
> UEFI and use BIOS mode.

> Disc is partitioned; / , swap , /home , no bios-grub or EFI partition.

> Four attempts to install 18.04 all failed. Problem as noted above.
> Installed 16.04 no problem other than install media does boot as UEFI
> and the messages 16.04 installer gives are a bit succinct! but going
> back one stage does fix and install works good.

> During the 18.04 install attempts NO warning messages received.

With Ubuntu 18.04.1 (and effective today with the current bionic daily
images), the expected behavior is:

 - if the install image is booted in UEFI mode, and the target disk does not
   have an EFI System Partition, only the guided installation options which
   create an ESP will be presented.
 - if an ESP is available, both the UEFI and BIOS versions of GRUB will be
   installed to the target disk. If this is done but the system is not
   booted in UEFI mode, the install will not fail due to the inability of
   grub-install to write the boot order to nvram.
 - after reboot, the system should be bootable via either BIOS or UEFI from
   the target disk, as selected by the firmware.

I think this would address your requirements. Do you agree?

Also, please note that compiling kernel modules for hardware drivers does
NOT require you to disable UEFI boot. At most, it requires you to disable
UEFI SecureBoot. If you are using a dkms package for this module (such as
the broadcom-sta-dkms package), the system will guide you through the
process of enrolling a local kernel module signing key into the MOK firmware
database so that you do not have to disable SecureBoot at all.

Re comment 23, Thank you Steve.

Yes, from what you say of changes made i agree the problem this end will be solved. So i will have another go at installing 18.04 but will wait till 18.04.1 And i will have a go at UEFI boot and to enrol the broadcom-sta-dkms module that you say is possible. A new learning curve for me!

Thanks.

I just fall myself in this case and I think this example and my reflection can help this discussion ...
(Why do I think that you need not only a message, but also a choice box (legacy / efi) when installing ...)

My bios has efi disabled. I configured my boot start without efi with:
1 - cd / dvd
2 - usb
3 - HDD
and I just realized that as soon as I touch this config, it automatically duplicates my choices for devices in:
4 - cd / dvd efi
5 - usb efi
when I start with a cd or a usb key, it goes into auto boot and start directly by switching to 4 or 5 (!). Basically it forces the boot efi even if it is disabled and even if you have filled something else manually ...
that's how I got an "install failed"

If I start by doing F(4-5-6-7...) for boot option: no pb: I have my order manually filled (+ the duplicate choices in efi)

I have an ASUS with a bios update (but seeing what I read on the forums, it must not be the only ones to force the efi this way ...)

Same problem here with a Samsung laptop, with the 18.04.1 Kubuntu image.
A good fix should offer the choice between efi and non efi install like in 16.04, but with a text that is more clear.
Just cary on with the install in efi mode that only leads to install failure is no fix, it will just turn people away

Same issue, built my desktop PC using Asus Deluxe Z170 motherboard in *2017* and installed Win 10 from then bought Win 10 Home DVD. My PC turned out as MBR/BIOS system. I don't know why, that was Microsoft.

Now I wanted to dual boot with Ubuntu 18.04 but the ** USB installer crashes no matter how I create it (Rufus or UUI) etc. It always fails in grub-efi package and the installer won't even exit - it is stuck. Needs power cycle. Please supply a fix soon, I need working Linux. You can also point me to any really operational Linux distro.

Ok, Debian 9 works out-of-box - it detects Win 10 as Win Vista during install and Grub is successfully installed with working dual-boot. It took one try and about 1 hour (Nvidia install included).

The link is https://www.debian.org/distrib/

I used 64-bit netinst iso.

I believe we've addressed the crashes in installer with this bug:
https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1803031

This reverts part of the original changes, to catch cases where an ESP isn't present and the system in booting in UEFI mode: rather than crashing, there will be a clear warning presented to change the partitioning scheme used (to add an ESP partition).

If you absolutely don't want to do that, then the solution will be to boot in BIOS mode, where such a requirement doesn't exist (ie. if you boot in BIOS mode Ubuntu will install in BIOS mode; if you boot in UEFI mode, Ubuntu will install in UEFI mode; and if you install in UEFI mode, you should boot to disk in UEFI mode -- that's typically where things will break; people might be forced into booting in a specific mode for disk, and a different mode for USB / DVD).

If you are having issues with booting in the right mode for what you want; you might want to check forums/ doc for your particular BIOS, some have their own little quirks we might not know about.

In other words, I think we're handling this properly now, by forcing the creation of an ESP when you do the partitioning rather than crashing at the end of the install and not letting you know why things went badly.