Alpine's version of the first patch no longer applied, because we're
on a newer lvm2 version.
The fixes in both of these patches are either Musl-specific, or
shouldn't negatively affect Glibc, so change to applying them
unconditionally so they don't bitrot in future.
e606e4d6a9 ("lvm2: musl patches from alpine") added all these patches
from Alpine to fix Musl builds, but one doesn't actually seem related
to Musl. The Alpine issue[1] that led to its introduction links to a
Gentoo issue[2] about the same thing on Glibc.
We shouldn't be applying a fix for a non-libc-specific bug only to
Musl builds, and if this was going to be an issue for us we'd expect
to have seen it on Glibc by now. It's more likely that it's been
fixed in the meantime.
[1]: https://gitlab.alpinelinux.org/alpine/aports/-/issues/3107
[2]: https://bugs.gentoo.org/335492
I may have finally found a clean solution to the issues[1][2][3] with
the automatic discovery of wireless network interfaces.
[1]: https://github.com/NixOS/nixpkgs/issues/101963
[2]: https://github.com/NixOS/nixpkgs/issues/23196
[3]: https://github.com/NixOS/nixpkgs/pull/125917#issuecomment-856000426
Currently the start script fails right away if no interface is available
by the time it's running, possibly leaving the system without network.
This happens when running a little early in the boot. A solution is to
instead wait for at least one interface to appear before scanning the
/sys/class/net/ directory. This is done here by listening for the right
udev events (from the net/wlan subsystem) using the `udevadm monitor`
command and grep to match its output.
This methods guarantees the availability of at least one interface to
wpa_supplicant, but won't add additional interfaces once it has started.
However, if the current interface is lost, say unplugged, the service is
automatically stopped and will be restarted as soon as a one (not
necessarily the same) is detected. It would be possible make this fully
dynamic by running another service that continously listen for udev
events and manages the main wpa_supplicant daemon, but this is probably
overkill.
I tested the following cases:
- one interface, starting at boot, w/o predictable naming scheme
- two interfaces, starting at boot (intel wireless and a usb adapter),
w/o predictable naming scheme
- one interface after the system booted, w/o predictable naming scheme
- two interfaces after the system booted, w/o predictable naming scheme
- unplugging and plugging back the current interface
