[systemd-devel] Antw: [EXT] Re: /etc/os-release but for images

[Ulrich Windl]

>>> Davide Bettio <davide.bettio at secomind.com> schrieb am 23.03.2022 um 17:14 in
Nachricht
<CAAWU5L4QgZrNnCU15iSyumu4ThDxa-_cK49FBP8H0+tcvOYfLg at mail.gmail.com>:
> 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.

I wonder: Why not simply an md5sum over the image (or you favourite checksum)?
Does the same UUID really imply the image is the same? Likewise what about different UUIDs?

Regards,
Ulrich

> 
> 
>>
>> > 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.