IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
In https://bugzilla.redhat.com/show_bug.cgi?id=1933873 a keymap was set without
the package that provides it being installed (it2 is in kbd-legacy, which is
not installed by default). Setting a non-installed keymap is problematic,
because it results in nasty failures afterward (*). So let's to the same as
e.g. for locale data, and refuse a setting if the definition doesn't exists in
the filesystem.
The implementation using nftw() is not the most efficient, but I think it's OK
in this case. This is definitely not in any kind of hot path, and I prefer not
to duplicate the filename manipulation logic in a second function.
(*) If the keymap is not found, vconsole-setup.service will fail.
dracut-cmdline-ask.service has Requires=vconsole-setup.service, so it will also
fail, and this breaks boot. dracut-cmdline-ask.service having a hard dependency
is appropriate though: we sadly don't display what the keymap is, and with a wrong
keymap, any attempts to enter a password are likely to fail.
We would return a real error sometimes from the callback, and FTW_STOP other
times. Because of FTW_ACTIONRETVAL, everything except FTW_STOP would be
ignored. I don't think using FTW_ACTIONRETVAL is useful.
nftw() can only be used meaningfully with errno. Even if we return a proper
value ourselves from the callback, it will be propagated as a return value from
nftw(), but there is no way to distinguish this from a value generated by
nftw() itself, which is -1/-EPERM on error. So let's set errno ourselves so the
caller can at least look at that.
The code still ignores all errors.
Some code in systemd-run checks that a bus's unique name must start with
`:1.`. However the dbus specification on unique connection names only specifies
that it must begin with a colon. And the freedesktop/dbus implementation allows
allows unique names to go up to `:INT_MAX.INT_MAX`. So update the
current check to only look for a colon at the beginning.
Nominally, the bug was in unit_load_dropin(), which just took the last mtime
instead of calculating the maximum. But instead of adding code to wrap the
loop, this patch goes in the other direction.
All (correct) callers of config_parse() followed a very similar pattern to
calculate the maximum mtime. So let's simplify things by making config_parse()
assume that mtime is initialized and update it to the maximum. This makes all
the callers that care about mtime simpler and also fixes the issue in
unit_load_dropin().
config_parse_many_nulstr() and config_parse_many() are different, because it
makes sense to call them just once, and current ret_mtime behaviour make sense.
Fixes#17730, https://bugzilla.redhat.com/show_bug.cgi?id=1933137.
70-uaccess.rules sets the uaccess tag on devices with ID_SMARTCARD_READER
set, but it is set in 99-systemd.rules .
Move this to a 60-*.rules which already matches USB CCID class, factorising
the matching, so 70-uaccess.rules sets up these devices as expected.
It's useful to be able to combine a regular /usr/ file system with a
tmpfs as root, for an OS that boots up in volatile mode on every single
boot. Let's add explicit support for this via root=tmpfs.
Note the relationship to the existing systemd.volatile= option:
1. The kernel command line "root=/dev/… systemd.volatile=yes" will mount
the specified root fs, and then hide everything at the top by
overmounting it with a tmpfs, except for the /usr subtree.
2. The kernel command line "root=tmpfs mount.usr=/dev/…" otoh will mount
a toot fs at the top (just like the case above), but will then mount
the top-level dir of the fs specified in mount.usr= directly below
it.
Or to say this differently: in the first case /usr/ from the physical
storage fs is going to become /usr/ of the hierarchy ultimately booted,
while in the second case / from the physical storage fs is going to
become /usr of the hierarchy booted.
Philosophically I figure systemd.volatile= is more an option for
"one-off" boots, while root=tmpfs is something to have as default mode
of operation for suitable images.
This is currently hard to test reasonably, since Dracut refuses to
accept root=tmpfs. This needs to be addressed separately though.
Let's fine-tune the path_extract_filename() interface: on succes return
O_DIRECTORY as indicator that the input path was slash-suffixed, and
regular 0 otherwise. This is useful since in many cases it is useful to
filter out paths that must refer to dirs early on.
I opted for O_DIRECTORY instead of the following other ideas:
1. return -EISDIR: I think the function should return an extracted
filename even when referring to an obvious dir, so this is not an
option.
2. S_ISDIR, this was a strong contender, but I think O_DIRECTORY is a
tiny bit nicer since quite likely we will go on and open the thing,
maybe with openat(), and hence it's quite nice to be able to OR in
the return value into the flags argument of openat().
3. A new enum defined with two values "dont-know" and
"definitely-directory". But I figured this was unnecessary, given we
have other options too, that reuse existing definitions for very
similar purposes.
These two together are a lot like dirname() + basename() but have the
benefit that they return clear errors when one passes a special case
path to them where the extraction doesn't make sense, i.e. "", "/",
"foo", "foo/" and so on.
Sooner or later we should probably port all our uses of
dirname()/basename() over to this, to catch these special cases more
safely.
Add the i2c subsystem to those that create by-path links.
i2c devices may not have IDs so we can't rely on the by-id links
but they (or some of them) should at least have a path that we can use.
BPF filtering accesses fields in the netlink header that are
only filled in by libudev, never by the kernel. Therefore adding
BPF filters for kernel monitors is pointless. Even false filtering
of kernel events might be possible; at least it's hard to prove that
it can't occur.
