Talk:Arch boot process

From ArchWiki

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)

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 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 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 [1].
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[2].
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 esp/EFI/Linux.
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).
  1. 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.
  2. 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.
  3. systemd-boot supports loading UEFI file system drivers. These are provided by efifs and need to be placed into esp/EFI/systemd/drivers/.

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?

Gloomy (talk) 17:16, 9 September 2022 (UTC)

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)
Special:Diff/745524 should clarify this. -- nl6720 (talk) 07:26, 10 September 2022 (UTC)