This documents that explicit `Before=`/`After=` dependencies can be
used to selectively override implicit ordering coming from default
dependencies. That allows for more granular control compared to the
already documented `DefaultDependencies=no` option.
The alternative approach came up in a discussion around the ordering
of `boot-complete.target`, so this also adds an explicit suggestion
in that direction to the "Automatic Boot Assessment" documentation.
Ref: https://lists.freedesktop.org/archives/systemd-devel/2022-September/048330.html
No functional changes, just refactoring.
Note, this also makes synthesize_change() propagate the error from
synthesize_change_one(). However, the caller of synthesize_change()
ignores the failure anyway, hence the change does not take any effect.
This works becuase TPM2_FLAGS_USE_PIN is 1 and bool is a 1 so the bits
line up as expected, however if for some reason flags change values and
for clarity check if the boolean indicates this flag and pass the flag
value.
Signed-off-by: William Roberts <william.c.roberts@intel.com>
This way we can use it directly in measure.c, and thus remove a bit of
redundant code.
OpenSSL prefers uppercasing the MD names, others don't hence let's be
lenient here.
As usual, it seems to be mostly additions and corrections. Sadly, it seems a
bit of mojibake has crept in in various places. But it's hard to correct, in
particular because it's hard to detect all cases automatically. I think we can
ignore this for now.
When I run this a few weeks ago, ma-large.txt was gutted and 20-OUI.hwdb was
siginificantly smaller. For whatever reasons, it's back to normal now.
Systemd's credential interface is not yet natively supported by all
programs yet. Hence it's often required to run scripts to massage
secrets in the way the programs expect it.
This commit allows the ExecStartPre commands to access credentials.
Fixes https://github.com/systemd/systemd/issues/19604
We already checked that the sd_device object 'dev' is for a whole block
device. So, -ENOENT should not be triggeered here, and if it is, there
exists something spurious. Hence we should not ignore the failure.
If the filename of a device symlink is too long, then the temporary
filename may become invalid, and we fail to create symlink.
The function `tempfn_random()` used in symlink_atomic_full() generates
a safe temporary filename.
Note that, thanks to the PR #23043, now only one worker can handle
the same symlink simultaneously. Hence, the device ID based temporary
filename is not necessary.