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

Davide Bettio davide.bettio at secomind.com
Wed Mar 23 12:38:19 UTC 2022


Hello,

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

> On Mi, 23.03.22 10:51, Davide Bettio (davide.bettio at secomind.com) wrote:
>
> Well, if the distribution people build both packages and disk images,
> they can set IMAGE_ID/IMAGE_VERSION for the latter. But this should
> always be part of building images, not of building packages.
>
> > Can I safely just append those fields at the end of
> > the copy of the /etc/os-release file?
>
> That's the idea: take the packages, build an image, and then append
> IMAGE_ID/IMAGE_VERSION to it?
>

Sure, sounds pretty convenient, here my point was about blindly appending
those additional fields (trusting the distribution didn't already set
them).


> > Speaking of BUILD_ID, according to the spec sounds like a field
> > reserved to
>
> BUILD_ID? That's a different thing...
>
> https://www.freedesktop.org/software/systemd/man/os-release.html#IMAGE_ID=
> vs.
> https://www.freedesktop.org/software/systemd/man/os-release.html#BUILD_ID=
>
> > distributions: "BUILD_ID may be used in distributions where the original
> > installation image version is important", from my side what I need is to
> > identify the git revision + build date of the recipe I'm using to cook
> the
> > image installed on the system, also my plan is to change that ID every
> time
> > I cook a new image, furthermore I plan to replace the whole operating
> > system image (that I keep read-only) in order to update it, so BUILD_ID
> > would change at every update (so it sounds slightly different from the
> > original described semantic).
>
> BUILD_ID is not for that. You are looking for IMAGE_VERSION.
>

IMAGE_VERSION didn't look to me a good option for identifying nightly
builds, or any kind of build that wasn't cooked from a tagged image build
recipe.
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).
Here my aim was to provide a way to find which build recipe revision has
been used or when an image has been built, that is also useful when
debugging a device.

> Last but not least, I was looking for a machine parsable unique id, so I
> > plan to use BUILD_UUID if it is not kept reserved for other usages, that
> > will be an UUID that is freshly generated every time I cook a new image.
>
> What's this for?
>

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.
Compared to other options an UUID here would be both reliable and easy to
handle and generate.
Thanks again for the kind and helpful conversation,
regards,
Davide Bettio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20220323/273148e8/attachment.htm>


More information about the systemd-devel mailing list