EINVAL suggests that the caller passes an invalid argument. EIO is
for "input/output error", i.e. the error you'd get if the disk or
file system is borked, and this error code could be returned by the
underlying read/write functions.
Let's make the functions return an unambiguous error code.
During the call today we agreed to work towards -rc1 in January. Nevertheless,
I already started writing this up and I'll push it so it doesn't get lost.
I didn't include all the changes to systemd-repart, because those are still in
flux.
According to systemctl(1), we should use LSB return code 4
(EXIT_PROGRAM_OR_SERVICES_STATUS_UNKNOWN) when the state
is "no such unit" for is-{active,failed,enabled} verbs.
Fixes#25680
In both cases, the json string is short, so we can print it, which is useful
for diagnosing invalid data in packages. But we need escape non-printable
characters.
https://bugzilla.redhat.com/show_bug.cgi?id=2152685
I went over the rest of the codebase, and it seems that other calls to
json_parse() don't have this problem.
One had to read to the very end of the long description to notice that
the setting is actually primarily intended for oomd. So let's mention oomd
right at the beginning.
These are only needed for some kernel selftests but they prevent
building the mkosi image on aarch64 systems so let's drop them
until mkosi has support for conditional configuration so we can
only add these packages on the right architecture.
This improves the performance of parsing the file and reduces memory pressure.
Running 'fuzz-etc-hosts timeout-strv' with valgrind,
Before:
total heap usage: 321,020 allocs, 321,020 frees, 15,820,387,193 bytes allocated
real 0m23.531s
user 0m21.458s
sys 0m1.961s
After:
total heap usage: 112,408 allocs, 112,408 frees, 7,297,480 bytes allocated
real 0m8.664s
user 0m8.545s
sys 0m0.065s
Hopefully fixes oss-fuzz#47708 (https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=47708).
After #25268, it is now possible to check whether a credential
is present on a FIDO2 token without actually attempting to retrieve said
credential. However, when cryptsetup plugins are not enabled, the
fallback unlock routines are not able to make multiple attempts with
multiple different FIDO2 key slots.
Instead of looking for one FIDO2 key slot when trying to unlock, we now
attempt to use all key slots applicable.
Fixes#19208.
This solves Debian Bug report 1008760:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1008760.
Solution was inspired by this kernel bug report message:
https://bugzilla.kernel.org/show_bug.cgi?id=204967#c15.
My measured pad dimensions with a ruler were 85x44mm.
But I decided to take the 2x size reported by the current kernel
when invoking the touchpad-edge-detector command from the
libdev-tools package. Because this comment claims that the old
vs new kernel reportings differ by factor 2:
https://bugzilla.kernel.org/show_bug.cgi?id=204967#c3 .
Therefore I have used this command to get the new entry to 60-evdev.hwdb:
"root@pb:~# touchpad-edge-detector 80x34 /dev/input/event2
Touchpad ETPS/2 Elantech Touchpad on /dev/input/event2
Move one finger around the touchpad to detect the actual edges
Kernel says: x [0..1254], y [0..528]
Touchpad sends: x [0..2472], y [-524..528] -^C
Touchpad size as listed by the kernel: 40x17mm
User-specified touchpad size: 80x34mm
Calculated ranges: 2472/1052
Suggested udev rule:
# <Laptop model description goes here>
evdev:name:ETPS/2 Elantech Touchpad:dmi:bvnPackardBell:bvrV1.21:bd08/09/2012:br21.240:svnPackardBell:pnEasyNoteTS11HR:pvrV1.21:rvnPackardBell:rnSJV50_HR:rvrBaseBoardVersion:cvnPackardBell:ct10:cvrV1.21:*
EVDEV_ABS_00=0:2472:31
EVDEV_ABS_01=-524:528:31
EVDEV_ABS_35=0:2472:31
EVDEV_ABS_36=-524:528:31
"
This tool was "deprecated" back in 65eb4378c3,
but only by removing documentation. This is somewhat surprising, but udevadm
hwdb --update and systemd-hwdb update generate different databases. udevadm
runs in compat mode and (as far as I have been able to figure out from a quick
look), it omits filename information and does some other changes to the
datastructures. The consuming code (udev) is the same in both cases, so this
"compatibility mode" seems very strange. But I don't think it's worth trying to
figure out why things were done this way. Let's just push people towards the
new code.
Inspired by https://github.com/systemd/systemd/issues/25698#issuecomment-1346298094.
Yu Watanabe
Jiayi Chen
David Tardon
Zbigniew Jędrzejewski-Szmek
Daan De Meyer
Luca Boccassi
Mike Yuan
AndyChi
January
Peter Cai
uerdogan
Will Fancher