Fedora Developers Discussing Possibility Of Dropping Legacy BIOS Support

[Tomin]

The 800-series chipset boards from ASUS had UEFI.

I'm pretty sure that not all of them had UEFI. The first motherboard with 800-series chipeset that I found with quickly searching claims to have "AMI BIOS": https://www.asus.com/Motherboards/M5A87/specifications/

For comparison this 970 motherboard has "UEFI BIOS" and its UEFI is well advertised on product overview: https://www.asus.com/Motherboards/M5A97/specifications/

[Giovanni Fabbro]

The compression ratio is expected to be more like 3:1 or more (depends on the specific compression algorithm used and they have their own tradeoffs). If there is memory pressure beyond that, earlyoom (which is the default in workstation edition and expected to be default for KDE spin in the next release) kicks in and typically does a much better targeting of processes than OOM killer. If you are interested in the specifics, feel free to participate in the test days and submit your feedback.

That's not what the project owner said: he said specifically:

The zram driver starts to allocate memory at roughly 1/2 the rate of page outs, due to compression

I don't like this wording either:

If 2:1 is really obtained...

Sounds like an assumption to me.

This is the part that I don't like either:

During startup, create a zram device /dev/zram0, with a size equal to 50% RAM, but capped† to 4 GiB

So, on a 4GB RAM system, you only have a usable 2GB at startup and the other 2GB is compressed for swap? Then that means that the extra 2-4GB of compressed pages takes extra CPU cycles to compress and decompress?? What if the workload would've just fit between the 2 and 4GB amount of RAM without having zram turned on? Shouldn't zram be applied dynamically instead of statically allocating the RAM at startup? And what happens to processes that still don't fit within the ~6GB of virtual memory (assuming the 2GB allocated physical RAM addresses 4GB of pages) that you get on a 4GB system?

[Giovanni Fabbro]

no, it does not. on windows you start with downloading codecs. on linux it works out of the box

What planet are you living on?

[Giovanni Fabbro]

I'm pretty sure that not all of them had UEFI. The first motherboard with 800-series chipeset that I found with quickly searching claims to have "AMI BIOS": https://www.asus.com/Motherboards/M5A87/specifications/

For comparison this 970 motherboard has "UEFI BIOS" and its UEFI is well advertised on product overview: https://www.asus.com/Motherboards/M5A97/specifications/

Some of the mid-range and higher end models (880/890) that they used to have had UEFI/GPT booting. Could've been hybrid, but it still worked. Asus was ahead of Gigabyte because of that. At the time, Gigabyte boards were cheaper, but the firmware stuff was pretty bad. Lots of Gigabyte boards were stranded in EOL-hell with final BIOS versions adding bug fixes and new CPU compatibility but only coming out as non-production-quality betas, with features removed (like network booting or power management features) to fix their problems because they chose lower-memory BIOS chips. Also, a lot of the Gigabyte boards didn't have an in-built firmware flasher or OS executable, and instead needed a DOS boot disk to flash them. You ever try making a DOS boot disk on Windows before Rufus? How about on a floppy disk because USB thumbdrives had bad support and you couldn't flash from a bootable CD? That's what it was like. Asus had their "EZ Flash"-whatever right in the BIOS, and it supported USB thumbdrives filesystems.

[RahulSundaram]

That's not what the project owner said

I know, hence the added note on the compression algorithm used. Specifically some of them have better compression than others. You can look at the zram compression comparisons for more details

[aht0]

no, it does not. on windows you start with downloading codecs. on linux it works out of the box

The fuck? You download VLC and you are set. Times when you had download codecs for windows were.. era of WinXP?

In other hand, if you wanted OpenSUSE to show movies, you HAD to add custom repo and replace codec-related packages, by default it didn't support much (only non-patent-encumbered codecs included in distro). Still probably hasn't changed that policy.

https://opensuse-guide.org/codecs.php

[edwaleni]

UEFI is EFI 2.0. EFI 1.0/1.1 is what you might find on weird server motherboards before UEFI was a thing, as well as older Mac systems. UEFI is what Windows Vista SP1 and newer support. Windows never supported EFI before UEFI, except on Itanium IA-64, but that's been entirely discontinued anyway. Most of the EFI 1.x variants on server boards are just for system management purposes and include a shell, but supposedly you can shoehorn in a Linux install on them in rare cases. If you can boot Windows on it, it's UEFI. Desktop boards from companies like Intel didn't have EFI prior to UEFI. UEFI was included on boards all the way back to Core 2 days, but it was sometimes unstable and very slow to boot, or didn't always support booting from anything except a hard drive, which made it pretty useless since you had to pre-install an OS image through hard drive replication on another machine; you couldn't boot from USB or CD/DVD on some boards. Most of the old stuff is "Hybrid UEFI" wherein there was just EFI/GPT supported boot path in the BIOS. Nowadays it's all "Native UEFI" with optional BIOS boot via a BIOS emulation chip called a Compatibility Support Module (CSM). The UEFI does the hardware init, while the CSM takes over boot when it's enabled, although it usually means slower bootup, so it's best to keep it off for newer OS installs.

If you're having problem booting after installation, it's probably because your firmware is old and doesn't properly read the bootloader registration - check your installer logs to see if it threw any errors. In UEFI, bootloaders have to be installed on a FAT[32] partition, and it has to be registered in the firmware. Windows will often show up as "Windows Boot Manager", whereas Linux ones will often just simply show as the distro name: "ubuntu", "fedora", etc. Older boards, and especially those from OEM systems (Acer laptops had this issue) didn't do this properly. Newer stuff with UEFI 2.3.x generally "just works". I found that Windows tends to do this better on older boards while Linux bootloaders aren't always registered correctly, probably because it's related to Secure Boot certificate linking. If you have an old board with UEFI with or without Secure Boot and Windows installs fine but Linux doesn't, check to see if Secure Boot is enabled and disable it to see if that works. Otherwise, you might have to see if there's a bootloader selection tool in the firmware interface "BIOS Setup" (sometimes they still call it that when it's UEFI) and select the bootx64.efi or shimx64.efi file in your boot/esp partition. Some OEM firmware interfaces even require that you create a BIOS password before being able to modify bootloader settings or disabling Secure Boot, so YMMV.

Thanks for the detailed response. Oddly I have a mega core Xeon Lenovo that calls it UEFI but it's a legacy boot menu and appears to be supporting EFI 1.2.

I already threw out a collection of Acer's, Dell's and others that had EFI v1 and were just impossible to setup properly beyond Windows.

[AmericanLocomotive]

I think cutting off BIOS is a bit premature at this point. Most OEM systems by ~2009-2010 were UEFI, but a lot of retail motherboard vendors were slow getting there. It wasn't until 2012 or so when everyone really got on board with UEFI. That means there are Sandy Bridge, FX-series chips, and maybe even Ivy-Bridge class chips still running on BIOS systems. Most of those systems (provided they are at least quad core) are still more than adequate.

[michaelb1]

Dropping the "legacy BIOS" support is a horrible idea:
Not just there are a lot of "legacy BIOS" PCs, especially in a corporate world where the upgrades are slower than in the domestic environments.
There are also a lot of really modern PCs running a coreboot firmware with a SeaBIOS payload - which is a modern "legacy BIOS" written in C.
SeaBIOS has just 50k code lines: infinitely slimmer and much more efficient than a bloated UEFI abomination, even a Tianocore opensource one.
UEFI is a "SystemD of a BIOS world", in a horrible way.
Well, if you'd drop a Legacy BIOS support, more of the coreboot opensource BIOS people will move to the other distros,
hopefully those which don't have a SystemD security-vulnerable bloatware - for example, Artix Linux, great user-friendly Arch without SystemD.
So please go ahead and drop "legacy BIOS" support, so there would be one more reason for us to abandon Fedora with a SystemD hardcoded into it.

[michaelb1]

BIOS is 16-bit

Not necessarily. If I remember correctly, SeaBIOS - default payload of opensource coreboot BIOS - is 32-bit.
It's also written mostly in C. And there's nothing UEFI can do that BIOS can't do at least theoretically.
If you can't find some UEFI's (anti-?) feature in a coreboot+SeaBIOS, maybe it wasn't important enough to be added.
GPT and >2.2TB support - everything is possible in the opensource BIOS, if there's enough dedication