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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This restores the preference order from before 9e82a74. The code
previous to that change 'preferred' /boot over /boot/efi; that
commit changed it to check /boot/efi before checking /boot.
Changing this precedence could (and did, for me) have unexpected
effects - it seems safer to leave it how it was.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
(cherry picked from commit a5307e173b)
Otherwise, systemd-homed-active.service will fail to deactivate all
homes because homectl can no longer talk to homed if dbus stops first.
As a result, /home cannot be umounted.
Doing this on systemd-homed-active.service instead works as well, but
systemd-homed will exit 1 if dbus is already shut down.
(cherry picked from commit e00a25a7b4)
BPF LSM is cgroup unaware and it's set up is happening in core manager.
It occures that the current implementation is too restrictive and causes
pid 1 to freeze.
Instead:
* in bpf_lsm_setup set manager->restrict_fs pointer last,
so it is an indicator that the set up was successful
* check for manager->restrict_fs before applying unit options
(cherry picked from commit 299d941723)
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.
(cherry picked from commit b7cba81553)
If the action failed, we should log about the issue, and continue.
Exiting would bring the graphical session down, which of course is not
appreciated by users.
As documented in previous commits, a non-negative return from the callback
doesn't matter, so the callback is simplified a bit.
Fixes#21991.
(cherry picked from commit 8207b8321b)
Otherwise we might hit a window where the coredump happens before
midnight, but we check for it after midnight, which yields no results.
E.g.:
```
$ coredumpctl --no-legend --no-pager --file system.journal
Wed 2022-01-05 01:00:06 CET 359 0 0 SIGABRT journal /usr/bin/udevadm n/a
$ coredumpctl --since 23:59:55 --no-legend --no-pager --file system.journal
No coredumps found.
$ coredumpctl --since "2022-01-04 23:59:59" --no-legend --no-pager --file system.journal
Wed 2022-01-05 01:00:06 CET 359 0 0 SIGABRT journal /usr/bin/udevadm n/a
```
(cherry picked from commit 1b51599f29)
The previous message was confusing errors. When we're rotating because
we've reached the file size limit, let's log a better message.
Fixes#22007.
(cherry picked from commit eff79e4e22)
The check was added in 77547d5313, 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:
>>> from parse_hwdb import *
>>> g = 'v' + upperhex_word(4) + Optional('p' + upperhex_word(4))
>>> g.parseString('v04D8pE11C*')
(['v', '04D8', 'p', 'E11C'], {})
>>> g.parseString('v04D8pe11c*')
(['v', '04D8'], {})
The following matches are OK:
usb:v0627p0001:*QEMU USB Keyboard*
usb:v0627p0001:*
usb:v0627p0001*
usb:v0627*
(cherry picked from commit 1a37237e2f)
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.)
(cherry picked from commit e897b07f97)
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.
(cherry picked from commit 5f74fcd41c)
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.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2036517.
(cherry picked from commit c790632cab)
The flag is now only used in test-sysctl-util.c, and it should be
replaced with uname(), because of the same reason as the previous
commit.
(cherry picked from commit 9383fa08bd)
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.
Fixes#21896.
(cherry picked from commit d8d6b2275f)
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.
Fixes: #21956
(cherry picked from commit 75747c8a39)
This fixes a bug introduced by eaba9bb3e6.
The commit mistakenly drops 'x' in ID_NET_NAME_MAC, and adds colons.
The colons were dropped by the commit dfa4876c41,
but the missing 'x' was not added at that time.
Follow-up for dfa4876c41.
(cherry picked from commit 60e930fc3e)
Meson would generate the following compile test:
#define crypt_set_metadata_size meson_disable_define_of_crypt_set_metadata_size
#include <limits.h>
#undef crypt_set_metadata_size
#ifdef __cplusplus
extern "C"
#endif
char crypt_set_metadata_size (void);
#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;
}
which seems to work correctly.
(cherry picked from commit aac8071730)
But handle them gracefully. Otherwise, when the route to the address is
being configured, kernel refuse the route.
Note that kernel's wireguard module handle e.g. 192.168.10.3/24 as
192.168.10.0/24.
Fixes#21929.
(cherry picked from commit af670fc635)
This also fixes the pointer assigned to the gr_mem element of struct group.
Fixes a bug introduced by 47fd7fa6c6.
Fixes#21935.
(cherry picked from commit 1e65eb8f9b)
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.
Fixes https://github.com/systemd/systemd/issues/21933
(cherry picked from commit 466f2351bb)
