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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Everywhere else that `conf.get('ENABLE_*')` is used as a boolean key for
something (for example in if statements) it always checks if == 1, but
in this one case it neglects to do so. This is important because
conf.get yields the same int that was stored, but if statements require
booleans.
So does executable's "install" kwarg, at least according to the
documentation. In actuality, it accepts all types without sanity
checking, then uses python "if bool(var)", so you can actually do
`install: 'do not'` and that's treated identical to `true`. This is a
type-checking bug which Meson will eventually fix.
muon fails on the same code, today.
(cherry picked from commit 9e4a50bcdf)
(cherry picked from commit 3a382bf86b)
by default, gcrypt defaults to an userspace RNG, this is
the wrong thing (tm) to do on linux.
Switch to the SYSTEM rng instead.
(cherry picked from commit 80f967311a)
(cherry picked from commit ca0ed3a78c)
Kubevirt is currently technically based on KVM (but not xen yet[1]).
The systemd-detect-virt command, used to differentiate the current
virtualization environment, works fine on x86 relying on CPUID, while
fails to get the correct value (none instead of kvm) on aarch64.
Let's fix this by adding a new 'vendor[KubeVirt] = kvm' classification
considering the sys_vendor is always KubeVirt.
[1] https://groups.google.com/g/kubevirt-dev/c/C6cUgzTOsVg
Signed-off-by: Fei Li <lifei.shirley@bytedance.com>
(cherry picked from commit c15d1ac2c4)
(cherry picked from commit e7d635f0b9)
Known-Answer list whose remaining TTL is less than half of their original TTL
(cherry picked from commit f941c12427)
(cherry picked from commit ef6c379089)
Fixes the following assertion:
---
Assertion 'r > 0' failed at src/resolve/resolved-mdns.c:180, function mdns_do_tiebreak(). Aborting.
---
(cherry picked from commit f2605af1f2)
(cherry picked from commit 0070302b3c)
Also, this makes mDNS regular queries sent without delay (except for
one caused by the default accuracy of sd-event).
Note, RFC 6762 Section 5.2 is about continuous mDNS query, which is not
implemented yet.
(cherry picked from commit 765647ba80)
(cherry picked from commit 41810cb166)
When running on images you don't want to modify the /tmp
directory even if it's writable, and often it will just
be read-only. Set PrivateTmp=yes.
Fixes https://github.com/systemd/systemd/issues/23592
(cherry picked from commit f2d26cd89b)
(cherry picked from commit 6e111d2811)
This reverts commit e4de58c823.
If mkdir() fails and the path does exist, then the later mount
command fails anyway. Hence, it is not necessary to fail here.
Fixes#24120.
(cherry picked from commit e5e6b7c225)
(cherry picked from commit b1e494d64d)
We ignore xattr copy failures on all other cases, and we should do so
here too.
Fixes: #24106
(cherry picked from commit d3efe29452)
(cherry picked from commit 200cbc299b)
The variable `inst` was set to NULL by TAKE_PTR().
This fixes the following log message:
```
systemd[1]: Unit getty@tty2.service has alias (null).
```
(cherry picked from commit 7c35b78a0b)
(cherry picked from commit 9ac0ad80fe)
For the system manager, /run/systemd/private is publicly accessible, because
/run/systemd is 0755, and /run/systemd/private is 0777. For the user manager,
/run/user/<uid> is 0700, and /run/user/<uid>/systemd/private is 0777. This
does not directly cause any security issue because we check the sender in
bus_check_peercred (ucred.uid != 0 && ucred.uid != geteuid()).
But it makes sense to limit access to the socket to avoid wasting time in PID1.
Somebody could send messages there that'd we'd reject anyway. It also makes
things more explicit.
(cherry picked from commit df1cbd1adf)
(cherry picked from commit dc3333bcc9)
since in this specific case (r == 0) `errno` is irrelevant and most likely
set to zero, leading up to a confusing message:
```
[ 120.595085] H systemd[1]: session-5.scope: No PIDs left to attach to the scope's control group, refusing: Success
[ 120.595144] H systemd[1]: session-5.scope: Failed with result 'resources'.
```
(cherry picked from commit e99b9285cb)
(cherry picked from commit 5c822e33c9)
Whitespace inside of the <varname> field was propagated to the displayed form,
causing strange indentation.
(cherry picked from commit 9cfc294fe0)
(cherry picked from commit b7c5530a1f)
Ambient capabilities should not be passed implicitly to user
services. Dropping them does not affect the permitted and effective sets
which are important for the manager itself to operate.
(cherry picked from commit 963b6b906e)
(cherry picked from commit c88309d5cd)
Inspired by https://github.com/systemd/systemd/pull/24024 this is
another user mode helper, where this might be an issue. hence let's
rather be safe than sorry, and also connect stdin/stdout/stderr
explicitly with /dev/null.
(cherry picked from commit 50492ce815)
(cherry picked from commit 689487785f)
When invoked as the coredump handler by the kernel, systemd-coredump's
stdout and stderr streams are closed. This is dangerous as this means
the fd's can get reallocated, leading to hard to debug errors such as
log messages ending up being appended to a compressed coredump file.
To avoid such issues in the future, let's bind stdout/stderr to
/dev/null so the file descriptors can't get used for anything else.
(cherry picked from commit 1f9d2a8199)
(cherry picked from commit fba50bc0fc)
Let's not allow anyone to look into /root/ if we create it via the
base-filesystem logic. i.e. change 0755 → 0750 as default access mode
for /root/, in case we create it if it happens to be missing.
(cherry picked from commit 93cbc9ca12)
(cherry picked from commit 64be8d8a34)
This current code checks the wrong directory. This was broken in
4c39d899ff which converted the previous
code incorrectly.
(cherry picked from commit 92631578ff)
(cherry picked from commit 625472b219)
This new call can execute both of the old operations, but also do
generic fstatat() like behaviour.
(cherry picked from commit a586dc791c)
(cherry picked from commit 9255fa3a15)
This allows growfs to expand the filesystem even when the underlying
block device cannot be expanded. This has been useful for example on
LUKS devices that have already been expanded using systemd-repart.
This works around the following error:
```
root@mobian:/home/mobian# /usr/lib/systemd/systemd-growfs /
crypt_resize() of /dev/block/179:2 failed: Operation not permitted
```
(cherry picked from commit e9a28b8ccd)
(cherry picked from commit 378e187ed4)
This causes systemd-growfs to exit before resizing the partition when
`--dry-run` is passed. Resizing during a dry run of a change breaks the
users expectations.
(cherry picked from commit d26c0f7243)
(cherry picked from commit 00c6c62845)
Otherwise, sd-device object received through sd-device-monitor does not
show current tags.
Fixes#23799.
(cherry picked from commit 4bc4040bc0)
(cherry picked from commit 7f80102343)
In most cases, it is not necessary to call them without retrieving
result. But, most of other getter functions for sd-device can take NULL.
Let's follow the way for consistency.
(cherry picked from commit 793ab3e9dd)
(cherry picked from commit 925cff4a15)
Newer binutils versions currently trigger the following warnings due to
a bug in gnu-efi
on arm64:
/usr/bin/ld.bfd: warning: src/boot/efi/systemd-bootaa64.elf has a LOAD segment with RWX permissions
on amd64:
/usr/bin/ld.bfd: warning: /usr/lib/crt0-efi-x86_64.o: missing .note.GNU-stack section implies executable stack
This results in a build failure due to --fatal-warnings.
Work around this issue by suppressing those warnings until gnu-efi has
been fixed.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1013341
(cherry picked from commit b0e5bf0451)
(cherry picked from commit 8a6f966be4)
dm-crypt device units generated by systemd-cryptsetup-generator
habe BindsTo= dependencies on their backend devices. The dm-crypt
devices have the db_persist flag set, and thus survive the udev db
cleanup while switching root. But backend devices usually don't survive.
These devices are neither mounted nor used for swap, thus they will
seen as DEVICE_NOT_FOUND after switching root.
The BindsTo dependency will cause systemd to schedule a stop
job for the dm-crypt device, breaking boot:
[ 68.929457] krypton systemd[1]: systemd-cryptsetup@cr_root.service: Unit is stopped because bound to inactive unit dev-disk-by\x2duuid-3bf91f73\x2d1ee8\x2d4cfc\x2d9048\x2d93ba349b786d.device.
[ 68.945660] krypton systemd[1]: systemd-cryptsetup@cr_root.service: Trying to enqueue job systemd-cryptsetup@cr_root.service/stop/replace
[ 69.473459] krypton systemd[1]: systemd-cryptsetup@cr_root.service: Installed new job systemd-cryptsetup@cr_root.service/stop as 343
Avoid this by not setting the state of the backend devices to
DEVICE_DEAD.
Fixes the LUKS setup issue reported in #23429.
(cherry picked from commit cf1ac0cfe4)
(cherry picked from commit 4f86dd2849)
Commit 70e74a5997 ("pstore: Run after modules are loaded") added After=
and Wants= entries for all known kernel modules providing a pstore.
While adding these dependencies on systems where one of the modules is
not present, or not configured, should not have a real affect on the
system, it can produce annoying error messages in the kernel log. E.g.
"mtd device must be supplied (device name is empty)" when the mtdpstore
module is not configured correctly.
Since dependencies cannot be removed with drop-ins, if a distro wants to
remove some of these modules from systemd-pstore.service, they need to
patch units/systemd-pstore.service.in. On the other hand, if they want
to append to the dependencies this can be done by shipping a drop-in.
Since the original intent of the previous commit was to fix [1], which
only requires the efi_pstore module, remove all other kernel module
dependencies from systemd-pstore.service, and let distros ship drop-ins
to add dependencies if needed.
[1] https://github.com/systemd/systemd/issues/18540
(cherry picked from commit 8b8bd621e1)
The systemd-pstore service takes pstore files on boot and transfers them
to disk. It only does it once on boot and only if it finds any. The typical
location of the pstore on modern systems is the UEFI variable store.
Most distributions ship with CONFIG_EFI_VARS_PSTORE=m. That means, the
UEFI variable store is only available on boot after the respective module
is loaded.
In most situations, the pstore service gets loaded before the UEFI pstore,
so we don't get to transfer logs. Instead, they accumulate, filling up the
pstore over time, potentially breaking the UEFI variable store.
Let's add a service dependency on any kernel module that can provide a
pstore to ensure we only scan for pstate after we can actually see pstate.
I have seen live occurences of systems breaking because we did not erase
the pstates and ran out of UEFI nvram space.
Fixes https://github.com/systemd/systemd/issues/18540
(cherry picked from commit 70e74a5997)
On switching root, a device may have a persistent databse. In that case,
Device.enumerated_found may have DEVICE_FOUND_UDEV flag, and it is not
necessary to downgrade the Device.deserialized_found and
Device.deserialized_state. Otherwise, the state of the device unit may
be changed plugged -> dead -> plugged, if the device has not been mounted.
Fixes#23429.
[mwilck: cherry-picked from #23437]
(cherry picked from commit 4fc69e8a09)
(cherry picked from commit 131206de78)
The issue #12953 is caused by the following:
On switching root,
- deserialized_found == DEVICE_FOUND_UDEV | DEVICE_FOUND_MOUNT,
- deserialized_state == DEVICE_PLUGGED,
- enumerated_found == DEVICE_FOUND_MOUNT,
On switching root, most devices are not found by the enumeration process.
Hence, the device state is set to plugged by device_coldplug(), and then
changed to the dead state in device_catchup(). So the corresponding
mount point is unmounted. Later when the device is processed by udevd, it
will be changed to plugged state again.
The issue #23208 is caused by the fact that generated udev database in
initramfs and the main system are often different.
So, the two issues have the same root; we should not honor
DEVICE_FOUND_UDEV bit in the deserialized_found on switching root.
This partially reverts c6e892bc0e.
Fixes#12953 and #23208.
Replaces #23215.
Co-authored-by: Martin Wilck <mwilck@suse.com>
(cherry picked from commit 75d7b5989f)
