[systemd-devel] /etc/os-release but for images

[Davide Bettio]

Hello,

Il giorno mer 23 mar 2022 alle ore 13:56 Lennart Poettering <
lennart at poettering.net> ha scritto:

> > Also sadly IMAGE_VERSION doesn't allow + which is used from semver for
> > build metadata (such as 1.0.0+21AF26D3 or 1.0.0+20130313144700).
>
> Ah, interesting. This looks like something to fix in our syntax
> descriptio though. I am pretty sure we should allow all characters
> that semver requires.
>
> Can you file an RFE issue about this on github? Or even better, submit
> a PR that adds that?
>

I opened this PR: https://github.com/systemd/systemd/pull/22841

This doesn't enable full semver support since that would require allowing
A-Z range, but I'm not sure if it is something we really want to enable
(uppercase in semver looks quite uncommon by the way).

That said, I'd always include some time-based counter in automatic
> builds, so that the builds can be ordered. Things like sd-boot's boot
> menu entry ordering relies on that.
>

This is indeed a good advice.


> > That's pretty useful when storing a relation between the exact update
> > bundle that has been used to flash a device, and the system flashed on a
> > device. It turns out to be pretty useful when collecting stats about a
> > device fleet or when remote managing system versions and their updates.
> > So what I would do on os-release would be storing an UUID that is
> generated
> > every time a system image is generated, that UUID can be collected/sent
> at
> > runtime from a device to a remote management service.
>
> Why wouldn't the IMAGE_VERSION suffice for that? Why pick a UUID where
> a version already works?
>
I would use the UUID as a further metadata in addition to IMAGE_VERSION,
also for the reasons I describe later here in this mail.


>
> > Compared to other options an UUID here would be both reliable and easy to
> > handle and generate.
>
> UUID is are effectively randomly generated. That sucks for build
> processes I am sure, simply because they hence aren't reproducible.
>

Using a reliable digest, such as the one that can be generated with `casync
digest`, was my first option, however if you think about an update system
such such as RAUC and its bundles, you might still have the same exact
filesystem digest mapping to a number of different bundles, since they can
bring different hook scripts and whatever.
I'm also aware of scenarios where the same filesystem tree has been used to
generate different flash images in order to satisfy different flash sizes /
NAND technologies.
So from a practical point of view having an UUID, and forcing a different
one in /etc/os-release every time a filesystem image / RAUC bundle is
created allows us to have a reasonable 1:1 mapping between the update
artifact and the system image that is on the device.
Last but not least having it in /etc/os-release makes it pretty convenient
to read it (and for sure using an UUID is easier than trying to embed the
digest of the filesystem where  /etc/os-release is kept ;) )
Also there is an interesting bonus: UUID is globally unique also in
scenarios where users try to delete and recreate version tags without
incrementing the version number (or other messy scenarios).

BTW, there's now also this:
>
> https://systemd.io/BUILDING_IMAGES/#image-metadata
>

Thanks, this feature looks pretty interesting.

Regards,
Davide Bettio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220323/4d7fdcd9/attachment-0001.htm>