Pass variables with host properties to scripts

[davide125]

mkosi commit the issue has been seen with

main

Used host distribution

Fedora Linux 41

Used target distribution

Fedora Linux 41

Linux kernel version used

No response

CPU architectures issue was seen on

None

Unexpected behaviour you saw

It would be useful to know the host distribution, release and architecture when inside scripts such as mkosi.sync; while detection is easy enough to reimplement, mkosi is already doing it and uses a consistent format (e.g. it always refers to aarch64 as arm64). For these, I'd suggest adding $HOST_DISTRIBUTION, $HOST_RELEASE, $HOST_ARCHITECTURE. It would also be useful to have a $MKOSI variable pointing to the mkosi binary, so that if one needs to run mkosi from inside one of the scripts it'll be guaranteed to be the same version.

Used mkosi config

No response

mkosi output

No response

[septatrix]

What is you use case - should this also apply to the tools tree distro?

[davide125]

In https://github.com/davide125/arcadeos/blob/66435dd4328aa16fc8d58b98e379a7ef3640d975/mkosi.sync I'm building systemd inside mkosi.sync; this is done by calling mkosi, and it would be good to ensure it's the same mkosi that's running one level up (hence the $MKOSI variable suggestion). As for the host distribution variables, in this scenario the inner mkosi build (for the "host" systemd) ends up building a tools tree, and I would like to ensure it's always targeting the host distribution and release (right now e.g. it will build debian testing when run on ubuntu, which seems to be fine in practice, but IMO is a needless deviation).

[davide125]

And to elaborate, IMO $HOST_DISTRIBUTION and friends should always be the actual host, regardless of whether a tools tree is in play; we should add a separate set for the tools tree (say, $TOOLS_TREE_DISTRIBUTION etc) if that's desired.

[septatrix]

Not quite sure why you need to build systemd for the host and the target but I assume you will have your reasons. For now a workaround could be to mount your host's os-release under a different path as a build source and source it inside your script. Mkosi, I think, will always refer to the same binary as you invoked it with (maybe unless you install a mkosi on the tools tree, not sure about that)

[DaanDeMeyer]

It would also be useful to have a $MKOSI variable pointing to the mkosi binary, so that if one needs to run mkosi from inside one of the scripts it'll be guaranteed to be the same version.

Providing $MKOSI is very hard, because we'd need to also make sure to provide all the associated python modules, it's not a single script/binary that we can just mount into the sandbox, which we'd need to do since mkosi might be a distribution package and installed into /usr which would be replaced entirely if a tools tree is used.

Not quite sure why you need to build systemd for the host and the target but I assume you will have your reasons.

Not that far fetched, you might want a new systemd in the image and use e.g. UKI profiles which require a very new ukify on the host.

I'd suggest adding $HOST_DISTRIBUTION, $HOST_RELEASE, $HOST_ARCHITECTURE.

We already make the entire mkosi config available via MKOSI_CONFIG as a json file that can be easily parsed with jq, that should provide the necessary information. It's not as easy as environment variables, but this is niche enough that it doesn't warrant separate environment variables I think.