ci: Use mkosi sandbox to run the integration tests

Using mkosi sandbox allows all the tools for the test logic themselves
to be executed from the tools tree as well.

tests: Setup logging properly

tests: Always pass process environment to mkosi

Let's not override the entire environment when we need some extra
environment variables.

tests: Do not register test containers/vms with systemd-machined

tests: Remove privilege dropping for image builds

This just does not work reliably at all. We change uid/gid but keep
all the environment variables which is just a recipe for issues. Let's
enforce running everything as root if one wants to run the tests that
require root privileges.

Move uid check back to have_cache()

We moved this to reuse_cache() before the introduction of mkosi-sandbox
because we would change uids during execution. Now that we don't do that
anymore, we can move the check back to have_cache().

ci: Centralize package installation in unit-tests job

Also get rid of the microsoft-prod.list hack by just not running
apt-get update anymore which avoids the need to remove the microsoft
repositories.

ci: Move grub2 for opensuse to mkosi tools tree packages

ci: Add centos tools tree CI

ci: Re-enable Arch with ubuntu tools build

Now that we'll fetch a recent keyring, we can re-enable this specific
combo

tests: Skip booting from directory in user namespace with single user

We need newuidmap/newgidmap to be able to boot from a directory which
can't ever work in a user namespace with a single user so skip the
test in that case.

action: Only install package managers and debian-keyring

Instead, let's recommend users to use the default tools tree to get
their dependencies which is generally recommended as it reduces their
dependencies on what's installed on the host system.

centos: Install erofs-utils in tools tree

mkosi-tools: Install systemd-ukify on Azure, CentOS and Fedora

systemd-ukify is not architecture dependant anymore so let's always
install it. It's also packaged in CentOS Stream and Azure Linux so
let's install it there as well.

mkosi-tools: Fix architecture condition

We need to match the architecture of the tools tree we're building,
not the host architecture. In practice these will always be the same
so this doesn't actually change behavior.

Make mkosi available inside mkosi sandbox via zipapp

Currently, mkosi has to be installed outside of /usr when using a
tools tree with mkosi sandbox to make it available inside mkosi
sandbox. Let's remove this restriction by packaging up the host's
mkosi as a zipapp and making the zipapp available in the sandbox.

Remove mkosi.types to avoid conflict with standard library types.py

The process related stuff is moved to run.py and the rest is moved
to util.py

Special case tools image in keyring_cache() and metadata_cache()

Similar to cache_tree_paths(), give the metadata and keyring cache
for the default tools tree a custom name to avoid conflicts with the
other image caches.

Move keyring_cache() and metadata_cache() next to cache_tree_paths()

Make Register= a feature

By default, we want to register if machined is available and not
otherwise so let's make Register= a feature that defaults to "auto".

Rework crypto-policies again

Currently, we only write our own rpm-sequoia crypto policy if one
isn't provided by the tools tree. However, the centos stream 10 crypto
policy is restrictive enough that we can't build older centos releases
or opensuse images with it.

To fix this, let's switch things around again and go back to copying
the crypto policy from the tools tree into the sandbox tree and modifying
the rpm-sequoia policy to fit our needs. For mkosi sandbox, we do reuse
the crypto policies from the tools tree unmodified.

Note that we copy from /usr/share/crypto-policies/DEFAULT instead of
/etc/crypto-policies, as when using mkosi sandbox, we get
/etc/crypto-policies from the host which is full of symlink's to the host's
/usr, even if the tools tree might not be using crypto policies at all.

We also rename finalize_crypto_mounts() to finalize_certificate_mounts()
as it only handles certificates now.

appease spellchecker

Use Initrds= for qemu direct kernel boot as a fallback

Fixes #3180

docs: Make more clear that the SHA256SUMS is prefixed with the output

Fixes #3027

Merge pull request #3397 from DaanDeMeyer/signed

Add support for pre-signed Bootloader variants without shim

Parse mkosi.profiles in included configuration

Fixes #3174

Add support for pre-signed Bootloader variants without shim

Currently we only pick up pre-signed bootloader binaries if
ShimBootloader=signed is configured. Let's also add support for
installing pre-signed bootloader binaries without using shim.

Drop out of date paragraph about not installing grub for EFI

Merge pull request #3395 from DaanDeMeyer/addon

kernel-install: Various fixes

mkosi-initrd: Simplify

kernel_image is not optional so get rid of the if check.

mkosi-initrd: Add extra logging to kernel-install plugin

mkosi-addon: Skip if provided kernel image is not a UKI

Reduce duplication between mkosi-initrd and mkosi-addon

Simplify KernelInstallContext.parse() a little

qemu: Look for /usr/libexec/qemu-kvm as well

On CentOS Stream, only /usr/libexec/qemu-kvm is available.

Skip firmware descriptions without nvram-template

Merge pull request #3393 from behrmann/addonfixups

Addon fixups

man: Move plugin sections under the kernel-install section

man: Generate mkosi-addon man page as well

Add mkosi-addon and kernel-install plugin

Add new mkosi-addon and kernel-install plugin to build local
customizations into an EFI addon.

This allows us to move closer to the desired goal of having
universal UKIs, built by vendors, used together with locally
built enhancements.

Use $HOME in current_home_dir() regardless of whether we're in it or not

If $HOME is set, let's always use it as a fallback if we're not running
from a home directory.

Enforce that images with Overlay=yes only add files

Any extension images built with Overlay=yes should never override
files in the base image, so let's add some enforcement to make
sure that's the case by automatically removing files that already
exist in the base image.

Revert "action: Fix up $PATH as a workaround"

Issue was fixed in a new image.

This reverts commit 49832f6c2af0f7ef0a458d1e0795ad1854ecd863.

Use os.walk() to remove empty directories

mypy: enable scripts_are_modules

Otherwise mypy errors on type checking multiple kernel-install
scripts in kernel-install/.

Merge pull request #3386 from DaanDeMeyer/addon-initrd-empty

addon: Don't add initrd section if buildroot is empty

Run modinfo from the tools tree when building a standalone extension image

If we're building a standalone extension image, modinfo won't be
installed in the image buildroot, so run modinfo from the host
instead.

Pass in Context to functions in kmod.py

Preparation for the next commit.

Improve formatting of filter_kernel_modules()

addon: Don't add initrd section if buildroot is empty

Don't remove root directory when removing empty directories

ci: Make kernel-install script checks more generic

Let's check all .install scripts in the kernel-install directory.

Make sure addon initrds are compressed as well

Inverse output format check for run_shell()

Make use of use_outer_compression() more

Remove empty directories from extension images

Don't check for populated OS root if Format == none

Let's skip checking if the OS root is populated if Format == none
so that Format=none and Distribution=custom can be used to execute
arbitrary code in a build script without actually building an image.

Allow adding kernel modules in extension images

When building standalone extension images (without Overlay=yes),
let's process kernel modules but not run depmod. depmod produces a
single monolithic file which means we can't extend it from an
extension image without overriding the base file.

Merge pull request #3378 from DaanDeMeyer/addon

Add kernel command line to addon

Add kernel command line to addon

Let's allow adding making more than just initrd addons.

Rename initrd-addon to addon

Add ToolsTreeRelease= match

Update NEWS

Merge pull request #3373 from DaanDeMeyer/centos

centos: epel-next does not exist anymore since CentOS Stream 10

centos: epel-next does not exist anymore since CentOS Stream 10

Detailed in https://discussion.fedoraproject.org/t/epel-10-proposal/44304.

centos: Bump default image to CentOS Stream 10 as well

action: Fix up $PATH as a workaround

Can be removed once https://github.com/actions/runner-images/issues/11414
is addressed.

Merge pull request #3371 from DaanDeMeyer/cache

Cache package manager in cache manifest again

Add package manager back to the cache manifest

As detailed in the previous commit, it's important to cache the
package manager used in the cache manifest. If we don't, we'll end
up reusing the wrong metadata cache which won't have any metadata in
it for the new package manager.

Rebuild default tools tree before cleaning up other images

It turns out we have to put the used package manager in the cache
manifest as the metadata cache needs to be refreshed if the package
manager used changes, otherwise the metadata cache will be reused but
the new package manager won't actually be able to find any metadata
since the metadata cache contains metadata for another package manager.

To avoid running into all the problems we had previously trying to do
this, we have to make sure that the default tools tree is always available
whenever we run have_cache() on a (non-default tools tree) image, so that
the package manager we decide to use to build the image is always the same.

To achieve that, we make sure to rebuild the tools tree before doing checks
and cleaning up other images when doing a regular build. This means whenever
we call have_cache() the default tools tree will be available if it is used.

Improve cache manifest mismatch logging message

fedora: Use a lower repository metadata expire time for rawhide

Let's mimick Fedora's own rawhide repository configuration and use
a metadata expire time of 6h when building rawhide images so that
we don't end up keeping stale repository metadata around for too
long which will result in dnf being unable to find certain packages
as they will have been replaced by a newer version in rawhide already.

Bump Arch initrd size again ...

Seems like Arch is gaining a lot of weight lately in it's core
packages.

Merge pull request #3368 from DaanDeMeyer/epel

Various CentOS Stream improvements

centos: Enable EPEL for c10s tools tree as well

Now that EPEL exists for c10s, let's enable it for the c10s tools
tree as EPEL has distribution-gpg-keys which is crucial to be able
to use c10s as a tools tree.

Look for the CentOS Stream official GPG in /etc/pki/rpm-gpg as well

Turns out the key names in /etc/pki/rpm-gpg are slightly different
so let's update the logic to search properly for both.

Only use a fallback in find_rpm_gpgkey() if one is defined

Improve find_rpm_gpgkey() declaration formatting

Fix type of second overload of find_rpm_gpgkey()

The return type is optional when we get any boolean that's not a
literal True, so widen the type to bool to fix that.

action: Stop populating pacman keyring

Not required anymore now that mkosi does this itself.

Merge pull request #3366 from DaanDeMeyer/keyring

Add a keyring cache and use it for Arch Linux

Add a keyring cache and use it for Arch Linux

Currently, the Arch keyring from the host or tools tree is always
used directly without any option to modify it (except by modifying
it directly on the host or in the tools tree). We also don't support
RepositoryKeyFetch= for the Arch Linux keyring and it's one of the
sources of annoying mounts outside of /usr which complicates
"mkosi sandbox".

Let's improve the situation by switching to our own pacman keyring
instead of using the one from the tools tree or host. Instead, we'll
only use /usr/share/pacman/keyrings from the host or tools tree to
populate the keyring we maintain ourselves. Users can extend the
keyring created by mkosi with their own keys via sandbox trees. If
RepositoryKeyFetch= is enabled, we'll download the archlinux-keyring
package and extract the keyring from there into the sandbox.

The keyring cache is maintained together with the repository metadata
cache. The only difference is that sync_repository_metadata() will
update the global package cache whereas the keyring directory is always
maintained per cache directory instead of globally.

We take the opportunity to stop using Michel's kernel-utils ppa with a
more recent archlinux-keyring package in favor of enabling
RepositoryKeyFetch= by default for Arch builds on Ubuntu.

sandbox: Use dict to store bind mounts instead of set

dict guarantee iteration in insertion order, set does not which matters
in this specific case.

Introduce support for overriding system's DeviceTree

While experimenting with OS images on development boards where either
the bootloader doesn't load a Flattened DeviceTree Blob, or if one wants
to replace the one provided by the bootloader with a specific/new one
for development/experimentation/testing purposes, it's convenient to use
the OS-loaders ability to load a specific DeviceTree blob.

Add a new option to mkosi, to cause a specified DeviceTree blob to be
baked into the UKI, or copied into /boot and added to the systemd loader
entry.

As different distributions store the dtb files in different locations
the requested file is searched for in the locations spotted in Debian,
Fedora, Arch Linux packages (both from distro and kernel build system -
as these differs as well).

Resolves #2439
Based on initial effort by Manuel Traut.

Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>

Add support for machined registration using varlink

Add missing parentheses to make sure we don't throw away scope for virtiofsd

Merge pull request #3363 from DaanDeMeyer/sandbox

sandbox: Make terminal background color cyan if on tty

sandbox: Don't allow nested mkosi sandbox invocations

Until a good usecase pops up it's probably best to disallow this since
when it happens it's most likely a user error rather than intended.

sandbox: Drop tools tree in run_verb() instead of when parsing config

Another change to make mkosi sandbox in and outside the sandbox identical.

sandbox: Make terminal background color cyan if on tty

Let's make the sandbox more recognizable by turning the terminal
background cyan if on a tty.

Use MKOSI_HOST_DISTRIBUTION in config_default_tools_tree_distribution()

It doesn't really matter since we won't use the tools tree in the
sandbox anyway but this reduces the diff between mkosi summary outside
and inside the sandbox.

centos: Bump default release to 10

Make sure we use the same host distribution/release in sandbox

If the distribution is not explicitly specified in the config file
and the host distribution does not match the tools tree distribution,
then currently mkosi -f sandbox mkosi -f and mkosi -f will build images
for different distributions.

Let's make sure these commands use the same default distribution by
communicating the host distribution and release to the sandbox via
environment variables and using them to determine the default values to
use if available.

Only add keylayouts to grub image on x86

Update NEWS

Make grub EFI logic architecture independent

Fixes #3352

sandbox: Slight optimization

Bind mount /dev/fuse in sandbox

/dev/fuse is needed to support building container images from within the
mkosi.build scripts. Make it avaiable in the sandbox just like /dev/null
and its friends.

Since not all mkosi builds runs in host contexts where /dev/fuse is
actually available, update the logic to skip the /dev/fuse node if it is
not present.

Only use extra search paths when running in sandbox

Since ExtraSearchPaths= might be built within the sandbox, we have
to make sure that we're in the sandbox when potentially executing
binaries from ExtraSearchPaths=. This was almost always the case,
except when setup= was used when constructing the sandbox, as the
command in setup= is executed outside of the sandbox.

To fix this we also had the option to remove the setup= argument
from sandbox_cmd() and execute the command from setup= within the
sandbox as well, but this would mean the synchronization mechanism
we added in https://github.com/systemd/mkosi/pull/3298 to make sure
we don't register vms with machined before the scope is started would
stop working, so for now we keep setup= and instead make sure we don't
use paths from ExtraSearchPaths= when executing the commands in setup=.

Implementation wise, we get rid of modifying mkosi's own $PATH to append
the extra search paths, and instead construct the proper $PATH in
sandbox_cmd().

Because we get rid of prepend_to_environ_path(), we also get rid of
the logic to construct a separate directory for any files listed in
ExtraSearchPaths=, but this logic turned out to be undocumented and
broken because the separate directory we add to $PATH wasn't mounted
into the sandbox so since this logic was always broken and nobody ever
complained we opt to remove it here to keep the implementation simple.

apt: avoid ?exact-name for systemd packages

There is a strange interaction between ?exact-name, apt repositories
generated by OBS and multiple architectures, that breaks installing
packages:

$ apt install --dry-run '?exact-name(systemd-cryptsetup)'
NOTE: This is only a simulation!
      apt needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!

systemd-cryptsetup is already the newest version (257.999+731+g8c5b35957-0).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

Unsatisfied dependencies:
 systemd-cryptsetup : Conflicts: systemd-cryptsetup:i386 but 257.999+731+g8c5b35957-0 is to be installed
                      Conflicts: systemd-cryptsetup:arm64 but 257.999+731+g8c5b35957-0 is to be installed
 systemd-cryptsetup:i386 : Conflicts: systemd-cryptsetup but 257.999+731+g8c5b35957-0 is to be installed
                           Conflicts: systemd-cryptsetup:arm64 but 257.999+731+g8c5b35957-0 is to be installed
 systemd-cryptsetup:arm64 : Depends: libc6:arm64 (>= 2.38) but it is not installable
                            Depends: libcryptsetup12:arm64 (>= 2:2.7) but it is not installable
                            Depends: libssl3t64:arm64 (>= 3.0.0) but it is not installable
                            Depends: libsystemd-shared:arm64 (= 257.999+731+g8c5b35957-0) but it is not going to be installed
                            Conflicts: systemd-cryptsetup but 257.999+731+g8c5b35957-0 is to be installed
                            Conflicts: systemd-cryptsetup:i386 but 257.999+731+g8c5b35957-0 is to be installed
Error: Unable to correct problems, you have held broken packages.

It seems ?exact-name selects _all_ available packages, unless an architecture
is specified:

$ apt install --dry-run '?exact-name(systemd-cryptsetup:amd64)'
NOTE: This is only a simulation!
      apt needs root privileges for real execution.
      Keep also in mind that locking is deactivated,
      so don't depend on the relevance to the real current situation!

Summary:
  Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0

But this only happens with the repository metadata format generated
on OBS. There are multiple formats, apparently.

https://download.opensuse.org/repositories/home:/bluca:/systemd/Debian_Testing/

So either we set the specific architecture in the common mkosi.conf,
or we need a separate mkosi.conf with a trigger to filter out releases
where the packages are not available.
I chose the latter as it the filters are fixed, while adding by architecture
means every time a new arch is added, it needs to be duplicated.

This is only necessary for packages that are hosted on OBS, ie: the
systemd ones.