Let's define a clean way how we can reestablish file watches in homed.
This is a relevant in case we overmount /home/ as a whole. It's very
useful for our testcase in particular.
When unregistering a home there's a chance this "reveals" another home
by the same name in /home/, hence immediately schedule a rescan, the
same way we already schedule it in on remove.
Also, drop the conditionalization when scheduling a rescan during
remove, for the same reasons: a remove might reveal another home, and we
cannot check for that ahead of time. Trying to check is kinda a
pointless optimization anyway, since this is not a frequent operation
and rescanning is not the end of the world.
Currently homed scans /home/ via inotify for new .home + .homedir/
popping up to register as local users. Let's also add an explicit way to
request this form of "adoption": a bus call that takes a path and that
makes a home dir activatable locally.
(Usecase: you cross boot between two systems – let's say your traditional
fedora and your ParticleOS – and want to use the same homedir from both:
simply mount the /home dir from the other somewhere, and then hit
"homectl adopt /somewhere/lennart.home" and you have the user locally
too).
Since this only covers user creation/registration for now, let's hide it
behind an env var. We might reconsider this eventually and make it a
proper switch one day, but who knows, it after all has this "debug tool"
wiff.
The transient one is generally the more relevant one, since it is
typically used to reach this host remotely, and it's what shells show
you. Hence show it first.
Strictly speaking we don't need to tag these devices, because tpm2-tss
already does so, but given we do this for /dev/tpmrm0, we should
probably do this comprehensively if we rely on this ourselves.
Fixes: #36653
None of the package specs leave leftover files in the source directory
anymore, so let's stop using BuildSourcesEphemeral=yes and check in CI
that we don't regress.
Let's stop using BuildSourcesEphemeral= and instead make sure we don't
generate any auxiliary files during the mkosi build process.
We achieve this through a combination of trap to remove any new files
we create and bind mounts from /tmp over existing files whenever we need
to modify an existing file.
We also add a CI step to ensure we don't regress
Currently, if you boot PID 1 in a container you always see a complaint
that BPF LSM won't work. That's fine, and log worthy, but probably not
above debug level. After all this is a really common case, and we should
gracefully adopt to our execution environment.
* 38b41a729e Clean up debuginfo files as well in %clean
* 7bc5883654 Fix missing question mark
* d22561d59e Also drop auxiliary files related to sysusers compat
* e825459f2d Change python-zstd depenedency to python-zstandard
* 0a3907745e Version 257.4
* 1bdfa29ce2 Neuter sysusers macros
Boolean values have to be handled separately for RestrictNamespaces=
because
they get stored in a field with reverse meaning (which namespaces are
retained),
so let's check which field we're parsing and set the proper value
accordingly.
https://github.com/systemd/systemd/pull/32941
added support for firecracker/cloud-hypervisor and
their unix-domain socket to AF_VSOCK multiplex.
but I forgot to add the pattern in the ssh config drop-in.
fix it now!
We only consider something not a tty if it's not connected to a tty
and not connected to /dev/null, so let's use the environment variable
instead to tell machinectl shell that it shouldn't do any of its TTY
stuff.
tianocore does some weird shit with its terminal emulation and regular
fills half the terminal with grey background and then invokes us with
this not cleared up. Hence let us clear this up for it: as part of the
ansi sequence based reset let's position the cursor explicitly at the
beginning of the current line, and erase everything till the end of the
screen. This makes boot output in tianocore vms much much cleaner.
Note that this does *not* erase any terminal output *before* the cursor
position where we take over, because that typically contains valuable
information still we should not erase.
@poettering hrm, there's still one thing unclear to me: we currently
have no way for canceling factory reset via IPC. And adding that to
varlink service solely doesn't seem feasible either, since the state
departs from the active state of `factory-reset.target` and it would
become impossible to re-request it without restarting
`factory-reset.target` _and all dependencies_, which feels
unmaintainable.
Boolean values have to be handled separately for RestrictNamespaces= because
they get stored in a field with reverse meaning (which namespaces are retained),
so let's check which field we're parsing and set the proper value accordingly.
At the moment the gpt-auto generator does its things we already
transitioned into the host OS, i.e. the root fs and /usr/ are mounted.
Hence suppress image policy checks for those two partitions.
This actually matters, because the root hash/usr hash is taken into
consideration for the image policy checks, but we don't have that in
gpt-auto and hence would refuse operation claiming policy conflicts
event though we never actually operate on the root fs via the dissection
logic.
