https://lwn.net/SubscriberLink/891273/ea9c5e88260a64e9/ LWN.net Logo LWN .net News from the source LWN * Content + Weekly Edition + Archives + Search + Kernel + Security + Distributions + Events calendar + Unread comments + ------------------------------------------------------------- + LWN FAQ + Write for us * Edition + Return to the Front page User: [ ] Password: [ ] [Log in] | [Subscribe] | [Register] Subscribe / Log in / New account Fedora considers deprecating legacy BIOS [LWN subscriber-only content] Welcome to LWN.net The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider subscribing to LWN. Thank you for visiting LWN.net! By Jake Edge April 20, 2022 A proposal to "deprecate" support for BIOS-only systems for Fedora, by no longer supporting new installations on those systems, led to a predictably long discussion on the Fedora devel mailing list. There are, it seems, quite a few users who still have BIOS-based systems; many do not want to have to switch away from Fedora simply to keep their systems up to date. But, sometime in the future, getting rid of BIOS support seems inevitable since the burden on those maintaining the tools for installing and booting those systems is non-trivial and likely to grow over time. To head that off, a special interest group (SIG) may form to help keep BIOS support alive until it really is no longer needed. Proposal The proposal to "Deprecate Legacy BIOS" was, as usual, posted on behalf of its owners, Robbie Harwood, Jiri Konecny, and Brian C. Lane, by Fedora program manager Ben Cotton. It currently targets Fedora 37, which is due in October, though there is reason to believe the change will not happen quite that soon. The reasons for removing the support are described in the proposal: UEFI is defined by a versioned standard that can be tested and certified against. By contrast, every legacy BIOS is unique. Legacy BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) and on its way out. As it ages, maintainability has decreased, and the status quo of maintaining both stacks in perpetuity is not viable for those currently doing that work. [...] While this will eventually reduce workload for boot/ installation components (grub2 reduces surface area, syslinux goes away entirely, anaconda reduces surface area), the reduction in support burden extends much further into the stack - for instance, VESA support can be removed from the distro. The proposal says that, eventually, BIOS support will have to be removed, but that maintaining the ability to boot existing Fedora systems with BIOS is meant to help smooth the process. Fedora already has requirements that effectively restrict it to systems made after 2006, so this change would extend those restrictions somewhat further. Intel stopped shipping the last vestiges of BIOS support in 2020 (as have other vendors, and Apple and Microsoft), so this is clearly the way things are heading - and therefore aligns with Fedora's "First" objective. The subject was raised back in 2020, which also led to a (predictably) long thread, though it was not a change proposal at that time. Some of the "relevant points from that thread" are listed in the Feedback section of the proposal. There are, of course, machines that are BIOS-only and any kind of hardware deprecation for the distribution is impossible "without causing some amount of friction". In addition, there is no way to migrate from a BIOS installation to a UEFI-based system, since "repartitioning effectively mandates a reinstall". In particular, a UEFI partition would need to be added to the system. The Contingency Plan section of the proposal describes an ugly future for the status quo, but also a possible way forward: Leave things as they are. Code continues to rot. Community assistance is required to continue the status quo. Current owners plan to orphan some packages regardless of whether the proposal is accepted. Another fallback option could be, if a Legacy BIOS SIG organizes, to donate the relevant packages there and provide some initial mentoring. Longer term, packages that cannot be wholly donated could be split, though it is unclear whether the synchronization thereby required would reduce the work for anyone. Affected systems As might be guessed, multiple replies from users of affected systems were seen in the thread, starting with Neal Gompa. He said that he is sympathetic to the change, but thinks that it is "way too early to do across the board". He has a system that struggles to boot Linux with UEFI and his workarounds are beyond the abilities of most users. David Airlie said that he recently worked on a project to rewrite the Mesa driver for a wide range of Intel GPUs. Many of the systems he used to develop and validate those drivers are pre-UEFI systems, but it was "of great benefit to me and the community" that he could use Fedora for that work. For future projects, he would have to consider moving away from Fedora, which would be a sad state of affairs. Hans de Goede said that he had several systems at home that were BIOS-only and happily running Fedora now. Obsoleting them just contributes to the e-waste problem; "Looking specifically at fixed PCs and not laptops this proposal would (eventually) turn 2/5 PCs in my home unusable, which really is unacceptable IMHO." He also pointed to Airlie's work on Intel GPUs, saying that "it seems rather silly to drop support for this hw after just investing a significant chunk of time to breathe new [life] into their GPU support" But it is not just desktops and laptops that are affected by a change of this sort. 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: OVH is another big provider and they don't offer UEFI boot with their VPS range. I've just confirmed it with their support. Since one of my servers is hosted by OVH, I'd have to either migrate to another hosting provider or migrate off Fedora. Which is ironic, considering my involvement in Fedora. Stewart Smith added some "thoughts both from an EC2 [Elastic Compute Cloud] perspective, and an Amazon Linux as a downstream of Fedora perspective". Most EC2 instance types boot using BIOS by default, though many can use UEFI and new types are likely to get UEFI support, but there are "a *lot* of instance types, a whole bunch of which are less likely to support UEFI". There is no installer for cloud images, instead they use the Amazon Machine Image (AMI) format, but "AMIs that don't run on all instance types tend to cause confusion, no matter how [clearly] you document the limitations". So Amazon Linux has an interest in ensuring that BIOS booting still works well, "likely for a decent number of years to come (however much I wish this wasn't the case)". Gompa complained that the change is not really a deprecation, but is instead a removal, because the lack of packages and tooling that support BIOS "makes several scenarios (including recovery) harder". It also puts the burden on users to determine if their hardware can boot and install Fedora, but UEFI has not yet reached a critical mass where it can be assumed to work. Alberto Abrao agreed, noting that this change would "leave behind a LOT of serviceable hardware", especially in the server space: Ironically, Fedora is one of the distributions out there that allows me to extract the most out of older hardware. It would be a terrible loss to have to move to a different one, but it's hard to reason purchasing new hardware - especially right now, with pandemic-related supply issues still ongoing - to keep up with this change. In that message, Gompa also said that he is a "a fan of using UEFI instead of BIOS" and that he has done work to add UEFI support to Fedora cloud images. He just does not believe that it is time, yet, to make that switch. Part of the reason is that he believes the UEFI experience on Fedora is not all that good. A wander into secure boot In his original reply to the proposal, Gompa also asked about Fedora support for NVIDIA drivers under UEFI secure boot. Peter Robinson said that was out of the scope of the proposal, since users can disable secure boot if they need support for drivers, like NVIDIA's, that are not signed by the Fedora kernel-module keys. But Gompa replied that it is sometimes easier to have users fall back to booting from BIOS; furthermore: You're right that these are different problems, but I've also seen very little appetite for reducing the suffering of Fedora Linux users on UEFI Secure Boot with the *most common issue* we have: an NVIDIA driver that doesn't do anything because of the lockdown feature. If you're planning to say that UEFI is the only way to boot, then that means you need to be prepared to accept that our UEFI experience is *worse* than our BIOS one right now, and someone needs to take ownership to improve it. Harwood, who is one of the feature owners, said that NVIDIA users can either use the open-source nouveau driver (which is signed), sign their own copy of the driver "(involves messing with certificates, so not appropriate for all users)", or disable secure boot. But several people pointed out that nouveau does not really solve the problem, especially for more recent NVIDIA hardware; it does not provide access to accelerated graphics operations for recent GPUs and tends to have quite a few bugs even for the older models. Michael Catanzaro pointed out that the options Harwood described are problematic from a user-experience perspective: The user experience requirement is: user searches for NVIDIA in GNOME Software and clicks Install. No further action should be necessary. We didn't make the NVIDIA driver available from the graphical installer with the intention that arcane workarounds would be required to use it. But Adam Jackson thought that the NVIDIA problem was not Fedora's to solve. There are technical means to make it work and "NVIDIA are the ones with the private source code". But Chris Murphy sees things differently, noting that Fedora is sending mixed messages: When users have a suboptimal experience by default, it makes Fedora look bad. We can't have security concerns overriding all other concerns. But it's really pernicious to simultaneously say security is important, but we're also not going to sign proprietary drivers. This highly incentivizes the user to disable Secure Boot because that's so much easier than users signing kernel modules and enrolling keys with the firmware, and therefore makes the user *less safe*. On the other hand, Fedora does not actually have a full secure boot implementation, Lennart Poettering said, so by disabling it "you effectively lose exactly nothing in terms of security right now". The reason is that the initrd is not signed, so it can be subverted: What good is a trusted boot loader or kernel if it then goes on loading an initrd that is not authenticated, super easy to modify (I mean, seriously, any idiot script kiddie can unpack a cpio, add some shell script and pack it up again, replacing the original one) - and it's the component that actually reads your FDE LUKS password. SIG In his message linked above, De Goede volunteered to form a SIG along the lines suggested in the proposal. He noted that previous attempts to keep 32-bit x86 alive when Fedora removed support for i686 had run aground, but felt that BIOS is different: Legacy BIOS boot support is basically only about the image-creation tools + the bootloader. As various people have mentioned in the thread BIOS support is still very much a thing in data-centers, so I expect the upstream kernel community to keep the kernel working with this for at least a couple of years. Where as both the kernel + many userspace apps were breaking on i686. After Fedora project leader Matthew Miller started a new thread about the possibility of having a video call to discuss the BIOS issue, which was generally seen as not being something that would do much more than rehash what had already been aired, De Goede renewed his call for a Legacy BIOS SIG. He envisioned it as a lightweight organization that focused on testing Fedora on BIOS systems, particularly the next version of Fedora early in its development, in order to file and fix bugs. The new thread largely went over the same ground as the first, at some length, naturally, though there was also some concrete planning of what a new SIG would do--and how. Harwood said that what is needed is a place to assign bugs and a way to get those problems addressed. "The overall goal of the SIG needs to be to reduce load on existing bootloader contributors." But Harwood also wondered whether Fedora should redefine its support for BIOS: Given there is consensus that legacy BIOS is on its way out, we think Fedora release criteria in this area should be re-evaluated. Not only does support change from "fully supported" to "best effort", but we should re-evaluate what is/isn't release blocking, and probably clarify who owns what parts. Several people disagreed with that characterization of the status of BIOS. Chris Adams said: "I don't think this statement is true, unless Fedora doesn't want to be considered for a bunch of popular VM hosts (e.g. Linode and such) that have no stated plans to support UEFI." Perhaps BIOS support for physical hardware could be phased out, though. De Goede agreed that BIOS support is still needed in some contexts: Given what the server product folks have indicated that BIOS boot support is quite important for them I'm not sure if changing the release criteria is in order. I do agree that any blocker bugs related to legacy BIOS booting should be assigned to; and taken care of by the legacy BIOS boot SIG. The change proposal will be discussed and decided by the Fedora engineering steering committee (FESCo), but its prospects do not look good. The FESCo ticket for the proposal has already gotten five "-1" votes from members and there are nine on the committee. Those votes are not binding, but it still looks pretty unlikely this change will go through--at least for Fedora 37. But the change will, seemingly, happen eventually. One of the complaints seen in the ticket (and threads) is that the proposal calls it a deprecation, but that is not really what it entails; new versions of Fedora will not be able to be installed on the older hardware, which could be problematic if an in-place upgrade goes awry. In addition, Fedora versions are only supported for about a year, so at some point upgrading may not really be an option if BIOS support is removed. That means users of those systems would have to migrate to a different distribution or keep running an unsupported version as it slowly bitrots. In a blog post about the change, Cotton pointed out that while he did not think the distribution "should abandon old hardware willy-nilly", there is a balance to be struck: I think some distros should strive to provide indefinite support for older hardware. I don't think all distros need to. In particular, Fedora does not need to. That's not what Fedora is. "First" is one of our Four Foundations for a reason. Other distros focus on long-term support and less on integrating the latest from upstreams. That's good. We want different distros to focus on different benefits. With luck, the SIG will take over any packages needed to keep BIOS functioning, since their owners plan to orphan them regardless of the outcome of the proposal. Keeping BIOS alive on Fedora for another few years--how many is difficult to guess--would seem to have a fair number of benefits at this point, though there is obviously a maintenance burden associated with it as well. If the change does not get approved this time around, we will likely see the proposal recur for Fedora 38 (or later), but if the SIG takes off, that may be postponed for some time. When it does come up again, however, we can probably expect another lengthy discussion in Fedora-land. [Send a free link] ----------------------------------------- (Log in to post comments) Fedora considers deprecating legacy BIOS Posted Apr 20, 2022 22:52 UTC (Wed) by atai (subscriber, #10977) [ Link] bad idea. I the era of chip shortage, the legacy systems shall continue to be used for as long as they work. Software shall continue to support these systems. Free software, especially. [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 20, 2022 22:52 UTC (Wed) by atai (subscriber, #10977) [ Link] "I" => "In" [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 0:15 UTC (Thu) by fenncruz (subscriber, #81417) [ Link] Are these companies that seem to be completely dependant on legacy BIOS still working ready to contribute the workers/cash to keep it working? [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 7:48 UTC (Thu) by taladar (subscriber, #68407) [ Link] Are the people who champion UEFI willing to put in the work to make it actually work as well or better than BIOS? [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 10:27 UTC (Thu) by leoluk (subscriber, #97665) [ Link] Yes - there is a ton of ongoing work on EFI in projects like EDKII[1] and the various bootloaders and utilities. Things like TPM-backed attestation and Secure Boot require EFI. Meanwhile, Legacy BIOS is stagnant and only kept around for compatibility reasons. [1]: https://github.com/tianocore/edk2 [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 9:41 UTC (Thu) by johannbg (subscriber, #65743) [ Link] If Amazon indirectly advertises itself like a big billboard sign, that it's subjective to persistent BIOS infections on fedora devel I doubt that all the other legacy bios dependent users/companies have neither the skill or the financial resources to contribute anything of value and I'm not even sure what that is supposed to be. The fact is it's quite easy these days to setup "refurbish" shop that plays into peoples/companies environmental guilt, that buys used known exploitable hardware then refurbish it's and injects it with persistant bios exploitation and resell's it to that target audience ( "Green" individuals/companies ). And for whatever reason people seem to be under the assumption that bios is not used after boot, which could not be further from the truth since the OS needs the bios for various reason and since it does, the OS always *trusts* the bios. One ( popular ) way to exploit that fact is to use the BIOS-32 calls OS have and do an direct-to-kernel binary execution from there ( here you can see where the Linux Kernel detects and calls this service [1] ) so fourth and so on ( people can educate themselves how to best exploit legacy/cms bios, there are enough examples out there and in use in the wild ). Anyways Fedora could not only be leading the way of moving the Linux ecosystem towards UEFI but also get rid of so much of technical debt in Fedora in the process and just leave the legacy users to some distribution better suited for that ( some LTS distro like CentOS, RHEL, etc ) but it seem that "my usecase matters the most even thou I dont contribute jack to Fedora or the ecosystem in general ) crowd wins again and this will be postponed to F40 and this whole dialog had again in the community. [1] https://github.com/torvalds/linux/blob/b253435746d9a4a701... [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 10:22 UTC (Thu) by pbonzini (subscriber, #60935) [Link] BIOS-32 is only used on 32-bit systems. [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 10:34 UTC (Thu) by johannbg (subscriber, #65743) [Link] Yes I know I was just using it as an example. I'm not sure if you are aware of it but everytime any distro mentions anything about deprecating 32-bit support, a squeel like from a pig is heard in the void and someone's pony dies so 32-bit still seems to be live and well to me :) [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 10:32 UTC (Thu) by LtWorf (subscriber, #124958) [ Link] So we should throw away millions of tonnes of perfectly good computers because of some hypothetical attack? Typical security person mindset. [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 12:12 UTC (Thu) by johannbg (subscriber, #65743) [Link] Sorry I dont follow as in I'm not sure what you mean these are hypothetical attacks, these attacks have existed in the wild since last century ( for example Chernobyl a.k.a CIH a.k.a Spacefiller ) Well funded ( law enforcement ) agencies have them in their arsenal to circumwent hard-drive encryption and in covert operation ( confuscating a computer, insert the exploit, release the subject and monitor the subject ) as well as pretending to be hardware sales company that sells drug cartels or other questionable businesses hardware ( used or new ), to infiltrate and monitor their operations while the other "darker" side is using those exploits to extort or otherwise profit from them. These attacks are very much real and have existed in the wild for over two decades. There is nothing hypothetical about them at all. And I'm not sure what you mean by throwing away a perfectly good computer. What do you consider a perfectly good computer? I'm all for recycling and reuse but the fact is computers dont last forever and computer's longevity is based on, it's usage,the environment it resides in and the quality of the component it's made out of so it can last as little as couple of days or for as long as one or two decades in otherwords people's milage might vary in that regard depending on the manufacture or even just product lines between manufactures. The fact is distributions cannot be expect having to support old hw forever since it increases it's maintainership and will hinder the adoption of new technologies for those distribution so it's better to just use a distribution that is tailored to such usecases for that target audience. ( like LTS distribution or something like I guess slackware which presumably looks and operate just like it did when it was initally created at least it's website is most certainly from that era ) [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 13:39 UTC (Thu) by wtarreau (subscriber, #51152) [Link] > These attacks are very much real and have existed in the wild for over two decades. > There is nothing hypothetical about them at all. Yes they've existed, no they're not hypothetical, but they're totally outdated and pointless nowadays when it's both ultra-cheap and effective to develop a browser malware and that this has become by far the most effective way to steal users' information to the point that it's an industry now (look for "malware as a service"). Sorry but I do not want to mess up with that secure boot. It's only as secure as my ability to use it properly, which is basically zero. However it surely guarantees that I will eventually lose my data when not being able to recover my system after some bugs, crashes or other issues with my machine. We should not force the user to endure pain that is designed to "protect them" against their will from attacks that are not relevant to them. We should instead educate users to where risks are and how to care about what matters. We'd already make a much bigger progress if people stopped reading HTML e-mails... While I had been seriously considering migrating from Slackware to Fedora a few months ago when slack15 was really longing to come, at least this discusssion just convinced me that it was absolutely not a good idea! [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 18:01 UTC (Thu) by johannbg (subscriber, #65743) [Link] There is no such thing as outdated means of explotation, you use the right tool, for the right job that helps you obtaining your objectives and likewise with your computer which is a computer originally designed to make your life easier, so you choose the distribution that works for you. If that happens to be slack good for you, if it happens to be Fedora great, if that happens to be *BSD awesome but please dont fall into this whole "I would have moved to x distro" or worse "If x feature is implemented I stop using the x distro" crowd. [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 20:29 UTC (Thu) by jwarnica (subscriber, #27492) [Link] This is a physical attack. I'd be sympathetic for remote holes being allowed by policy. It still requires more than a casual attacker. I won't be that guy to say that if you don't have anything to hide then law enforcement will leave you alone. But I will say that if you do have something to hide from law enforcement, then its your problem to get a sufficiently modern system to keep them out. [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 22:17 UTC (Thu) by nix (subscriber, #2304) [Link] > However it surely guarantees that I will eventually lose my data when not being able to recover my system after some bugs, crashes or other issues with my machine. This is exactly why I'm not using secure boot -- but I note that secure boot works for millions of people perfectly well. I suspect the reason why is simply that they are not systems hackers regularly futzing with early boot (most people aren't). Those people (like us) who *are* systems hackers regularly futzing with early boot should either learn how secure boot works or simply not use it, but that doesn't mean it's not appropriate for the vast majority who aren't routinely doing things like that. (As for the added security: many of the attacks secure boot protects against are physical, and I'm not worried about those: anyone who can attack systems I care about that way has broken into my house and I have much bigger problems. But I'm not sure what to do about the possibility of remote attackers implanting persistent malware in my UEFI firmware or something. Secure boot would protect against that, but I still have it turned off because it would also make it more likely to turn a moderately bad boot problem into a disastrous one, and frankly the system failing to boot because of UEFI malware *is* a disaster, arguably worse for me than it booting with the malware active would be. It's a tradeoff... how common *is* UEFI malware anyway? Is it even a threat worth worrying about for someone like me who is basically a random boring person and thus unlikely to be of interest to major governments unless they are malware-implanting literally everyone in the population?) [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 0:16 UTC (Thu) by sub2LWN (subscriber, #134200) [ Link] Arbitrarily removing support for the installer but keeping support for BIOS itself could lead to the jankiest assortment of cloned/ re-imaged installations imaginable. Maybe a forked installer would appear, although distro-hopping or not updating would be more likely. +-1 for interesting times. [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 6:57 UTC (Thu) by LtWorf (subscriber, #124958) [ Link] On my work machine (6 years old) enabling UEFI makes the wifi work very unreliably, so I boot it in BIOS mode. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 8:11 UTC (Thu) by rwmj (subscriber, #5474) [Link] A lot of comments so far talking about hardware, but to my mind it's really the cloud providers (especially the second tier ones) and VPS hosters where this is going to be painful. We've supported UEFI (OVMF) in qemu since the early 2010s, and the other hypervisors have also had UEFI for a long time, but BIOS boot is still very common for VMs running in clouds and often the only option supported. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 10:23 UTC (Thu) by johannbg (subscriber, #65743) [Link] I'm not seeing the relevance here I mean that this is being painful for some cloud/vps providers presumably due to them experiencing some sort of management tools issues is a self inflicted wound is it not? Those companies should have the required means to prevent this from happening or is the (f)oss ecosystem supposed to be handholding businesses these days? [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 10:28 UTC (Thu) by rwmj (subscriber, #5474) [Link ] I'm going to guess they have a system that works (BIOS) and has done for 15+ years, they have management tooling all around that, probably custom stuff written a decade ago, so why would they see any need to change? There is a technical issue too since UEFI is considerably slower to boot and has much greater complexity. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 11:13 UTC (Thu) by johannbg (subscriber, #65743) [Link] > I'm going to guess they have a system that works (BIOS) and has done for 15+ years, they have management tooling all around that, probably custom stuff written a decade ago, so why would they see any need to change? UEFI is just one step short from becoming mandatory requirements in government contracts and usually if for example the U.S government says jumps, the vendors jump and businesses better be in shape when that call to jump comes. Anyways still not seeing why *we* ( and by we I mean the entire (f) oss ecosystem ) should care I mean it's companies own responsibility to keep themselves relevant and competitive on the market, we do not exist to do that for them. > There is a technical issue too since UEFI is considerably slower to boot and has much greater complexity. This is the direction the industry is taking ( and has been for quite a while, as you yourself are very much aware of ), so it's not like there are any other choice other than to put in work to mitigate any downsides it brings. People might not like it and businesses might choose to stick their head in the sand and ignore it but it is what it is. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 10:30 UTC (Thu) by leoluk (subscriber, #97665) [ Link] As long as distros keep supporting legacy boot, cloud providers have little incentive to switch to EFI boot. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 10:41 UTC (Thu) by johannbg (subscriber, #65743) [Link] Right because people are like water, they always take the shortest route. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 12:23 UTC (Thu) by dullfire (subscriber, #111432) [Link] > Right because people are like water, they always take the shortest route. I would suggest looking at some maps with rivers on them. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 13:41 UTC (Thu) by smoogen (subscriber, #97) [ Link] There is a common language translation where a phrase gets switched by one or two words and looks the same to the non-native speaker. If we go with 'people like water always take the easiest route', does that make the original phrase better for you? [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 14:34 UTC (Thu) by Wol (subscriber, #4433) [Link] Time flies like an arrow, fruit flies like a banana ... Cheers, Wol [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 16:08 UTC (Thu) by rgmoore ( supporter , #75) [ Link] The criticism isn't of the wording, it's of the content. Water frequently does not take the shortest route, as you can determine by looking at a map. Instead, rivers meander all over the place. A river can even erode through the soil into the underlying rock, causing its old meandering path to be literally set in stone. There may be some truth to the idea of people behaving like water, but it has more to do with their path being heavily determined by history. Both will usually take an established route even when it is long and convoluted. It's only the occasional dramatic event that causes rivers- or people- to change their course. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 16:16 UTC (Thu) by sfeam (subscriber, #2841) [ Link] People are like water: both will stagnate in a local minimum rather than finding the energy to overcome a barrier that constrains them. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 17:38 UTC (Thu) by johannbg (subscriber, #65743) [Link] I propably should have said people are like water, they always take the path of least resistance. Those that are bothered by the inaccuracy of that can replaces "least resistant" with the "distribution of flow that will lead to the least "total" resistance" but most people should have gotten the gist of what I meant. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 13:42 UTC (Thu) by rwmj (subscriber, #5474) [Link ] If every distro switched this might be the case, but it's unlikely if only Fedora does it. However big things which might make this happen would be Windows 11 and RHEL 10, although one is not very relevant on cloud and the other is some years in the future. [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 18:18 UTC (Thu) by johannbg (subscriber, #65743) [Link] Well it all starts with one distribution taking the lead, usually it's Arch these days but Fedora is better positioned to take the lead for this particular change. That said why should UEFI miracles start happening when RHEL 10 get's released? [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 14:37 UTC (Thu) by cortana (subscriber, #24596) [ Link] I think there are still issues about snapshotting VMs that were booted with UEFI (though perhaps this is a limitation in libvirt rather than QEMU?) [Reply to this comment] Clouds and VPSes Posted Apr 21, 2022 21:10 UTC (Thu) by dmoulding (subscriber, #95171) [Link] Yes, exactly this. I'd bet the number of Linux installations on BIOS *today* outnumbers the number of installations on UEFI ten fold. And they are even *thinking* about deprecating BIOS now? [Reply to this comment] Fedora considers deprecating legacy BIOS Posted Apr 21, 2022 8:27 UTC (Thu) by Lionel_Debroux (subscriber, # 30014) [Link] In the Phoronix forum thread about the same topic, "skeevy420" mentions the Clover bootloader, which has an ability to emulate a UEFI. I'm sharing the link to 1) spread the knowledge (it was the first time I read about that project) and 2) possibly get some interesting takes from users of that project :) [Reply to this comment] Copyright (c) 2022, Eklektix, Inc. Comments and public postings are copyrighted by their creators. Linux is a registered trademark of Linus Torvalds