Talk:Arch boot process

SecureBoot support in the Feature Comparison table

I'd like to add a column describing whether each bootloader can be adapted to work with SecureBoot or not. For example, EFISTUB cannot, since the cmdline is stored in firmware, not signed,and can be altered by an attacker. systemd-boot OTOH, is very easy to sign, and can load bundles with a signed initfs and cmdline. Any objections to this? WhyNotHugo (talk) 17:59, 14 July 2021 (UTC)

Sounds like a good idea! I'd only include the primary bootloaders though. See discussion below about proposed changes to the table. Jasonwryan (talk) 21:30, 13 January 2022 (UTC)

Even more columns? Then at least remove 1 column to make up for it. Like ReiserFS (who uses that?) -- Alad (talk) 22:02, 13 January 2022 (UTC)

Removal of bootloaders in the AUR

I think the feature table should only really concern itself with bootloaders that people actually use. Currently unexperienced people are guided to the table and met with a lot of information. It doesn't help that everything is added. Legacy stuff should go as well. We could have a legacy table if people see the need, but honestly who uses most of that after? Certainly not based off on this list? Foxboron (talk) 21:07, 13 January 2022 (UTC)

Agreed. I don't see the need for a legacy table, but perhaps some of the more experimental/alternative bootloaders could be included in a separate section (not a table), that links to their wiki or upstream documentation. Anyone wanting to play with one of those will presumably be competent enough to work it out for themselves... Jasonwryan (talk) 21:28, 13 January 2022 (UTC)

The real issue is in 1. the amount of columns 2. the verbose descriptions they contain. Removing a few rows from the table isn't going to change that. -- Alad (talk) 22:01, 13 January 2022 (UTC)

We are still removing information from the sum total of the table which does make it easier to read. Less rows makes it also easier to remove columns. Consolidating the filesystem support is a good first step I reckon.

Foxboron (talk) 22:14, 13 January 2022 (UTC)

If some boot loaders are going to be removed from the table, then I then I think they should still be listed in some way, e.g. in a list with Template:App. -- nl6720 (talk) 09:58, 14 January 2022 (UTC)

I think EFISTUB stuff should be it's own section, and we can list alternative bootloaders below the list, yes. Foxboron (talk) 10:04, 14 January 2022 (UTC)

Removal of legacy and AUR stuff from the table to relegate it to an App-formated list below seems better for legibility and makes is easier to extend if/when new bootloaders are packages in the AUR. Separating EFISTUB (and Unified kernel image?) seems logical too, since they are not directly bootloaders. What would a "consolidated" FS support column look like though ? --Erus Iluvatar (talk) 11:06, 14 January 2022 (UTC)

I think one table is better than a smaller table accompanied by a list of Apps. There is value in presenting all the information consistently, even splitting the table to two tables/sections would be equivalent to adding one extra boolean column (Is the boot loader in AUR?), but in an inconsistent way. — Lahwaacz (talk) 13:56, 15 January 2022 (UTC)

I agree. Multiple tables/lists just make it more confusing for the reader, as can be seen with the various Network configuration and Network configuration/Wireless tables. -- nl6720 (talk) 14:00, 15 January 2022 (UTC)

It seems the only consensus was on condensing where possible the columns, here's a draft below. --Erus Iluvatar (talk) 11:05, 7 September 2022 (UTC)

IMHO the information about file system capabilities/limitations should be moved to the respective boot loader wiki article to avoid losing it entirely. Also "Both" in "Partition table" is not entirely correct, there's more than two, it's just that nothing besides the two is relevant. -- nl6720 (talk) 09:31, 8 September 2022 (UTC)

Good point, I've reverted to separate MBR/GPT columns since it does not significantly change the size of the table. I'll try to update each boot loader pages when I find enough time to to so properly.

Maybe we would have enough space in the table now to add a "Full disk encryption" column now?

--Erus Iluvatar (talk) 19:03, 24 September 2022 (UTC)

"Full disk encryption" meaning dm-crypt/LUKS or fscrypt or something else? Only GRUB has limited support for LUKS and I don't think any boot loader supports fscrypt (i.e. can access encrypted directories). -- nl6720 (talk) 08:54, 26 September 2022 (UTC)

Ugh... My inexperience with encryption is showing: support for encrypted /boot I think? (What "Without encryption" in the table represents) --Erus Iluvatar (talk) 09:26, 26 September 2022 (UTC)

Oh. As the note in Arch boot process#Feature comparison says, "Without encryption" refers to fscrypt. What "without encryption" means, though, is that the boot loader cannot access an fscrypt enabled file system at all, even if the /boot directory on it is unencrypted (yes it needs to be specifically supported). At least, I think so. Or "without encryption" could mean that the boot loader does not support decrypting fscrypt, but AFAIK none of them do. -- nl6720 (talk) 09:35, 26 September 2022 (UTC)

We'll leave that can of worms for the dedicated pages then :D --Erus Iluvatar (talk) 09:46, 26 September 2022 (UTC)

Name	Firmware		Partition table		Multi-boot	File systems	Notes
Name	BIOS	UEFI	MBR	GPT	Multi-boot	File systems	Notes
EFISTUB	–	Yes	Yes	Yes	–	Inherited from firmware¹	The kernel is a valid EFI executable which can be loaded directly from the UEFI firmware with efibootmgr, or another bootloader.
Unified kernel image	–	Yes	Yes	Yes	–	Inherited from firmware¹	systemd-stub(7), a kernel, initramfs and kernel command line packed into EFI executable to be loaded directly from UEFI firmware or another boot loader.
GRUB	Yes	Yes	Yes	Yes	Yes	Built-in	See GRUB for setup-specific limitations.
Limine	Yes	Yes	Yes	Yes	Yes	Limited	No encryption support.
rEFInd	No	Yes	Yes	Yes	Yes²	Limited¹	No encryption support. Supports auto-detecting kernels and parameters without explicit configuration, and supports fastboot [1].
Syslinux	Yes	Partial	Yes	Yes	Partial	Limited	No support for encryption and certain file system features. Can only access the file system it was installed to[2].
systemd-boot	No	Yes	Manual	Yes	Yes²	Extensible^1,3	Can only launch binaries from the ESP or the Extended Boot Loader Partition (XBOOTLDR partition). Automatically detects unified kernel images placed in `esp/EFI/Linux`.
GRUB Legacy	Yes	No	Yes	No	Yes	Limited	Discontinued in favor of GRUB.
LILO	Yes	No	Yes	No	Yes	Limited	Discontinued due to limitations (e.g. with Btrfs, GPT, RAID, encryption).

File system support is inherited from the firmware. The UEFI specification mandates support for the FAT12, FAT16 and FAT32 file systems[3], but vendors can optionally add support for additional file systems; for example, the firmware in Apple Macs supports the HFS+ file system. If the firmware provides an interface for loading UEFI drivers on startup, then support for additional file systems can be added by loading (independently acquired) file system drivers.
A boot manager. It can only launch other EFI applications, for example, Linux kernel images built with CONFIG_EFI_STUB=y and Windows bootmgfw.efi.
systemd-boot supports loading UEFI file system drivers. These are provided by efifs and need to be placed into esp/EFI/systemd/drivers/.