161–170 of 233 posts
Earlier quoted context omitted.
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.
NTFS was also undocumented, and whatever the ntfs-3g folks or others working on alternate implementation figured out, it was via reverse engineering.
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)
Earlier quoted context omitted.
>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…
You arguably don't need a bootloader at all with EFI. You could just use the efistub.
Earlier quoted context omitted.
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.
blueflow's favorites list is remarkably revealing.
Earlier quoted context omitted.
- 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 th…
> 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.
So, not a problem, with the huge advantage FAT can be implemented/validated/etc in a few dozen lines of code.
KISS
Earlier quoted context omitted.
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 workstatio…
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.
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.
> 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 usi…
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.
Earlier quoted context omitted.
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 , 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…
> 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,…
Old hardware is great. Expecting people to support it forever for free is folly. This is exactly why people pay IBM/RedHat for support.
Earlier quoted context omitted.
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.
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…
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.
> 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 usi…
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 t…
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"