Arnaud Ferraris [Tue, 4 Oct 2022 16:52:33 +0000 (18:52 +0200)]
repart: always honour `--discard=no`
Currently, even if `--discard=no` is passed to `systemd-repart`, the
`context_discard_gap_after()` function still runs normally, discarding
e.g. all blocks between the GPT and the start of the first partition.
This can lead to issues on some embedded devices, where this space
holds the bootloader and shouldn't be modified (creating a protective
partition there is not always possible due to the specifics of the boot
process of some ARM-based SoC's).
This commit ensures passing `--discard=no` would be enough to ensure
the bootloader isn't wiped in such cases.
libbpf: add compat helpers for libbpf down to 0.1.0
- new symbols are available from libbpf 0.6.0 so could be used with
libbpf.so.0, but we're sure the old symbols will be there and this
simplifies code
- detection at runtime should always work, regardless of whether systemd
has been compiled with older or newer libbpf and runs with older or newer
libbpf
Aleksey Vasenev [Wed, 5 Oct 2022 19:33:53 +0000 (22:33 +0300)]
ata_id: Fixed getting Response Code from SCSI Sense Data (#24921)
The Response Code is contained in the first byte of the SCSI Sense Data.
Bit number 7 is reserved or has a different meaning for some Response Codes
and is set to 1 for some drives.
However, without the cache the binaries will fall back to `/lib64/libc.so.6`
which breaks tests that use the minimal verity images (like TEST-29),
because we install only the first version (that's shown by `ldd` at
the time the images are created):
```
[ 91.595343] testsuite-29.sh[747]: + portablectl --profile=trusted attach --now --runtime /usr/share/minimal_0.raw minimal-app0
Starting systemd-portabled.service...
[ OK ] Started systemd-portabled.service.
Starting minimal-app0-foo.service...
Starting minimal-app0.service...
[ 104.432217] cat[858]: cat: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
[ 104.435080] cat[857]: cat: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
[FAILED] Failed to start minimal-app0.service.
See 'systemctl status minimal-app0.service' for details.
```
```
$ chroot /var/tmp/systemd-test.nMHPfc/minimal/
/bin/bash: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
```
With the ldconfig's cache it seems to work as expected:
```
$ chroot /var/tmp/systemd-test.gVtYLg/minimal
bash-4.4# cat --version
cat (GNU coreutils) 8.30
...
```
Topi Miettinen [Mon, 3 Oct 2022 15:13:42 +0000 (18:13 +0300)]
tmpfiles: fix assert
Oct 03 17:33:20 systemd-tmpfiles[872]: Assertion 'IN_SET(i->type, CREATE_BLOCK_DEVICE|CREATE_CHAR_DEVICE)' failed at src/tmpfiles/tmpfiles.c:1837, function create_device(). Aborting.
I think this is caused by the line:
b! /dev/private/smartmontools-dev/sda 0660 root disk - 8:0
Yu Watanabe [Mon, 3 Oct 2022 02:54:20 +0000 (11:54 +0900)]
network: ndisc: drop addresses and friends when RA with zero lifetime is received
Routers may send options with zero lifetime if previously announced
information is outdated. Hence, if we receive such messages, then we
need to drop relevant addresses or friends.
See e.g. https://www.rfc-editor.org/rfc/rfc4861#section-12.
Yu Watanabe [Mon, 3 Oct 2022 03:42:40 +0000 (12:42 +0900)]
network: make sec_to_usec() map 0sec -> 0usec
Zero lifetime in RA is special, and we should not assign possibly very
short lifetime addresses or friends.
This should not change anything at least now, preparation for later
commits. Note, DHCPv4 and v6 code also uses it, but sd-dhcp-client and
sd-dhcp6-client already filtered messages with zero lifetime. Hence,
the change should not affect DHCP code.
Thomas Hebb [Thu, 29 Sep 2022 06:40:35 +0000 (23:40 -0700)]
network: don't forget old RAs when a new one arrives
IPv6 Neighbor Discovery lets us autoconfigure a link's IPv6 addresses,
routes, DNS servers, and DNS search domains by listening for Router
Advertisement (RA) packets broadcast by one or more routers on the link.
Each RA can contain zero or more "options," each describing one piece of
configuration (e.g. a single route).
Currently, when we receive an RA from a router, we delete any addresses,
routes, etc. that originated from that router's previous RAs unless
they're also present as options in the new RA.
That behavior is a violation of RFC 4861[1]. In Section 9, the RFC
states that
Senders MAY send a subset of options in different packets. ... Thus,
a receiver MUST NOT associate any action with the absence of an
option in a particular packet. This protocol specifies that
receivers should only act on the expiration of timers and on the
information that is received in the packets.
Several other passages in the RFC reiterate this. Section 6.2.3:
A router MAY choose not to include some or all options when sending
unsolicited Router Advertisements.
Section 6.3.4:
Hosts accept the union of all received information; the receipt of a
Router Advertisement MUST NOT invalidate all information received in
a previous advertisement or from another source.
At least one consumer router in production today, the Google Nest Wifi,
often sends RAs that omit its global IPv6 prefix. When current versions
of systemd-networkd receive those RAs, they immediately delete the
interface's global IPv6 address, which breaks IPv6 connectivity.
Fix the issue by removing the invalidation logic entirely. It's not
needed at all, since we already invalidate addresses, routes, and DNS
configuration when the interface goes down or their lifetimes expire.
This fix does have the side effect of preventing changes to the .network
file (e.g. denylisted prefixes, whether to add routes from RAs) from
taking effect as soon as a new RA arrives. Instead, a full interface
reconfiguration is needed. But triggering those changes on RA receipt
was already rather arbitrary and out of the administrator's control, so
I think this change is fine.
commit 69203fba700e ("network: ndisc: remove old addresses and routes
after at least one SLAAC address becomes ready") introduced this
behavior. commit 50550722e3ba fixed it partially, by preventing one
router's RAs from invalidating another router's configuration.
[1] https://www.rfc-editor.org/rfc/rfc4861
Fixes: 69203fba700e ("network: ndisc: remove old addresses and routes after at least one SLAAC address becomes ready")
The iscsi-init.service calls `sh` which might, in certain circumstances,
pull in instrumented systemd NSS modules causing `sh` to fail. Let's mitigate
this by pulling in an env file crafted by `create_asan_wrapper()` that
(among others) pre-loads ASan's DSO.
test: expand the expression in `cleanup_initdir()`
Otherwise we might unexpectedly return 1 if the `get_bool` call fails.
If the `get_bool` part in `get_bool "$TEST_SETUP_CLEANUP_ROOTDIR" && _umount_dir "${initdir:?}"`
fails, the whole expression will short-circuit evaluate to 1, and since it's
the last expression in the function it's also it's return value, which doesn't
reflect the original intent of the expression:
ci: pin stefanbuck/github-issue-parser to a tagged release
Since [0] got resolved ([1]) we can finally pin the action to a tagged
release (v2.0.4 ATTOW) and let Dependabot to do its job by updating it
to the latest tagged release when it becomes available.
manager: fix/change evaluation of ConditionFirstBoot
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:
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.
Christian Hesse [Fri, 30 Sep 2022 08:26:43 +0000 (10:26 +0200)]
systemctl: color ignored exit status in yellow, not red
If the executable path is prefixed with "-", an exit code of the command
normally considered a failure (i.e. non-zero exit status or abnormal exit
due to signal) is recorded, but has no further effect and is considered
equivalent to success.
Let's honor this with `systemctl status`, and color ignored exit status
in yellow, not red.
Jonas Kümmerlin [Thu, 29 Sep 2022 16:51:03 +0000 (18:51 +0200)]
generator: skip fsck if fsck command is missing
This is useful for systems which don't have any fsck.
We already skip emitting the fsck dependency when the fsck.$fstype helper
is missing, but fstab-generator doesn't necessarily know the fstype when
handling the root= parameter.
Previously, systemd-fsck was started for these mounts and then exited
immediately because it couldn't find the fsck.$fstype helper.
Allows to skip check that ensures units must not be running.
I have a use case that would use reattach, except the orchestrator
is using a non-standard versioning scheme, so image matching cannot
work. As a workaround, need to be able to detach and then attach
manually, without stopping the units to avoid extended downtimes
and loss of FD store.
1. Use Type=notify to wait until "resolvectl monitor" successfully
installed its monitor, so that we know that queries enqueued later
will definitely be seen.
2. Use "grep -m1" to watch "journalctl -f" output to wait precisely for
the RR data we want to see, and immediately exit.
This shortens code quite a bit, and should make it more robust.
resolved: add generic formatters for RRs into JSON
For now we can use it to send broken-down records of JSON via the
monitor logic, but one day we can certainly reuse for dumping the
caches, or to implement a ResolveRecord() varlink call one day.
The socket is only accessible to privileged clients anyway, no need to
add another (user unfriendly) restriction via opt-in setting. let's just
allow this for privileged clients, mirroring "busctl monitor", or
"tcpdump" and similar, which all just work if you have privs.
(This does not break API, since we never did a release witht the
"Monitor" dbus property or config setting in place, i.e. with cb456374e096f0ebe9b70d7ddd98e16a4be24ee6)
sd-event: add helper for exiting event loop on SIGTERM/SIGINT
In many (most?) of our event loops we want to exit once SIGTERM/SIGINT
is seen. Add a common helper for that, that does the right things in a
single call.
sd-event: if signal nr has high bit set sd_event_add_signal() auto-block it via sigprocmask()
So far we expected callers to block the signals manually. Which is
usually a good idea, since they should do that before forking off
threads and similar. But let's add a mode where we automatically block
it for the caller, to simplify things.
projects / thirdparty / systemd.git / log
