Frantisek Sumsal [Sat, 20 Aug 2022 19:57:18 +0000 (21:57 +0200)]
hashmap: use assert_se() to make clang happy
Otherwise it complains about a set but unused variable:
```
../src/basic/hashmap.c:1070:48: error: variable 'n_rehashed' set but not used [-Werror,-Wunused-but-set-variable]
unsigned old_n_buckets, new_n_buckets, n_rehashed, new_n_entries;
^
1 error generated.
```
Aryan singh [Sat, 20 Aug 2022 10:02:54 +0000 (15:32 +0530)]
hwdb: Add Avita Liber NS13A2 (#24376)
This fixes the discrepancies in the coordinate ranges for the touchpad, touchpad in this device(NS13A2) is generic and the same one is used in most models.
Frantisek Sumsal [Fri, 19 Aug 2022 14:30:24 +0000 (16:30 +0200)]
test: correctly process multiline strings in $KERNEL_APPEND
Some tests (like TEST-02) set a multiline string to $KERNEL_APPEND
(which is a valid thing to do), unfortunately we'd use only the first
line of it and throw the rest away, e.g:
```
$ printf "%s" "$x"
hello
this is a multiline
kernel command line
$ read -ra out <<< "$x"
$ printf "%s" "${out[@]}"
hello
```
Let's use readarray/mapfile instead to avoid this:
Add a new tpm2_parse_pcr_argument() helper that unifies how we merge PCR
masks in a single function, we can use all over the place. Previously we
had basically the same code for this at 4 places.
Michal Sekletar [Tue, 2 Aug 2022 10:38:30 +0000 (12:38 +0200)]
rules: import previous SYSTEMD_READY state for suspended DM devices and skip other rules
We can't get any FS meta-data from a suspended device. Hence defer
making any plugged/unplugged decisions, i.e. we just import whatever was
previous state and skip processing all other rules.
Thanks Lennart Poettering <lennart@poettering.net> for suggesting this
solution.
Rene Hollander [Sat, 13 Aug 2022 19:38:02 +0000 (21:38 +0200)]
Add --efi-boot-option-description argument to bootctl to control the name of the boot
entry.
By default an entry named "Linux Boot Manager" is created (which is the
previous behavior). With the flag the name of the entry can be
controlled, which is useful when installing systemd-boot to multiple ESP
partitions and having uniquely named entries.
cryptsetup: make sure all token-based codepaths are effected by SYSTEMD_CRYPTSETUP_USE_TOKEN_MODULE env var
Previously the env var was only checked when conditionalizing use of our
own libcryptsetup loadable token modules. But let's also use it for any
other kind of token module, including possible internal ones by
libcryptsetup.
In some places, the code was already using that, so only the header file needed
to be adjusted.
We use 'nl' for the sd_netlink* when it's passed in as input. I was considering
renaming to 'netlink', but that'd add a lot of verbosity and also we have
'sd_journal *j' in sd-journal, so the short name matches in style.
Finding a suitable limit that would fit any use cases out there is pretty hard
and since /dev is only writeable by root anyway, let's simply drop the limit.
Instead of always asking for passphrase, if the device has LUKS2 header check:
- If only regular passphrases are registered, ask for passphrase.
- If only recovery keys are registered, ask for recovery key.
- If both regular passphrases and recovery keys are registered, ask for
passphrase or recovery key.
udev: hwdb: Add rules to match cros-ec-accel by 'location' sysfs file
The cros-ec-accel devices report their mounting location by the 'label'
sysfs file only since Linux v6.0. With earlier kernels, a nonstandard
'location' file reports this, but slightly differently (lid instead of
display) [1].
Add udev rules to import the correct hwdb entries based on this
'location' file for cros-ec-accel devices, so that the base-mounted
accel matrix has the correct value for older kernels as well.
hwdb: Add Chromebook accel orientation quirks based on sysfs label
The base-mounted accelerometer on Chromebooks return values same as the
display when the lid angle is 180 degrees, instead of when the lid is
closed. To match userspace expectations we must further rotate the
existing accelerometer mounting matrix by 180 degrees around the X axis:
A previous commit lets us distinguish between the two cros-ec-accel
devices on these boards by their 'label' sysfs file. Add hwdb entries
that make base-mounted accelerometers use this correct matrix, and
display-mounted ones use the existing one.
Note that the cros-ec-accel drivers use 'label' only since Linux v6.0.
The old match strings are not removed to support older kernels, even
though they are only correct for the display-mounted sensor.
udev: hwdb: Match iio sensors based on their label
The IIO subsystem exposes a 'label' sysfs file to help userspace better
identify its devices [1]. Standardized labels include the sensor type
along with its location, including 'accel-base' and 'accel-display'.
Most Chrome OS boards have two accelerometers that are indistinguishable
except for this label (or a 'location' sysfs file before Linux v6.0),
and need different mounting matrix corrections based on their location.
Add a udev rule that matches hwdb entries using this label, so we can
correct both accelerometers on these devices with hwdb entries. The
existing rules and hwdb entries are not modified to keep potential
out-of-tree entries working, but new entries in this form will override
existing ones. Also add currently standardized labels to parse-hwdb.py.
initrd-parse-etc: override argv[0] to avoid dracut issue
Quoting https://github.com/systemd/systemd/pull/24054#issuecomment-1210501631:
> this would need a patch in dracut, specifically adding the
> systemd-sysroot-fstab-check to the list of installed stuff:
> https://github.com/dracutdevs/dracut/blob/fe8fa2b0cadbb33e27c8dd8b5851548dcd65835c/modules.d/00systemd/module-setup.sh#L47.
>
> I could do this manually in the CI (and I guess I'd have to do it anyway even
> if the patch lands in upstream, since it won't be available in C8S), but it
> should get there first before merging this PR, otherwise it's going to break
> Rawhide.
Yu Watanabe [Thu, 18 Aug 2022 06:39:22 +0000 (15:39 +0900)]
network: unref existing sd_ipv4acd object when not necessary
On reconfiguring an interface, the new setting may not enable IPv4ACD
for an existing address anymore. Hence, we need to unref it. Otherwise,
newly requested addresses may never be ready for (re-)configuring.
Yu Watanabe [Thu, 18 Aug 2022 05:15:23 +0000 (14:15 +0900)]
network: fix DHCPv4 address renewal with IPv4ACD
Previously, when a DHCP address is renewed and if the IPv4ACD for the
address is enabled, the address will never drop the probing flag, thus
the lifetime of the address will never be updated.
This drops NETWORK_CONFIG_STATE_PROBING, and the IPv4ACD status is
managed another bit, Address.acd_bound. And, the flag is updated only
when the IPv4ACD announced the address or detects conflict.
Luca Boccassi [Wed, 17 Aug 2022 18:43:01 +0000 (19:43 +0100)]
test: expect libdevmapper failure in TEST-50-DISSECT
libdevmapper/device mapper driver can return semi-random failures when
opening verity devices, and we have fallback code to deal with it.
But the test was not expecting the fallback path, so it became unreliable.
For whatever reason, nowadays we add entries that are quite long, so
we were using line continuation for most of new entries. This is hard
to read and edit. So let's just make the table wide enough to accomodate
all the names without line splits.
tpm2-util: credit TPM2 RNG entropy only once per boot
Acquiring random data from the TPM is not precisely quick, let's speed
things up by doing this at most once per boot. For that, let's maintain
a flag file in /run/.
Yu Watanabe [Wed, 17 Aug 2022 05:44:27 +0000 (14:44 +0900)]
udev: rename various validate() -> should_reload() for builtin commands
Previously, true by validate() means several configs are outdated and we
need to reload configs. That's not intuitive for me. Let's rename the
functions.
Yu Watanabe [Mon, 8 Aug 2022 17:02:02 +0000 (02:02 +0900)]
backlight: fix issue on multiple graphics cards system
If a system has multiple graphics cards, then we cannot associate
platform backlight devices to backlight devices under PCI bus.
Previously, in such case, vaidate_device() for a raw backlight device
might erroneously detect a platform device and return false. So, users
could not save/load backlight level.
This makes validate_device() give up to associate platform devices on
non-PCI bus with raw backlight devices. That may cause unwanted
backlight level save or restore by systemd-backlight@.service, but users
can workaround that by masking specific instances of the service.
manager: allow assignment of properties on target/swap/device units
E.g. Documentation or Markers could apply to any unit type. This already worked
partially, because a direct dbus call could be made:
After rebuild with the patch, but before the manager has been restarted:
$ build/systemctl --user set-property dev-zram0.swap Markers=+needs-restart
$ build/systemctl --user show -p Markers dev-zram0.swap
Markers=needs-restart
I noticed that that the rpm unit restart helper was throwing errors for target
units. We should just let the Markers be set for those too, even if it doesn't
do anything in the end. This way we don't need to special-case by unit type.
Kai Lueke [Tue, 16 Aug 2022 10:29:12 +0000 (12:29 +0200)]
man: Correct information on sysext masking
While I had tested that a symlink to /dev/null works to "mask" a sysext
I must have gotten something wrong and thus the instructions in 519c2f0d6b343d140f7e08e3eb0f46708c023b4a don't work. What works,
at least at the moment, is to instead have an empty directory with the
extension name under /etc/extensions/.
Correct the info in the man page and add a test for it.
Avram Lubkin [Tue, 16 Aug 2022 12:51:21 +0000 (08:51 -0400)]
sysusers: add fsync for passwd (#24324)
https://github.com/systemd/systemd/pull/6636 added `fsync()` when
temporary shadow, group, and gshadow files are created, but it was
not added for passwd. As far as I can tell, this seems to have been
an oversight. I'm seeing real world issues where a blank /etc/passwd
file is being created if a machine loses power early in the boot process.
TPM2 knows two types of policy sessions: "real" ones and "trial" ones. The
latter allow you to calculate a policy hash without this enforcing any
policy, which the former do. Typically you want to use the "trial" ones
when enrolling, and you have to use the "real" ones for unlocking. So
far we used "real" ones for both cases. Which works fine – as long as
the policy put together matches the current reality (e.g. the PCR values
included in the policy are the ones currently in place in the TPM).
Let's switch to using trial sessions for enrolling. First of all this is
preparation for later work to implement further policy extensions (for
example, policies binding to literally specified PCR values, instead of
the once currently measured). But from my perspective more importantly
it actually is cleaner, as it communicates more clearly what we are
actually doing here.