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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We shouldn't report that the file is empty if the stating fails. Let's do the
same as in other places, and just ignore the error and let the subsequent
operation fail.
(cherry picked from commit 7d0c47dad0d4282c3924a654a8fe18fc5d7766f8)
Currently, active journal files are excluded, which means that vacuuming
may not remove anything even if *MaxUse= has been exceeded.
(cherry picked from commit 9ea46af4f2368b41d57705bac09774778126507f)
It's a sycall group of our own definition, and the output is erroneous
to claim otherwise. Let's hide it.
This adds syscall_set_add() which is nicely symmetric to the existing
syscall_set_remove().
Follow-up for: 6d6a08547c03f96dc798cda1ef4a8d3013d292d5
(cherry picked from commit 950c0ed38935198a67a57c645e499555eaf006eb)
These three new syscalls are mostly just new flavours or extensions of
existing syscalls, hence add them to the same groups.
(cherry picked from commit 76e86b8dd8cca9f9fee120289945b29e1dbbe215)
My user manager says:
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.gnome.Terminal.desktop:256: Unknown key name 'Actions' in section 'Desktop Entry', ignoring.
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.gnome.Terminal.desktop:258: Unknown section 'Desktop Action new-window'. Ignoring.
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.gnome.Terminal.desktop:343: Unknown section 'Desktop Action preferences'. Ignoring.
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.telegram.desktop.desktop:12: Unknown key name 'Actions' in section 'Desktop Entry', ignoring.
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.telegram.desktop.desktop:13: Unknown key name 'SingleMainWindow' in section 'Desktop Entry', ignoring.
systemd-xdg-autostart-generator[2933]: /home/zbyszek/.config/autostart/org.telegram.desktop.desktop:19: Unknown section 'Desktop Action Quit'. Ignoring.
This is not useful. Those are externally-provided files, and they are likely to
have entries which we know nothing about.
(cherry picked from commit b5a70eeecdb593f8498c0bc163d5a12297cfb55d)
btrfs_get_block_device_fd() returns -ENOTTY if fstatfs().f_type !=
BTRFS_SUPER_MAGIC
btrfs_get_block_device_fd() is run by verify_fsroot_dir() by
verify_xbootldr() by find_xbootldr_and_warn() if
statx($presumed-XBOOTLDR).stx_dev_major == 0 ("maybe a btrfs device")
Every bootctl verb_install() runs find_xbootldr_and_warn(), by default
with /boot
If your /boot .stx_dev_major=0 but /not/ btrfs, bootctl install/update
quietly exits 1 with no note so as to what exactly failed (debug also
empty, and the strace isn't exactly clear since no syscall actually
failed)
This is the case on ZFS and the Debian filesystem layout: /boot/efi is
the ESP, and everything else under / is ZFS:
$ sudo env SYSTEMD_LOG_LEVEL=debug bootctl update
Found cgroup2 on /sys/fs/cgroup/, full unified hierarchy
Found container virtualization none.
File system "/boot" is not a FAT EFI System Partition (ESP) file system.
Using EFI System Partition at /boot/efi.
Checking whether /boot/efi/EFI/systemd/ contains any files…
$ echo $?
1
and funnier still:
$ sudo bootctl update --graceful
$ echo $?
1
Which is great, and also breaks postinst, which runs precisely the
latter, with no feedback at all
By checking for -ENOTTY we accept that the path being investigated
"is not it" if it's on ZFS (and any other filesystem that returns
.stx_dev_major == 0 but isn't btrfs)
(cherry picked from commit ed89819f8fd7bfe99cd652082076e85e1417e4e9)
Uncompressed aarch64 and riscv64 kernels have a different startpoint than x86.
Example output from ukify:
aarch64: NotImplementedError: unknown file format (starts with b'MZ@\xfa')
riscv64: NotImplementedError: unknown file format (starts with b'MZo\x10')
Add check for (b'MZ') to catch both in one call.
Fix:
https://github.com/systemd/systemd/issues/26923
(cherry picked from commit bf9f07a62966043c0f1fd7ac4a249790643d1f9a)
Whenever we're going to close all file descriptors, we tend to close
the log and set it into open when needed mode. When this is done with
the logging target set to LOG_TARGET_AUTO, we run into issues because
for every logging call, we'll check if stderr is connected to the
journal to determine where to send the logging message. This check
obviously stops working when we close stderr, so we settle the log
target before we do that so that we keep using the same logging
target even after stderr is closed.
(cherry picked from commit a3b00f91bb985fa10bc33db5c7883e33dbdf83d0)
Suppress errors when creating/writing EFI variables during 'bootctl update' if
'--graceful' mode is active (as the documentation indicates).
Closes#26773.
(cherry picked from commit 06d104d58ffa23c958b9b2a2809c61fb25e6f762)
systemd-dissect requires the entirety of the partition following the
signature to be zeroed, so let's do just that.
(cherry picked from commit d28c6ce62c4915ec5f7e10dc49be5e51c2356dad)
This case is a bit surprising, even if logical if one understands how the
parser works. Let's be more explicit.
Follow-up for 7b3693e4e4c9cae50fca65136278a62fae11327e.
(cherry picked from commit 449172f943acadc7fd1e2293a615c7cb0d87fcd6)
If no usage type is explicitly specified, ext will choose one based
on the filesystem size. Let's override this and always use the
"default" usage type so that we can create filesystems that are
initially small but might grow later without opting in to the "small"
usage type.
(cherry picked from commit 59c3c195f432243a1d4b2a7210e9699db83cb335)
Although it may be true that /sysroot and its children don't belong in
local-fs.target, that doesn't mean they shouldn't come after
local-fs-pre.target. For instance, systemd-hibernate-resume@.service needs to
come before /sysroot and its children, but currently that only happens
coincidentally because of the ordering between systemd-fsck@.service and
local-fs-pre.target. As a result, mount units can be mistakenly started
simultaneously with systemd-hibernate-resume@.service, which can cause
corruption and data loss in the worst of cases.
(cherry picked from commit 6e017b19a804639101fc87b4b78c02f7639c6d0c)
Read the magic first, try reading the full DOS exe header only in case
the magic check succeeds.
This avoids throwing an header read error on small dummy files as used
by test-kernel-install.
(cherry picked from commit 78088b8f43717a43661cd2c1627a9860904c4794)
For any user on a semi-recent kernel, effectively this setting is pointless.
We should deprecate it once not needed anymore for the v1 hierarchy. For
now, adjust the description.
(cherry picked from commit 695e39dd632801871b4e96b39bc8e7511083a34e)
Reloading might be slow, especially when under memory pressure, and watchdogs
might be triggered. It is useful to have timestamped telemetry in the journal
to see how long a reload takes.
(cherry picked from commit af2fb2f250e664973d947554414749e9b94d68a1)
IN C23, thread_local is a reserved keyword and we shall therefore
do nothing to redefine it. glibc has it defined for older standard
version with the right conditions.
v2 by Yu Watanabe:
Move the definition to missing_threads.h like the way we define e.g.
missing syscalls or missing definitions, and include it by the users.
Co-authored-by: Yu Watanabe <watanabe.yu+github@gmail.com>
(cherry picked from commit 5545f336fd09148e8d9aa7f83ed19384deaf7a64)
'pos' is incremented after each assignment. If we use the maximum number
of arguments, we end up with pos==9 after all the assignments, and it
points to where the next value would be assigned. This position must remain
NULL.
The assert I "fixed" was intentionally introduced in
26abdc73a212b90f7c4b71808a1028d2e87ab09f as a bugfix. So my "fix" repeated
the same error that was fixed back then.
(cherry picked from commit 14ecfc1cd2e8050214b56cf3588740e20666b3cd)
Fixup for d2ebd50d7f9740dcf30e84efc75610af173967d2
and 6920049fad4fa39db5fec712f82f7f75b98fd4b9:
- add a comment that the last arg must be NULL and adjust the assert.
- move initialization around so that fields are declared,
initialized, and consumed in the same order.
- move declaration of pos adjacent do declaration of command_line.
This makes it easy to see that it was not initialized correctly.
- initialize buffers before writing the pointer into the args array.
This makes no difference for the compiler, but it just feels "wrong"
to do it in opposite order.
Because pos was off, we would ignore args after the timeout, and also
overwrite the buffer if enough args were used.
I think this is case shows clearly that declaring all variables at the
top of the function, with some initialized and other not, is very
error-prone. The compiler has no issue with declaring variables whereever,
and we should take advantage of this to make it keep declaration,
initialization, and use close. (Within reason of course.)
(cherry picked from commit 4688b08984cef43414a236d1c2afc5860a1703b9)
Fixes a bug introduced by 3e4d0f6cf99f8677edd6a237382a65bfe758de03.
The auxv metadata is unaligned, as the length of the prefix
"COREDUMP_PROC_AUXV=" is 19. Hence, parse_auxv{32,64}() may triger
an undefined behavior (or at least cause slow down), which can be
detected when running on an undefined behavior sanitizer.
This also introduces a macro to define `parse_auxv{32,64}()`.
Fixes#26912.
(cherry picked from commit 9b032f932c4172fac379234d9d42cf2b266ccaea)
Follow-up for 924775e8ce49817f96df19c2b06356c12ecfc754.
The loop run with `STRV_FOREACH_PAIR()`, hence `if (*(unit_id+1))` is
not a good way to detect if there exist a next entry.
Fixes#26872.
(cherry picked from commit 366eced4c81a15a25b9225347fa203aa67798b02)
This reverts commit cd3c8a117ccf3505e49d34324473e2175ef0a9ce which was
papering over the bug instead of a proper fix made by the previous
commit.
(cherry picked from commit 8c499a61c46eb434db04d3ee4b116a0a755b3797)
For those token types that support matching of alternative patterns,
their token values are interpreted as nulstr, so make sure the parser
does the right thing and makes these token values terminated by two
subsequent NULs so they could be safely interpreted as nulstr.
Before this fix, the following rules would result to "echo foo" invocation:
ENV{foo}=", RUN"
ENV{foo}=="bar", RUN+="echo foo"
because the value of `ENV{foo}` is treated as nulstr, and it used to match
against alternative patterns, in this case `bar`, `, RUN`, and `="echo foo`.
Fixes: 25de7aa7b90c ("udev: modernize udev-rules.c")
(cherry picked from commit c43ff248f94266cfc93e300a2d3d163ed805e55b)
We want an empty string, not NULL. I made some brainfart here.
Fixup for 1980a25dc03aa500d4ee2725d696f68d265cd4ca.
(cherry picked from commit add74820b72be58f57722000a343ee3b63195eff)
Commit 76a86ffdbee2dd9ef0f2b5338e14eb6ba7671456 added function
ipv4acd_update_mac() but invoked ipv4ll_update_mac(), which doesn't
align with debug or commit messages.
(cherry picked from commit 0a14f83a0edb2c809c932b5d98240dd10a6bb79a)
Follow-up for 82c2095a5e407bcf041dc7bde84791deec95ff9c.
> I feel like the logging here may be a bit confusing on the new path.
> Previously you did get a message that explained what was going on. Now you get
> an info message that the layout could not be compiled, and … that's all. I can
> imagine this being a confusing red herring if someone was trying to debug a
> problem and saw this message. Perhaps we should log something else instead/as
> well, on the case where libxkbcommon isn't present, to say that's what we're
> logging about and it just means we can't validate the configuration, not that
> it's definitely invalid?
(cherry picked from commit 080ecabfd78df6e97530c6d9aaa2e0e78746dd29)
When compliled without libxkbcommon, we do no verification and accept the
arguments as given. When compliled against with, if dlopen() works, we do the
verification. But if dlopen() fails, we would refuse the call and return
SD_BUS_ERROR_INVALID_ARGS. 5de344704df64d8f31448f1222432bc87ddcfbef added things
this way when converting to dlopen(), but it seems not very useful: it can be
expected that when the library is supported but missing at runtime, we degrade
softly, and that the behaviour is something inbetween the cases of hard disable
at compilation time and full support. But right now we behave more strictly then
if disabled at compilation. Change the code to just warn if dlopen fails, but
accept the arguments.
(There are various minimization scenarios where forcing the installation of
libxkbcommon is not useful. E.g. a small installation where we want to set the
keymap via logind, but the configuration is managed by a configuration
management system and is known to be valid. Verification via libxkbcommon is
just overhead in this case.)
800f65f827c9828d4c872d44b19ca8a008505690 moved the check earlier, so now even
a noop case of setting the values that were already in place can fail.
C.f. https://bugzilla.redhat.com/show_bug.cgi?id=2175244.
(cherry picked from commit 82c2095a5e407bcf041dc7bde84791deec95ff9c)
