glibc (and also musl, though we do not officially support it yet)
silently ignores colon prefix in $TZ. Let's always not prefix the
timezone.
tzset(3) states:
> A nonempty value of TZ can be one of two formats, either of which can
> be preceded by a colon which is ignored.
Addresses https://github.com/systemd/systemd/pull/38876#discussion_r2384347594.
The next version of swtpm will support RSA4096, but it needs to be called
with a new parameter in order to do so. Try with it first, and if
execution fails, fallback to running without it.
This is especially needed for OBS builds, as the signing key is RSA4096
and cannot be changed by users, so the generated UKIs have RSA4096 signatures
for the pcrsig sections, and swtpm refuses them without the new support.
It helps nobody to break compatibility for a missing definition
for printing an error.
Just add the missing definition if not present, as it is already
done for thousands of others from the kernel, glibc, etc.
This partially reverts commit d8b60944f5.
Previously, an input string ends with short timezone spec e.g. WET,
was parsed by setting $TZ environment variable to the timezone.
But the timezone might be different from the original local timezone,
thus the result might not follow the timezone change in the original
local timezone.
This makes the check of the short timezone spec with tzname[] earlier,
then it is not necessary to load another timezone file for e.g. WET,
and provides expected time.
This also make it use SAVE_TIMEZONE macro and drop use of forking
process. This makes greatly improve performance when parsing string
that contains timezone different from the current local timezone.
Unfortunately, there is still one corner case that our test fails.
When tzdata is built with rearguard enabled, then at least
Africa/Windhoek timezone does not provide correct time, but time shifted
1 hour from the original.
linux https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsroot.html
states `ntp0-ip` as parameter to `ip=` command line.
Until now systemd-network-generator would fail if ntp was provided with
-EINVAL due to trailing arguments.
Stay in line with kernel doc and handle ntp value properly.
Previously, we shift arrays on read and then shift back on write.
It is inefficient and not necessary.
Let's directly use the buffer that kernel provides as is.
Let's check both the per user machined and the system machined instead
of only the system machined. We give preference to the per user machined
and fall back to the system machined.
This is also preparation for the installer later, split out of #38764.
It makes the experience a lot nicer if our nice little tools aren't
constantly interrupted by log spew from the kernel.
Fixes: #34448
This allows Type 1 entries to take advantage of multiprofile efi files
by allowing the configuration of the profile associated with that entry.
It will now parse the profile key in a Type 1 config to select that
profile when booting that efi file instead of relaying in the cmdline
Signed-off-by: Itxaka <itxaka@kairos.io>
For "wizard" style interactive tools it's very annoying if they are
interrupted by kernel log output or PID1's status output. let's add some
infra to disable this temporarily. I decided to implement this as an IPC
service so that we can make this robust: if the client request the
muting dies we can automatically unmute again.
This is hence a tiny varlink service, but it can also be started
directly from the cmdline.
In integration tests (for example TEST-85-NETWORK-NetworkctlTests)
LINK_OPERSTATE_RANGE_INVALID and required_for_online == -1 are serialized as
```
"RequiredForOnline": "true",
"RequiredOperationalStateForOnline": [null, null]
```
Such link should be reported as required_for_online=False and not
serialize nulls.
Except for the test, bpf_firewall_compile() is only called by the following:
cgroup_context_apply() -> cgroup_apply_firewall() -> bpf_firewall_compile()
and in the early stage of cgroup_context_apply(), it checks if the cgroup
runtime exists. Hence, it is not necessary to try to allocate the
runtime in bpf_firewall_compile().
All other resource control features work as 'best-effort', and failures
in applying them are handled gracefully. However, unlike the other features,
we tested if the BPF programs can be loaded and refuse execution on failure.
Moreover, the previous behavior of testing loading BPF programs had
inconsistency: the test was silently skipped if the cgroup for the unit does
not exist yet, but tested when the cgroup already exists.
Let's not handle failures in loading custom BPF programs as critical, but
gracefully ignore them, like we do for the other resource control features.
Follow-up for fab347489f.
Before 23ac08115a, even if we failed to
create the cgroup for a unit, a cgroup runtime object for the cgroup is
created with the cgroup path. Hence, the creation of cgroup is failed,
execution of the unit will fail in posix_spawn_wrapper() and logged
something like the following:
```
systemd[1]: testservice.service: Failed to create cgroup /testslice.slice/testservice.service: Cannot allocate memory
systemd[1]: testservice.service: Failed to spawn executor: No such file or directory
systemd[1]: testservice.service: Failed to spawn 'start' task: No such file or directory
systemd[1]: testservice.service: Failed with result 'resources'.
systemd[1]: Failed to start testservice.service.
```
However, after the commit, when we failed to create the cgroup, a cgroup
runtime object is not created, hence NULL will be assigned to
ExecParameters.cgroup_path in unit_set_exec_params().
Hence, the unit process will be invoked in the init.scope.
```
systemd[1]: testservice.service: Failed to create cgroup /testslice.slice/testservice.service: Cannot allocate memory
systemd[1]: Starting testservice.service...
cat[1094]: 0::/init.scope
systemd[1]: testservice.service: Deactivated successfully.
systemd[1]: Finished testservice.service.
```
where the test service calls 'cat /proc/self/cgroup'.
To fix the issue, let's fail earlier when we failed to create cgroup.
Follow-up for 23ac08115a (v258).
This is the first part of #38728, just the machined stuff, no the
importd stuff.
This definitely makes sense of its own, hence let's get this in first.
The original PR contains a tescase that tests machined + importd in
combination. This PR here hence is without a testcase, but it's there,
just in the other PR.
This looks large and is large, but do note that much of the machined
changes are very repetitive: they conditionalize PK checks to the system
version, as PK doesn't make sense in the use rversion.