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 had two of each: both homectl and journalctl had the whole dlopen()
wrapper, and journalctl had two implementations (slightly different) of the
code to print the fss:// pattern.
print_qrcode() now returns -EOPNOTSUPP when compiled with qrcode support. Both
callers ignore the return value, so this changes nothing.
No functional change.
For encrypted block devices that we need to unlock from the initramfs,
we currently rely on dracut shipping `cryptsetup.target`. This works,
but doesn't cover the case where the encrypted block device requires
networking (i.e. the `remote-cryptsetup.target` version). That target
however is traditionally dynamically enabled.
Instead, let's rework things here by adding a `initrd-cryptsetup.target`
specifically for initramfs encrypted block device setup. This plays the
role of both `cryptsetup.target` and `remote-cryptsetup.target` in the
initramfs.
Then, adapt `systemd-cryptsetup-generator` to hook all generated
services to this new unit when running from the initrd. This is
analogous to `systemd-fstab-generator` hooking all mounts to
`initrd-fs.target`, regardless of whether they're network-backed or not.
Why this change
---------------
Assumption - PAM's auth stack is properly configured.
Currently account pam_systemd_home.so returns PAM_SUCCESS for non
systemd-homed users, and a variety of return values (including
PAM_SUCCESS) for homed users.
account pam_unix returns PAM_AUTHINFO_UNAVAIL for systemd-homed
users, and a variety of return values (including PAM_AUTHINFO_UNAVAIL)
for normal users.
No possible combination in the pam stack can let us preserve the
various return values of the modules. For example, the configuration
mentioned in the manpage causes account pam_unix to never be reached
since pam_systemd_home just returns a success for ordinary users. Users
with expired passwords are allowed to log in because a check cannot be
made.
More configuration examples and why they don't work are mentioned
in #16906 and the downstream discussion linked there.
After this change
-----------------
account pam_unix will continue to return wrong value for homed users.
But we can skip the module conditionally using the return value from
account pam_systemd_home. We can already do this with the auth and
password modules.
This creates a private mount namespace for test-mountpint-util, with all
propagation from the host turned off. This gives us the guarantee that
/proc/self/mountinfo remains fixed and constant while we operate,
removing potential races against other unrelated stuff running on the
system that changes the mount table.
Prompted-by: #17050
(I doubt this actually fixes 17050, this is mostly to make sure that we
aren't possibly affected by such races in our test)
Failed to enter shared memory directory multipath: Permission denied
→
Failed to enter shared memory directory /dev/shm/multipath: Permission denied
When looking at nested directories, we will print only the final two elements
of the path. That is still more useful than just the last component of the
path. To print the full path, we'd have to allocate the string, and since the
error occurs so very rarely, I think the current best-effort approach is
enough.
So far we didn't allow empty properties, but it makes sense to do so, for
example to distinguish empty data from lack of data. It also makes it easy to
override properties (back to the empty) value for specific cases.
Using `bootctl set-default @current` will set the default loader entry
to the currently booted entry as read from the `LoaderEntrySelected` EFI
variable.
Also `bootctl set-oneshot @current` will set the oneshot loader entry to
the current booted entry.
Correspondingly `@default` and `@oneshot` can be used to read from the
LoaderEntryDefault and LoaderEntryOneshot EFI variables.
Recently the Semaphore CI started to fail pretty much constantly due to
GPG key verification fails. After a quick search this is a pretty common
issue with the Ubuntu keyserver in the last month. To make this,
hopefully, a bit more stable, let's use a few different keyservers in
case some of them fail.
Previously, .device units generated by SYSTEMD_ALIAS= udev properties
are not supported to specify devices for e.g. 'udevadm info'.
Before:
```
$ udevadm info sys-subsystem-net-devices-enp0s31f6.device
Unknown device "sys-subsystem-net-devices-enp0s31f6.device": No such device
```
After:
```
$ ./udevadm info sys-subsystem-net-devices-enp0s31f6.device
P: /devices/pci0000:00/0000:00:1f.6/net/enp0s31f6
L: 0
E: DEVPATH=/devices/pci0000:00/0000:00:1f.6/net/enp0s31f6
E: INTERFACE=enp0s31f6
E: IFINDEX=2
E: SUBSYSTEM=net
E: USEC_INITIALIZED=25317523
E: ID_NET_NAMING_SCHEME=v245
(snip)
```
By making them unsigned comparing them with other sizes is less likely
to trigger compiler warnings regarding signed/unsigned comparisons.
After all sizes (i.e. size_t) are generally assumed to be unsigned, so
these should be too.
Prompted-by: https://github.com/systemd/systemd/pull/17345#issuecomment-709402332
The properties are not unquoted by udev, so the quotes effectively became part
of the value.
Even though those properties were added quite a while ago
(086c001e29,
d7d31692bf), they never started being used
(because of issues with having multiple layouts), see
https://gitlab.gnome.org/GNOME/mutter/-/issues/906,
https://bugzilla.gnome.org/show_bug.cgi?id=775681.
Let's remove the quotes while we still can.
From https://bugzilla.gnome.org/show_bug.cgi?id=775681#c7:
> Note to self: the values for XKB_FIXED_LAYOUT and XKB_FIXED_VARIANT are
> quoted, meaning that we need to remove the quotes before passing the values
> from udev_device_get_property_value() to xkb_keymap_new_from_names()
> otherwise the compilation of the keymap fails (please don't ask how I found
> out...)
`route_get()` compares input with existing routes, however previously,
the input may did not have information about gateway. So, the
comparison result might be incorrect, and the foregoing set_put() might
return -EEXIST.
With the switch from log_debug() to log_debug_errno() in commit c413bb28df
systemd-update-done would fail without any error message if /etc
or /var were read-only. This restores the previous behaviour to
silently ignore these directories again.
Ensure that systemd-random-seed.service has completed before marking
a first boot as completed to guarantee that a saved seed will only be
used after it has been initialized at least once.
Make sure systemd-firstboot completes before reaching first-boot-complete.target
and thus marking the first boot as completed. This way, it is
guaranteed that systemd-firstboot has a chance to complete provisioning
at least once, even in cases of the first boot getting aborted early.
Add a new target for synchronizing units that wish to run once during
the first boot of the system. The machine-id will be committed to disk
only after the target has been reached, thus ensuring that all units
ordered before it had a chance to complete.
sync() before committing a transient machine-id to disk. This will
ensure that any filesystem changes made by first-boot units will have
been persisted before the first boot is marked as completed.
Currently, a loss of power after the machine-id was written but before
all units with ConditionFirstBoot=yes ran would lead to the next boot
finding a valid machine-id, thus not being marked first boot and not
re-running these units.
To make the first boot mechanism more robust, instead of writing
/etc/machine-id very early, fill it with a marker value "uninitialized"
and overmount it with a transiently provisioned machine-id. Then, after
the first boots completes (when systemd-machine-id-commit.service runs),
write the real machine-id to disk.
This mechanism is of course only invoked on first boot. If a first boot
is not detected, the machine-id is handled as previously.
Fixes: #4511
If the first boot was aborted, /etc/machine-id might read as
"uninitialized" in some cases. Add a separate case for this
instead of printing a confusing error message.
When systemd-repart runs from initramfs, it reads out /etc/machine-id
from the rootfs as a seed for partition UUIDs. However, the machine-id
could be in an "uninitialized" state from a previous failed first boot.
In this situation the -ENOMEDIUM code-path (no machine-id set) should be
taken.
When nspawn starts an image, this image could be in any state, including
an aborted first boot. For this case, it needs to correctly handle the
situation like there was no machine-id at all.
Add a new ID128_PLAIN_OR_UNINIT format which treats the string
"uninitialized" like the file was empty and return -ENOMEDIUM. This
format should be used when reading an /etc/machine-id file from an image
that is not currently running.
