Before this patch, if a network has multiple routers and one of them
provides a captive portal, then the portal was overwritten or cleared
when another RA from another router is received.
This makes captive portals managed in the similar way as DNS servers or
DNS domains. So now captive portal can safely handled even if a network
has multiple routers.
While we don't strictly follow the rule, most of our userspace names
these fields that count entries in some array n_xyz, hence let's do so
in the EFI boot code too, to make things less special.
We gained a bunch of new features that deserve reporting to userspace,
hence add matching flags for each.
This allows userspace to determine if installing addons in the ESP even
makes sense.
This is inspired by a similar changes in #28057
The change is intended to reproduce the issue #27983, though the
original issue is highly racy, and the test does not reproduce it
reliably. But, anyway, it is better to change the partition label to
test the devlink removal.
Follow-up for 381f6d4ba5.
When the function is called, the device may be already removed, and
another device has the same syspath. Such situation can occur when a
partition removed and another is created. In that case, the sysfs paths
of the removed and newly created partitions can be same, but their
devnums are different, and thus the database files corresponding to the
devices are also different.
Fixes#27981.
Let's make our units more robust to being added to an initrd:
1. systemd-boot-update only makes sense if sd-boot is available in /usr/
to copy into the ESP. This is generally not the case in initrds, and
even if it was, we shouldn't update the ESP from the initrd, but from
the host instead.
2. The rfkill services save/restore rfkill state, but that information
is only available once /var/ is mounted, which generally happens
after the initrd transition.
3. utmp management is partly in /var/, and legacy anyway, hence don't
bother with it in the initrd.
Follow-up for 123c0e24dd.
Note, the entry was originally added for IdeaPad Flex 5 in
21b589a155.
Then, a bug introduced by 19db450f3a.
But, when it was fixed by 738a195bd5,
the glob becomes too stricter, and another variant was added by
123c0e24dd.
Follow-up for 017a7ba4f4
Before this commit, when a unit that is restarting propagates stop
to other units, it can also depend on them, which results in
job type conflict and thus failure to pull in the dependencies.
So, let's introduce a new dependency atom UNIT_ATOM_PROPAGATE_STOP_GRACEFUL,
and use it for PropagatesStopTo=. It will enqueue a restart job if
there's already a start job, which meets the ultimate goal and avoids
job type conflict.
Fixes#26839
Yu Watanabe
Lennart Poettering
Luca Boccassi
Frantisek Sumsal
Mike Yuan