The code to evaluate the kernel command line option was busted because it
was doing 'return b == !!r' at a point where 'r > 0'. Thus we'd return "true"
in both cases:
$ SYSTEMD_PROC_CMDLINE=systemd.condition-first-boot build/systemd-analyze condition 'ConditionFirstBoot=true'
test.service: ConditionFirstBoot=true succeeded.
Conditions succeeded.
$ SYSTEMD_PROC_CMDLINE=systemd.condition-first-boot build/systemd-analyze condition 'ConditionFirstBoot=false'
test.service: ConditionFirstBoot=false succeeded.
Conditions succeeded.
We only use 'ConditionFirstBoot=true' in units, so this wasn't noticed.
But I think the logic is broken in general: the condition should evaluate as
true only during initial boot. If we rerun the units at later points, we should
not consider ConditionFirstBoot to be true.
Also, the first boot logic is also used in pid1 itself. AFAICT, for two
things: in first boot machine-id is initialized transiently (this allows
first-boot operations to be restarted if boot fails), and preset-all is
executed. But this logic was different and separate from the logic to
evaluate ConditionFirstBoot. The distinction is abolished, and the operations
in pid1 now use the same logic as ConditionFirstBoot, which means that the
kernel command line option is checked, and condition_test_first_boot()
just tests whether pid1 thinks we're in first boot.
This makes things easier to grok for the user: there's just one condition for
"first boot" and it applies to both pid1 and units.
$ SYSTEMD_LOG_LEVEL=debug build/systemd-firstboot --prompt-root-password
Found container virtualization systemd-nspawn.
Found /etc/locale.conf, assuming locale information has been configured.
Failed to read credential firstboot.keymap, ignoring: No such device or address
Prompting for keymap was not requested.
Found /etc/localtime, assuming timezone has been configured.
Prompting for hostname was not requested.
Found /etc/machine-id, assuming machine-id has been configured.
Found /etc/passwd and /etc/shadow, assuming root account has been initialized.
Creation of /etc/kernel/cmdline was not requested, skipping.
Currently, NetworkManager will set DNSOverTLS according to its
`connection.dnsovertls` configuration only once during connection,
instead of every single restart of systemd-resolved, causing resolved to
lose the configuration on restart.
Fix this by persisting DNSOverTLS in the runtime state file, which will
also make it more consistent with other interface-specific settings.
Since open-iscsi 2.1.2 [0] the initiator name should be generated via
a one-time service instead of distro package's post-install scripts.
However, some distros still use this approach even after this patch,
so prefer the already existing initiatorname.iscsi file if it exists.
[0] https://github.com/open-iscsi/open-iscsi/commit/f37d5b653f9f251845db3f29b1a3dcb90ec89731
TL;DR
This effectively reverts 8327fd1b11,
eaba9bb3e6, and its follow-ups, as the
original issue was already fixed by the kernel side.
The original issue that the above commits tried to 'fix' is that reading
phys_port_name triggers a lock in the kernel, hence processing multiple
interfaces at the same time causes extreme slow down.
To workaround the issue, the above commits made several necessary
information retrieved through netlink instead of sysfs attributes.
A patch set for the kernel was proposed as a fix for the issue:
https://lore.kernel.org/all/20210928125500.167943-1-atenart@kernel.org/
and some of them were merged to v5.16:
https://github.com/torvalds/linux/commit/146e5e733310379f51924111068f08a3af0db830,
It has been already backported to 5.4.160, 5.10.80, 5.14.19, and 5.15.3.
When these commits were proposed, it is already claimed that such issue
should be fixed by the kernel side, and udevd should not workaround it.
Neverthless the feature was introduced, as these have theoretical
performance improvement, even if phys_port_name sysattr does not have the
above issue, as in that way udevd can obtain multiple information about
the interface with a single netlink socket operation. See the discussion
in #20744.
However, in reality, only `iflink`, `type`, `address`, and `phys_port_name`
attributes from netlink are used in the udev net_id builtin command. Hence,
after the original issue being fixed in the kernel side, there should be
almost no performance improvement for udevd.
Furthermore, combining attributes from netlink and sysfs makes hard to
test net_id builtin. See #21725.
Let's drop mostly meaningless code, and make net_id builtin easily testable.
Closes#21725.
The compiler may decide computations like these are not doing anything
and decide to optimize them away. This would defeat the whole fuzzing
exercise. This macro will force the compiler to materialize the value
no matter what. It should be less prone to accidents compared to using
log functions, which would either slow things down or still optimize the
value away (or simply move it into the if branch the log macros create).
The benefit over assert_se would be that no requirement is made on the
value itself. If we are fine getting a string of any size (including
zero), an assert_se would either create a noisy compiler warning about
conditions that would alawys be met or yet again optimize the whole
thing away.
Fixes compile error with -Dopenssl=false.
```
In file included from ../../home/watanabe/git/systemd/src/shared/pkcs11-util.h:12,
from ../../home/watanabe/git/systemd/src/cryptenroll/cryptenroll.c:24:
../../home/watanabe/git/systemd/src/shared/openssl-util.h:56:21: error: conflicting types for ‘X509’; have ‘struct X509’
56 | typedef struct X509 X509;
| ^~~~
In file included from /usr/include/openssl/crypto.h:25,
from /usr/include/openssl/bio.h:20,
from /usr/include/openssl/asn1.h:16,
from /usr/include/openssl/ec.h:17,
from /usr/include/fido.h:10,
from ../../home/watanabe/git/systemd/src/shared/libfido2-util.h:18,
from ../../home/watanabe/git/systemd/src/cryptenroll/cryptenroll-fido2.h:7,
from ../../home/watanabe/git/systemd/src/cryptenroll/cryptenroll.c:6:
/usr/include/openssl/ossl_typ.h:123:24: note: previous declaration of ‘X509’ with type ‘X509’ {aka ‘struct x509_st’}
123 | typedef struct x509_st X509;
| ^~~~
```