While it is technically true that it shouldn't be a problem for virtualization scenarios, I have explored this before for Fedora Cloud with @davdunc, and we have determined it is not feasible because most VPS providers do not use or offer UEFI boot. Eliminating legacy BIOS support would make openSUSE impossible to use on those platforms.

There are also cases with real hardware where UEFI boot is buggy or broken, and the only fallback to make things work is CSM/legacy BIOS boot mode. A lot of pre 2017 hardware is in this bucket, especially before 2015.

Does hardware before 2015 support x86_64-v2 cpu features?

Does hardware before 2015 support x86_64-v2 cpu features?

According to the script from https://unix.stackexchange.com/a/631226, my 2011 ThinkPad X220 (running Tumbleweed) supports x86-64-v2.

I can't picture just what would be removed to prevent legacy booting. Is this some kind of kernel functionality being eliminated, merely the installer refusing to boot except in UEFI mode, or something else? The PC I'm typing this from is Kaby Lake, v3 2017, on 15.6, but very purposely not using UEFI, in large part because of multi- multiboot present on every PC I own, one (GNU/Linux) bootloader per PC, which is all any IBM-compatible PC requires.

x86_64-v2 should be generally supported going back to 2009 (Windows 8 era).

No, it is not. It's an arbitrary bundle of CPU features, some of which are used as product line differentiators in the same product family, and as a result there is no clear cutoff when x86_64-v2 started being universally supported.

As for the way legacy BIOS support is disabled: Yes, it's a kernel feature. To boot using a specific firmware the kernel needs to have a 'stub' that is recognized as a valid executable by that firmware, and unpacks the kernel while executing under that firmware. These are separate for legacy BIOS and EFI.

Hi

We would like to hear from you:
Are you aware of any remaining use cases where the absence of legacy BIOS support could be a blocking issue?

1) UEFI requires a compatible graphics card. Older cards do not support UEFI's GOP or UGA protocols, so the display will remain dark on boot. The solution is to boot in UEFI's emulated BIOS mode (aka CSM, aka Compatibility Support Module mode)

2) BIOS on VMs is still an important use case.

3) There's x86-64 hardware with BIOS only.

Best regards
Thomas

My QNAP NAS's CPU (Intel(R) Xeon(R) CPU E3-1225 V2, from 2012) supports x86-64-v2, yet the motherboard is BIOS-only. It is currently running Leap 15.6.

Of course I understand that for SLES this specific use case might not matter much (especially since SLE15 has still plenty of years of support left) - but I think there are still some Leap users running this kind of hardware combination.

I for once, would be happy to upgrade said machine to 16.0 as soon as it's stable.

I vote to retain legacy BIOS boot.

The only concern I have is often the process if you have to install the nvidia kernel drivers the hard way is much simpler if you switch to legacy bios and don't need to worry about signing keys etc.

Secure boot requires EFI (on x86) but EFI does not require secure boot. It's very much possible to boot using EFI without fiddling with signing keys.

If removing the legacy bios also means coreboot systems cannot boot opensuse anymore, i would be against it. i have a intel tigerlake (v2 capable at least) which is coreboot and i could not use it anymore.

also, but i have currently no knowledge, how well maintained for SUSE/OpenSUSE is the virtualization with the UEFI-system instead of legacy BIOS? If that works well, at least that one is one headache less.

It has been pointed out on the mailing list that with UEFI saving the VM state is flaky.

That's likely one of the reasons legacy BIOS is used so much for VMs.

I'm personally thinking of all desktop virtualization solutions suchas VMWare, Virtualbox, KVM/virt-manager, Parallels where these all prefer legacy bios boot by default. Same for OpenStack. We would have to make sure that default SLES/openSUSE profiles are all switched to UEFI, or users will have bad time figuring out what's wrong. I only suspect that cockpit/libvirt would be the same.

I still have Ivy Bridge and even Sandy Bridge systems around which still work fine (and will continue to work for years to come). Removing legacy boot and requiring x86_64_v2 would break them.

So I think this is a very bad idea. It's almost as bad as what Microsoft does with their artificial barrier to running Windows 11 on older machines. I think a Linux distribution should NOT do such stupid things for no good reasons!

It has been pointed out on the mailing list that with UEFI saving the VM state is flaky.

That's likely one of the reasons legacy BIOS is used so much for VMs.

My understanding is that QEMU snapshotting is unavailable when booted in UEFI mode, which is a huge feature loss for people.

My understanding is that QEMU snapshotting is unavailable when booted in UEFI mode, which is a huge feature loss for people.

Good catch! Coincidentally even Proxmox VE has issues snapshotting UEFI guests - in this case with TPM, because TPM always uses .raw storage, so if underlying FS does not support snapshots (ext4 for example) it is not possible to snapshot whole VM (even when it otherwise uses qcow2 which supports snapshots even on plain ext4).

More details are on https://bugzilla.proxmox.com/show_bug.cgi?id=4693

VMs in UEFI have general issues, because part of mandatory boot configuration is stored in NVRAM, which has to be included with VM export/import - otherwise various problems may occur (depends how smart is UEFI implementation in Hypervisor). Plain BIOS is significantly better, because required boot configuration is stored just on disk image.

SUSE seem to plan for supporting legacy boot stack at least in certain scenarios (Public Cloud as of today). This means that we can have it as it is in Leap 16.0 as of today. We might have a problem getting priority for issues specific to real HW legacy boot, the prediction is that all "potential issues" would be likely happening on VMs (supported cases) as well.

Seems like there is nothing to do on our side. We keep Leap as it is, the legacy bootstack will still be supported by SUSE, as they need it for Public Cloud / VMs. Closing the issue as rejected.