14 ms·

Fedora considers deprecating legacy BIOS

176 points by bitcharmer 5y ago

raverbashing 5y ago
Yeah it seems like a bad idea Especially because of: > Fedora is also installed on cloud servers and virtual machines of various sorts, some of which do not support anything other than booting via BIOS. The proposal noted that the time of the 2020 discussion, Amazon's AWS did not support UEFI, but that has changed. Marc Pervaz Boocha pointed out that many virtual private server (VPS) providers do not support UEFI, giving Linode and Vultr as examples. Dominik "Rathann" Mierzejewski reported that OVH is also affected (or just running virtualized stuff locally)
- martijnvds 5y ago
  It's easy to use EFI when virtualizing things locally. libvirt/kvm supports it, Hyper-V supports it, Virtualbox supports it, ESXi supports it.
  - londons_explore 5y ago
    But change a working virtualized system from BIOS to EFI and there is a good chance a bunch of other things will break. Lots of memory mappings and hardware detection stuff changes if you switch from BIOS to EFI, together with the likely need to repartition or add a virtual disk for the EFI boot partition.
  - AshamedCaptain 5y ago
    As far as I can see, only Hyper-V enables it by default as of today; this means most of the VMs being created _right now_ we can assume to be BIOS rather than UEFI.
  - cesarb 5y ago
    > libvirt/kvm supports it, I recall reading somewhere that using UEFI on qemu/kvm caused problems with snapshotting and/or migration; is that still the case?
  - ridgered4 5y ago
    libvirt/kvm sort of supports it, unless you want to use snapshots I guess. https://bugzilla.redhat.com/show_bug.cgi?id=1881850 https://bugzilla.redhat.com/show_bug.cgi?id=1881850 That bug appears to be a duplicate, I use legacy bios type for all my VMs to get around this since it's been a problem for at least 5 or more years.
Nux 5y ago
The idea was turned down, luckily. There are too many downside at this point in time.
- AreYouSirius 5y ago
blueflow 5y ago
> UEFI is defined by a versioned standard that can be tested and certified against. By contrast, every legacy BIOS is unique. The "standard" for BIOSes was at first the IBM PC ROS's Reference Manual, and later the PS/2 Reference. Naturally, many vendors failed to implement it correctly. But the problem with EFI is the same. Still hoping that someday, EFI netboot support will be something usable. I once considered using EFI as a basis for booting some of my bare-metal works, but: - it requires the GPT partitioning scheme, which in turn requires handling of UUIDs. Their endianess is not little, big - its mixed. mixed in the same value. This is a quirk inherited from Microsoft. - EFI system partition is the FAT file system, which is an FS that is even older than the legacy BIOS. Many gory details. Legacy from Microsoft. - EFI "executables" are actually windows executables, who still start with the 'MZ' header from MS-DOS. The real mode code for displaying "This program cannot be run in DOS mode" is, depending on the toolchain, sometimes still included. Also legacy from Microsoft. I don't see why Linux users should be enthusiastic about adopting this.
- emteycz 5y ago
  I don't see why Linux users would care about this. It boots the system, nobody cares it uses some old MS tech.
  - blueflow 5y ago
    Because "removing legacy" was one of the key arguments of EFI enthusiasts, and its still plenus bovis stercus.
    - froh 5y ago
      "Full of faeces from cows" is and remains vulgar no matter how it's spelled.
      - zozbot234 5y ago
        There's nothing "vulgar" whatsoever about cow dung. It is an eco-friendly, renewable material and commonly used for many sacred rituals in India.
cpach 5y ago
I’m not sure I like that idea. Some older PCs have a very buggy and crappy UEFI implementation. Using UEFI on those can be a nightmare. And upgrading the firmware might not be possible, or only possible via Windows. (Thinkcentre M72e, I’m looking in your direction.)
ulzeraj 5y ago
Nothing against EFI but secure boot as it is is a pain in the ass. Want to install some kernel module to enjoy your Xbox controller? Too bad you need to follow this convoluted guide about generating and installing certificates to sign your driver... or just disable the whole secure boot thingie. Its like selinux hardware edition.
- Foxboron 5y ago
  This is a misnormer though. Secure Boot and kernel modules are not inherently dependent on each other. However modern Linux distribution carry out-of-tree patches which throws the Secure Boot keys into the Linux platform keyring and enforce lockdown mode. This isn't a thing on the stock kernel.
  - AshamedCaptain 5y ago
    They also do this because it is likely that Microsoft will stop signing their bootloaders/kernels with their UEFI CA keys if they allow arbitrary user modules to be loaded (because it would be trivial to abuse those kernels to break Windows' full disk encryption). And if Microsoft stops signing your bootloaders it is an automatic death sentence for your distribution, as you can no longer boot the LiveCD without "scary prompts" and/or fiddling with the BIOS setup.
    - Foxboron 5y ago
      >And if Microsoft stops signing your bootloaders it is an automatic death sentence for your distribution, as you can no longer boot the LiveCD without "scary prompts" and/or fiddling with the BIOS setup. Not really? Several popular Linux distributions simply do not support Secure Boot. Arch Linux is one of them.
      - bscphil 5y ago
        Just for clarification, I believe you mean that it's not something supported out of the box, in the form of a signed kernel / bootloader. It is something Arch Linux users could choose to set up themselves; there's a whole wiki article on it.
cabirum 5y ago
I can see grub2, syslinux, and anaconda are affected in the proposal. (Syslinux removed, others simplified). But then, these are common linux components, not specific to fedora. They are old and battle tested by now, do they really require significant resources to maintain beyond running some automated tests?
turminal 5y ago
Fedora is often the first distro to adopt radical changes like this and then all the other distros follow and then everyone has to live with their decisions, which often turn out to be made too soon. Not looking forward to having to deal with this one.
- johnny22 5y ago
  it's not really happening, or at least not yet. I don't see why this even got posted the way it was.
AshamedCaptain 5y ago
Oh god. So after Windows drops support basically for any PC that is 4 years old, a Linux distribution entertains the idea to follow closely and drop support for any PC that is 10 years old? Is this corporate influence? I cannot believe BIOS boot support is even close to the amount of code required for UEFI boot. Before you say "UEFI is much older than 10 years old", please remember that UEFI only started being a default ever since Windows 8 (10 years old). Windows 7 can't even boot on UEFI (it requires BIOS emulation to be active). I have a system from 7 years ago that while it claims to have an UEFI BIOS, it is so full bugs it is unusable except to boot Windows. I mean, critical bugs, as in, you boot Linux with UEFI just once, you risk the UEFI var storage getting corrupted and the motherboard becoming a paperweight.
- 8K832d7tNmiQ 5y ago
  Look, even if RHEL 10 gonna drop UEFI support maybe sometime in the future, there's gonna be some retro enthusiats who would happily fork it with BIOS support returned. Also, why are you so focused with corporate decision of a distro that is obviously cattered for future devices?
  - AshamedCaptain 5y ago
    "10 year old hardware" is retro ? Ivy Bridge is retro these days? This hardware is not just usable, it is _perfectly usable_, up to the point you'd barely distinguish it Gnome-performance-wise from something from last year if you pair with an SSD (which is not so strange). This is not a 486 with 4megs of RAM that requires a special DE. These are machines with many gigs of RAM that have graphic cards which are still better than some of today's low-end cards. If any change like this is ever accepted, drawing the support line at "10 year old hardware", it's going to be hard to ever again claim that Linux is good for the environment.
    - anthk 5y ago
      You can use several GNU/Linux distros which support BIOSes, even libre ones.
nemetroid 5y ago
I understand the need to get around some of the quirks inherent in BIOS, but the idea of rich pre-OS applications just seems completely backwards. The goal for the early boot environment should be to hand off to the real operating system as soon as possible. Just let me select which disk partition to boot from and the operating system will take it from there, thanks.
- bigpod 5y ago
  its all about UX, if you have an environment that has lots of menus and settings something even bios had to control certien aspects of your system like virtualization support and such you would like to have good UX, because of that UEFI was created. Now if you wanted to do that from OS you can but you need a technology many people hate and want to remove from their systems and hardware called Management Engine. Yes this is the purpose of ME allow changing of UEFI settings from either the OS of machine itself or changing of UEFI settings from another machine without requirement of IPMI(idrac iLo and simular implementations) and rebooting to get to it. Implementation of some sort of ME allows you to overclock your CPU from OS. So AMD has some sort of ME(of course its not called ME since that is just name of intel implementation) as well(how wide in functionality is another question) so do GPUs.
- mwcampbell 5y ago
  > the idea of rich pre-OS applications just seems completely backwards. is at odds with: > let me select which disk partition to boot from As soon as there's any UI at all, one has to deal with much of the complexity of modern UI. For one thing, I'm sure modern firmware has to support modern HID input devices, such as USB keyboards. But also, ideally, that UI should be accessible to people who can't use a minimal screen-and-keyboard UI implementation, such as blind people. This is an area where, even with UEFI, PCs fall short. I like the way Apple has resolved this on its Apple Silicon Macs [1]. As I understand it, as soon as the Mac has to display any UI at boot time, it boots into a minimal version of macOS itself, where VoiceOver and any other accessibility tool can run. I agree, though, that in the common case where the default OS is booted, the path from power-on to OS kernel should be as short as practical. Booting into a BIOS in 8086 emulation mode hardly seems like the best way to do this. But then, a design-by-committee solution like UEFI might not be optimal either. It pains me somewhat to say this, but Apple's proprietary, vertically integrated solution might be near optimal. [1]: https://github.com/AsahiLinux/docs/wiki/Introduction-to-Apple-Silicon https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
mjg59 5y ago
My short summary of this: pretty much every x86 client system since 2012 has shipped with working UEFI support (because Microsoft required it for new Windows 8 systems), and from a compatibility perspective Linux works Just Fine with basically all of them. Servers took a little longer (HP, especially, wanted to do things like just add GPT support to their BIOS implementation), but even that's in a good position now. The biggest concern I have is around cloud, where many providers still don't offer UEFI support. I was on the Fedora technical committee in the past, and if I were still there I feel like I wouldn't go for this now. But I've also been very marginally involved in Fedora in recent years, and I don't think I have a good sense of what the tradeoffs are here. There are legitimate points where it's reasonable to say goodbye to the past, and maybe this is one of them.
- userbinator 5y ago
  Linux works Just Fine with basically all of them. Do you remember this? https://news.ycombinator.com/item?id=11008449 https://news.ycombinator.com/item?id=11008449
  - mjg59 5y ago
    Yeah, turns out representing EFI variables as a filesystem was a mistake (sorry, that was my fault)
- AshamedCaptain 5y ago
  Drawing the line at 10 years old is ... way too close for comfort. I could understand to drop i386 because it basically amounts to another entire architecture, and besides it seems with i386 you are also generally RAM limited which makes it harder to use a recent DE. But a 10 year old computer is perfectly capable of running even the latest version of the heavy-est DEs. Also, "working UEFI supports" means working enough to boot Windows and not much else. Kernel bugzilla still has lots of UEFI bugs open for early UEFI firmware, and even not-so-early UEFI firmware (cough efi=no_disable_early_pci_dma ).
  - Sharlin 5y ago
iod 5y ago
UEFI emulation is a thing. For people with legacy-only firmware systems, you too can run UEFI on lazy cloud providers and legacy hardware. I do this on my 14 year old dell laptop just so that all my x86_64 systems have the same boot efistub linux kernel images. All you need is to use one of the EDK DUET bootloader builds such as BootDuet¹, or for an easier user experience CloverBootloader². Only complaint is secureboot emulation can be a pain. But I imagine with Windows 11 around the corner requiring TPMs (which might require emulation on older hardware that doesn't have it) and secureboot, UEFI firmware emulators with these feature will probably get more popular and more accessible. ¹ https://github.com/migle/BootDuet https://github.com/migle/BootDuet ² https://github.com/CloverHackyColor/CloverBootloader https://github.com/CloverHackyColor/CloverBootloader
- zinekeller 5y ago
  > But I imagine with Windows 11 around the corner requiring TPMs (which might require emulation on older hardware that doesn't have it) and secureboot, UEFI firmware emulators with these feature will probably get more popular and more accessible. Unfortunately, there's no appetite - there's no point since that in a significant break Windows 11 only runs on new processors that happens to have both UEFI and TPM (not always enabled by default but it's there).
  - iod 5y ago
    Apparently you can officially just shut off the restriction that forces Windows 11 to only run on new CPUs and the newest TPM by just setting a registry key AllowUpgradesWithUnsupportedTPMOrCPU on install.¹ But I never use Windows and don't plan to start anytime soon, so it's not something that I will try. ¹ https://support.microsoft.com/en-us/windows/ways-to-install-windows-11-e0edbbfb-cfc5-4011-868b-2ce77ac7c70e https://support.microsoft.com/en-us/windows/ways-to-install-...
- AshamedCaptain 5y ago
  I don't think you can emulate a TPM via software. You need a hook in the firmware and use SystemManagementMode/SMM, very likely.
guerrilla 5y ago
I understand why this stuff usually bothers people but I think this makes for Fedora specifically... they're popular and bleeding-edge, so they want to work on the latest popular hardware and not cater to minorities. If a hacker needs different, there's other distros and DIY, if a company needs different then they can just invest in maintenance of that themselves. Yeah, EFI sucks bad and we should be working to replace it with something that's free/open and actually good but this is the environment we're actually operate in and being in denial of that doesn't help anyone.
bigpod 5y ago
while fedora defenetly is not my cup of tea, first thing i do when i get a new system(desktop or laptop) is disable legacy bios/CSM whatever it is labeled as. This is to prevent mirriad of issus BIOS brings including its horrible MBR. GPT is million times better and for someone who dual boots on many machines (and has a drive with 14 different operating systems as a test) to all you legacy BIOS and MBR fans MBR doesnt cut it and is cause of many headaches if you dual boot. Remember how some people have had issues with windows destroying booting of linux that is due to MBR being a useless piece of antiquated software and breaking. It wasnt windows's fault its just that its update utility had to overwrite a part of MBR and since MBR was already basically a house of cards all you had to do to break it is have a little mishap and your linux boot is gone (it was same on other side just less people were crying about it because well they blamed windows for breaking itself)
- morganvachon 5y ago
  This is fine for you and your use case, but some of us (as pointed out in the article) are forced to stay with BIOS either due to owning legacy hardware that is still fully functional and even necessary, or because we use VMs and/or hosted services that require BIOS and don't support UEFI, or both. I'm one of those; I use a few legacy machines locally and I have VPS instances hosted with Vultr. Granted, I don't use Fedora so this doesn't directly affect me yet, but the Linux community has a history of too-early adoption of ideas started at Fedora (systemd, pulseaudio) that take years to reach production-ready status, if ever. At some point those of us who still use legacy hardware at home/work will be forced to either throw out perfectly good machines, or switch to a holdout distro like Slackware or Void (not that there's anything wrong with either of those) and lose valuable time moving our workflow. We'll also be at the mercy of our hosting providers as they decide whether to overhaul their entire hosting backend, or else drop Fedora and any other distro that follows their lead. I get that UEFI is the future of bootstrapping, but it's too early to pull the plug on BIOS.
  - TZubiri 5y ago
    At this point we should have learned the lesson from systemd, I think red hat now has a bad enough reputation that everything with their brand is an instant rejection, and any suggestion they throw is taken as a suggestion of what not to do. Red hat flatlined when it was acquired by IBM, a consequence of a free as in free beer model to software.
amir 5y ago
I wish people would stop sharing LWN subscriber links for karma. They're not meant to be shared in social news websites. https://lwn.net/op/FAQ.lwn#slinks https://lwn.net/op/FAQ.lwn#slinks 20 of the poster's last 30 submissions have been LWN subscriber links.
- reaperducer 5y ago
  They're not meant to be shared in social news websites. From your link: "Where is it appropriate to post a subscriber link? Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared."
  - debugnik 5y ago
    Having access to nearly every paid LWN article on a news aggregator certainly feels like "a way to defeat our attempts to gain subscribers". But others said these links are subscriber-specific so I guess LWN is fine with it if they aren't taking the links down.
- Macha 5y ago
  As well as LWN's declared policy, the subscriber links are also linked to the user that generated them - if LWN felt they were being abused, they could disable that user's access to them.
lynguist 5y ago
According to Wikipedia, Intel’s 945 chipset for Core 2 processors ships with UEFI. This was originally released in 2006. Note that Google Chrome which is the web browser with the highest adoption rate requires a CPU with SSE3 support which was introduced in 2004. Which platform older than a Core 2 can even run the latest operating systems? The very latest Pentium 4 range (2004-2006)? So we would just be dropping support for them? That’s OK.
- lynguist 5y ago
  I found that the latest BIOS only devices were released in 2013 which are based on the AMD Bobcat processor (AMD’s version of Intel Atom). I wouldn’t know what operating system to run on those systems.
- cestith 5y ago
  OpenBSD 7.1 was just released and supports my G5 Mac. It also supports i386, UltraSparc, and Digital Alpha. NetBSD supports i386, Alpha, Amiga, 32-bit Sparc, 32-bit MIPS, ARMv6, StrongARM, sun2, sun3... LinuxMint still supports i686. Debian supports i386, i686, armel, armhf, s390, and MIPS. Slackware supports i586 and s390. Kali supports i686. Void Linux supports i686, ARMv6, ARV7. FreeBSD supports arm, armel, i386, ia64, mips, mipsel, sparc64, pc98, powerpc, powerpc64, ps3, xbox. Alpine supports i486, ppc64le, s390x, armhf. Devuan supports i686. Gentoo supports i486, i586, i686, alpha, arm, hppa, ia64, mips, powerpc, ppc64, sparc64. Which of these don't have recent releases?
  - lynguist 5y ago
    According to discussions on the Gentoo [1] and Fedora [2] forums, i686 without SSE2 could be broken in some packages in subtle ways. One is that the stack alignment changed from 4 bytes to 16 bytes, another is long NOPs, another is that some software seems to require SSE2 on i686 like rustc or qt. Even those platforms that claim to build for i686, I’m not sure if everything works correctly on pre-SSE2 (Pentium Pro, Pentium III, older Pentium 4) CPUs. And I don’t think any of the Linux distributions will actually run on a i386, i486 or i586 as i686 is almost required to have multithreading without busy waits. The BSDs I don’t know about, but it’s a fair number of distributions that seem to support older x86 CPUs you posted. I didn’t know there would be so many. I couldn’t find Linux Mint though. [1]: https://forums.gentoo.org/viewtopic-t-1087434.html?sid=4b6827908e12de8e6092b660efa28f3a https://forums.gentoo.org/viewtopic-t-1087434.html?sid=4b682... [2]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HC2NLE3CQHIJRWFYSPR6HQI67PZLZP4E/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...
BirAdam 5y ago
At a time when the world is producing several hundred million tons of e-waste each year, that this was even entertained is bad. I suppose its fine to make toxic trash mountains in the third world to get rid of a small amount of code bloat?
- mustache_kimono 5y ago
  Anyone who says things like this, should be the ones that have to support the legacy code. They should be sentenced to a 15+ year old computer and to explain to their colleagues how we just can't do anything new, because we need to use GCC 4.7 to build the world because <legacy CPU>, now used by 20 non-paying users, won't work with anything newer. Fedora is only one, relatively fast moving distro, which gives you their software for free, and which didn't even make this decision, but who could blame them if they did, in their position?
  - probably_wrong 5y ago
    > They should be sentenced to a 15+ year old computer I bought my computer about 15 years ago, with what at the time was a pretty beefy setup. I still use it for my everyday work because, as it turns out, you don't need much more than 4Gb of RAM to surf the internet. Due to buggy UEFI support, I cannot reinstall Windows 10 on that PC. If Linux stopped supporting Bios, I'd have to throw it away. But more importantly, this computer has better performance than the computers of many of my relatives in South America. I wish every developer in the first world had to explain at least once to their nieces that no, Roblox will not work on their Chinese Android tablet with 1Gb of RAM.
    - mustache_kimono 5y ago
      But Linux isn't ending support of BIOS, Fedora considered it but won't yet. If Arch Linux decided not to support BIOS, we'd say, "Well they are a bleeding edge distro", but guess what, "Shhhh... so is Fedora." Old hardware is great. Expecting people to support it forever for free is folly. This is exactly why people pay IBM/RedHat for support.
    - 5y ago
userbinator 5y ago
Leave things as they are. Code continues to rot. What is this ever-present BS about "rot"!? Why do people think continual changes are even needed? Code should become more stable over time, an ideal that I wish much more software would follow. The way BIOS boot works has basically remained unchanged ever since the first IBM PC, and it's incredibly simple. Linus Torvald's opinion of EFI is worth reading: https://yarchive.net/comp/linux/efi.html https://yarchive.net/comp/linux/efi.html 7C00h forever! ;-)
- tenebrisalietum 5y ago
  The intersection point between simple and useful is this: - Firmware understands some sort of minimal filesystem and how to talk to a device containing it. - Firmware has a configuration store that holds a few variables and a device tree. - Firmware has the ability to load binary images into RAM from the minimal filesystem above. - On boot, configuration is checked, the kernel and initrd are binary-loaded into RAM, and the firmware jumps to the kernel with a pointer to the commandline, initrd, and device tree. U-Boot more or less does this and it's beautiful. The bootloader loads your OS and then gets out of the way. No multistage crap or overengineered firmware interfaces.
  - userbinator 5y ago
    I don't think firmware should care at all about filesystems, because that's already halfway towards being an OS. It should just load the first sector from the selected boot device and jump to it.
    - tenebrisalietum 5y ago
      - You're already getting into "halfway towards being an OS" territory if you want to netboot. - Eliminating variable code from the boot process makes it more secure and reliable. Why do I need to load a separate loader to load my OS which is overwriteable by my OS if the firmware can do it in a standard, fixed way? - At least have some mechanism to load an arbitrary number of sectors.
BeefWellington 5y ago
This is a bit of a tone deaf idea to explore right now. If anything, the environment and chip shortage issues should be pushing people to promise extending support for older systems for another decade. That said, while there are loads of systems out there that could still use BIOS, I like to look at the second hand market. There are a lot of Dell R710s for sale on eBay still (700+ listings). These are commonly suggested as a good "intro to homelabbing" server in a variety of places. These systems were released in 2009, often featuring CPUs from 2007-2008. They support UEFI 2.1. Contrasting this, some UEFI implementations are horrifically buggy and largely seem designed to only work with Windows. I think 10 years is probably too close a cutoff but I do think that eventually it becomes a lot more work to maintain it (like i386 builds, x32 builds, etc.) and becomes not worth it except for niche distros. If we factor in things like environmental impact, it makes a great deal more sense to continue to support older systems for some longer period of time.
- ancientsofmumu 5y ago
  Side note: Red Hat disabled the kernel code for the Perc 6/I raid card which is standard in the basic R710 chassis starting with RHEL8. Unless you have the higher end H710 raid controller or whatever else, Red Hat rendered this chassis controller inoperable with their custom in-house kernel patching process.
- bitwize 5y ago
  > Contrasting this, some UEFI implementations are horrifically buggy and largely seem designed to only work with Windows. UEFI specifications are like Web specifications: they're good to wipe your ass with, but on the Web when the rubber meets the road, the only "standard" that matters is "does it work in Chrome" (in the past, IE). Similarly the only standard that a UEFI implementation need comply with is "does it boot Windows".
- li2uR3ce 5y ago
  > That said, while there are loads of systems out there that could still use BIOS, I like to look at the second hand market. I have lots of UEFI hardware with never-to-be-fixed bugs that are mitigated by just using BIOS boot. These are from Dell and Supermicro. The Dells when set for UEFI would boot 50% of the time and 100% of the time in BIOS mode. The workaround was well known and is the only reasonable thing to do. It's EOL from dell it will never be patched. The Supermicro's would work great in UEFI but the factory default was BIOS boot. The trouble is that these particular systems had a reasonably high chance of loosing BIOS setup data if they took a power hit (APC UPS are complete garbage FWIW). We'd have to send someone to a remote location to switch it back to UEFI or just reinstall in BIOS mode. By default they would remarkably turn back on when the power was restored and would recover fine if they could boot. This stuff isn't useless or even THAT old. It's just unreliable in UEFI mode. While most newer stuff from these brands have more reliable UEFI, we're going to keep using hardware that is good enough. We work around hardware/firmware problems because there's nothing out there that doesn't have quirks. "Old" hardware has known quirks that have workarounds that have already been "paid for" with expended labor. New hardware has new quirks that you have to pay off. Of course it's all moot for this discussion as we don't use rolling quirk factories like Fedora.
zaolin 5y ago
The whole step moving forward into the UEFI direction on Client Computing Systems (laptops, desktop) is the right way. Even if I dislike the UEFI specification and existing implementations, the spec is more than 24 years old. It might fulfill its purpose as a bootloader/OS interface. The UEFI BDS interface, the one the most people see and the operating system interfaces, is now standardized for many operating systems and OEMs, making it easier to integrate and maintain. It is finally possible to use standard security mechanisms (verified, measured boot) to secure your device. So we can use such technologies to ensure device security reasonably as we do in my corp www.immu.ne The custom certificate provisioning is a mess and hard to use, but that can be possibly made easy by projects like: https://github.com/Foxboron/sbctl https://github.com/Foxboron/sbctl I don't believe the UEFI interface is beneficial for data-center or embedded devices. The UEFI BDS interface was developed for client platforms and required physical presence. It leads to complexity in the DC and embedded world. I feel a more suitable approach would be www.linuxboot.org which is already used by many Hyperscalers and Embedded companies. That's my 50 cents about the story. My background, I am coreboot developer and security architect.
cestith 5y ago
A whole lot of the maintenance headache could be solved by choosing five or fewer BIOS implementations to fully support and letting everything else go by the wayside. Choose the ones from VMware, VirtualBox, and such and a couple of popular server and desktop ones.
egberts1 5y ago
You will have to pry that BIOS from my cold dead hands. Burnt EEPROM still remains the ultimate security.
rvp-x 5y ago
Fedora didn't even support UEFI on their cloud images before Fedora 35, released 5 months ago. https://pagure.io/cloud-sig/issue/309 https://pagure.io/cloud-sig/issue/309
kevinoid 5y ago
Perhaps this is a good time to ask: I'd like to use UEFI for my qemu+libvirt virtual machines, but I need snapshot support. Since QEMU doesn't support pflash internal snapshots <https://gitlab.com/libvirt/libvirt/-/commit/9e2465834f4bff4068e270f15e9ed5d7301de045 https://gitlab.com/libvirt/libvirt/-/commit/9e2465834f4bff40...> and libvirt can't revert or delete external snapshots <https://bugzilla.redhat.com/show_bug.cgi?id=1519002 https://bugzilla.redhat.com/show_bug.cgi?id=1519002>, I don't see a way to achieve this. The issue was discussed on virt-tools in 2017 <https://listman.redhat.com/archives/virt-tools-list/2017-September/msg00008.html https://listman.redhat.com/archives/virt-tools-list/2017-Sep...> and the situation appears to be unchanged. Do others have a workable solution?
Scramblejams 5y ago
In my admittedly limited time using Linux (switched to it full-time in ~2001), the total amount of effort I've spent troubleshooting issues has probably been dominated by two categories: 1. Getting audio to behave. 2. Boot problems. (waves at LILO) I don't know enough details about how UEFI and BIOS and MBR and GRUB and all of this works -- which probably contributed to my difficulties. But the problems certainly didn't end when I left LILO behind. So it always makes me wonder: Have the people responsible for the bootloaders ever used a Mac? My goodness it could not be simpler. Hold the right key combo at boot time and you get a nice interface that shows you all the bootable devices you've got plugged in. USB, SATA, NVMe, whatever, it's there. And when you select one and boot, it actually works. Recognizing that we don't actually need a GUI for this, and the challenge is different because Apple gets to use firmware and only worries about one type of OS, what would it take to make a PC bootloader work just as nicely?
- dralley 5y ago
  > Apple gets to use firmware and only worries about one type of OS, And a very, very narrow set of potential hardware compared to the entire PC ecosystem.
- ElectricalUnion 5y ago
  > what would it take to make a PC bootloader work just as nicely? If we take Apple's bootloader as a base line: Drop GPU support, except for blessed models, from initial boot support. Remove RAM customization options. Can't change speed and timings. Can't support ECC. Might as well disallow customizing RAM alltogether and solder it to the board or in the SOC. Remove CPU customization options. Can't change speed, enable or disable supported features. Can't chage ACPI tables. Remove storage customization options. Can't change storage speed, protocol support. Can't even add or remove internal storage devices at all, if we go by the latest trend. Implement a bluetooth stack onto the bootloader firmware, because that's for sure safe and could never go wrong. Force OSes to write their pairing keys in the firmware storage. Implement a wifi stack onto the bootloader firmware, because that's for sure safe and could never go wrong. Force OSes to write their pairing keys in the firmware storage. Implement internet-based, network boot support from a centralized, blessed location. Because that's completly safe and could never go wrong.
codedokode 5y ago
> UEFI is defined by a versioned standard that can be tested and certified against But is it actually tested against or only can be?
2OEH8eoCRo0 5y ago
Good. More time to work on new stuff.
morekozhambu 5y ago

176 points by bitcharmer 5y ago

Yeah it seems like a bad idea Especially because of: > Fedora is also installed on cloud servers and virtual machines of various sorts, some of which do not support anything other than booting via BIOS. The proposal noted that the time of the 2020 discussion, Amazon's AWS did not support UEFI, but that has changed. Marc Pervaz Boocha pointed out that many virtual private server (VPS) providers do not support UEFI, giving Linode and Vultr as examples. Dominik "Rathann" Mierzejewski reported that OVH is also affected (or just running virtualized stuff locally)

martijnvds 5y ago
It's easy to use EFI when virtualizing things locally. libvirt/kvm supports it, Hyper-V supports it, Virtualbox supports it, ESXi supports it.
- londons_explore 5y ago
  But change a working virtualized system from BIOS to EFI and there is a good chance a bunch of other things will break. Lots of memory mappings and hardware detection stuff changes if you switch from BIOS to EFI, together with the likely need to repartition or add a virtual disk for the EFI boot partition.
- AshamedCaptain 5y ago
  As far as I can see, only Hyper-V enables it by default as of today; this means most of the VMs being created _right now_ we can assume to be BIOS rather than UEFI.
- cesarb 5y ago
  > libvirt/kvm supports it, I recall reading somewhere that using UEFI on qemu/kvm caused problems with snapshotting and/or migration; is that still the case?
- ridgered4 5y ago
  libvirt/kvm sort of supports it, unless you want to use snapshots I guess. https://bugzilla.redhat.com/show_bug.cgi?id=1881850 https://bugzilla.redhat.com/show_bug.cgi?id=1881850 That bug appears to be a duplicate, I use legacy bios type for all my VMs to get around this since it's been a problem for at least 5 or more years.

Nux 5y ago

The idea was turned down, luckily. There are too many downside at this point in time.

AreYouSirius 5y ago

blueflow 5y ago

> UEFI is defined by a versioned standard that can be tested and certified against. By contrast, every legacy BIOS is unique. The "standard" for BIOSes was at first the IBM PC ROS's Reference Manual, and later the PS/2 Reference. Naturally, many vendors failed to implement it correctly. But the problem with EFI is the same. Still hoping that someday, EFI netboot support will be something usable. I once considered using EFI as a basis for booting some of my bare-metal works, but: - it requires the GPT partitioning scheme, which in turn requires handling of UUIDs. Their endianess is not little, big - its mixed. mixed in the same value. This is a quirk inherited from Microsoft. - EFI system partition is the FAT file system, which is an FS that is even older than the legacy BIOS. Many gory details. Legacy from Microsoft. - EFI "executables" are actually windows executables, who still start with the 'MZ' header from MS-DOS. The real mode code for displaying "This program cannot be run in DOS mode" is, depending on the toolchain, sometimes still included. Also legacy from Microsoft. I don't see why Linux users should be enthusiastic about adopting this.

emteycz 5y ago
I don't see why Linux users would care about this. It boots the system, nobody cares it uses some old MS tech.
- blueflow 5y ago
  Because "removing legacy" was one of the key arguments of EFI enthusiasts, and its still plenus bovis stercus.
  - froh 5y ago
    "Full of faeces from cows" is and remains vulgar no matter how it's spelled.
    - zozbot234 5y ago
      There's nothing "vulgar" whatsoever about cow dung. It is an eco-friendly, renewable material and commonly used for many sacred rituals in India.

cpach 5y ago

I’m not sure I like that idea. Some older PCs have a very buggy and crappy UEFI implementation. Using UEFI on those can be a nightmare. And upgrading the firmware might not be possible, or only possible via Windows. (Thinkcentre M72e, I’m looking in your direction.)

ulzeraj 5y ago

Nothing against EFI but secure boot as it is is a pain in the ass. Want to install some kernel module to enjoy your Xbox controller? Too bad you need to follow this convoluted guide about generating and installing certificates to sign your driver... or just disable the whole secure boot thingie. Its like selinux hardware edition.

Foxboron 5y ago
This is a misnormer though. Secure Boot and kernel modules are not inherently dependent on each other. However modern Linux distribution carry out-of-tree patches which throws the Secure Boot keys into the Linux platform keyring and enforce lockdown mode. This isn't a thing on the stock kernel.
- AshamedCaptain 5y ago
  They also do this because it is likely that Microsoft will stop signing their bootloaders/kernels with their UEFI CA keys if they allow arbitrary user modules to be loaded (because it would be trivial to abuse those kernels to break Windows' full disk encryption). And if Microsoft stops signing your bootloaders it is an automatic death sentence for your distribution, as you can no longer boot the LiveCD without "scary prompts" and/or fiddling with the BIOS setup.
  - Foxboron 5y ago
    >And if Microsoft stops signing your bootloaders it is an automatic death sentence for your distribution, as you can no longer boot the LiveCD without "scary prompts" and/or fiddling with the BIOS setup. Not really? Several popular Linux distributions simply do not support Secure Boot. Arch Linux is one of them.
    - bscphil 5y ago
      Just for clarification, I believe you mean that it's not something supported out of the box, in the form of a signed kernel / bootloader. It is something Arch Linux users could choose to set up themselves; there's a whole wiki article on it.

cabirum 5y ago

I can see grub2, syslinux, and anaconda are affected in the proposal. (Syslinux removed, others simplified). But then, these are common linux components, not specific to fedora. They are old and battle tested by now, do they really require significant resources to maintain beyond running some automated tests?

turminal 5y ago

Fedora is often the first distro to adopt radical changes like this and then all the other distros follow and then everyone has to live with their decisions, which often turn out to be made too soon. Not looking forward to having to deal with this one.

johnny22 5y ago
it's not really happening, or at least not yet. I don't see why this even got posted the way it was.

AshamedCaptain 5y ago

Oh god. So after Windows drops support basically for any PC that is 4 years old, a Linux distribution entertains the idea to follow closely and drop support for any PC that is 10 years old? Is this corporate influence? I cannot believe BIOS boot support is even close to the amount of code required for UEFI boot. Before you say "UEFI is much older than 10 years old", please remember that UEFI only started being a default ever since Windows 8 (10 years old). Windows 7 can't even boot on UEFI (it requires BIOS emulation to be active). I have a system from 7 years ago that while it claims to have an UEFI BIOS, it is so full bugs it is unusable except to boot Windows. I mean, critical bugs, as in, you boot Linux with UEFI just once, you risk the UEFI var storage getting corrupted and the motherboard becoming a paperweight.

8K832d7tNmiQ 5y ago
Look, even if RHEL 10 gonna drop UEFI support maybe sometime in the future, there's gonna be some retro enthusiats who would happily fork it with BIOS support returned. Also, why are you so focused with corporate decision of a distro that is obviously cattered for future devices?
- AshamedCaptain 5y ago
  "10 year old hardware" is retro ? Ivy Bridge is retro these days? This hardware is not just usable, it is _perfectly usable_, up to the point you'd barely distinguish it Gnome-performance-wise from something from last year if you pair with an SSD (which is not so strange). This is not a 486 with 4megs of RAM that requires a special DE. These are machines with many gigs of RAM that have graphic cards which are still better than some of today's low-end cards. If any change like this is ever accepted, drawing the support line at "10 year old hardware", it's going to be hard to ever again claim that Linux is good for the environment.
  - anthk 5y ago
    You can use several GNU/Linux distros which support BIOSes, even libre ones.

nemetroid 5y ago

I understand the need to get around some of the quirks inherent in BIOS, but the idea of rich pre-OS applications just seems completely backwards. The goal for the early boot environment should be to hand off to the real operating system as soon as possible. Just let me select which disk partition to boot from and the operating system will take it from there, thanks.

bigpod 5y ago
its all about UX, if you have an environment that has lots of menus and settings something even bios had to control certien aspects of your system like virtualization support and such you would like to have good UX, because of that UEFI was created. Now if you wanted to do that from OS you can but you need a technology many people hate and want to remove from their systems and hardware called Management Engine. Yes this is the purpose of ME allow changing of UEFI settings from either the OS of machine itself or changing of UEFI settings from another machine without requirement of IPMI(idrac iLo and simular implementations) and rebooting to get to it. Implementation of some sort of ME allows you to overclock your CPU from OS. So AMD has some sort of ME(of course its not called ME since that is just name of intel implementation) as well(how wide in functionality is another question) so do GPUs.
mwcampbell 5y ago
> the idea of rich pre-OS applications just seems completely backwards. is at odds with: > let me select which disk partition to boot from As soon as there's any UI at all, one has to deal with much of the complexity of modern UI. For one thing, I'm sure modern firmware has to support modern HID input devices, such as USB keyboards. But also, ideally, that UI should be accessible to people who can't use a minimal screen-and-keyboard UI implementation, such as blind people. This is an area where, even with UEFI, PCs fall short. I like the way Apple has resolved this on its Apple Silicon Macs [1]. As I understand it, as soon as the Mac has to display any UI at boot time, it boots into a minimal version of macOS itself, where VoiceOver and any other accessibility tool can run. I agree, though, that in the common case where the default OS is booted, the path from power-on to OS kernel should be as short as practical. Booting into a BIOS in 8086 emulation mode hardly seems like the best way to do this. But then, a design-by-committee solution like UEFI might not be optimal either. It pains me somewhat to say this, but Apple's proprietary, vertically integrated solution might be near optimal. [1]: https://github.com/AsahiLinux/docs/wiki/Introduction-to-Apple-Silicon https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...

mjg59 5y ago

My short summary of this: pretty much every x86 client system since 2012 has shipped with working UEFI support (because Microsoft required it for new Windows 8 systems), and from a compatibility perspective Linux works Just Fine with basically all of them. Servers took a little longer (HP, especially, wanted to do things like just add GPT support to their BIOS implementation), but even that's in a good position now. The biggest concern I have is around cloud, where many providers still don't offer UEFI support. I was on the Fedora technical committee in the past, and if I were still there I feel like I wouldn't go for this now. But I've also been very marginally involved in Fedora in recent years, and I don't think I have a good sense of what the tradeoffs are here. There are legitimate points where it's reasonable to say goodbye to the past, and maybe this is one of them.

userbinator 5y ago
Linux works Just Fine with basically all of them. Do you remember this? https://news.ycombinator.com/item?id=11008449 https://news.ycombinator.com/item?id=11008449
- mjg59 5y ago
  Yeah, turns out representing EFI variables as a filesystem was a mistake (sorry, that was my fault)
AshamedCaptain 5y ago
Drawing the line at 10 years old is ... way too close for comfort. I could understand to drop i386 because it basically amounts to another entire architecture, and besides it seems with i386 you are also generally RAM limited which makes it harder to use a recent DE. But a 10 year old computer is perfectly capable of running even the latest version of the heavy-est DEs. Also, "working UEFI supports" means working enough to boot Windows and not much else. Kernel bugzilla still has lots of UEFI bugs open for early UEFI firmware, and even not-so-early UEFI firmware (cough efi=no_disable_early_pci_dma ).
- Sharlin 5y ago

iod 5y ago

UEFI emulation is a thing. For people with legacy-only firmware systems, you too can run UEFI on lazy cloud providers and legacy hardware. I do this on my 14 year old dell laptop just so that all my x86_64 systems have the same boot efistub linux kernel images. All you need is to use one of the EDK DUET bootloader builds such as BootDuet¹, or for an easier user experience CloverBootloader². Only complaint is secureboot emulation can be a pain. But I imagine with Windows 11 around the corner requiring TPMs (which might require emulation on older hardware that doesn't have it) and secureboot, UEFI firmware emulators with these feature will probably get more popular and more accessible. ¹ https://github.com/migle/BootDuet https://github.com/migle/BootDuet ² https://github.com/CloverHackyColor/CloverBootloader https://github.com/CloverHackyColor/CloverBootloader

zinekeller 5y ago
> But I imagine with Windows 11 around the corner requiring TPMs (which might require emulation on older hardware that doesn't have it) and secureboot, UEFI firmware emulators with these feature will probably get more popular and more accessible. Unfortunately, there's no appetite - there's no point since that in a significant break Windows 11 only runs on new processors that happens to have both UEFI and TPM (not always enabled by default but it's there).
- iod 5y ago
  Apparently you can officially just shut off the restriction that forces Windows 11 to only run on new CPUs and the newest TPM by just setting a registry key AllowUpgradesWithUnsupportedTPMOrCPU on install.¹ But I never use Windows and don't plan to start anytime soon, so it's not something that I will try. ¹ https://support.microsoft.com/en-us/windows/ways-to-install-windows-11-e0edbbfb-cfc5-4011-868b-2ce77ac7c70e https://support.microsoft.com/en-us/windows/ways-to-install-...
AshamedCaptain 5y ago
I don't think you can emulate a TPM via software. You need a hook in the firmware and use SystemManagementMode/SMM, very likely.

guerrilla 5y ago

I understand why this stuff usually bothers people but I think this makes for Fedora specifically... they're popular and bleeding-edge, so they want to work on the latest popular hardware and not cater to minorities. If a hacker needs different, there's other distros and DIY, if a company needs different then they can just invest in maintenance of that themselves. Yeah, EFI sucks bad and we should be working to replace it with something that's free/open and actually good but this is the environment we're actually operate in and being in denial of that doesn't help anyone.

bigpod 5y ago

while fedora defenetly is not my cup of tea, first thing i do when i get a new system(desktop or laptop) is disable legacy bios/CSM whatever it is labeled as. This is to prevent mirriad of issus BIOS brings including its horrible MBR. GPT is million times better and for someone who dual boots on many machines (and has a drive with 14 different operating systems as a test) to all you legacy BIOS and MBR fans MBR doesnt cut it and is cause of many headaches if you dual boot. Remember how some people have had issues with windows destroying booting of linux that is due to MBR being a useless piece of antiquated software and breaking. It wasnt windows's fault its just that its update utility had to overwrite a part of MBR and since MBR was already basically a house of cards all you had to do to break it is have a little mishap and your linux boot is gone (it was same on other side just less people were crying about it because well they blamed windows for breaking itself)

morganvachon 5y ago
This is fine for you and your use case, but some of us (as pointed out in the article) are forced to stay with BIOS either due to owning legacy hardware that is still fully functional and even necessary, or because we use VMs and/or hosted services that require BIOS and don't support UEFI, or both. I'm one of those; I use a few legacy machines locally and I have VPS instances hosted with Vultr. Granted, I don't use Fedora so this doesn't directly affect me yet, but the Linux community has a history of too-early adoption of ideas started at Fedora (systemd, pulseaudio) that take years to reach production-ready status, if ever. At some point those of us who still use legacy hardware at home/work will be forced to either throw out perfectly good machines, or switch to a holdout distro like Slackware or Void (not that there's anything wrong with either of those) and lose valuable time moving our workflow. We'll also be at the mercy of our hosting providers as they decide whether to overhaul their entire hosting backend, or else drop Fedora and any other distro that follows their lead. I get that UEFI is the future of bootstrapping, but it's too early to pull the plug on BIOS.
- TZubiri 5y ago
  At this point we should have learned the lesson from systemd, I think red hat now has a bad enough reputation that everything with their brand is an instant rejection, and any suggestion they throw is taken as a suggestion of what not to do. Red hat flatlined when it was acquired by IBM, a consequence of a free as in free beer model to software.

amir 5y ago

I wish people would stop sharing LWN subscriber links for karma. They're not meant to be shared in social news websites. https://lwn.net/op/FAQ.lwn#slinks https://lwn.net/op/FAQ.lwn#slinks 20 of the poster's last 30 submissions have been LWN subscriber links.

reaperducer 5y ago
They're not meant to be shared in social news websites. From your link: "Where is it appropriate to post a subscriber link? Almost anywhere. Private mail, messages to project mailing lists, and blog entries are all appropriate. As long as people do not use subscriber links as a way to defeat our attempts to gain subscribers, we are happy to see them shared."
- debugnik 5y ago
  Having access to nearly every paid LWN article on a news aggregator certainly feels like "a way to defeat our attempts to gain subscribers". But others said these links are subscriber-specific so I guess LWN is fine with it if they aren't taking the links down.
Macha 5y ago
As well as LWN's declared policy, the subscriber links are also linked to the user that generated them - if LWN felt they were being abused, they could disable that user's access to them.

lynguist 5y ago

According to Wikipedia, Intel’s 945 chipset for Core 2 processors ships with UEFI. This was originally released in 2006. Note that Google Chrome which is the web browser with the highest adoption rate requires a CPU with SSE3 support which was introduced in 2004. Which platform older than a Core 2 can even run the latest operating systems? The very latest Pentium 4 range (2004-2006)? So we would just be dropping support for them? That’s OK.

lynguist 5y ago
I found that the latest BIOS only devices were released in 2013 which are based on the AMD Bobcat processor (AMD’s version of Intel Atom). I wouldn’t know what operating system to run on those systems.
cestith 5y ago
OpenBSD 7.1 was just released and supports my G5 Mac. It also supports i386, UltraSparc, and Digital Alpha. NetBSD supports i386, Alpha, Amiga, 32-bit Sparc, 32-bit MIPS, ARMv6, StrongARM, sun2, sun3... LinuxMint still supports i686. Debian supports i386, i686, armel, armhf, s390, and MIPS. Slackware supports i586 and s390. Kali supports i686. Void Linux supports i686, ARMv6, ARV7. FreeBSD supports arm, armel, i386, ia64, mips, mipsel, sparc64, pc98, powerpc, powerpc64, ps3, xbox. Alpine supports i486, ppc64le, s390x, armhf. Devuan supports i686. Gentoo supports i486, i586, i686, alpha, arm, hppa, ia64, mips, powerpc, ppc64, sparc64. Which of these don't have recent releases?
- lynguist 5y ago
  According to discussions on the Gentoo [1] and Fedora [2] forums, i686 without SSE2 could be broken in some packages in subtle ways. One is that the stack alignment changed from 4 bytes to 16 bytes, another is long NOPs, another is that some software seems to require SSE2 on i686 like rustc or qt. Even those platforms that claim to build for i686, I’m not sure if everything works correctly on pre-SSE2 (Pentium Pro, Pentium III, older Pentium 4) CPUs. And I don’t think any of the Linux distributions will actually run on a i386, i486 or i586 as i686 is almost required to have multithreading without busy waits. The BSDs I don’t know about, but it’s a fair number of distributions that seem to support older x86 CPUs you posted. I didn’t know there would be so many. I couldn’t find Linux Mint though. [1]: https://forums.gentoo.org/viewtopic-t-1087434.html?sid=4b6827908e12de8e6092b660efa28f3a https://forums.gentoo.org/viewtopic-t-1087434.html?sid=4b682... [2]: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/HC2NLE3CQHIJRWFYSPR6HQI67PZLZP4E/ https://lists.fedoraproject.org/archives/list/devel@lists.fe...

BirAdam 5y ago

At a time when the world is producing several hundred million tons of e-waste each year, that this was even entertained is bad. I suppose its fine to make toxic trash mountains in the third world to get rid of a small amount of code bloat?

mustache_kimono 5y ago
Anyone who says things like this, should be the ones that have to support the legacy code. They should be sentenced to a 15+ year old computer and to explain to their colleagues how we just can't do anything new, because we need to use GCC 4.7 to build the world because <legacy CPU>, now used by 20 non-paying users, won't work with anything newer. Fedora is only one, relatively fast moving distro, which gives you their software for free, and which didn't even make this decision, but who could blame them if they did, in their position?
- probably_wrong 5y ago
  > They should be sentenced to a 15+ year old computer I bought my computer about 15 years ago, with what at the time was a pretty beefy setup. I still use it for my everyday work because, as it turns out, you don't need much more than 4Gb of RAM to surf the internet. Due to buggy UEFI support, I cannot reinstall Windows 10 on that PC. If Linux stopped supporting Bios, I'd have to throw it away. But more importantly, this computer has better performance than the computers of many of my relatives in South America. I wish every developer in the first world had to explain at least once to their nieces that no, Roblox will not work on their Chinese Android tablet with 1Gb of RAM.
  - mustache_kimono 5y ago
    But Linux isn't ending support of BIOS, Fedora considered it but won't yet. If Arch Linux decided not to support BIOS, we'd say, "Well they are a bleeding edge distro", but guess what, "Shhhh... so is Fedora." Old hardware is great. Expecting people to support it forever for free is folly. This is exactly why people pay IBM/RedHat for support.
  - 5y ago

userbinator 5y ago

Leave things as they are. Code continues to rot. What is this ever-present BS about "rot"!? Why do people think continual changes are even needed? Code should become more stable over time, an ideal that I wish much more software would follow. The way BIOS boot works has basically remained unchanged ever since the first IBM PC, and it's incredibly simple. Linus Torvald's opinion of EFI is worth reading: https://yarchive.net/comp/linux/efi.html https://yarchive.net/comp/linux/efi.html 7C00h forever! ;-)

tenebrisalietum 5y ago
The intersection point between simple and useful is this: - Firmware understands some sort of minimal filesystem and how to talk to a device containing it. - Firmware has a configuration store that holds a few variables and a device tree. - Firmware has the ability to load binary images into RAM from the minimal filesystem above. - On boot, configuration is checked, the kernel and initrd are binary-loaded into RAM, and the firmware jumps to the kernel with a pointer to the commandline, initrd, and device tree. U-Boot more or less does this and it's beautiful. The bootloader loads your OS and then gets out of the way. No multistage crap or overengineered firmware interfaces.
- userbinator 5y ago
  I don't think firmware should care at all about filesystems, because that's already halfway towards being an OS. It should just load the first sector from the selected boot device and jump to it.
  - tenebrisalietum 5y ago
    - You're already getting into "halfway towards being an OS" territory if you want to netboot. - Eliminating variable code from the boot process makes it more secure and reliable. Why do I need to load a separate loader to load my OS which is overwriteable by my OS if the firmware can do it in a standard, fixed way? - At least have some mechanism to load an arbitrary number of sectors.

BeefWellington 5y ago

This is a bit of a tone deaf idea to explore right now. If anything, the environment and chip shortage issues should be pushing people to promise extending support for older systems for another decade. That said, while there are loads of systems out there that could still use BIOS, I like to look at the second hand market. There are a lot of Dell R710s for sale on eBay still (700+ listings). These are commonly suggested as a good "intro to homelabbing" server in a variety of places. These systems were released in 2009, often featuring CPUs from 2007-2008. They support UEFI 2.1. Contrasting this, some UEFI implementations are horrifically buggy and largely seem designed to only work with Windows. I think 10 years is probably too close a cutoff but I do think that eventually it becomes a lot more work to maintain it (like i386 builds, x32 builds, etc.) and becomes not worth it except for niche distros. If we factor in things like environmental impact, it makes a great deal more sense to continue to support older systems for some longer period of time.

ancientsofmumu 5y ago
Side note: Red Hat disabled the kernel code for the Perc 6/I raid card which is standard in the basic R710 chassis starting with RHEL8. Unless you have the higher end H710 raid controller or whatever else, Red Hat rendered this chassis controller inoperable with their custom in-house kernel patching process.
bitwize 5y ago
> Contrasting this, some UEFI implementations are horrifically buggy and largely seem designed to only work with Windows. UEFI specifications are like Web specifications: they're good to wipe your ass with, but on the Web when the rubber meets the road, the only "standard" that matters is "does it work in Chrome" (in the past, IE). Similarly the only standard that a UEFI implementation need comply with is "does it boot Windows".
li2uR3ce 5y ago
> That said, while there are loads of systems out there that could still use BIOS, I like to look at the second hand market. I have lots of UEFI hardware with never-to-be-fixed bugs that are mitigated by just using BIOS boot. These are from Dell and Supermicro. The Dells when set for UEFI would boot 50% of the time and 100% of the time in BIOS mode. The workaround was well known and is the only reasonable thing to do. It's EOL from dell it will never be patched. The Supermicro's would work great in UEFI but the factory default was BIOS boot. The trouble is that these particular systems had a reasonably high chance of loosing BIOS setup data if they took a power hit (APC UPS are complete garbage FWIW). We'd have to send someone to a remote location to switch it back to UEFI or just reinstall in BIOS mode. By default they would remarkably turn back on when the power was restored and would recover fine if they could boot. This stuff isn't useless or even THAT old. It's just unreliable in UEFI mode. While most newer stuff from these brands have more reliable UEFI, we're going to keep using hardware that is good enough. We work around hardware/firmware problems because there's nothing out there that doesn't have quirks. "Old" hardware has known quirks that have workarounds that have already been "paid for" with expended labor. New hardware has new quirks that you have to pay off. Of course it's all moot for this discussion as we don't use rolling quirk factories like Fedora.

zaolin 5y ago

The whole step moving forward into the UEFI direction on Client Computing Systems (laptops, desktop) is the right way. Even if I dislike the UEFI specification and existing implementations, the spec is more than 24 years old. It might fulfill its purpose as a bootloader/OS interface. The UEFI BDS interface, the one the most people see and the operating system interfaces, is now standardized for many operating systems and OEMs, making it easier to integrate and maintain. It is finally possible to use standard security mechanisms (verified, measured boot) to secure your device. So we can use such technologies to ensure device security reasonably as we do in my corp www.immu.ne The custom certificate provisioning is a mess and hard to use, but that can be possibly made easy by projects like: https://github.com/Foxboron/sbctl https://github.com/Foxboron/sbctl I don't believe the UEFI interface is beneficial for data-center or embedded devices. The UEFI BDS interface was developed for client platforms and required physical presence. It leads to complexity in the DC and embedded world. I feel a more suitable approach would be www.linuxboot.org which is already used by many Hyperscalers and Embedded companies. That's my 50 cents about the story. My background, I am coreboot developer and security architect.

cestith 5y ago

A whole lot of the maintenance headache could be solved by choosing five or fewer BIOS implementations to fully support and letting everything else go by the wayside. Choose the ones from VMware, VirtualBox, and such and a couple of popular server and desktop ones.

egberts1 5y ago

You will have to pry that BIOS from my cold dead hands. Burnt EEPROM still remains the ultimate security.

rvp-x 5y ago

Fedora didn't even support UEFI on their cloud images before Fedora 35, released 5 months ago. https://pagure.io/cloud-sig/issue/309 https://pagure.io/cloud-sig/issue/309

kevinoid 5y ago

Perhaps this is a good time to ask: I'd like to use UEFI for my qemu+libvirt virtual machines, but I need snapshot support. Since QEMU doesn't support pflash internal snapshots <https://gitlab.com/libvirt/libvirt/-/commit/9e2465834f4bff4068e270f15e9ed5d7301de045 https://gitlab.com/libvirt/libvirt/-/commit/9e2465834f4bff40...> and libvirt can't revert or delete external snapshots <https://bugzilla.redhat.com/show_bug.cgi?id=1519002 https://bugzilla.redhat.com/show_bug.cgi?id=1519002>, I don't see a way to achieve this. The issue was discussed on virt-tools in 2017 <https://listman.redhat.com/archives/virt-tools-list/2017-September/msg00008.html https://listman.redhat.com/archives/virt-tools-list/2017-Sep...> and the situation appears to be unchanged. Do others have a workable solution?

Scramblejams 5y ago

In my admittedly limited time using Linux (switched to it full-time in ~2001), the total amount of effort I've spent troubleshooting issues has probably been dominated by two categories: 1. Getting audio to behave. 2. Boot problems. (waves at LILO) I don't know enough details about how UEFI and BIOS and MBR and GRUB and all of this works -- which probably contributed to my difficulties. But the problems certainly didn't end when I left LILO behind. So it always makes me wonder: Have the people responsible for the bootloaders ever used a Mac? My goodness it could not be simpler. Hold the right key combo at boot time and you get a nice interface that shows you all the bootable devices you've got plugged in. USB, SATA, NVMe, whatever, it's there. And when you select one and boot, it actually works. Recognizing that we don't actually need a GUI for this, and the challenge is different because Apple gets to use firmware and only worries about one type of OS, what would it take to make a PC bootloader work just as nicely?

dralley 5y ago
> Apple gets to use firmware and only worries about one type of OS, And a very, very narrow set of potential hardware compared to the entire PC ecosystem.
ElectricalUnion 5y ago
> what would it take to make a PC bootloader work just as nicely? If we take Apple's bootloader as a base line: Drop GPU support, except for blessed models, from initial boot support. Remove RAM customization options. Can't change speed and timings. Can't support ECC. Might as well disallow customizing RAM alltogether and solder it to the board or in the SOC. Remove CPU customization options. Can't change speed, enable or disable supported features. Can't chage ACPI tables. Remove storage customization options. Can't change storage speed, protocol support. Can't even add or remove internal storage devices at all, if we go by the latest trend. Implement a bluetooth stack onto the bootloader firmware, because that's for sure safe and could never go wrong. Force OSes to write their pairing keys in the firmware storage. Implement a wifi stack onto the bootloader firmware, because that's for sure safe and could never go wrong. Force OSes to write their pairing keys in the firmware storage. Implement internet-based, network boot support from a centralized, blessed location. Because that's completly safe and could never go wrong.

codedokode 5y ago

> UEFI is defined by a versioned standard that can be tested and certified against But is it actually tested against or only can be?

2OEH8eoCRo0 5y ago

Good. More time to work on new stuff.

morekozhambu 5y ago