$ udevadm test /devices/pci0000:00/0000:00:14.0/usb2/2-4/2-4.1/2-4.1.3
...
2-4.1.3: /usr/lib/udev/rules.d/40-libgphoto2.rules:9 Importing properties from results of builtin command 'usb_id'
2-4.1.3: /usr/lib/udev/rules.d/50-udev-default.rules:13 Skipping builtin 'usb_id' in IMPORT key
2-4.1.3: /usr/lib/udev/rules.d/50-udev-default.rules:13 Importing properties from results of builtin command 'hwdb --subsystem=usb'
2-4.1.3: hwdb modalias key: "usb:v17EFp3054:OneLink+ Giga"
2-4.1.3: /usr/lib/udev/rules.d/50-udev-default.rules:15 Importing properties from results of builtin command 'hwdb 'usb:v17efp3054''
2-4.1.3: No entry found from hwdb.
2-4.1.3: /usr/lib/udev/rules.d/50-udev-default.rules:15 Failed to run builtin 'hwdb 'usb:v17efp3054'': No data available
2-4.1.3: /usr/lib/udev/rules.d/50-udev-default.rules:52 MODE 0664
except that the existing one was done with uppercase digits and the full match pattern,
and the second one was done with lowercase digits.
With the previous commit we only have uppercase digits in our match patterns, so we can
drop the duplicate import. (Some other projects might have rules that used the lowercase
match patterns, and people might have some local rules that did that too. But the second
import was only added recently so I think it's better to rip off the bandaid quickly.)
hwdb: fix check for uppercasedness of match patterns
The check was added in 77547d5313ea916d2fb64ca5a8812734e9b50f92, but
it doesn't work as expected. Because the second part is wrapped in Optional(),
it would silently "succeed" when the lowercase digits were in the second part:
Empty files and empty strings seem to have triggered various
issues in the past so it seems they shouldn't be ignore by the
fuzzers just because fmemopen can't handle them.
Prompted by https://github.com/systemd/systemd/pull/21939#issuecomment-1003113669
meson: generate better arch defines for clang bpf compilation
The code assume that meson's cpu_family can be mapped directly to
'-D__<cpu_family>__'. This works in a surprising number of cases, but not for a
few architectures. PPC uses "powerpc", and RISC-V omits the trailing underscores.
ARM and RISC-V require a second define too.
Fixes #21900.
(I don't think this matters too much: we need *something* so that gnu/stubs.h
can be successfully included. But we don't actually call syscalls or depend too
much on the host environment, so things should be fine as long as we don't get
a compilation error.)
When the support for "synthetic errno" was added, we started truncating
the errno value to just the least significant byte. This is generally OK,
because errno values are defined up to ~130.
The docs don't really say what the maximum value is. But at least in principle
higher values could be added in the future. So let's stop truncating
the values needlessly.
The kernel (or libbpf?) have an error where they return 524 as an errno
value (https://bugzilla.redhat.com/show_bug.cgi?id=2036145). We would
confusingly truncate this to 12 (ENOMEM). It seems much nicer to let
strerror() give us "Unknown error 524" rather than to print the bogus
message about ENOMEM.
coredump: do not crash if we failed to acquire exe path
The COREDUMP_EXE attribute is "optional", i.e. we continue to process the
crash even if we didn't acquire it. The coredump generation code assumed
that it is always available:
#5 endswith at ../src/fundamental/string-util-fundamental.c:41
[ endswith() is called with NULL here, and an assertion fails. ]
#6 submit_coredump at ../src/coredump/coredump.c:823
#7 process_socket at ../src/coredump/coredump.c:1038
#8 run at ../src/coredump/coredump.c:1413
We use the exe path for loop detection, and also (ultimately) pass it to
dwfl_core_file_report(). The latter seems to be fine will NULL, so let's just
change our code to look at COMM, which should be more reliable anyway.
core/bpf: tighten handling of return values, improve messages
The code was written unidiomatically, using r as a boolean value, and
confusing errno and r in some places. AFAICS, there wasn't any actual
problem: even in the one place where errno was used instead of r, it would
almost certainly be initialized.
It seems that some libbpf functions set errno, while others return the
error, possibly encoded. Since there are almost no docs, the only way to
know is to read the code of the function. To make matters worse, there is
a global libbpf_mode which can be set to change the convention. With
LIBBPF_STRICT_DIRECT_ERRS in libbpf_mode, some functions set errno while others
return a negative error, and the only way to know is to read the code, except
that the split is now different. We currently don't set
LIBBPF_STRICT_DIRECT_ERRS, but even the possibility makes everything harder
to grok.
This is all very error-prone. Let's at least add some asserts to make sure that
the returned values are as expected.
Jan Janssen [Sat, 1 Jan 2022 15:37:27 +0000 (16:37 +0100)]
boot: Use objcopy to align sections
Not aligning these can create gaps in the section table. Some
firmware does not handle this nicely resulting in secure boot
signature fails.
Using objcopy ensures that any new sections in the future will be
properly aligned.
Jan Janssen [Wed, 29 Dec 2021 14:02:04 +0000 (15:02 +0100)]
meson: Remove efi-cc option
Changing the efi compiler this way doesn't really work. The gnu-efi
header checks as well as supported compiler flag checks use the
regular cc that meson detects. Changing the compiler this way will
end up with bad compiler flags. For the very same reason, this does
not work with a cross-compiler without going through proper meson
cross-compilation steps either.
The proper way to build systemd-boot with a different compiler is to
use a different build folder and then just use the proper ninja build
target to only build the bootloader/stub.
The commit mistakenly drops 'x' in ID_NET_NAME_MAC, and adds colons.
The colons were dropped by the commit dfa4876c417e2a9935d58100d44d94bb41cd5bfb,
but the missing 'x' was not added at that time.
#if defined __stub_crypt_set_metadata_size || defined __stub___crypt_set_metadata_size
fail fail fail this function is not going to work
#endif
int main(void) {
return crypt_set_metadata_size ();
}
This works fine when the identifier being queried is an actual function. But
crypt_token_max() is an inline function, so getting the address would fail,
leading to a false negative result. Complation would fail because the function
would be defined twice.
With this patch, the check is changed to include the header:
#include <libcryptsetup.h>
#include <limits.h>
#if defined __stub_crypt_set_metadata_size || defined __stub___crypt_set_metadata_size
fail fail fail this function is not going to work
#endif
int main(void) {
void *a = (void*) &crypt_set_metadata_size;
long long b = (long long) a;
return (int) b;
}
Yu Watanabe [Thu, 30 Dec 2021 18:48:17 +0000 (03:48 +0900)]
hostname-setup: gracefully handle kernel with empty CONFIG_DEFAULT_HOSTNAME
Previously, sethostname_idempotent_full() calls gethostname_full() with
GET_HOSTNAME_ALLOW_NONE and GET_HOSTNAME_ALLOW_LOCALHOST flags. That
intended to get any values set by kernel. But, that does not work, as
the hostname may be empty.
Let's simplify the logic. The function sethostname_idempotent_full()
intends to set the requested hostname only when the current hostname
is different from the requested one. So, no check in getostname_full()
is required. Hence, simply use the result of uname() here.
Luca Boccassi [Thu, 30 Dec 2021 00:54:32 +0000 (00:54 +0000)]
systemd-run: ensure error logs suggest to use '--user' when appropriate
Before:
$ systemd-run --service-type=notify --user false
Job for run-rc3fe52ee6ddd4a6eaaf1a20e0a949cdf.service failed because the control process exited with error code.
See "systemctl status run-rc3fe52ee6ddd4a6eaaf1a20e0a949cdf.service" and "journalctl -xeu run-rc3fe52ee6ddd4a6eaaf1a20e0a949cdf.service" for details.
After:
$ systemd-run --service-type=notify --user false
Job for run-r7791e380a7b6400ea01d6a0e5a458b23.service failed because the control process exited with error code.
See "systemctl --user status run-r7791e380a7b6400ea01d6a0e5a458b23.service" and "journalctl --user -xeu run-r7791e380a7b6400ea01d6a0e5a458b23.service" for details.
The commit makes several functions skipped if the manager is already
in finished state, as
> In manager_check_finished(), more steps are skipped if MANAGER_IS_FINISHED().
> Those steps are idempotent, but no need to waste cycles trying to do them
> more than once.
However, the idle pipe may be re-opened after manager is finished:
manager_dispatch_run_queue() -> manager_watch_idle_pipe().
So, the closing the pipe is not idempotent here.
Luca Boccassi [Sun, 26 Dec 2021 16:45:13 +0000 (16:45 +0000)]
chrattr-util: return EOPNOTSUPP from chrattr_full if no other failure was observed
When chattr_full tries to apply flags one-by-one, and one fails,
record which errno was returned. But record EOPNOTSUPP(&friends)
only if no other error is observed, and return it only in that case
(otherwise keep returning ENOANO), so that callers can respond
appropriately to EOPNOTSUPP vs more relevant errors.
For example, this lets tmpfiles.d log at debug level when a filesystem
flag cannot be applied because the filesystem does not support it,
but at warning level if something else went wrong when applying it.
Restores logging behaviour of tmpfiles.d to pre-250.
Hans de Goede [Sat, 25 Dec 2021 10:19:03 +0000 (11:19 +0100)]
hwdb: 60-keyboard: Fix volume-button mapping on Asus TF103C
The Asus TF103C misses the home button in its PNP0C40 GPIO resources
causing the button mappings for the volume buttons to be off by one,
leading to the volume-up button sending home button presses and the
volume-down button sending volume-up button presses.
Add a 60-keyboard hwdb entry to correct the mappings. Note this is
split over 2 input devices because the soc_button_array driver
creates separate input devices for power + home and vol up/down.
This is done because power/home act as wakeup buttons where as
the volume buttons do not.
This means that after this fixup the home -> volume-up button
still acts as a wakeup button, there is nothing which can be done
about this without adding a kludge to the kernel which is not
worth the trouble (IMHO).
test: ignore the error about our own libraries missing during image creation
19:50:59 F: Missing a shared library required by /var/tmp/systemd-test.NIPT2q/root/lib/systemd/libsystemd-core-250.so.
19:50:59 F: Run "ldd /var/tmp/systemd-test.NIPT2q/root/lib/systemd/libsystemd-core-250.so" to find out what it is.
19:50:59 F: libsystemd-shared-250.so => not found
19:50:59 F: Cannot create a test image.
meson: allow specifying a custom "tag" for the private shared libaries
We have /usr/lib/systemd/libsystemd-{shared,core}-nnn.so. With this
path the 'nnn' part can be changed to something different. The idea
is that during a package build this will be set to the package version.
This way during in-place upgrades with the same major version both
the new and old libraries can cooexit. This should fix the issue
when systemd programs are called during package upgrades and fail
to exec because the expect different symbols in the library they
are linked to.
This should fix https://bugzilla.redhat.com/show_bug.cgi?id=1906010.
projects / thirdparty / systemd.git / log
