[HN Gopher] Fedora considers deprecating legacy BIOS
___________________________________________________________________
Fedora considers deprecating legacy BIOS
Author : bitcharmer
Score : 161 points
Date : 2022-04-21 08:54 UTC (14 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| AshamedCaptain wrote:
| 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.
| bigpod wrote:
| honestly at some point we should think about deprecating old
| code old stuff and i think 10 years might not be such a bad
| number, of course good deprecation policy would tell you for
| few releases before that something will get removed but its
| linux so even if they said we are removing BIOS support in
| fedora 40 everyone would cry
|
| also it takes about same amount of code to boot BIOS and UEFI
| TZubiri wrote:
| "Is this corporate influence?"
|
| Of course? Fedora Linux is an asset of the company Red Hat,
| their prevailing revenue model seems to have something to do
| with adding their own brand of complexity to otherwise simple
| open source systems, see systemd.
|
| Since its acquisition by IBM (NYSE:IBM), Red Hat has entered
| the conglomerate of publicly owned companies, their profits are
| linked together with other public hardware manufacturers like
| Intel (NASDAQ:INTC), through intraday traders and index funds.
|
| In summary, removing support for older hardware increases sale
| of new hardware, hardware and software companies coordinate
| profit sharing through stock markets. Pretty simple.
| AreYouSirius wrote:
| 8K832d7tNmiQ wrote:
| 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 wrote:
| "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 wrote:
| You can use several GNU/Linux distros which support BIOSes,
| even libre ones.
| spicybright wrote:
| I agree, and that's the strength of linux, but here's a
| slight devils advocate:
|
| If someone is heavily invested into RH for their BIOS
| only infra, this could be an issue for them. I'm sure
| there's large operations that would need fixing up if
| these change happens.
|
| Not that RH is obligated to cater fully to that crowed of
| course. But 10 years is a bit silly, especially with how
| expensive hardware is now due to covid.
|
| All that said, it's not going to be an issue like
| everyone is making it out to be.
|
| Individuals should have few problems forking mainline to
| keep BIOS support, and large organizations will be given
| amble time to upgrade (at least years. RH isn't stupid
| with it's corporate customers.)
| dralley wrote:
| RHEL has a 3 year cadence, so if (if) RHEL 10 makes this
| change it won't have been 10 years, it will have been 13
| years.
| nix23 wrote:
| Yeah it's funny, my workstation is a 12yo HP-Z600
| workstation upgraded for like 30$ to 2CPU's/16Cores and
| 47GB Ecc-Ram, and now someone tells me it's retro but it's
| still often faster than new Hardware.
| anothernewdude wrote:
| It's Red Hat, they dropped their support for community based
| linux. Why wouldn't they also drop support for old hardware.
| dralley wrote:
| That's not true... CentOS Stream is more of a "community"
| than CentOS was. If you had a bug in CentOS all you can do is
| file an issue in the Red Hat bug tracker and wait because
| there was no way to contribute.
|
| With Stream it's open to not just bugfixes but community-
| contributed enhancements.
| Barrin92 wrote:
| >a Linux distribution
|
| I think it matters quite a lot that the distro in question is
| Fedora which is by design forward looking and kind of a
| testbed. They have been shipping Wayland as a default since
| 2016 when it still had countless of hardware and software
| problems. Part of the diversity of the linux ecosystem is that
| distros can be opinionated.
| javchz wrote:
| Yes. I mean if it was centos / alma or debian, I would be
| scared we enter into an era of discarting perfectly capable
| hardware, but Fedora has always been packed "with the lastest
| but stable enough".
|
| I'm not a UEFI huge fan (I've use boot-repair a lot of times
| since its creation), but I can see why maintaining a legacy
| bootloader could be distracting.
| wing-_-nuts wrote:
| Wayland! Ye gods. I tried. I really did. I understand that
| from a developer standpoint, it's the future. I understand
| from a security standpoint, it's more secure. From a user
| standpoint? It completely breaks _so much_ functionality
| (copy / paste, screen share, blue light filters, etc). Video
| players crash and sometimes take down the whole OS with it.
| It puts so much responsibility that used to be the job of the
| x server off on the window managers.
|
| This shift to wayland has been one of the most user hostile
| decisions I've seen. Every distro that defaults to wayland
| pushes me that much closer to simply running linux in a WSL
| container on windows.
| sph wrote:
| Wayland has changed since you last tried. I haven't got
| copy paste or blue light issues with it since Fedora 35
| went with Wayland-by-default. Screen share is iffy on
| Electron, but that behemoth is slow to pick up new
| technologies.
|
| I don't know about video players crashing either.
|
| When talking about a fast moving new piece of technology,
| it's good to give it a try once in a while and not let your
| 4 year old experience colour your judgement.
| wing-_-nuts wrote:
| I gave up last week. Vlc and celluloid were crashing
| under gnome. They worked under swaywm but couldn't find a
| way to install a redshift wayland clone that worked.
| There are a whole lot of things that still simply 'don't
| work' especially if you venture outside of gnome and kde.
| dralley wrote:
| If you were using GNOME, then it has a redshift clone
| built in.
| wing-_-nuts wrote:
| Yes, gnome has night light, but unfortunately vlc crashes
| under wayland and it takes the entire OS with it. I
| haven't discovered any smoking guns, but I assume it's
| some sort of OOM issue, which is funny on a system with
| 8GB of ram.
|
| Switching to gnome on xorg, it's rock solid stable.
|
| I will wait to switch back to wayland when I'm forced to
| a few years down the line. I'm done bleeding on the edge.
| dralley wrote:
| > vlc crashes under wayland and it takes the entire OS
| with it. I haven't discovered any smoking guns, but I
| assume it's some sort of OOM issue
|
| As someone already pointed out, VLC doesn't support
| wayland natively, so it's running under Xwayland.
| Ironically the issue could very well be X related.
| taifleh wrote:
| VLC doesn't support wayland. It's an X application.
|
| take a look at https://arewewaylandyet.com/ to find some
| alternative app for your X-only software
|
| Also make sure to alias vlc to your new alternative, i
| keep forgetting i don't have vlc installed anymore...
| wing-_-nuts wrote:
| I tired using celluloid which is a gnome wrapper around
| mpv, but it stopped working. Running it on the command
| line, I'm prompted with an exception and admonished that
| wayland support is 'experimental' and known to be
| unstable.
| sph wrote:
| I use celluloid on Wayland. Never crashed. It'd be
| helpful to know what distro you are using. Fedora has the
| best Wayland experience of them all, others not so much.
|
| You wouldn't have a nice Wayland experience on Ubuntu
| 20.04 LTS for example.
| willis936 wrote:
| Yes Fedora is "a distribution of linux". A distribution that is
| an upstream of an enterprise distribution. Why do you care if
| enterprise markets don't care about legacy support? Just use
| another distribution. That's one of the boons of linux.
| bigpod wrote:
| 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)
| userbinator wrote:
| Ironically, the first thing I do is the opposite. BIOS boot has
| been simple and reliable for decades, and EFI remains a
| horrible mess.
|
| _Remember how some people have had issues with windows
| destroying booting of linux_
|
| The MBR is tiny (you could even write out all the entries on
| paper as a backup, like I became accustomed to many years ago
| whenever I partitioned a disk) --- and restoring it is also
| equally straightforward. I don't even know where to begin with
| troublshooting EFI's horribly overengineered boot entries and
| NVRAM variables...
| viraptor wrote:
| I agree in general, but not with this: "It wasnt windows's
| fault its just that its update utility had to overwrite a part
| of MBR". If they cared, they could spend some time to design /
| document a nice way for systems to redirect to the next entry.
| They could've used grub and chainload. They could've invited
| others to collaborate. It was very much in MS interest not to
| care and I totally blame them for doing just that.
| tremon wrote:
| _to all you legacy BIOS and MBR fans MBR doesnt cut it and is
| cause of many headaches if you dual boot._
|
| That's neither here nor there. You can still perform BIOS boots
| from a GPT-partitioned disk, in fact it works even better:
| while in MBR mode the stage1 grub loader must be placed in the
| unused 31kB between the partition table and the first partition
| start, GPT allows you to explicitly allocate a partition for
| the stage1 code. This means no more borkage because Windows
| overwrote an officially unused part of the disk, and the stage1
| payload is no longer limited to 31kB.
|
| Point being, your rant has nothing to do with BIOS vs UEFI
| boot.
| chasil wrote:
| Recovering mbr boot corruption on CentOS is relatively easy.
|
| Boot from the install media in rescue mode, chroot into
| /mnt/sysimage, then grub2-install onto /dev/sda.
|
| I've never had to do this outside of the redhat realm, but the
| procedure is not complex after a few rounds to commit it to
| memory.
| AreYouSirius wrote:
| morganvachon wrote:
| 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 wrote:
| 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.
| feikname wrote:
| > GPT is million times better
|
| Agreed.
|
| > It wasnt windows's fault its just that its update utility had
| to overwrite a part of MBR
|
| It was a reasonable assumption that whatever drive Windows' was
| installed on _already had a working bootloader_ installed,
| otherwise it wouldn 't have been able to boot itself to do
| Windows Update. Windows did NOT have to override it.
|
| This was not MBR fault. AFAIK Linux did NOT do the same thing
| as overriding, which is why it has separate `grub2-install` and
| `update-grub` commands. Once installed to a drive, `update-
| grub` will only change the simple config file it reads at boot.
| Perhaps both of them did override themselves when a bugfix or
| new feature was available, but I don't think Windows's
| bootloader changed much after any OS release.
|
| Now, GPT/UEFI is a million times better in that aspect because
| it can allow easily multiple different bootloaders that don't
| have to know of each other's existence. But I blame Windows in
| MBR case very much.
|
| Also, some though not all motherboards allow you booting from
| BOTH old-school MBR and newer GPT so you may not need to
| disable CSM and still eat your GPT cake. This may be useful if
| you e.g. have an old MBR drive with Linux and another GPT one
| with Windows.
| TZubiri wrote:
| This is the incorrect take on the subject. Dual booting is a
| feature used by less than one in ten thousand users. Obsoleting
| BIOS will obsolete millions of hardware pieces.
| AreYouSirius wrote:
| nemetroid wrote:
| 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.
| mwcampbell wrote:
| > 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-
| Appl...
| bigpod wrote:
| 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.
| zaolin wrote:
| lynguist wrote:
| 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.
| cestith wrote:
| 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 wrote:
| 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.
| BeefWellington wrote:
| 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.
| li2uR3ce wrote:
| > 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.
| bitwize wrote:
| > 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".
| guerrilla wrote:
| 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.
| raverbashing wrote:
| 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 wrote:
| It's easy to use EFI when virtualizing things locally.
|
| libvirt/kvm supports it, Hyper-V supports it, Virtualbox
| supports it, ESXi supports it.
| AshamedCaptain wrote:
| 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.
| ridgered4 wrote:
| libvirt/kvm sort of supports it, unless you want to use
| snapshots I guess.
| 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.
| cesarb wrote:
| > 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?
| londons_explore wrote:
| 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.
| 2OEH8eoCRo0 wrote:
| Good. More time to work on new stuff.
| Nux wrote:
| The idea was turned down, luckily.
|
| There are too many downside at this point in time.
| AreYouSirius wrote:
| blueflow wrote:
| > 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.
| mjg59 wrote:
| - previously, x86 MBR-style partition tables (which were the
| only thing really supported in Linux) gave you no strong
| semantic information about what a partition was[1]. GPT may
| involve GUIDs, but in the grand scheme of things that's a small
| part of the cost of mounting stuff.
|
| - FAT is old, and FAT is well-supported by basically anything,
| and what features do you want in the partition that contains
| your bootloader that FAT doesn't support?
|
| - Yeah in an ideal universe we wouldn't have to deal with PE
| binaries and we wouldn't have to deal with the Windows 64-bit
| calling convention for jumping into the firmware and also we've
| solved all of this shit and it just isn't a big deal any more.
| We can look at any platform and complain about the
| implementation details, but at least this one is better
| documented than the BIOS interface ever was.
|
| In summary: Linux has to boot on computers that exist, and most
| computers that exist have UEFI. The Linux community has had the
| opportunity to make meaningful improvements to the UEFI spec in
| a way that wasn't true with BIOS. UEFI isn't ideal, but it's
| better than what came before in this respect.
|
| [1] Partitions could be identified as "Linux", but that gave
| you no information about what they were or where they should be
| mounted. Current systemd-driven development has allowed us to
| define the partition mount point as part of the GPT data, which
| means they can be automatically mounted in the correct place
| without static configuration about partition layout
| zozbot234 wrote:
| > previously, x86 MBR-style partition tables (which were the
| only thing really supported in Linux) gave you no strong
| semantic information about what a partition was[1]
|
| LVM appears to solve this issue as well as the related issue
| of only supporting a limited number of partitions in BIOS.
| chasil wrote:
| I believe that btrfs can be whole-disk and avoid partitions
| entirely, which would drastically simplify things.
|
| The only snag is swap, which I don't believe can be on a
| subvolume.
|
| vgchange is a struggle for me, from the first time I saw it
| in HP-UX.
| StillBored wrote:
| Most (all?) linux filesystems work just fine against raw
| devices. They are simply unaware of the difference. The
| larger problem is firmware trying to find partition
| tables/etc in the middle of a filesytem, but even then
| its mostly a non issue because random data doesn't tend
| to look like partition tables or MBRs.
| asveikau wrote:
| > The only snag is swap, which I don't believe can be on
| a subvolume.
|
| Linux can make swap a regular file, even. It doesn't need
| to be a partition.
|
| Google result shows:
| https://wiki.archlinux.org/title/swap#Swap_file
| StillBored wrote:
| And its something you want to do for security reasons
| anyway, since linux by default isn't encrypting swap
| partitions. Putting swap on an LUKs encrypted partition
| is a bit of a PITA but allows one to hibernate/resume
| without fear that ones private keys end up in plaintext
| stored on a disk.
| forty wrote:
| And relevant to OP, you cannot hibernate on Linux with
| secure boot enabled, I think precisely because Linux
| doesn't know how to sign/encrypt the RAM dump (no idea
| how it's actually called)
| zhfliz wrote:
| until kernel 5.0 swap files were not supported on btrfs.
|
| there's also some limitations, see
| https://btrfs.readthedocs.io/en/latest/btrfs-
| man5.html#swapf...
| asveikau wrote:
| I don't think these limitations are that major, and not
| everybody uses btrfs either.
| blueflow wrote:
| mjg59 wrote:
| I'm responsible for a great deal of the UEFI support on x86
| Linux systems. You're absolutely free to have concerns
| about a lot of the political and social positions I hold,
| but this is a topic where I am literally a domain expert.
| If you disagree with me on this subject, present technical
| arguments.
| mwcampbell wrote:
| As a newcomer to this thread, just wanted to say thanks
| for bringing your domain expertise to this discussion
| even though you're certainly not obligated to do so. And,
| though I presume you've been paid for at least some of
| the work you've done on Linux UEFI support, thanks for
| that as well. I'm thankful that someone is willing to go
| to the trouble to make Linux relatively easy to boot and
| install on modern PCs, though I imagine the desktop Linux
| space isn't very lucrative.
| scrollaway wrote:
| As an outsider to this debate, you're the hostile party.
| You're replying with name calling to someone who gave you a
| respectful and detailed answer.
| howinteresting wrote:
| blueflow's favorites list is remarkably revealing.
| blueflow wrote:
| i fixed it! thanks for reminding me.
| blueflow wrote:
| Check the screenshot i posted in your sister post and
| guess why the font colors are off.
| blueflow wrote:
| dinosaurdynasty wrote:
| > what features do you want in the partition that contains
| your bootloader that FAT doesn't support?
|
| Atomic updates and not getting corrupted if the power is
| pulled/lost while the filesystem is being written to.
| StillBored wrote:
| I suspect your thinking about FAT as a general purpose
| filesystem rather than the uEFI System Partition (ESP). For
| the latter case, one simply serializes access to the
| FAT/directory and renames files into their final resting
| place. That is going to be as robust and uncorruptable as
| any of the more "advanced" file systems jouraling
| mechanisms. Sure you might have a lost FAT chain, or a FAT
| chain mismatch between FAT copies, but its not going to
| cause a boot problem and a FAT "fsck" operation done during
| boot is going to be the equivalent of throwing the
| incomplete journal entries away, and probably just as fast
| given most ESP's contain a less than a dozen files.
|
| So, not a problem, with the huge advantage FAT can be
| implemented/validated/etc in a few dozen lines of code.
|
| KISS
| sounds wrote:
| dralley wrote:
| Matthew left Red Hat 10 years ago. If you're going to "full
| disclosure" people, you should probably do a better job
| with the details.
| edgyquant wrote:
| I don't think this is an important detail, if anything it
| may skew people against them as it seems they have
| corporate interests
| homarp wrote:
| workED for Red Hat, per wikipedia:
| https://en.m.wikipedia.org/wiki/Matthew_Garrett
|
| Right now at Aurora
| Dwedit wrote:
| FAT filesystems tend to get the cluster chains corrupted,
| then all your files are suddenly truncated to exactly 1
| cluster long.
|
| So I'd rather use EXT3 or NTFS because of Journaling, and not
| FAT.
| qwerty456127 wrote:
| > what features do you want in the partition that contains
| your bootloader that FAT doesn't support?
|
| Well, I'd love to be able to drop a bunch of 8GB (notably FAT
| doesn't support files this big) LiveDVD disk images on a bare
| file system and see them in the computer's built-in boot-menu
| immediately. I already enjoy the fact I don't need a
| traditional boot loader (like GRUB) to handle multi-OS as I
| can have 2 independent EFI boot partitions (one for Windows
| and one for Linux) and use the computer's boot menu too
| choose which to boot from.
|
| Ideally the whole OS should be just a read-only boot image
| and a traditional partition should only be used for
| config/data files IMHO.
| brobinson wrote:
| Ventoy can do this: small EFI partition with keys you can
| enroll in SecureBoot and a fat second partition you drop
| all your ISOs onto.
| Nextgrid wrote:
| GRUB can also do this. In fact, I'd be in favour of
| deprecating GRUB as the default for UEFI on Linux distros
| as it's a huge codebase (including lots of legacy things)
| which is overkill for booting a single OS (the Linux
| kernel itself can be a UEFI application, no bootloader
| needed) but for this use-case it's perfect as it's
| essentially its own mini-OS and can handle a wide array
| of filesystems including LUKS, Linux mdadm RAID, LVM,
| etc.
| horsawlarway wrote:
| To be fair - some distros are moving away from GRUB as
| the default.
|
| Pop!Os uses systemd-boot (formerly gummi-boot) by default
| if you're on an UEFI system, and only falls back to GRUB
| for legacy bios.
|
| Arch is also much easier to setup on systemd-boot.
|
| The issue is that GRUB still has a very compelling
| support matrix - it'll work basically everywhere, and
| with most all configurations. So if you're already
| running a batteries included distro, where someone else
| is doing most of the configuration and the downstream
| systems are hugely variable (old consumer hardware) -
| then GRUB still makes the most sense.
| zozbot234 wrote:
| > notably FAT doesn't support files this big
|
| ExFAT can support those. You could also use the UDF file
| system.
| blueflow wrote:
| ExFAT is not supported by EFI.
| qwerty456127 wrote:
| But ExFAT lacks the FAT's virtues of being universally
| supported and royalty-free, yet still is a very dumb FS
| with no journal (which means unreliable) and no extended
| attributes (which means data-metadata separation
| impossible) so I don't see a reason for it to exist
| anywhere outside severely resource-limited embedded
| applications. I would rather use Ext4 everywhere for
| everything. Is the problem preventing wide adoption of
| Ext4 GPL?
| Beltalowda wrote:
| A EFI partition is mostly read-only, so I don't think
| that's a particularly large problem?
|
| > I would rather use Ext4 everywhere for everything. Is
| the problem preventing wide adoption of Ext4 GPL?
|
| The BSDs don't support ext{2,3,4} particularly well, and
| Linux doesn't support FFS/UFS particularly well. I mean,
| there's support for these things, but it's far from
| complete or perfect and it's taken a long time.
|
| It's just a fair amount of effort to implement
| filesystems well, and there's very little tolerance for
| errors. Ext4 isn't spectacularly complicated, but it's
| not exactly a simple FS either. I think that has more to
| do with lack of support than anything else: lots of
| effort for not all that much practical benefit.
| speeder wrote:
| Seemly ExFAT is specially unreliable... Nintendo Switch
| community first advice when you buy one is: If you buy a
| SD Card with ExFAT, reformat it to FAT, because ExFAT
| will eventually cause your files to be corrupted...
| oynqr wrote:
| The Switch has a bad exfat driver.
| babypuncher wrote:
| That may have more to do with Nintendo's implementation.
| The exFAT support that was added to the Linux kernel a
| few years ago has been fine.
| Macha wrote:
| NTFS hasn't been widely adopted by firmware manufacturers
| either. I don't think firmware manufacturers want to
| spend time implementing support for even the
| NTFS/ext/APFS era of filesystems, never mind anything
| newer like ZFS or btrfs.
| qwerty456127 wrote:
| > NTFS hasn't been widely adopted by firmware
| manufacturers either.
|
| Although very complex and very undocumented, NTFS has
| actually been adopted very widely and quite reliably.
| Most of the pre-smart TVs and set-top-boxes can read FAT
| and NTFS USB drives which makes NTFS the only choice if
| you want movies exceeding 4 GiBs.
| AshamedCaptain wrote:
| In fact NTFS is available on most commercial UEFI
| implementations. You can use NTFS to format your Windows
| install pendrive...
| vetinari wrote:
| NTFS was also undocumented, and whatever the ntfs-3g
| folks or others working on alternate implementation
| figured out, it was via reverse engineering.
| Macha wrote:
| Sure, but the manufacturers presumably play for licenses
| for the AMD AGESA, etc. so could pay for a NTFS license
| if they wanted to.
|
| And ext has plenty of documentation and they haven't
| implemented that either.
|
| So I think keeping down the software complexity is the
| more likely method. Down to
|
| 1. The limited software investment these companies make
| (often just buying and reskinning firmware from AMI)
|
| 2. The limited space available on the ROMs due to
| hardware cost savings (e.g. companies have had to drop
| GUIs or support for less popular APUs to add support for
| new generations of mainstream CPU in firmware updates)
| mjg59 wrote:
| That's a reasonable desire, but it's also not something
| that's supported by traditional BIOS - UEFI isn't any worse
| in this respect
| tremon wrote:
| _I can have 2 independent EFI boot partitions and use the
| computer 's boot menu too choose which to boot from._
|
| You don't need 2 EFI boot partitions for this -- you can
| have multiple boot loaders in the same EFI partition, each
| with its own entry in the boot menu. In fact, this is how I
| boot: the default entry boots the linux kernel directly
| from the EFI partition (some UEFI implementations require
| the kernel to have a .efi extension, others don't), and I
| have separate fallback entries for refind and shellx64 in
| case I need to boot with different kernel parameters.
| mmphosis wrote:
| The first and only instruction that runs is on the "read-
| only" boot image which can be the whole OS. The solid state
| image is read-only because the tab is physically in the
| read-only position. The is the entire specification for
| booting.
| Macha wrote:
| > Well, I'd love to be able to drop a bunch of 8GB (notably
| FAT doesn't support files this big) LiveDVD disk images on
| a bare file system and see them in the computer's built-in
| boot-menu immediately. I already enjoy the fact I don't
| need a traditional boot loader (like GRUB) to handle multi-
| OS as I can have 2 independent EFI boot partitions (one for
| Windows and one for Linux) and use the computer's boot menu
| too choose which to boot from.
|
| Different systems have different constraints. For example,
| loading the firmware interface on my systems so it can
| present a boot menu is way, way slower than rEFInd or Grub.
| And presents an ugly menu in a non-native resolution for my
| monitors. And doesn't let me override kernel parameters
| adhocly at boot time if needed (thought it has been a
| number of years since I have, I'm reluctant to let go of
| the option).
| op00to wrote:
| You don't like it because Microsoft has a hand in developing
| the standard?
| jordemort wrote:
| EFI doesn't actually mandate FAT for the system partition. The
| system partition can be any filesystem that the firmware
| supports.
|
| Of course, pretty much all EFI implementations only support
| FAT, so it's a bit of a moot point; the only one I'm aware of
| that supports anything else is the one on Intel Macs, which
| also understands HFS+.
|
| You can find a huge selection of EFI filesystem drivers at
| https://efi.akeo.ie/ but they're derived from GRUB and hence
| GPL, so don't expect the likes of American Megatrends to be
| bundling these any time soon.
| StillBored wrote:
| Well splitting hairs, it mandates that everyone support FAT,
| individual system+OS vendors can add their own filesystems,
| but then its vendor lock.
|
| So, just do FAT and be done with it. Adding other filesystems
| is just a waste of time because the ESP only needs to store a
| half dozen files or so.
|
| 13.3.1.1: "The EFI firmware must support the FAT32, FAT16,
| and FAT12 variants of the EFI file system"
| babypuncher wrote:
| I think FAT is a fair baseline. It can be implemented in a
| few dozen lines of code. Support for it is ubiquitous. It
| is not encumbered by any active patents. All the
| alternatives I have seen proposed are both considerably
| more complex and not ubiquitously supported.
| babypuncher wrote:
| Most of the issues you describe sound either trivial or non-
| issues entirely.
|
| The mixed-endianness of GUIDs sounds annoying, but also easily
| worked around. It seems worth putting up with for the
| resiliency offered having the GPT duplicated at the beginning
| and and end of the disk.
|
| I'm not sure the UEFI system partition has any practical need
| for anything newer or more complex than FAT. It is a very
| simple file system for which support is ubiquitous, and is far
| more capable than an MBR boot sector.
|
| The EFI executable format being derived from Microsoft does not
| seem like an inherent problem, unless you can point out some
| meaning limitation it has compared to an alternative. However I
| do not know enough about binary executable formats to debate
| the merits of PE over ELF, so I could be missing something.
|
| It seems to me the benefits of UEFI far outweigh the negatives
| here. And with UEFI now being ubiquitous in consumer and
| commercial hardware for about a decade now, I do not think a
| bleeding edge distro like Fedora dropping BIOS/MBR is a huge
| deal.
| emteycz wrote:
| I don't see why Linux users would care about this. It boots the
| system, nobody cares it uses some old MS tech.
| blueflow wrote:
| Because "removing legacy" was one of the key arguments of EFI
| enthusiasts, and its still plenus bovis stercus.
| froh wrote:
| "Full of faeces from cows" is and remains vulgar no matter
| how it's spelled.
| zozbot234 wrote:
| There's nothing "vulgar" whatsoever about cow dung. It is
| an eco-friendly, renewable material and commonly used for
| many sacred rituals in India.
| tpush wrote:
| The GP literally used it as a weird coded insult to UEFI
| (for whatever reason), India doesn't really enter this
| discussion.
| prmoustache wrote:
| Your point is a bit moot because removing bios support will
| actually allow the maintainer to stop maintaining the bios
| parts regardless of the fact some other old things are
| kept.
|
| While actually not removing bios support won't allow you to
| get rid of the aformentionned MS techs such as fat support.
|
| Having said that I think this is a wee bit early.
| blueflow wrote:
| You made a factual mistake: MBR/BIOS based boot does not
| depend on a specific filesystem, nor does it depend on a
| specific executable file format except for the boot
| sector. You can safely remove FAT support from your
| kernel config, except when you need it for EFI.
| prmoustache wrote:
| > You made a factual mistake: MBR/BIOS based boot does
| not depend on a specific filesystem, nor does it depend
| on a specific executable file format except for the boot
| sector.
|
| I never said that.
|
| I said removing bios support allows you to remove
| anything that provides bios support and that choosing to
| not remove it won't allow you to get rid of the EFI
| dependencies so it is a moot point to talk about old
| techs used by EFI.
| tremon wrote:
| It doesn't just "boot the system". The full EFI specification
| includes support for runtime services, i.e. proprietary code
| that keeps running even after your FLOSS operating system has
| booted. That's something Linux users should care about: it
| provides a backdoor for clinging to closed-source drivers on
| a pretend-open platform. There's already been proof-of-
| concept EFI viruses, it's only a matter of time until the
| first antivirus EFI service appears.
| mjg59 wrote:
| The UEFI runtime services provide functionality that is not
| generically exposed through any other OS environment. Linux
| could just refuse to provide those runtime features, and
| things would roughly work[1] - we'd still need to call some
| UEFI features in the boot stub, but the same is true of
| BIOS (look at what the 16-bit code does in terms of
| obtaining information that the kernel uses after init). If
| you want to drop all access to runtime services after
| kernel boot, you can by simply passing efi=noruntime to the
| kernel arguments.
|
| [1] Some features would be broken, like recognising whether
| the system had booted successfully
| tremon wrote:
| can efivarfs still be accessed after booting with
| efi=noruntime? If so, I might add that on my systems and
| see if anything breaks.
| mjg59 wrote:
| No, all runtime services are gone. You don't /strictly/
| need them in order to boot - most Linux distributions
| will install a loader in the fallback path and the
| firmware will run it even if there are no boot entries.
| anthk wrote:
| Even back in the BIOS days Linux overrode lots of BIOS
| stuff such as partition size limits once it booted.
| Schopenhauer01 wrote:
| Less legacy code for them to maintain. I see that as a win.
| adrian_b wrote:
| Fedora does not maintain any code related to legacy BIOS
| booting.
|
| That is done by the maintainers of the bootloader packages.
|
| What Fedora presumably intends is to remove all bootloader
| packages from the installation image.
|
| In that case, the Linux kernel can be booted only by using
| its included EFI stub.
|
| One less package in the installation image might be claimed
| to imply less maintenance work for Fedora, but in any case
| such maintenance work has nothing to do with the work done
| for maintaining legacy code.
| faho wrote:
| EFI is here, non-specialty Linux distros don't really have the
| option of not adopting it.
|
| So the choice is between adopting it and keeping BIOS
| indefinitely, or adopting it and at some point in the future
| dropping BIOS.
| chasil wrote:
| Intel ME is also here, and newer systems absolutely do not
| have the option to disable it, despite all it's flaws.
|
| ME security vulnerabilities cannot be fixed in many cases,
| and it is an intolerable risk for some.
|
| If you insist on a system that does not run ME at all, then
| the best you can run is a Core 2 Quad x9650 on BIOS.
|
| Be mindful of what you are losing when you deprecate that
| machine.
| blueflow wrote:
| False dichotomy: Not picking EFI does not mean keeping BIOS
| indefinitely.
| faho wrote:
| What replacement do you propose, then?
|
| Especially what replacement do you propose that works with
| the kind of typical hardware that non-specialty linux
| distros like Fedora want to support?
|
| Intel systems make up a large chunk of the hardware Fedora
| is used on, and as far as I can tell they're all-in on EFI.
|
| So Fedora _has_ to use EFI to be able to boot on Intel
| systems.
| blueflow wrote:
| I don't. I'm waiting for something else, until then,
| we'll stick with BIOS. Supporting EFI means implementing
| more legacy cruft than we already have with BIOS.
| StillBored wrote:
| Let me take a moment and point out, unless your using
| hardware from < 2005 or so, or one of the rare devices
| running a custom firmware you literally are using UEFI
| when you think your booting in BIOS mode.
|
| Others have pointed out that the CSM is no longer being
| shipped. The CSM is the "Compatibility Support Module"
| and its a UEFI shim driver that adds the legacy bios INTx
| operations to a UEFI implementation.
|
| So, most people booting in BIOS mode on hardware built in
| the past 15 years or so are actually running UEFI with an
| extra shim.
| mjg59 wrote:
| This is literally not an option - systems have shipped
| without BIOS compatibility for a long time now, so
| refusing to support UEFI is just not an option.
| adrian_b wrote:
| Except for some embedded computers with Atom CPUs and
| some enterprise-oriented laptops, I have not seen any
| systems without legacy BIOS compatibility.
|
| Nevertheless, the option to enable the legacy BIOS
| booting can be quite hard to find in the BIOS menus,
| which may deceive many into believing that a system does
| not support legacy BIOS booting, even when it actually
| does support it.
|
| On work computers belonging to a company, the BIOS
| configuration may be locked, so it might not be possible
| for the users to enable legacy BIOS booting.
| doubled112 wrote:
| I have a couple of AMD ASUS Vivobooks that don't have
| CSM/BIOS boot available
|
| Never noticed until I wanted to boot memtest.
|
| It's possible that I missed it, but Google results didn't
| look promising either.
| eklitzke wrote:
| From the article:
|
| > 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.
|
| You may not have seen many computers yet without legacy
| BIOS compatibility but this is going to be the norm for
| new computers very soon.
| adrian_b wrote:
| The last new PC that I have seen, and which still had
| legacy BIOS booting support, was a Dell laptop purchased
| in Q2 2021.
|
| However, it was a model launched in the second half of
| 2020. It is indeed possible that the models introduced
| since 2021 might omit the legacy BIOS booting support.
| blueflow wrote:
| mjg59 wrote:
| I don't think that's going to result in everyone shipping
| UEFI without BIOS compatibility suddenly changing their
| mind.
| blueflow wrote:
| tremon wrote:
| OpenFirmware: https://en.wikipedia.org/wiki/Open_Firmware
|
| Many systems get by just fine with a minimal ELF or
| multiboot loader and a firmware-provided devicetree
| specification. Dynamic hardware enumeration is performed
| by every OS anyway, the only hardware that must be
| initialized is the bootloader/kernel storage.
|
| For the x86 platform, this could be implemented via
| coreboot (libreboot always reads to me as lib-reboot)
| with a multiboot payload.
| faho wrote:
| Do you propose that Fedora not support EFI and tell its
| users to replace the firmare or only buy devices with
| that?
|
| That would be a _massive_ step backwards in hardware
| support.
|
| Like I said: They don't really have the option of not
| supporting EFI.
|
| Alternatively they can support EFI _and_ OpenFirmware,
| but that _increases_ the number of supported paths
| instead of decreasing them.
| adrian_b wrote:
| Actually I do not understand which is the problem of
| Fedora in this case.
|
| The distribution needs to do almost nothing to support
| either EFI or the legacy BIOS or any other booting
| method.
|
| That is the job of a bootloader package, not of the Linux
| distribution. For example I am using syslinux as the
| bootloader for all my computers, while grub is another
| example of a frequently used bootloader (but which seems
| to be excessively complex in comparison with syslinux).
|
| I assume that by supporting only EFI Fedora means that
| they will remove all bootloaders from their installation
| image, so that the Linux kernel will be launched by its
| EFI stub.
|
| I do not know about other bootloaders, but an installed
| syslinux package occupies only a few megabytes, maybe 10
| megabytes at most, so deleting it cannot provide much
| space for anything else.
|
| I cannot see how deleting a bootloader package may be
| claimed to be a significant simplification for the
| maintenance effort of the Fedora distribution.
| faho wrote:
| 1. They no longer need to package bios bootloaders
|
| 2. They no longer need to support bios booting in the
| forums - no asking "how do you boot this? Bios, EFI? Have
| you tried the other?", no telling people "EFI is required
| for feature X"
|
| 3. They no longer need to maintain the bios boot
| documentation
|
| 4. They no longer need to maintain the bios path in the
| installer/boot media
|
| 5. They no longer need to test the bios paths (or hope
| they don't break and be ashamed if they don't)
|
| 6. This makes it easier to switch to a EFI-only default
| bootloader (instead of Grub 2, which can do both)
|
| Is this _massive_? No, it 's possible to keep maintaining
| BIOS support. But it's not just freeing space on the
| package mirrors either.
| adrian_b wrote:
| I agree that restricting the boot method to EFI would
| reduce the testing time.
|
| Grub 2 is complex to configure, but there are other
| bootloaders that are much easier to configure, e.g.
| syslinux.
|
| Restricting the boot method to EFI does not reduce the
| need for documentation in any way.
|
| The user must still be instructed to enter the BIOS setup
| and verify whether their computer is not configured to
| boot in legacy mode, which would prevent booting. Also
| the user must be instructed to enter the BIOS setup even
| if the EFI mode is used, because the installation media
| might not boot anyway, because a wrong boot order is
| configured for EFI booting, and it must be changed.
|
| The most complex part of the installation is not the
| booting, but identifying the device where Fedora should
| be installed, which might be needed to be reformatted and
| repartitioned.
|
| So a lot of documentation is needed in any case, for
| novice users.
|
| Removing the booting in legacy mode increases the chances
| that the installation media will not boot without the
| user having to modify the BIOS setup, so it increases the
| chances of the user having to search support in the
| forums.
| faho wrote:
| >Grub 2 is complex to configure, but there are other
| bootloaders that are much easier to configure, e.g.
| syslinux.
|
| ~~Yes but syslinux is bios-only. So if you have to
| support EFI too (and you do because there's EFI-only
| hardware), you now either need to support syslinux _and
| an EFI bootloader_ , or a bootloader that supports both
| like Grub 2.~~
|
| Edit: The article seems to suggest that syslinux can be
| removed if bios boot is no longer supported. I read that
| as it being bios-only, but it seems to support EFI?
|
| >Restricting the boot method to EFI does not reduce the
| need for documentation in any way.
|
| You still need documentation, yes. But you no longer need
| any documentation for _booting with BIOS_.
|
| You no longer need to say "X is only supported in EFI, if
| you boot via BIOS you need to do Y" or anything like
| that, and keep those parts updated.
|
| The part of the docs that says "To boot EFI, do X. To
| boot BIOS, do Y" can be cut down to "To boot Fedora,
| ensure X".
|
| That is a reduction in the amount of documentation.
| usrn wrote:
| You arguably don't need a bootloader at all with EFI. You
| could just use the efistub.
| adrian_b wrote:
| Yes, it is easy to make a bootable device that can use
| either syslinux to boot when legacy BIOS is used or
| efistub to boot when EFI booting is used, eventually
| loading the same kernel.
|
| No other bootloader is needed.
| imtringued wrote:
| Or systemd-boot. I will admit I am using Grub2 on my
| current Linux installation but I never liked grub. I
| think grub sucks.
| tremon wrote:
| No, I don't propose that Fedora not support EFI. I do
| propose that Red Hat use some of its parent company's
| clout to push hardware vendors in a more open direction.
| bitwize wrote:
| But OEMs didn't choose OpenFirmware. They chose UEFI.
| Therefore, Linux must support UEFI, and that's where
| developer effort will go.
| StillBored wrote:
| "Many systems get by just fine with a minimal ELF or
| multiboot loader and a firmware-provided devicetree
| specification"
|
| Not really, none of those ecosystems has a fraction of
| the device variation that x86 has. When they do (arm) its
| a giant mess of incompatibility and non working hardware.
| Modern DT's are basically still tied to the linux kernel
| the same way that the old arm/platform descriptions tied
| firmware id's to individual kernel configurations. Which
| is why the answer to so many arm problems is "match your
| DT to the kernel revision", god help you if your trying
| to multiboot a *bsd/etc as well.
|
| PS: Openfirmware is basically dead, that might have been
| a valid answer in 1998, but even IBM/etc provide
| alternative boot mechanisms for linux/PPC at this point.
| The only thing that comes close to a current replacement
| is UEFI.
| adrian_b wrote:
| I have encountered various embedded computers which no
| longer have the legacy BIOS boot option, so using EFI is
| indeed necessary.
|
| However, the vast majority of server or desktop
| motherboards and of laptops still have the option for
| legacy BIOS booting, even if the option may be difficult
| to find in the BIOS menus.
|
| I have about a dozen servers, desktops and laptops and I
| have configured all of them to use legacy BIOS booting,
| because EFI booting does not have any advantage, only
| disadvantages.
|
| It would have been very easy to replace the ugly legacy
| BIOS booting method with a simple and clean method for
| booting, but unfortunately those who made the EFI
| specification have failed to achieve this goal.
| justsomehnguy wrote:
| >because EFI booting does not have any advantage, only
| disadvantage
|
| For an already installed system it doesn't really
| matters, so the point is moot here.
|
| But for the new systems setup I would always prefer a
| UEFI (with or without SecureBoot) because it allows to
| expose the HID management of the onboard/expansion board
| controllers, a proper way to return to the
| management/boot menu in the case of the failed boot.
|
| Sure, it doesn't always work good, but neither BIOS/CMS.
| quietbritishjim wrote:
| > UUIDs ... endianess is not little, big - its mixed. mixed in
| the same value
|
| UUIDs do not have any endianness. They are just a sequence of
| individual bytes.
|
| It's true that some ways of _generating_ UUIDs work by using
| the bytes of longer numbers, which I can believe use mixed
| endianness (I don 't know them well enough to remember myself).
| But no one should be relying on that when reading UUIDs back
| out, except maybe for debugging purposes.
|
| Or does GPT require interpreting the parts of UUIDs? If so,
| that is the real problem.
| GoblinSlayer wrote:
| UUID is defined as a sequence of 6 integer fields of various
| sizes. Their conversion to text is fairly straightforward,
| but serialization to bytes may vary depending on how you do
| it. "Whatever ends up in memory" is microsoft little endian
| format.
| blueflow wrote:
| Its relevant for converting them from and to their string
| representation.
|
| https://en.wikipedia.org/wiki/Universally_unique_identifier#.
| ..
| quietbritishjim wrote:
| Interesting link, thanks, I wasn't aware of that. The link
| seems to suggest that the odd mixed-endian string
| representation ("Variant 2") is now quite rare.
|
| With the one that's more common ("Variant 1"), I'd say that
| I *slightly* disagree that representing the byte sequence
| 99,aa,bb,cc as 99aabbcc is "big endian". If you don't
| philosphically think of the latter as a number, then it's
| just the bytes written out compactly. But I do see that if
| you think of it as a number then it's big endian,
| especially if you're distinguishing from variant 2.
| GoblinSlayer wrote:
| Variant is a very abstract concept mostly for humans,
| programs pay no attention to it and serialize all kinds
| of UUID the same way.
| Nextgrid wrote:
| The legacy BIOS boot system and MBR format has some real issues
| that could be improved but this just sounds like an ideological
| battle against things inspired by Microsoft rather than
| legitimate technical concerns. As far as I know, despite the
| things you list having Microsoft roots, they are well-
| documented and have free/libre implementations so Microsoft
| influences are not really a problem.
|
| The main problem you have is that convincing manufacturers
| _and_ proprietary OS makers (including Microsoft) to switch to
| a hypothetical UEFI replacement free of those issues is going
| to be an impossible task, while UEFI is already here and while
| not perfect appears to be better than the legacy BIOS boot
| system.
| jaclaz wrote:
| Only for the record, I don't know in Linux, but on windows (at
| least up to 10) it is perfectly possible to use MBR partitioned
| media to boot in UEFI (i.e. even if generally speaking GPT is
| "tied" to UEFI, GPT partitioning is not a requisite unless a
| greater than 4TB mass storage with 512 bytes/sector is used, 4K
| disks are generally not bootable for a number of operating
| systems, but they are rare anyway as boot media).
|
| Viceversa, it is possible with some loaders to boot BIOS from
| GPT (not easy-peasy or straightforward but it can be done).
|
| As well, the FAT is only a requisite if there is not an EFI
| driver for the filesystem, as an example some motherboards and
| RUFUS provide a NTFS driver that allows booting from NTFS
| volumes under UEFI.
|
| Still, while in theory GPT and UEFI have a few advantages,
| there is not in practice (yet) any meaningful reason to remove
| support to BIOS, though lately a number of notebooks have UEFI
| firmware only (no CSM aka BIOS), I cannot see how removing an
| option/choice from a distro can be a good thing.
| pja wrote:
| IIRC Windows 11 will no longer boot from MBR partitions & you
| have to convert them to GPT.
| little_panda wrote:
| It will; there are tweaks out there that explicitly allow
| for installing windows 11 on an mbr partition.
|
| Hint: download the latest version of Rufus, point it to a
| windows 11 iso and select the "Extended installation" mode.
| The result will happily install itself onto an MBR
| partition.
|
| I performed an upgrade (!) of a windows 10 installation to
| windows 11 in this manner; I'm writing from this SSD right
| now. PS C:\Users\alexa> $(get-disk | ?
| {$_.IsSystem}).PartitionStyle;
| [System.Environment]::OSVersion.Version MBR
| Major Minor Build Revision ----- ----- -----
| -------- 10 0 22000 0
| zahllos wrote:
| I am actually for keeping the legacy scheme around for a good
| while, mostly because there's plenty of hardware even now that
| relies on it.
|
| But UEFI is more sane. Bios systems map the first 512 bytes
| which are both code and partition table into ram. Into that you
| need to cram enough code to locate stage 2, which I think
| tended to be located in the alignment space between the MBR and
| the next sector. Stage 2 once loaded needed enough logic to
| find and load your boot partition, and load your config from
| it, parse the kernel list and finally load one of those
| kernels. I seem to remember grub hard coding where the stage2
| actually was, although I might be wrong about that. Either way
| it was a kinda fragile mess.
|
| Sure, every boot process needs to get enough logic loaded to do
| the next thing, but with efi this is all taken care of during
| efis various internal loading phases, nicely located in code on
| onboard flash where it probably should be. By the time it comes
| to look for what you want to load, you are already in long mode
| and we aren't hiding stuff in places not covered by a partition
| definition. It is kinda annoying they didn't consider a boot
| filesystem with large enough file storage for big images
| (exfat, udfs, other reasonable choice, we have the filesystems)
| but we can cope with that.
|
| The process for detecting bootable partitions and updating boot
| entries is a lot, lot saner than BIOS systems tend to be. Sure
| there are details of the design I don't like, and I kinda agree
| with your points there too, but substitute those for better
| choices and you still have a reasonable overall framework.
| im3w1l wrote:
| What I like about bios is how simple stupid it is. It reads a
| bunch of bytes in and boom and starts running them. Partition
| tables and multiple stages, yes that is the convention but
| you dont have to adhere to that if you dont want to. Having
| to change into long mode, yes that is an important wrinkle I
| give you that.
|
| Ok contrast that with UEFI. There are FAT boot partitions and
| PE executables and what not. That's a lot more complexity.
| jchw wrote:
| > - 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.
|
| No. They are not Windows executables. They won't run under
| Windows at all for multiple reasons. They are _PE executables_.
|
| PE is the executable format developed for Windows, and yes, it
| is backwards compatible with MZ executables, so it has the now-
| confusing MZ header even though that doesn't make sense under
| EFI. It also has some other weird details kind of hardcoded in,
| like some of the data directories, many of which don't make
| that much sense under EFI. Worse, it's a little weird to parse,
| with many things being deduced by using known structure sizes
| combined with offsets specified in fields.
|
| However, PE as a format is totally fine. Good, even. In its
| purest form, it really doesn't have that much baggage. It flat
| out has some advantages over ELF whose symbol table non-sense
| is notoriously complicated. Not so under PE: explicit table of
| exports, explicit table of imports. The imports go to specific
| modules. Symbols don't conflict. It's got cruft, but it's very
| simple to write a parser or loader, and I've done so a number
| of times before. With PE the runtime linking is handled by
| whatever OS is running, be it EFI or Windows; none of the
| INTERP stuff is needed.
|
| Frankly, I'd be OK with using PE on Linux too. When I was a
| kid, I toyed around with making a binfmt for PE. Of course I
| didn't finish (most notably, I never figured out how to do
| linking, since the ELF binfmt didn't really do that) but it's
| quite straightforward to get the actual loader going.
|
| As for the rest of the grievances... As far as I know, FAT and
| GPT are only required to be supported by EFI, not required to
| be used. Some EFI implementations support other filesystems for
| the ESP (like Apple with HFS+,) and I've not used one that
| won't happily use an ESP on an MBR.
| zahllos wrote:
| > No. They are not Windows executables. They won't run under
| Windows at all for multiple reasons. They are PE executables.
|
| Starting with the fact they have a dedicated set of
| "subsystem" values: https://docs.microsoft.com/en-
| us/windows/win32/debug/pe-form... - the win32 loader won't
| load anything that isn't the CUI or the GUI Windows one,
| although the kernel also knows about the native one. You'll
| just get the "this is not a Windows application" messagebox.
|
| With NASM, you can also override that linker stub. For
| example save this to a file: org 100h
| start: mov dx, msg mov ah, 9
| int 21h mov ah, 4Ch int 21h
| msg db 'Are you still running DOS in 2022? Wow! 640K enough
| for you!',13,10,'$'
|
| nasm -fbin -o stub.com stub.asm
|
| then if you are using Microsoft's tools you can use LINK.EXE
| <usual args> /STUB:stub.com and voila, if anyone _happens_ to
| (try to) your code under DOS, they'll get an amusing message.
|
| If you want it to take up minimum space, use this one:
| org 100h start: mov ah,4Ch
| int 21h
|
| which will just exit that program if run under dos.
|
| Apparently the header is hardcoded in mingw, but you could
| easily binary patch it in the resulting executable.
|
| I think I read somewhere you can also remove the stub
| completely, but I've never tried it.
|
| Edit: for my last comment, yes, you can definitely drop it:
| https://stackoverflow.com/a/9659538.
| kevinoid wrote:
| 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/9e2465834f4bff40...>
| and libvirt can't revert or delete external snapshots
| <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-Sep...> and the situation appears to be unchanged. Do
| others have a workable solution?
| BirAdam wrote:
| 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 wrote:
| 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 wrote:
| > _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.
| Narishma wrote:
| Windows 10 doesn't require UEFI. None of my computers have
| it and they all boot Windows 10 just fine.
| mustache_kimono wrote:
| 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.
| mjg59 wrote:
| 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.
| pabs3 wrote:
| The majority of x86 computers I have are BIOS only, only one of
| them is UEFI and I only have it because I found it discarded on
| the side of the road. I don't use the UEFI mode though, since
| my current install doesn't support booting in UEFI mode (no
| GPT) and wouldn't support booting in BIOS mode if I switched it
| to GPT and UEFI.
| AshamedCaptain wrote:
| 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 wrote:
| My current desktop's motherboard and CPU are from 2009. I
| have no idea if the MB supports UEFI; it definitely boots to
| BIOS by default. I've upgraded the storage, memory, and GPU,
| but there's been little cause to waste money on a new MB/CPU.
| But I guess I wouldn't install Fedora on this machine anyway,
| so _shrug_.
| mjg59 wrote:
| Eep! efi=no_disable_early_pci_dma only does anything if
| CONFIG_EFI_DISABLE_PCI_DMA is set, and distros should not be
| setting that by default (it's a thing that works Just Fine in
| theory, and specific implementations may fail hard with it -
| eg, if ExitBootServices() triggers a callback that assumes
| that a PCI device is able to DMA, things may explode). It's a
| useful security feature (I mean, I wrote it, I would say
| that) but it can break even if implementations follow the
| spec perfectly.
| superkuh wrote:
| You (and they) forget the part where graphics cards play an
| intimate role in MBR or UEFI boot. And there still innumberable
| quite functional graphics cards that will never, ever, allow a
| system to boot under UEFI. GPUs are deeply integrated into the
| boot up process.
|
| This is easy for IBM/Fedora to forget because GPUs probably
| don't matter much to them. They just take their intel
| integrated graphics on their workstation (or server) and go.
| And other linux devs are probably rich enough to buy a modern
| GPU.
|
| But it is a huge issue and it'll not have become irrelevant for
| at least another decade. Not being able to boot MBR will break
| (and prevent) much more than the Fedora, LWN, or most of the
| threads here are aware of.
| jeffbee wrote:
| I have a UEFI system right here under my desk that provides
| legacy BIOS services for running option ROMs, video cards,
| SCSI host bus adapters, network adapters, anything. It even
| scans out their legacy video outputs in a little window.
| There's nothing incompatible between UEFI and legacy option
| ROMs. Perhaps you are thinking of Secure Boot.
| superkuh wrote:
| >Perhaps you are thinking of Secure Boot.
|
| Nope. I think there must be a miscommunication here so I'll
| be more explicit.
|
| If you have CSM/BIOS mode on your UEFI default motherboard
| and you set it to CMB/BIOS mode of course you can run BIOS
| based video cards.
|
| But if you switch your mobo to UEFI boot (say, because you
| want to run future Fedora, or maybe boot off an nvme
| storage device) you can't use your BIOS firmware video
| cards (unless, like some gigabyte cards they shipped for a
| few years with both BIOS firmware and UEFI firmware). It
| has nothing to do with secureboot or signing or any of
| that. GPU's are intimitely involved (INT_10h in BIOS and
| something cursed in UEFI GOP) in the first few operations
| on boot in both systems and the firmware on the GPU has to
| be able to fulfill that role.
|
| So Fedora removing BIOS boot effectively removes the
| ability to use most video cards ever made. Anything
| designed before 2015 has a decent chance of causing
| trouble.
| mjg59 wrote:
| A lot of firmware supports using CSM to do GPU init and
| then providing UEFI interfaces on top of that. Of course,
| this is incompatible with Secure Boot.
| StillBored wrote:
| "you can't use your BIOS firmware video cards"
|
| Actually you can, you just don't get firmware boot
| support. Plenty of those boards work just fine in
| linux/etc because they reprogram the entire board using
| AtomBios/etc when the ati/nouveau/etc drivers load. The
| Arm/PPC/riscv people are all running the same PCIe boards
| as everyone else, and outside of a few cases they are
| doing just fine not running the x86 option roms.
| tpush wrote:
| What graphics cards make it unable to boot via UEFI?
| zajio1am wrote:
| > My short summary of this: pretty much every x86 client system
| since 2012 has shipped with working UEFI support
|
| That is AFAIK not true for industrial boards. For example
| current PC Engines APU2 boards just have Coreboot-based BIOS
| without UEFI.
| userbinator wrote:
| _Linux works Just Fine with basically all of them._
|
| Do you remember this?
|
| https://news.ycombinator.com/item?id=11008449
| mjg59 wrote:
| Yeah, turns out representing EFI variables as a filesystem
| was a mistake (sorry, that was my fault)
| iod wrote:
| 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 BootDuet1, or for
| an easier user experience CloverBootloader2. 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.
|
| 1 https://github.com/migle/BootDuet
|
| 2 https://github.com/CloverHackyColor/CloverBootloader
| AshamedCaptain wrote:
| I don't think you can emulate a TPM via software. You need a
| hook in the firmware and use SystemManagementMode/SMM, very
| likely.
| pabs3 wrote:
| Seems there are two such projects for that:
|
| https://github.com/stefanberger/swtpm
| http://sourceforge.net/projects/ibmtpm20tss/
| AshamedCaptain wrote:
| I mean "in a way that would allow you to boot Windows on
| top of it".
| Frenchgeek wrote:
| Interesting... I'll check if it can emulate 64 bits UEFI on a
| 32 bits one (yet 64 bits cpu): Finding anything to boot on my
| old tablet PC is becoming a pain.
| jeroenhd wrote:
| Windows 11 isn't going to work with emulated TPM stuff (unless
| you run Windows in a tiny Linux hypervisor will all PCIe space
| forwarded and an emulated virtual TPM, perhaps) but this
| approach should work perfectly fine for all other operating
| systems.
|
| In my Windows 10 setup, Bitlocker refuses to boot without a
| recovery key when I don't use GRUB to load Windows; presumably,
| Windows recorded the system state when I enabled Bitlocker,
| which was booted via Grub. In similar fashion I expect Windows
| 11 to actually work just fine on systems with a TPM as long as
| Grub is used every time.
| zinekeller wrote:
| > 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 wrote:
| 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.1 But I
| never use Windows and don 't plan to start anytime soon, so
| it's not something that I will try.
|
| 1 https://support.microsoft.com/en-us/windows/ways-to-
| install-...
| rvp-x wrote:
| Fedora didn't even support UEFI on their cloud images before
| Fedora 35, released 5 months ago.
|
| https://pagure.io/cloud-sig/issue/309
| Scramblejams wrote:
| 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 wrote:
| > 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.
| amir wrote:
| 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
|
| 20 of the poster's last 30 submissions have been LWN subscriber
| links.
| Macha wrote:
| 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.
| reaperducer wrote:
| _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 wrote:
| 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.
| codedokode wrote:
| > UEFI is defined by a versioned standard that can be tested and
| certified against
|
| But _is_ it actually tested against or only _can_ be?
| userbinator wrote:
| _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
|
| 7C00h forever! ;-)
| tenebrisalietum wrote:
| 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 wrote:
| 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 wrote:
| - 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.
| egberts1 wrote:
| You will have to pry that BIOS from my cold dead hands.
|
| Burnt EEPROM still remains the ultimate security.
| cpach wrote:
| 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.)
| cestith wrote:
| 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.
| ulzeraj wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| >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 wrote:
| 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.
| tremon wrote:
| That's because current generation of hardware does not
| mandate secure boot on x86. I expect that will change
| once Windows 11 has had a few years to turn the majority
| of the computers secure-boot capable due to its hardware
| demands.
| Foxboron wrote:
| That would be against the current UEFI spec. I get that
| people are cynical and expect this to happen but I don't
| think it will.
|
| There are however going to be a lot more issues self-
| enrolling keys going forward.
| jeroenhd wrote:
| Secure boot allows you to load your own keys. That's the
| way some Linux distros actually recommend you to set it up:
| sign your own bootloader, kernel, kernel modules,
| everything, and tell your motherboard to trust that. It's
| arguably even more secure than Microsoft's approach because
| anyone can boot a Windows install disk, but getting a boot
| drive with your signature on it requires breaking into your
| system. This could be a little challenging if you try to
| update firmware through manufacturer supplied boot images
| that expects their Microsoft signature to work, but it's
| not impossible to work around that.
|
| For dual booting you'd need to load both sets of keys (your
| own and Microsoft's) or configure your primary bootloader
| to trust Microsoft's signature and chainload.
|
| There's nothing inherently Microsoft related about secure
| boot, except for that on some Microsoft devices where the
| ability to use your own keys has been taken away from you.
| Don't buy a Microsoft Surface without checking its Linux
| limitations, basically, but that's a Microsoft problem, not
| a secure boot problem.
|
| If you don't like being restricted, just turn off secure
| boot. Or turn off any verification that happens after
| secure boot; it's the Linux kernel that's enforcing drivers
| it loads to be signed, not the secure boot standard. Patch
| out the verification routine with a return true if you have
| to.
|
| Everything will boot and load, which may or may not be a
| good thing, depending on your requirements.
| AshamedCaptain wrote:
| I am not saying that you can't fiddle with the BIOS (and
| or preloader or shim) to workaround this; I'm just saying
| that this is the MS-signed distro's motivation to
| lockdown bootloaders and kernels when you are booting
| with SecureBoot on.
| bitwize wrote:
| > There's nothing inherently Microsoft related about
| secure boot,
|
| Microsoft is the root of trust for ~100% of OEM secure
| boot implementations.
|
| Theoretically, you can implement Secure Boot with an
| alternative root of trust... but you'd have to get the
| OEMs on board... to the tune of many millions of dollars.
| Per OEM.
|
| The only alternative is to get users to install their own
| keys, which is fiddly and technical.
|
| Therefore, for all intents and purposes, Linux on the
| desktop is only a thing at all because Microsoft deigns
| to allow it for the time being.
| bscphil wrote:
| > The only alternative is to get users to install their
| own keys, which is fiddly and technical.
|
| It's a bit worse than that actually; it's actively scary
| and dangerous, as with much EFI stuff. Quoting the Arch
| Wiki:
|
| > Warning: Replacing the platform keys with your own can
| end up bricking hardware on some machines, including
| laptops, making it impossible to get into the UEFI/BIOS
| settings to rectify the situation. This is due to the
| fact that some device (e.g GPU) firmware (OpROMs), that
| get executed during boot, are signed using Microsoft's
| key.
|
| The key process creation itself is extremely manual and
| finicky, and probably prone to error.
|
| The process of enrolling your platform key involves
| deleting _all_ enrolled certificates. Let 's hope your
| hardware provider implemented this properly so you didn't
| just brick your system.
|
| > Once Secure Boot is in "User Mode" keys can only be
| updated by signing the update (using sign-efi-sig-list)
| with a higher level key. Platform key can be signed by
| itself.
|
| So _any_ loss of your platform key (e.g. by cosmic ray
| flipped bit, or hard drive failure, or simply user error)
| results in effectively bricking your hardware, right?
| (Unless and until you can rewrite the firmware with a
| hardware device.)
|
| I'm sure some folks have worked out a good process for
| managing all this, but it feels so flaky to me and I
| don't have a good handle on what is required to do this
| right. Back in the day, installing Linux for me used to
| involve 2-3 cycles of screwing up something with GRUB,
| having to boot into the LiveCD, and fixing things. Right
| now it feels like one screw up could be fatal to hundreds
| of dollars of hardware. That's before you get to the
| issue of having to mess with the EFI variables, which has
| resulting in bricking hardware in the past: https://www.t
| heregister.com/2016/02/02/delete_efivars_linux/
|
| Again, some of the above could be based on my
| misunderstandings, but that's kind of the point as well -
| the scary thing about secure boot / UEFI for Linux users
| is that it's a new area of _required_ knowledge that you
| seemingly need to be 100% right about or risk burning
| hardware.
| cabirum wrote:
| 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 wrote:
| 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 wrote:
| it's not really happening, or at least not yet. I don't see why
| this even got posted the way it was.
___________________________________________________________________
(page generated 2022-04-21 23:01 UTC)