bls: describe optional linux-appendroot key

[a3f]

The linux-appendroot key is an extension¹ to the bootloader specification implemented by barebox since 2015².

When set, it instructs barebox to generate a suitable root= command-line:

• If global.bootm.root_dev is set to a partition known to barebox, barebox will detect the file system on it and generate the suitable root command-line argument

• If global.bootm.root_dev is not set, barebox will use the file system containing the bootloader specification entries as the Linux rootfs.

The former is useful in A/B setups, where bootloader spec entries are shipped as part of an immutable partition image, which is at odds with customizing the root= option according to whether the A or B system is used.

The latter is especially useful for remote file systems like NFS or 9P: By placing bootloader specification entries directly into the rootfs, these file systems can be booted remotely by just pointing barebox at their remote path.

Describe this key in the specification with the same boolean syntax that loader.conf is using for its boolean keys.

Footnotes

1. End of https://www.barebox.org/doc/latest/user/booting-linux.html#boot-loader-specification ↩

2. https://github.com/barebox/barebox/commit/716fdbf18ca12feb81e26df729a5b8969e394e96 ↩

[a3f]

Hi, any thoughts on this? Is there a better place to discuss whether this would be an appropriate addition to the bootloader spec? Thanks!

[bluca]

Isn't this already covered by the GPT generators?

[a3f]

GPT generator can only fill out this role in the happy path:

• It requires GPT, which is not always a given. We are using bootloader spec with linux-appendroot on MBR, on NFS and on UBIFS-formatted raw NAND flash
• It requires UEFI for the LoaderDevicePartUUID variable, but UEFI is not a given on most embedded platforms yet (barebox as EFI payload does set this variable though)
• It requires an initramfs, while having the bootloader pass along the root device path it already knows doesn't

In absence of any of these, having the bootloader fix up the root= line directly is of great utility.

Thanks,

[bluca]

Sorry but I don't think it makes sense to add support for legacy things in new specifications, as it means everybody needs to support them to be compliant. Nobody should add support for MBR or BIOS these days, it's legacy stuff. It's of course fine to support them in your specific products/components if you wish to do so.

[a3f]

Sorry but I don't think it makes sense to add support for legacy things in new specifications

I wouldn't use MBR in a new project either, but you picked out just one thing in my enumeration.
The are IMHO multiple arguments that speak for linux-appendroot and MBR is just one, but by far not the most important.

To reiterate my previous point:

Not everything is

• a storage medium: cf. bootloader spec in remote file systems like NFS or 9P
• or is a disk that you would format with GPT. For raw flash, Linux would often put an UBI on top with UBI volumes (think LVM) and then a UBI file system which would contain bootloader spec entries. No MBR, no GPT.

as it means everybody needs to support them to be compliant.

As far as I know barebox is the only implementaton that implements devicetree-overlay, which is ok as it's optional. Why is the consideration different for linux-appendroot?

Nobody should add support for MBR or BIOS these days, it's legacy stuff.

We are mainly using linux-appendroot on ARM and while I look forward to have UEFI be widely available, I wouldn't equate x86 legacy BIOS with the well-supported and ubiquitous device tree oriented boot flow used on ARM .

It's of course fine to support them in your specific products/components if you wish to do so.

We already do, but for the reasons listed before, I think the change is generally useful. NFS root is not an esoteric use case and neither is not having an initramfs (or having an initramfs, but with systemd only in the "real" rootfs).

[bluca]

Not everything is

• a storage medium: cf. bootloader spec in remote file systems like NFS or 9P
• or is a disk that you would format with GPT. For raw flash, Linux would often put an UBI on top with UBI volumes (think LVM) and then a UBI file system which would contain bootloader spec entries. No MBR, no GPT.

Network boot via HTTP is supported in UEFI

As far as I know barebox is the only implementaton that implements devicetree-overlay, which is ok as it's optional. Why is the consideration different for linux-appendroot?

There's a UEFI protocol for device tree extensions

We are mainly using linux-appendroot on ARM and while I look forward to have UEFI be widely available, I wouldn't equate x86 legacy BIOS with the well-supported and ubiquitous device tree oriented boot flow used on ARM .

Device trees can be used with UEFI just fine and are in fact orthogonal - you might be thinking of ACPI, but that's completely different and separate. UEFI is supported on ARM too. Just use UEFI, adding support for legacy firmwares to this spec makes no sense, sorry.

I think the change is generally useful.

Sorry, but I just don't see how this is useful. If something can be done with UEFI, just do UEFI, as that's the present and future of firmware environments.

[a3f]

Thanks very much for your consideration. I disagree that UEFI has solved the issues. To elaborate:

Network boot via HTTP is supported in UEFI

HTTP boot does not replace NFS/9P. People use the same NFS/9P on different hosts concurrently, e.g., to reinstall cross-compiled software from a build-server and use it without reboot. HTTP boot in UEFI is not a replacement for this.

Being able to just drop in Type #1 Bootloader specification entries and be able to boot them straight feels pretty in-line with the spirit of the bootloader specification?

As far as I know barebox is the only implementaton that implements devicetree-overlay, which is ok as it's optional. Why is the consideration different for linux-appendroot?

There's a UEFI protocol for device tree extensions

If you mean the Device-Tree Fixup protocol, this is not a replacement for devicetree-overlay at all. That protocol is a way to ask the firmware, "Hey firmware, apply the changes YOU have". The devicetree-overlay key says, "Hey firmware, apply the change I have (as value to the key)".

I still see much parallels between linux-appendroot and devicetree-overlay.

We are mainly using linux-appendroot on ARM and while I look forward to have UEFI be widely available, I wouldn't equate x86 legacy BIOS with the well-supported and ubiquitous device tree oriented boot flow used on ARM .

Device trees can be used with UEFI just fine and are in fact orthogonal

"Just" is doing a lot of work here and I don't want to derail the discussion. Bootloader spec Type #1 can right now be used with device tree to build reliable systems that avoid many shortcomings of UEFI that are yet to be sorted out. One example: What happens when someone clones an embedded MMC and puts it on an SD-Card and boots with both inserted? Blame the user and boot whatever is not an acceptable option.

• you might be thinking of ACPI, but that's completely different and separate. UEFI is supported on ARM too.

I am not thinking of ACPI.

Just use UEFI, adding support for legacy firmwares to this spec makes no sense, sorry.

Device Tree only boot is not a legacy on embedded ARM systems, sorry. The traditional ARM boot flow has its fair share of historical baggage, but it's a fallacy to ignore the different historical baggage with UEFI and consider it a no-brainer "upgrade" for systems that look nothing like an IBM PC.

I think the change is generally useful.

Sorry, but I just don't see how this is useful. If something can be done with UEFI, just do UEFI, as that's the present and future of firmware environments.

I have detailed different ways this is useful and it's an optional key, of which there are others already. I am looking forward to get more hands-on experience with UEFI in unattended systems, but right now, using UEFI on the same systems, where bootloader spec with linux-appendroot is already used right now, is a downgrade in reliability.

[bluca]

I am looking forward to get more hands-on experience with UEFI in unattended systems, but right now, using UEFI on the same systems, where bootloader spec with linux-appendroot is already used right now, is a downgrade in reliability.

Sorry, but this really sounds like a solution in search of a problem. LIterally everything you said can be done just fine on UEFI. You can choose to ignore what the actual industry standard is, and stay tied to one of the several thousands bespoke and product-specific legacy solutions for your own use cases of course, but I am pretty sure this is the wrong place for any of this.

This is not a place where to go and dump every competing and slightly different implementation that might exist in any given product at any given time. It needs to fit in the ecosystem. And if it's about firmwares/bootloaders and it's not UEFI, sorry, but it just doesn't fit. Maybe in 10 years there will be a different standard for firmwares and bootloaders, but in 2025 this is the situation.

[a3f]

Sorry, but this really sounds like a solution in search of a problem. LIterally everything you said can be done just fine on UEFI.

I agree that it can be done differently using UEFI, but it comes with shortcomings of which I have described some.

You can choose to ignore what the actual industry standard is, and stay tied to one of the several thousands bespoke and product-specific legacy solutions for your own use cases of course, but I am pretty sure this is the wrong place for any of this.

I took much of your time already but I'd very much appreciate to learn about what state-of-the-art UEFI provides to workaround the limitations I listed.

While most my work is ARM with no UEFI, I have worked on x86 projects with UEFI as well and what I described pretty much applied there too to the best of my knowledge.

This is not a place where to go and dump every competing and slightly different implementation that might exist in any given product at any given time. It needs to fit in the ecosystem. And if it's about firmwares/bootloaders and it's not UEFI, sorry, but it just doesn't fit.

I understood the scope of the specification to be pragmatic about limitations. EFI variables are a staple, but yet they have reliability issues, so you do renames on the FAT¹. Similarly, EFI has limitations that linux-appendroot can address.

Maybe in 10 years there will be a different standard for firmwares and bootloaders, but in 2025 this is the situation.

It's unfortunate that our discussion took the turn of pitting UEFI against something else. To make my point clear: The issue is not limited to UEFI, it applies equally to UEFI and UEFI doesn't solve it AFAIK.

If you can point out where my thoughts gone wrong or just tell me to go implement a UEFI protocol that brings the reliability guarantees linux-appendroot could provide, I will not keep wasting your time further, but I would find it much unfortunate to have our discussion stall without each of us having understood what the other is trying to convey.

Thanks again for your prompt reply to my ping and for your continued feedback. The PR either gets better with a more coherent argument in favor of it or I (and whoever reads this) can learn what should be done instead for new projects.

Footnotes

1. I wonder if this is a 100% safe thing to do in absence of a journal with the mixed quality of the UEFI fimware's filesys implementation, but I digress ↩