Re: systemd-nspawn container not starting on RHEL9.0

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mi, 03.08.22 15:40, Thomas Archambault (toma@xxxxxxxxxxxxxxxxx) wrote:

> Good day everyone on the dev list,
> We are adding an analysis tool to our application that uses the host's
> rootfs as one of its inputs.
>
> As a proof of concept, we used systemd-nspawn on Fedora 34 to create an
> isolated container environment using the host's rootfs as the container's
> rootfs and things worked correctly and as expected. The host's rootfs is
> analyzed with tmp and results files generated within the container without
> persistent modifications affecting the host's rootfs. Since RHEL is our
> ultimate target platform, I've been trying to duplicate our work over
> RHEL9.0 without success with the container not being instantiated.
>
> I've tried to boil down the duplication code to the simplest example, which
> is also an example in the man page $ sudo systemd-nspawn -xbD/. As with my
> prototyping, the container does not seem to be instantiated.
> Any help with troubleshooting, or specific known issues, or requests for
> more data would be appreciated.

"-x" is ephemeral mode. This means nspawn will make a copy of the OS
tree before booting into it, and remove it afterwards.

"-x" on btrfs is very fast and space efficient, because btrfs supports
both snapshots and reflinks. nspawn will make a subvol snapshot if the
root you specify is a subvol. It will make reflink-based file copies
otherwise.

Other file systems have a more 1990's feature set, i.e. no reflinks
nor snapshots. (modern xfs on very new kernels can support reflinks if
this is opt-in'ed to.) In that case we have to copy the data files
with their contents, and that's slow.

Hence, what backing fs do you use?

if you use non-btrfs it might hence simply be that we are busy
individually copying all files...

Lennart

--
Lennart Poettering, Berlin