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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When generating verity partitions, we only know the partition UUID
of the verity data and hash partition after doing the verity
formatting. This means we can't use the verity partition UUID as
input for deriving the filesystem/luks UUIDs. Currently, we derive
the filesystem/luks UUID from the null UUID instead, which isn't
ideal. Instead, let's always generate a partition UUID and use it
to derive the fs/luks UUIDs, but only use it as the actual partition
UUID if we're not doing verity for the partition.
If everything points to the fact that TPM2 should work, but then the
driver fails to initialize we should handle this gracefully and not
cause failing services all over the place.
Fixes: #25700
When an AP goes up, the kernel may emit a netlink event indicating that
the interface has gained carrier. In that event, we should check if the
SSID has changed before attempting to reconfigure. Not doing so means
that the link->ssid member is not updated, leading to a potential
mismatch if some of the .network configurations match on SSID=.
There are however scenarios where the above heuristic is not enough.
Specifically, if the interface carrier state flip-flops within a short
enough interval, the internal throttling of netlink events inside the
kernel may suppress intermediate linkdown+linkup events (cf. Linux
net/core/link_watch.c). So there is no linkup event to react on.
To improve on the latter scenario, it is proposed to make newer kernels
emit an NL80211_CMD_START_AP multicast event when an AP goes up. This
event will not be dropped by link_watch. systemd-networkd can then react
to such events as well, and optionally reconfigure the link if the SSID
has changed. This will only work with newer kernels though.
As you can see in the below, the dropped dependency Before=issue-24990.service
is not logged, but the dependency Before=test1.service which is not owned by
the units generated by the TEST-26 is logged.
Before:
systemd[1]: issue-24990.service: Dependency After=test1.service dropped, merged into issue-24990.service
systemd[1]: issue-24990.service: Dependency Before=test1.service dropped, merged into issue-24990.service
After:
systemd[1]: issue-24990.service: Dependency After=test1.service is dropped, as test1.service is merged into issue-24990.service.
systemd[1]: issue-24990.service: Dependency Before=issue-24990.service in test1.service is dropped, as test1.service is merged into issue-24990.service.
Currently rename_netif() will not attempt to rename a device if it is
already up, because the kernel will return -EBUSY unless live renaming
is allowed on the device. This restriction will be removed in a future
kernel version [1].
To cover both cases, always attempt to rename the interface and return 0
if we get -EBUSY.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=bd039b5ea2a9
If a current alternative name is to be used to rename a network
interface, the alternative name must be removed first. If interface
renaming fails, restore the alternative name that was deleted if
necessary.
Commit 434a348380 ("netlink: do not fail when new interface name is
already used as an alternative name") added logic to set the old
interface name as an alternative name, but only when the new name is
currently an alternative name. This is not the desired outcome in most
cases, and the important part of this commit was to delete the new name
from the list of alternative names if necessary.
When configuring a link's alternative names, the link's new name to-be
is not allowed to be included because interface renaming will fail if
the new name is already present as an alternative name. However,
rtnl_set_link_name will delete the conflicting alternative name before
renaming the device, if necessary.
Allow the new link name to be set as an alternative name before the
device is renamed. This means that if the rename is later skipped (i.e.
because the link is already up), then the name can at least still be
present as an alternative name.
This reverts commit 5dd34c2604.
`resolvectl monitor` sends notify event, and systemd-run wait for the
service being in active state. Hence, the loop is not necessary.
