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)
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)
- 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)
- 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)
|Name||Firmware||Partition table||Multi-boot||File systems||Notes|
|EFISTUB||–||Yes||Both||–||Inherited from firmware1||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||Both||–||Inherited from firmware1||, 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||Both||Yes||Built-in||See GRUB for setup-specific limitations.|
|Limine||Yes||Yes||Both||Yes||Limited||No encryption support.|
|rEFInd||No||Yes||Both||Yes2||Limited1||No encryption support.|
Supports auto-detecting kernels and parameters without explicit configuration, and supports fastboot .
|Syslinux||Yes||Partial||Both||Partial||Limited||No support for encryption and certain file system features.|
Can only access the file system it was installed to.
|systemd-boot||No||Yes||Officially GPT only||Yes2||Extensible1,3||Can only launch binaries from the ESP or the Extended Boot Loader Partition (XBOOTLDR partition).|
Automatically detects unified kernel images placed in
|GRUB Legacy||Yes||No||MBR only||Yes||Limited||Discontinued in favor of GRUB.|
|LILO||Yes||No||MBR only||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, 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
- systemd-boot supports loading UEFI file system drivers. These are provided by and need to be placed into
Clarify what "the BIOS boot partition (GRUB on BIOS/GPT only)." means
Small comment as an unexperienced reader - it's unclear what exactly "the BIOS boot partition (GRUB on BIOS/GPT only)." means under the list of places that the second stage of the bootloader can be loaded? Does it mean that GRUB is the only bootloader that supports reading from the BIOS boot partition?
- Would "the BIOS boot partition (only with GRUB on BIOS/GPT)." be less ambiguous?
- A "BIOS boot partition" is the GRUB-specific way to handle the pairing of a GPT partition table on a machine with a BIOS.
- --Erus Iluvatar (talk) 17:31, 9 September 2022 (UTC)