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