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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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)
(cherry picked from commit 90ba721560b67e329fff4f2c4e59f5c578d8f440)
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)
(cherry picked from commit f6388f561cad25f440c2637ce3f1399ed8ed9b7f)
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)
(cherry picked from commit 22c47d24a447112bbf8022a79d9c3940a2f04316)
Otherwise, several error logs may not be shown.
(cherry picked from commit a723521fd26d40ce90357e4e9b8131f1e1656ab5)
(cherry picked from commit ce06e000b8b7d993670cdd2f827c92c7fef4c93e)
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)
(cherry picked from commit b041337a7a5219398cb304e6cb31456327a7e371)
The nvme by-id symlink changes to the latest namespace when a new namespace gets
added, for example by connecting multiple NVMe/TCP host controllers via nvme
connect-all.
That is incorrect for persistent device links.
The persistent symbolic device link should continue to point to the same NVMe
namespace throughout the lifetime of the current boot.
Therefore the namespace id needs to be added to the link name.
(cherry picked from commit c5ba7a2a4dd19a2d31b8a9d52d3c4bdde78387f0)
(cherry picked from commit 059ca4fe8fc4740adc9690689f03de491b8d0e61)
`dracut.kernel.7` is just a symlink to `dracut.cmdline.7`, so the web reference
points to a non-existent URL
(https://man7.org/linux/man-pages/man7/dracut.kernel.7.html).
(cherry picked from commit 9baeb58fcdcd3b8893fc485bb33726820ce46e94)
(cherry picked from commit 2a8c1168b11f7144d98fa126bc9a06a2bc92383d)
The user manager connects to oomd over varlink. Currently, during
shutdown, if oomd is stopped before any user manager, the user
manager will try to reconnect to the socket, leading to a warning
from pid 1 about a conflicting transaction.
Let's fix this by ordering user@.service after systemd-oomd.service,
so that user sessions are stopped before systemd-oomd is stopped,
which makes sure that the user sessions won't try to start oomd via
its socket after systemd-oomd is stopped.
(cherry picked from commit cafd2c0be404cb8879f91d15e05cc8b695b32629)
(cherry picked from commit c4848032f132e0cb82c7967e5434378c98111a8c)
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)
(cherry picked from commit 2ead535f0d0ceec9b3b9565ed056c3ccef0779af)
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)
(cherry picked from commit 1b51f6a8f0f7fc891b2d5885190fdaffd82ccea2)
These are all under $XDG_RUNTIME_DIR/systemd instead of directly
under $XDG_RUNTIME_DIR.
(cherry picked from commit 80c7d4b8fa9f8283af7f0213739e3463c68a30f6)
(cherry picked from commit 16183e66f63f2023f77a3088c8a8ca7f3de9db59)
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)
(cherry picked from commit c7280b7c1f2bfeb4054c17eecd8a70f022115c32)
Necessary for some CI setups where we boot an nspawn container on a host
with older systemd with legacy hierarchy, so systemd mounts its stuff
under /sys/fs/cgroup/systemd.
(cherry picked from commit 715b4c26dc9f447a8d7b8cab33c243e15386ce2c)
(cherry picked from commit ff746117083e7418e378e46868aad601db57d920)
mkfs.btrfs (unlike mkfs.ext4) checks if the target already contains
a file system and refuses to continue if so. This causes spurious fails
in case the random garbage on the temporary device matches a valid FS
header:
[ 19.723806] testsuite-64.sh[355]: + udevadm lock --device=/dev/mapper/encbtrfs0 --device=/dev/mapper/encbtrfs1 --device=/dev/mapper/encbtrfs2 --device=/dev/mapper/encbtrfs3 mkfs.btrfs -M -d raid1 -m raid1 -L btrfs_mencdisk -U deadbeef-dead-dead-beef-000000000003 /dev/mapper/encbtrfs0 /dev/mapper/encbtrfs1 /dev/mapper/encbtrfs2 /dev/mapper/encbtrfs3
[ 19.918934] testsuite-64.sh[2494]: ERROR: /dev/mapper/encbtrfs0 appears to contain an existing filesystem (hfsplus)
[ 19.920490] testsuite-64.sh[2494]: ERROR: use the -f option to force overwrite of /dev/mapper/encbtrfs0
Let's force mkfs.btrfs to overwrite the file system in such case.
(cherry picked from commit b3ba7d6274aff864a80dc9b1ff7d88ad376da451)
(cherry picked from commit 12c3b1980b47a87139c3f4406161df69e7515873)
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)
(cherry picked from commit 4b12a1cf9249a2e59c2824958dfa6d56222c5d68)
When cpu controller is disabled, thing would often still behave as if
it was. And since the cpu controller can be enabled "magically" e.g. by
starting user@1000, add a note for users to be careful. Autogrouping
is described well in the man page, incl. how to enable or disable it,
so it should be enough to refer to that.
(cherry picked from commit dca031d2290311d8670d34fd758397644796e114)
(cherry picked from commit 6bef1f00852aaf7e0e599f510c84e97e3a27eed9)
For CPUWeight=: there is an important distinction between our default of
[not set], and the kernel default of "100". Let's not say that our default
is "100" because then 'systemctl show' output is hard to explain.
For task accounting, it's the kernel that does the accounting, not systemd.
(cherry picked from commit 396d298d6b0c50a3ab3242392de43dd50df6d45f)
(cherry picked from commit 2a31faf6255e06b757274d20cf98fdd8eae64fc6)
For a user, information which cgroup controllers are enabled based on
the unit configuration is rather important. Not only because it determines
what resource control is peformed by the kernel, but also because controllers
have a non-negligible cost, especially for deep nesting, and users may want
to *not* have controllers enabled.
Our documentation did its best to avoid the topic so far. This was partially
caused by the support for cgroup v1, which meant that any discussion of
controllers had to be conditional and messy. But v1 is deprecated on its way
out, so it should be fine to just describe what happens with v2.
The text is extended with a discussion of how controllers are enabled and
disabled, and an example, and for various settings that enable controllers
the relevant controller is now mentioned.
(cherry picked from commit 253d0d591bdca605c9a775e22407f9ae80003234)
(cherry picked from commit da8c0e0978c0fc91a70dbd5139208274cd8d9c0d)
The details discussion of how search and route-only domains work is in
systemd-resolved.service(8). But users are more likely to look at
resolved.conf(5), because that's where Domains= is described. So let's add a
reference to the other man page there, and also strengthen the text a bit. In
particular, in systemd-resolved.service(8) we say "route-only", which makes
the distinction with search domains clearer. Let's use the same in the other
man page too.
This is based on feedback from Lukáš Nykrýn that the man page is not clear
enough.
(cherry picked from commit 87291a26f5262c47bdb3493d15534c18f25870e6)
(cherry picked from commit c7afeee1e6b42d2c68074dc0b89ace502a16315b)
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)
(cherry picked from commit 25b5c24e59b63abe081c31e3d9a3dd392c2fdbae)
To make ConditionKernelCommandLine= or friend not confused when we are
running in a container.
Addresses https://github.com/systemd/systemd/pull/26887#discussion_r1143358884.
(cherry picked from commit d2ebd50d7f9740dcf30e84efc75610af173967d2)
(cherry picked from commit 0417b2875521424104d27229c13681c03baf9290)
[The patch didn't apply cleanly. When fixing stuff, I left the array size
as it was. The extra few bytes don't matter and this way it's unlikely to
be wrong.]
Follow-up for c5673ed0de3bec38f68d8113d253842b47766e27.
(cherry picked from commit 6920049fad4fa39db5fec712f82f7f75b98fd4b9)
(cherry picked from commit 0880a3af7775a3ecb022fa2bc772ef23c4fbbfd7)
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)
(cherry picked from commit bff4f7b3fd77b2dd2fe8813e2038a33a1992021e)
As we ignores the failure in merge_unit_ids(), so unit_ids may be NULL.
(cherry picked from commit 5803c24da5cf543a55c4fce9009a9c5f2b18519a)
(cherry picked from commit 591a82f24fa233e8011a8baf8bade597d550e557)
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)
(cherry picked from commit 7002c5c210a7ae3607bd8a424112e9f8789bc5f9)
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)
(cherry picked from commit 56a81351afe89711442058a5b373cafa0288feaf)
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)
(cherry picked from commit 88d8ab119df0239e70a5312f1f2c179c7f642dec)
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)
(cherry picked from commit 59ae2a45a92025097de94cc7c0c622aa990179cf)
