Otherwise a coredump started at the inconvinient moment can stop
shutdown.target leaving the system in a halfway-down state:
Pulling in shutdown.target/start from systemd-poweroff.service/start
Added job shutdown.target/start to transaction.
...
Keeping job shutdown.target/start because of systemd-poweroff.service/start
...
[ OK ] Stopped target Remote File Systems.
shutdown.target: starting held back, waiting for: systemd-networkd.socket
sysinit.target: stopping held back, waiting for: remount_tmp.service
systemd-coredump.socket: Incoming traffic
...
systemd-coredump@0-243-0.service: Trying to enqueue job systemd-coredump@0-243-0.service/start/replace
Added job systemd-coredump@0-243-0.service/start to transaction.
Pulling in systemd-journald.socket/start from systemd-coredump@0-243-0.service/start
Added job systemd-journald.socket/start to transaction.
Pulling in system.slice/start from systemd-journald.socket/start
Added job system.slice/start to transaction.
Pulling in -.slice/start from system.slice/start
Added job -.slice/start to transaction.
Pulling in system-systemd\x2dcoredump.slice/start from systemd-coredump@0-243-0.service/start
Added job system-systemd\x2dcoredump.slice/start to transaction.
Pulling in system.slice/start from system-systemd\x2dcoredump.slice/start
Pulling in shutdown.target/stop from system-systemd\x2dcoredump.slice/start
Added job shutdown.target/stop to transaction.
...
Keeping job systemd-poweroff.service/stop because of umount.target/stop
Keeping job shutdown.target/stop because of systemd-coredump@0-243-0.service/start
The maximum allowed value of the sysfs device index entry was limited to
16383 (2^14-1) to avoid the generation of unreasonable onboard interface
names.
For s390 the index can assume a value of up to 65535 (2^16-1) which is
now allowed depending on the new naming flag NAMING_16BIT_INDEX.
Larger index values are considered unreasonable and remain to be
ignored.
See kernel's rtm_to_fib_config() in net/ipv4/fib_frontend.c and
rtm_to_fib6_config() in net/ipv6/route.c.
Note that if both gateway and multipath routes are specified, then
kernel ignores gateway. So, strictly speaking, setting both gateway and
multipath routes is allowed by kernel. But such situation is mostly
user's misconfiguration. Let's refuse it.
Note that the conditions newly added in route_configure() are redundant,
as all static configurations are already verified in
route_section_verify(), and dynamic configurations do not set
nexthop_id or multipath routes. Just for safety.
Usually, removing non-existing addresses, routes, and etc, are safe.
However, when multiple interfaces lost their carriers simultaneously,
then manager_drop_routes() and manager_drop_nexthop() are called multiple
times. If a route with a blackhole nexthop is removed in that process,
the later removal requests of the route fail with -EINVAL, rathar
than -ESRCH, as the corresponding nexthop does not exist anymore.
So, let's not remove routes which managed by Manager more than once.
The ifdef pattern is the same for all syscalls, so most of the time, if one is
not defined, all others will too. So let's reduce the noise a bit and emit one
warning in case the support for the architecture is fully missing. (Current
template was copied over from before when we added numbers for each syscall by
hand and stopped making sense when we started generating the header from a
table that is expected to have all syscall numbers.)
This patch fix scancode 0x120001 mapping to key code F20 micmute
The previous scancode is not correct, it will cause the micmute
hotkey no function when testing the mic mute
https://github.com/systemd/systemd/pull/19316 failed with:
[1065/1670] Linking target systemd-hwdb
--- command ---
14:28:29 /root/src/test/hwdb-test.sh
--- stdout ---
./systemd-hwdb does not exist, please build first
I'm not sure what is going on here… In principle meson says that tests may be
called from any directory, but in practice is was always the build directory.
So far we were relying on systemd-hwdb being present in '.', and this worked.
Either way, it's nicer to pass the exact path, so let's do that.
This allows to limit units to machines that run on a certain firmware
type. For device tree defined machines checking against the machine's
compatible is also possible.
We were duplicating setting flags for the message and a combination of
NLM_F_APPEND and NLM_F_CREATE which does not make sense. We should have
been using NLM_F_REPLACE and NLM_F_CREATE since the kernel can
dynamically create neighbors prior to us adding an entry. Otherwise, we
can end up with cases where the message will time out after ~25s even
though the neighbor still gets added. This delays the rest of the setup
of the interface even though the error is ultimately ignored.
