Bugzilla – Bug 1224025
Detection of EFI (ASUS?)
Last modified: 2024-05-08 14:49:43 UTC
On ASUS (and perhaps other UEFI implementations) there are two boot entries for DVD in the boot override list. It appears that when one is chosen the EFI will be installed by LEAP 15.6RC, and with the other MBR boot will be installed. This can lead to a very confusing disk situation when an MBR boot is installed on top of an existing EFI boot. It would be useful if at some early stage during installation a warning/information would be given indicating which boot will be installed. Particularly useful would be a warning that MBR boot will be installed on top of a disk partitioned for EFI boot. When I attempted to fix the boot to use EFI the installer said that the hardware did not support EFI. This was not correct. I had booted with the non-EFI entry for the DVD.
If your machine's BIOS / UEFI firmware lets you choose the boot mode (PC legacy vs. secure boot (UEFI)) on the fly, that's a severe bug in that BIOS / UEFI firmware because that boot mode will be purely temporary, and the next regular boot will almost certainly be whatever is configured in the machine's CMOS RAM (the settings that you can configure with the BIOS / UEFI firmware). Worse, even if they do also override subsequent boots, it will clash with existing operating systems. If you have a Windows installation that is set up for secure boot (UEFI) and then you use that override menu to boot into a Linux installation DVD or USB stick in PC legacy boot mode, that Linux will of course use PC legacy boot. If it resizes your Windows, you will end up with two operating systems with conflicting boot modes; one of them will no longer boot. For all variants of SUSE Linux, you can easily see from the installation medium boot screen already if you are booting into PC legacy or UEFI mode: https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-boot-parameters.html#sec-boot-parameters-screen If you see a row of function key descriptions at the bottom, it's PC legacy (BIOS boot) mode: > F1 F2 F3 F4 F5 F6 > Help Language Video mode Source Kernel Driver > English Default Default Default No If you don't see those function key descriptions, just a Grub menu, it's UEFI mode: https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-boot-parameters.html#sec-boot-parameters-uefi > C: Command Line E: Edit Entry
Later in the partitioning workflow step, an UEFI installation will either propose to create a new ESP (EFI System Partition) or to reuse an existing one. In either case, that partition will be mounted at /boot/efi. If there is no /boot/efi in the partitioning proposal, it's not EFI: https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-install.html#sec-yast-install-partitioning-suggested And you will see the boot mode in the "Installation Settings" workflow step in the "Booting" section: https://doc.opensuse.org/documentation/leap/startup/html/book-startup/cha-install.html#sec-yast-install-proposal Notice >> Booting >> ------- >> >> - Boot Loader Type: GRUB2 EFI >> - Secure Boot: enabled (disable) >> - Update NVRAM: enabled (disable) Up to this point, your system was not modified yet, so it is totally safe to get to this step with the "Next" button in all previous steps. Only when you click "Install" here and in the confirmation pop-up dialog, the installation begins. So the information is already there, and also quite visible; it might be more subtle and for experts in the boot screen, but in this final step, I don't think there is any mistaking whether it's PC legacy (BIOS) boot or UEFI boot.
See also https://en.opensuse.org/openSUSE:UEFI
See also https://github.com/yast/yast-storage-ng/blob/master/doc/efi.md Notice the boot parameters > efi=1 or > efi=0 to override the default (U)EFI detection.
Yes, your Windows example is what happened to me. It's an antique system (12 years old) so they'll never update the BIOS. The boot override is on the same EUFI setup page as the controls for secure boot, etc., so they might consider it a non-bug anyhow. After it happened I did read the manuals and figure out what I had done wrong. The easiest fix was to erase the disk and start over, merely time consuming, but it was for a complete re-install so nothing important was lost. My suggestion is just that the installation could notice that it's creating a very unusual partition and boot setup where one of the systems is not bootable. If it had stopped and asked me to confirm that this was really what I wanted, or whether I had booted improperly and wanted reboot properly it would have saved some time. This bug report and comments might be enough too, since others may do a search for EFI bugs and find this.
We discussed this in the team earlier today, but it's not so easy: Trying to fix one scenario might easily break another one. For example, when there is an existing ESP, but the user is about to install a legacy boot system, something is probably about to go wrong: That's an inconsistent setup. Or so we might think, and warn the user accordingly; but that might just be a user who likes to experiment a lot, and who tests the benefits of one boot mode over the other. You'd be amazed about the real-life scenarios that our users come up with, and how many such experimenting users we have. This one scenario and a warning might still be an improvement, though; such a warning would be easy to confirm and override. The opposite scenario not so much, though: If there is an existing OS on the disk using legacy boot, and the user boots the installation medium in UEFI mode and installs an UEFI-based system in parallel, we would simply propose to create an ESP, and that other system wouldn't boot anymore. And it gets worse if users mix and match those things with different disks; we can't even be sure which one is truly the boot disk. Is it /dev/sda or /dev/nvme0n1 ? Your guess is as good as mine. Only the BIOS / the UEFI firmware knows for sure, and the user could easily change it between reboots. That whole legacy BIOS boot vs. UEFI boot thing is another case of PC legacy and its zombies: Trying to remain compatible with a 1985 PC and its weird history and operating systems comes at a cost. And that cost is ambiguity and confusion. But come to think of it, considering that the PC world now has about 40 years worth of history (and SUSE Linux 30 years, and YaST 25 years (since 1999)), all that stuff works amazingly well. It's a lot like the bumblebee: According to the laws of aerodynamics, there is no way that it should be able to fly; but the little bumblebee in its ignorance doesn't know about that and flies regardless. ;-)
I can see how doing anything more than warning would be a mistake. A simple text warning or further information on the page describing intended boot and partitioning with a bit of "what you are doing is unusual, are you sure?" would suffice. I wouldn't ask for a special confirmation. That's already there with the question of whether to proceed. I would have stopped and checked the manual rather than proceed, because I was just planning a routine multi-boot setup. (I might never have triggered this, except that we don't have CDROM/DVD/USB boot available in the normal boot list. So I had to override to pick the DVD. I made a mistake, didn't notice that the DVD was on the list twice, and picked the wrong entry for boot device override. So in a sense it's already a slightly unusual boot setup.) It could also be limited to the checking the partitioning and boot changes to be made. That narrows the scope and eliminates the multidisk boot complexities. It could just be the current description of EFI, MBR, etc. changes plus a statement that this configuration is not common and explaining what's odd. This problem may fade away as the old PCs wear out and cease to function, so maybe waiting for the hardware to fail is reasonable.