libdevmapper/device mapper driver can return semi-random failures when
opening verity devices, and we have fallback code to deal with it.
But the test was not expecting the fallback path, so it became unreliable.
Fixes https://github.com/systemd/systemd/issues/23866
For whatever reason, nowadays we add entries that are quite long, so
we were using line continuation for most of new entries. This is hard
to read and edit. So let's just make the table wide enough to accomodate
all the names without line splits.
Acquiring random data from the TPM is not precisely quick, let's speed
things up by doing this at most once per boot. For that, let's maintain
a flag file in /run/.
Previously, true by validate() means several configs are outdated and we
need to reload configs. That's not intuitive for me. Let's rename the
functions.
If a system has multiple graphics cards, then we cannot associate
platform backlight devices to backlight devices under PCI bus.
Previously, in such case, vaidate_device() for a raw backlight device
might erroneously detect a platform device and return false. So, users
could not save/load backlight level.
This makes validate_device() give up to associate platform devices on
non-PCI bus with raw backlight devices. That may cause unwanted
backlight level save or restore by systemd-backlight@.service, but users
can workaround that by masking specific instances of the service.
Closes#24223.
E.g. Documentation or Markers could apply to any unit type. This already worked
partially, because a direct dbus call could be made:
After rebuild with the patch, but before the manager has been restarted:
$ build/systemctl --user set-property dev-zram0.swap Markers=+needs-restart
$ build/systemctl --user show -p Markers dev-zram0.swap
Markers=needs-restart
I noticed that that the rpm unit restart helper was throwing errors for target
units. We should just let the Markers be set for those too, even if it doesn't
do anything in the end. This way we don't need to special-case by unit type.
While I had tested that a symlink to /dev/null works to "mask" a sysext
I must have gotten something wrong and thus the instructions in
519c2f0d6b don't work. What works,
at least at the moment, is to instead have an empty directory with the
extension name under /etc/extensions/.
Correct the info in the man page and add a test for it.
https://github.com/systemd/systemd/pull/6636 added `fsync()` when
temporary shadow, group, and gshadow files are created, but it was
not added for passwd. As far as I can tell, this seems to have been
an oversight. I'm seeing real world issues where a blank /etc/passwd
file is being created if a machine loses power early in the boot process.
TPM2 knows two types of policy sessions: "real" ones and "trial" ones. The
latter allow you to calculate a policy hash without this enforcing any
policy, which the former do. Typically you want to use the "trial" ones
when enrolling, and you have to use the "real" ones for unlocking. So
far we used "real" ones for both cases. Which works fine – as long as
the policy put together matches the current reality (e.g. the PCR values
included in the policy are the ones currently in place in the TPM).
Let's switch to using trial sessions for enrolling. First of all this is
preparation for later work to implement further policy extensions (for
example, policies binding to literally specified PCR values, instead of
the once currently measured). But from my perspective more importantly
it actually is cleaner, as it communicates more clearly what we are
actually doing here.
No user-visible change in behaviour.
The lifetime of variables decalred in the main switch/case body is just
weird. Let's not rely on it, but just open a new {} block, like
everywhere else in similar cases.
When an extension image has binaries they should match the host
architecture. Currently there is no way to specify this requirement.
Introduce an ARCHITECTURE field in the extension's release file that
may be set to prevent loading on the wrong host architecture.
Since this new field is introduced late, we don't want to make
specifying it mandatory as it would break existing sysext images.
See https://github.com/systemd/systemd/issues/24061
