<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">Hello,</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">First of all, thanks for your answers.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">It wasn't really clear to me that the /etc/os-release file was editable from a 3rd party other than the distribution maintainers, so thanks for the clarifications. Are the distributions required to leave IMAGE_ID and IMAGE_VERSION empty? Can I safely just append those fields at the end of the copy of the /etc/os-release file?</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Speaking of BUILD_ID, according to the spec sounds like a field reserved to distributions: "<code class="gmail-varname">BUILD_ID</code> 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).</div><div class="gmail_default" style="font-family:monospace,monospace">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.<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Regards,</div><div class="gmail_default" style="font-family:monospace,monospace">Davide Bettio.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno mar 22 mar 2022 alle ore 18:09 Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Di, 22.03.22 17:10, Davide Bettio (<a href="mailto:davide.bettio@secomind.com" target="_blank">davide.bettio@secomind.com</a>) wrote:<br>
<br>
> Hello,<br>
><br>
> I would like to figure out if anyone has proposed any kind of standard for<br>
> storing metadata about a system image.<br>
<br>
The IMAGE_ID= and IMAGE_VERSION= fields from /etc/os-release are<br>
supposed to be used for that.<br>
<br>
i.e. the idea was that you can take a generic distro (fedora, debian,<br>
…) build an image off it, and it will put its own os info in<br>
/usr/lib/os-release, and make /etc/os-release a symlink to it. Your<br>
image build would then replace /etc/os-release with a file, that<br>
incorporates /usr/lib/os-release and adds in IMAGE_ID=/IMAGE_VERSION=.<br>
<br>
Each time you rebuild the image your image building tool would repeat<br>
that step. i.e. it would be the image builder tool's job to extend the<br>
generic OS data from /usr/lib/ with info about the image and place the<br>
result in /etc/.<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div>