wpa_supplicant service fails at boot, but starts fine after boot (with systemctl start wpa_supplicant) #101963
Comments
|
Note that while #82462 seems similar, it doesn't note the failure pattern with wpa_supplicant and is instead focused on the iwd failure. |
veprbl
added
the
6.topic: nixos
|
What does the journal say? What is the exit status? |
|
The content of the journal is included in the issue under the details block with the summary text " Is there more extensive journal output that would be helpful here? I'm happy to provide more journal output if you have a commandline for journalctl in mind. |
|
Oh, sorry I missed the little arrow. The exit status is 255 (-1) and it's printing the usage: this confirms my theory that wpa_supplicant is being passed invalid options at boot. The fault is most likely in the following shell script: |
|
Yes, I suspect that it's due to a delay in the wlan interface appearing. As I said in the issue itself:
|
|
I can confirm the suspicion: I ran the script with |
This resolves issue NixOS#101963. When the service is started and no interface is ready yet, wpa_supplicant is being exec'd with no `-i` flags, thus failing. Once the interfaces are ready, the udev rule would fire but wouldn't restart the unit because it wasn't currently running (see systemctl(1) try-restart). The solution is to exit (with a clear error message) but always restart wpa_supplicant when the interfaces are modified.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This resolves issue NixOS#101963. When the service is started and no interface is ready yet, wpa_supplicant is being exec'd with no `-i` flags, thus failing. Once the interfaces are ready, the udev rule would fire but wouldn't restart the unit because it wasn't currently running (see systemctl(1) try-restart). The solution is to exit (with a clear error message) but always restart wpa_supplicant when the interfaces are modified. (cherry picked from commit 8f17761)
|
Should be fixed in the next channel update. |
|
Unfortunately, I had to revert the fix: it's causing a long delay in the boot of a system with systemd-udev-settle. |
|
Maybe we should make Following NixOS manual this is quite a surprising failure. |
|
It looks like that it's the only way. I wonder how distros deal with this problem: I think on arch you have to specify an interface, not sure about others. |
|
Tripped over this almost immediately when upgrading my testing laptop to 21.05. I think a mention in the release notes would be very helpful. |
|
Since I couldn't get rid of all the |
This is the only way to solve issue NixOS#101963, for now.
|
The problem should be "fixed" for now. When systemd-udev-settle is fully removed (only four modules left: #73095 (comment)) I'll reintroduce the automatic selection of a network card. |
|
I made a new patch to fix this problem, this one doesn't depend on systemd-udev-settle being removed. |
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
|
This should be completely resolved by #127595 (now in nixos-unstable). |
|
@rnhmjoj You saved me: johnrichardrinehart/nix@ff35906 . I use that Thanks a lot! |
Describe the bug
On the Raspberry Pi 4B, I've enabled wireless with the following
configuration.nixfragment:When the system is rebooted, wpa_supplicant tries to start, but instead we just get a print out of the wpa_supplicant usage. Starting it manually after the system boots with
systemctl start wpa_supplicantcauses it to start without issue`journalctl -u wpa_supplicant` from after a reboot and a `systemctl start wpa_supplicant`
I believe what is happening here is likely the wifi interface (
wlan0) not showing up until after thewpa_supplicant-startscript (which tries to enumerate the wifi interfaces) runs, resulting in a bad set of args being passed to wpa_supplicant.To Reproduce
Steps to reproduce the behavior:
/etc/nixos/configuration.nixnixos-rebuild switchExpected behavior
wpa_supplicant service starts after reboot without intervention
Additional context
This is a new rpi4 install using the sd-card image from hydra
Notify maintainers
Metadata
Maintainer information:
The text was updated successfully, but these errors were encountered: