[Backport release-21.05] nixos/wireless: make wireless.interfaces mandatory #125917
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
ofborg
bot
added
10.rebuild-darwin: 0
|
Was this absolutely necessary? For me it broke eval for a bunch of systems that were on a supposedly stable channel |
|
Unfortunately yes, without specifying an interface it's possible for the |
|
What about https://hydra.nixos.org/jobset/nixos/release-21.05-small#tabs-errors ? This blocks all channels |
|
It was reported in #125288 too. I don't know what's going on: the assertions should only ever be evaluated if |
|
It is enabled because it's an installation device? You said so yourself in #125288 (comment) |
|
maybe we can revert this, and just make it a warning? Or add cc @grahamc curious your opinion |
|
I’m not keen on backporting this new breaking change.
I haven’t looked in to this change much. To be honest I find it a bit
weird to require specifying interfaces. I don’t necessarily know about
or want to specify the interfaces I want wireless on. Typically I just
enable “wireless” and then if I plug in a new wireless card it works
okay. I have similar concerns about but being and to generally enable
dhcp, but that is another concern.
My feeling is users in general don’t really want their boot to fail if
their network card is missing.
On June 6, 2021, GitHub ***@***.***> wrote:
maybe we can revert this, and just make it a warning?
Or add networking.wireless.enable = lib.mkForce false; suggestion to
error.
cc @grahamc <https://github.com/grahamc> curious your opinion
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#125917 (comment)>,
or unsubscribe <https://github.com/notifications/unsubscribe-
auth/AAASXLGLC4ZD3U27C6EVUT3TRQDR3ANCNFSM46FVAICA>.
|
|
On closer look I would like the original PR reverted, extended, and
reopened. I think might be a fine idea to add a list of mandatory
interfaces, but I don’t think it is such a good idea to casually remove
the feature of detecting interfaces.
…On June 7, 2021, GitHub ***@***.***> wrote:
I’m not keen on backporting this new breaking change.
I haven’t looked in to this change much. To be honest I find it a
bit
weird to require specifying interfaces. I don’t necessarily know
about
or want to specify the interfaces I want wireless on. Typically I
just
enable “wireless” and then if I plug in a new wireless card it works
okay. I have similar concerns about but being and to generally
enable
dhcp, but that is another concern.
My feeling is users in general don’t really want their boot to fail
if
their network card is missing.
On June 6, 2021, GitHub ***@***.***> wrote:
> maybe we can revert this, and just make it a warning?
>
> Or add networking.wireless.enable = lib.mkForce false; suggestion
to
> error.
>
> cc @grahamc <https://github.com/grahamc> curious your opinion
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#125917 (comment)-
855484906>,
or unsubscribe <https://github.com/notifications/unsubscribe-
auth/AAASXLGLC4ZD3U27C6EVUT3TRQDR3ANCNFSM46FVAICA>.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#125917 (comment)>,
or unsubscribe <https://github.com/notifications/unsubscribe-
auth/AAASXLDDB56TPTRAJVL4LVLTRS5PBANCNFSM46FVAICA>.
|
|
I opened #126075 to revert the change and make the assertion a warning.
Me too, the problem is wpa_supplicant isn't designed to work this way. This requires a hack (looping over I think there really is no way around this. The proper solution would be to poll udev for a wireless card, either by patching wpa_supplicant or from the script
It has a high chance of failure that leaves users without a network. On my machines wpa_supplicant failed to start consistently. |
|
Hydra is currently unable to finish an eval: https://hydra.nixos.org/jobset/nixos/release-21.05#tabs-evaluations so this should be changed (or hydra jobs need to be changed) |
|
@jonringer that's what @dasJ meant by "This blocks all channels". Currently at least unstable{,-small} and release-21.05{,-small} cannot advance because of this. |
|
Yea, I just hadn't checked myself until recently. |
I may have finally found a clean solution to the issues[1][2][3] with the automatic discovery of wireless network interfaces. [1]: NixOS#101963 [2]: NixOS#23196 [3]: NixOS#125917 (comment) 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
Description
Backport of #125288 to
release-21.05.