After the commit 773024685b, DNS servers
or domains are dropped when their lifefime become zero. Hence, it is not
necessary to try to them when writing state file.
Of course, because of the accuracy of the timer event source or priority
of event sources, a possibility is introduced that a DNS server or domain
with zero lifetime is stored in the state file. However, such entry will
be dropped soon when the timer event source is triggered. Hence, that
should not cause any real issues.
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.
Signed-off-by: Arnaud Ferraris <arnaud.ferraris@gmail.com>
- 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
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.
We already depend on the skeleton APIs introduced in libbpf 0.7 so
let's bump our minimum version to reflect that.
We don't enforce bpf compilation on mkosi anymore since not all
distros have sufficiently up-to-date libbpf available.
The glibc stuff on ppc64le C8S is a little bit wild, as there are two
versions:
```
$ ldconfig -p | grep libc.so
libc.so.6 (libc6,64bit, hwcap: "power9", OS ABI: Linux 3.10.0) => /lib64/glibc-hwcaps/power9/libc-2.28.so
libc.so.6 (libc6,64bit, OS ABI: Linux 3.10.0) => /lib64/libc.so.6
```
and with `/etc/ld.so.cache` present all binaries use the first one:
```
$ ldd /bin/cat
linux-vdso64.so.1 (0x00007fffa8070000)
libc.so.6 => /lib64/glibc-hwcaps/power9/libc-2.28.so (0x00007fffa7e20000)
/lib64/ld64.so.2 (0x00007fffa8090000)
```
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
...
```
UNIT_DEPENDENCY_MOUNTINFO_OR_FILE was a bit strange as unlike the other flags
we don't know where the dependency came from exactly. Indeed its origin could
have been from the mount unit file or from /proc/self/mountinfo.
Instead this patch replaces UNIT_DEPENDENCY_MOUNTINFO_OR_FILE with 2 new
dependency flags: UNIT_DEPENDENCY_MOUNT_FILE and UNIT_DEPENDENCY_MOUNTINFO. The
former indicates that the dep is created from the unit file but unlike
UNIT_DEPENDENCY_FILE, it will be replaced by a dep with the
UNIT_DEPENDENCY_MOUNTINFO flag as soon as the kernel will make the mount
available in /proc/self/mountinfo.
The quota options have always been read from the unit file and ignored if only
present in /proc/self/mountinfo. IOW the quota services are not (automagically)
pulled in for mounts initiated by the user running mount(8).
If reading the sysattr failed with such error, the whole operation in
net_id builtin command will fail, and the interface will not be renamed.
Fixes a bug introduced by 5bbcfbaa11.
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
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.
Follow-up for 2ccada8dc4.
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.
Yu Watanabe
Zbigniew Jędrzejewski-Szmek
Arnaud Ferraris
Michal Koutný
Dominique Martinet
drosdeck
Aleksey Vasenev
Daan De Meyer
Frantisek Sumsal
Franck Bui
Luca Boccassi
Christian Brauner
Lennart Poettering
Marius Vollmer
Topi Miettinen
Richard Phibel
Richard Phibel