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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
Primarily:
1. Mention that we prefer if return parameters carry "ret_" as prefix in
their name
2. Clarify that debug-level logging is always OK, and irrelevant to when
deciding whether a function is logging or non-logging.
p itself is never null. Because of this, we would always
call sd_notify() in cleanup, even though the intention was to only
call it if notify_start() was executed.
When /etc/machine-id contains the string "uninitialized" instead of
a valid machine-id, treat this like the file was missing and mark this
boot as the first (-> units with ConditionFirstBoot=yes will run).
The proc-sys-fs-binfmt_misc.mount unit should not be enabled by
preset-all because it should only be used as fallback in case
proc-sys-fs-binfmt_misc.automount cannot be used on a system. In these
cases it should be enabled manually by an administrator.
Negative value means there is no match between a PCI device and any of
the slots. In the following commit we will extend this and value of 0
will indicate that there is a match between some slot and PCI device,
but that device is a PCI bridge.
