This TCTI module is the one we need to actually access a Linux TPM
device, we'll hence pretty much always need it if we do TPM at all.
Given that we nowadays turn off dlopen() after fork() in the child,
let's explicitly load it as part of dlopen_tpm2() so that it is
available whenever TPM2 is used.
Linux console is very weird when it comes to ANSI color sequences.
Not only that it isn't aware of ':' separator (c.f.
https://github.com/systemd/systemd/pull/40878#issuecomment-3979826739),
it even skips the whole CSI-m sequence if it contains parts it cannot
parse. Hence when color mode is set to 256 (i.e. default when no
extra info is available) let's always emit two distinct CSI-m sequences,
and set the fallback 16 color first in case the terminal doesn't have
complete support for the 256 one.
Replaces #40905
usb hubs tend to expose removable attribute as unknown. This makes some
problems like a hub for external usb ports in pogo pins is unknown and
also soldered hubs in laptops for keyboard+touchpad.
Let's set internal when the device removable attribute is fixed and
external when removable, but when it's unknown lets check the parent
ports (not the host devpath!=0) attribute to decide.
This makes us to missdetect pogo ping connected external usb hubs but
let us to correctly detect laptop internal keyboards and touchpads that
are wired through hubs instead directly.
This behaviour is more desirable, as actually there are a bunch of
laptops with this setup.
Fixes: a4381cae8b.
Closes#40877. As requested, --extra-drive=path[:format] is changed
to --extra-drive=[format:]path, so that the parsing is less ambiguous.
(In the original request, it was requested that the empty format can be
used also, but that was dropped in the second version of the patch.)
Closes#40883. As described in the issue, it's not "jobs" that are
marked, and also the name is unnecessarilly long.
I think we don't need any compatibility measures here. At least in the
rpm world, package upgrade scripts go through the helper which is part
of the package so the new systemctl and the new helper are upgraded
together.
After kernel commit 907bc9268a ("Input: atkbd - map F23 key to support default copilot shortcut")
Fn+F5 combination (switch touchpad on/off) stopped working correctly.
Fn produces F23, it is probably a bug in BIOS, ther eis no "Copilot" key.
It was ignored before that commit, but now we have to remap it here in hwdb.
This workaround is similar to systemd commit d2502f55a2
("hwdb/keyboard: Map FN key on TUXEDO InfinityFlex 14 Gen1")
Hardware probe of this notebook: https://linux-hardware.org/?probe=7aca7ed668
See also: https://bugzilla.rosa.ru/show_bug.cgi?id=19950
Closes#40883. As described in the issue, it's not "jobs" that are
marked, and also the name is unnecessarilly long.
I think we don't need any compatibility measures here. At least in the
rpm world, package upgrade scripts go through the helper which is part
of the package so the new systemctl and the new helper are upgraded
together.
Follow-up for 93d768e0f3. The commit with
the fix didn't mention this, but the reported reproducer was:
> Install openSUSE Tumbleweed with account-utils and systemd v258.
> Compile and install systemd v260. Run "varlinkctl list-methods
> /run/account/newidmapd-socket" -> the newidmap service crashes in
> varlink_idl_format_all_fields(). Recompile newidmap with systemd v260
> headers -> varlinkctl list-methods works again.
Other people might hit the same issue, so let's mention that this was
fixed.
So far statx_mount_same() assumed STATX_MNT_ID_UNIQUE didn't exist.
However it does exist, hence do something useful if we see it set. Note
that this creates a certain ambiguity: if we compare one statx struct
with STATX_MNT_ID_UNIQUE and one without it (but with the regular mnt
id), then we cnanot really come to a clear conclusion, hence need to
introduce a third, unknown state.
Note that we don't request STATX_MNT_ID_UNIQUE yet wherever we call
statx_mount_same(). THis will be added in a later commit.
The old name suggested this would only check if the two inodes are on
the same mount, but it actually checks if they are the same inodes too.
Let's rename it to make this clearer, in particular as we have
both statx_inode_same() and statx_mount_same() already, and they are
even used here, and hence very confusing.
This also drops two checks from the test case, which are simply wrong.
Given they apparently weren't load bearing (since no CI tripped up),
let's just drop them.
The same optimization is already applied in the very similar
dir_fd_is_root() check a few lines up – with the exception that it
doesn't accept AT_FCWD there. And frankly turning off
CHASE_AT_RESOLVE_IN_ROOT if we operate on AT_FCWD is simply wrong. Hence
remove this code.
Let's harden things in case concurrent access is allowed to a root tree
passed via CHASE_AT_RESOLVE_IN_ROOT: let's not just validate via the
path if we hit the root of the tree, but also by comparing inodes +
mount ids.
Hardening opportunity reported by Sebastian Wick.
In one of the next commits we want to acquire .stx_mnt_id from statx()
for each inode we traverse (plain fstat() doesn't provide that field).
Hence let's port chase() over to statx() as preparation for that.
No change in behaviour.
Let's add some protections in case we deal with inodes owned by an
untrusted person, with concurrent access: let's put a limit on how long
we traverse, and fail eventually so that live changes cannot send us in
circles indefinitely.
This reworks the current CHASE_MAX logic so that it not only applies to
symlinks transitions, but to any transitions.
This also bumps CHASE_MAX a bit, given that it's now bumped on every
single iteration of the loop.
When install_subdir encounters a mkosi.tools tree with a /bin to
/usr/bin symlink it fails to copy it because it dereferences but still
treats it like a file.
Work around the Meson bug by excluding the mkosi.tools tree from
installation like mkosi.local is excluded. We anyway don't want the
tools tree end up there.
When removing marked routes, the condition `if (ret)` incorrectly
overwrites any previously accumulated error in `ret` with the latest
return value `r`, even if `r >= 0` (success). This means an earlier
real error can be silently cleared by a subsequent successful
route_remove() call.
The parallel address_remove() block just above uses the correct
`if (r < 0)` pattern. Apply the same fix to the route_remove() block.