9 ms·

> 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

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

emteycz 5y ago
I don't see why Linux users would care about this. It boots the system, nobody cares it uses some old MS tech.
- blueflow 5y ago
  Because "removing legacy" was one of the key arguments of EFI enthusiasts, and its still plenus bovis stercus.
  - froh 5y ago
    "Full of faeces from cows" is and remains vulgar no matter how it's spelled.
    - zozbot234 5y ago
      There's nothing "vulgar" whatsoever about cow dung. It is an eco-friendly, renewable material and commonly used for many sacred rituals in India.
      - tpush 5y ago
        The GP literally used it as a weird coded insult to UEFI (for whatever reason), India doesn't really enter this discussion.
  - prmoustache 5y ago
    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 5y ago
      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 5y ago
        > 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 5y ago
  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 5y ago
    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
    - anthk 5y ago
      Even back in the BIOS days Linux overrode lots of BIOS stuff such as partition size limits once it booted.
    - tremon 5y ago
      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 5y ago
        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.
Schopenhauer01 5y ago
Less legacy code for them to maintain. I see that as a win.
- adrian_b 5y ago
  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 5y ago
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.
- blueflow 5y ago
  False dichotomy: Not picking EFI does not mean keeping BIOS indefinitely.
  - faho 5y ago
    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 5y ago
      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.
      - mjg59 5y ago
        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.
        blueflow 5y ago
        mjg59 5y ago
jaclaz 5y ago
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 5y ago
  IIRC Windows 11 will no longer boot from MBR partitions & you have to convert them to GPT.
  - little_panda 5y ago
    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
mjg59 5y ago
- 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
- blueflow 5y ago
  - mjg59 5y ago
    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 5y ago
      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.
quietbritishjim 5y ago
> 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.
- blueflow 5y ago
  Its relevant for converting them from and to their string representation. https://en.wikipedia.org/wiki/Universally_unique_identifier#Encoding https://en.wikipedia.org/wiki/Universally_unique_identifier#...
  - quietbritishjim 5y ago
    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 5y ago
      Variant is a very abstract concept mostly for humans, programs pay no attention to it and serialize all kinds of UUID the same way.
- GoblinSlayer 5y ago
  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.
op00to 5y ago
You don’t like it because Microsoft has a hand in developing the standard?
zahllos 5y ago
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 5y ago
  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. But either way, the design is so simple that you could write a little hello world mbr-program with a hex editor. It's a handful of bytes. Ok contrast that with UEFI. There are FAT boot partitions and PE executables and what not. That's a lot more complexity.
jordemort 5y ago
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/ 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 5y ago
  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 5y ago
    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.
Nextgrid 5y ago
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.
jchw 5y ago
> - 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 5y ago
  > 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-format#windows-subsystem 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 https://stackoverflow.com/a/9659538.
babypuncher 5y ago
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.
saghm 5y ago
> - 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. I've always wondered why it was required that my EFI partition be FAT. I've had systems where that partition has gotten messed up and required an fsck from a recovery boot, and it seemed like it should be possible to either do that automatically in some way, but being able to use a filesystem that self-corrects would be nice too (although maybe overkill for the 1 GB or whatever I give it). I guess maybe it would only be possible to perform the fsck if I booted from a different partition, which then could develop the same issue. This does make me wonder how silly it would be to have a duplicate boot partition on each of my machines that I only mount to sync over changes to the real one so I could avoid needing to grab my flash drive when stuff like this happens...

emteycz 5y ago

I don't see why Linux users would care about this. It boots the system, nobody cares it uses some old MS tech.

blueflow 5y ago
Because "removing legacy" was one of the key arguments of EFI enthusiasts, and its still plenus bovis stercus.
- froh 5y ago
  "Full of faeces from cows" is and remains vulgar no matter how it's spelled.
  - zozbot234 5y ago
    There's nothing "vulgar" whatsoever about cow dung. It is an eco-friendly, renewable material and commonly used for many sacred rituals in India.
    - tpush 5y ago
      The GP literally used it as a weird coded insult to UEFI (for whatever reason), India doesn't really enter this discussion.
- prmoustache 5y ago
  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 5y ago
    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 5y ago
      > 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 5y ago
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 5y ago
  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
  - anthk 5y ago
    Even back in the BIOS days Linux overrode lots of BIOS stuff such as partition size limits once it booted.
  - tremon 5y ago
    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 5y ago
      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.

Schopenhauer01 5y ago

Less legacy code for them to maintain. I see that as a win.

adrian_b 5y ago
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 5y ago

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.

blueflow 5y ago
False dichotomy: Not picking EFI does not mean keeping BIOS indefinitely.
- faho 5y ago
  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 5y ago
    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.
    - mjg59 5y ago
      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.
      - blueflow 5y ago
        mjg59 5y ago

jaclaz 5y ago

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 5y ago
IIRC Windows 11 will no longer boot from MBR partitions & you have to convert them to GPT.
- little_panda 5y ago
  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

mjg59 5y ago

- 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

blueflow 5y ago
- mjg59 5y ago
  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 5y ago
    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.

quietbritishjim 5y ago

> 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.

blueflow 5y ago
Its relevant for converting them from and to their string representation. https://en.wikipedia.org/wiki/Universally_unique_identifier#Encoding https://en.wikipedia.org/wiki/Universally_unique_identifier#...
- quietbritishjim 5y ago
  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 5y ago
    Variant is a very abstract concept mostly for humans, programs pay no attention to it and serialize all kinds of UUID the same way.
GoblinSlayer 5y ago
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.

op00to 5y ago

You don’t like it because Microsoft has a hand in developing the standard?

zahllos 5y ago

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 5y ago
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. But either way, the design is so simple that you could write a little hello world mbr-program with a hex editor. It's a handful of bytes. Ok contrast that with UEFI. There are FAT boot partitions and PE executables and what not. That's a lot more complexity.

jordemort 5y ago

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/ 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 5y ago
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 5y ago
  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.

Nextgrid 5y ago

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.

jchw 5y ago

> - 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 5y ago
> 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-format#windows-subsystem 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 https://stackoverflow.com/a/9659538.

babypuncher 5y ago

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.

saghm 5y ago

> - 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. I've always wondered why it was required that my EFI partition be FAT. I've had systems where that partition has gotten messed up and required an fsck from a recovery boot, and it seemed like it should be possible to either do that automatically in some way, but being able to use a filesystem that self-corrects would be nice too (although maybe overkill for the 1 GB or whatever I give it). I guess maybe it would only be possible to perform the fsck if I booted from a different partition, which then could develop the same issue. This does make me wonder how silly it would be to have a duplicate boot partition on each of my machines that I only mount to sync over changes to the real one so I could avoid needing to grab my flash drive when stuff like this happens...