Proposal to add the boot loader specification to add a generic metadata key.

[jmarrero]

We are exploring ways to add metadata to capture state related to an OSTree deployment. The conversation background can be seen at: ostreedev/ostree#3032.

The most recent idea is to add extra data to the boot loader entry, as it seems like a valid place to keep track of deployment-specific metadata. An example of this is recording the last time and first time a specific entry was booted. We can also see tools like https://github.com/fedora-iot/greenboot adding other specific metadata that they could use to track when to discard a deployment.

Looking at https://uapi-group.org/specifications/specs/boot_loader_specification/, we wonder if we could extend the specification to add a generic metadata key.

It does seem like using the boot loader entry as the source of truth is compatible with what https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/ is doing too.

[poettering]

The most recent idea is to add extra data to the boot loader entry, as it seems like a valid place to keep track of deployment-specific metadata. An example of this is recording the last time and first time a specific entry was booted. We can also see tools like https://github.com/fedora-iot/greenboot adding other specific metadata that they could use to track when to discard a deployment.

what precisely do you want to track there? why do the timestamps matter, and why would you put something you need to regularly update like that inside the .conf files?

The boot counting logic systemd is using is carefully designed to never have to rewrite files, because fs drivers in firmware are generally not great. hence we stuffed it in the fnames, so they quite likely can be implemented via single sector writes, and do not require use of allocation algorithms (which is what is too hard for firmware to get right).

that said type1 files are supposed to be extensible, just add any keys you like, just prefix them with "x-foobar-" or so, to avoid collisions. I don't think there's a point in adding multiple levels of key/value pairs.

[cgwalters]

There is a lot of overlap with the boot counting spec, which we are also looking at integrating with.

why do the timestamps matter, and why would you put something you need to regularly update like that inside the .conf files?

The timestamps would be useful for the same reason the timestamps in journalctl --list-boots are useful in general (but we want to support systems with a transient journal).

that said type1 files are supposed to be extensible, just add any keys you like, just prefix them with "x-foobar-" or so, to avoid collisions. I don't think there's a point in adding multiple levels of key/value pairs.

Right, I think it'd just be useful to add that suggestion to the spec, and we should also note that implementations should aim to preserve unknown keys where it makes sense (e.g. tooling that mutates kernel arguments).

[poettering]

yeah, it would make sense to formalize the x-foobar- thing in the spec.