Change:
fi fi done <ins> if [ -z "$args" ]; then echo >&2 "<3>No wireless interfaces detected (yet)." exit 1 fi </ins> '' else '' args="${concatMapStringsSep " -N " (i: "-i${i} $iface_args") ifaces}" ''}

Discussion:
Describe the bug On the Raspberry Pi 4B, I've enabled wireless with the following fragment: When the system is rebooted, wpasupplicant tries to start, but instead we just get a print out of the wpasupplicant usage. Starting it manually after the system boots with causes it to start without issue <details<summaryfrom after a reboot and a </summary</detailsI believe what is happening here is likely the wifi interface () not showing up until after the script (which tries to enumerate the wifi interfaces) runs, resulting in a bad set of args being passed to wpasupplicant. To Reproduce Steps to reproduce the behavior: nixos on a rpi4 the wireless configuration noted above to that wpasupplicant has not started. Expected 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 <!-- Please @ people who are in the list of the offending package or module. If in doubt, check for whoever last touched something. --Metadata Maintainer information:
Note that while seems similar, it doesn't note the failure pattern with wpa_supplicant and is instead focused on the iwd failure.
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 " from after a reboot and a " (click on that text to see the journal). 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 wpasupplicant 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 at boot and indeed no card was found, which resulted in wpasupplicant being started without and the usage error. Technically, this shouldn't be a problem because the module also adds a udev rule to restart wpasupplicant when an interface appears, but it doesn't look like it's working.

Until I figure this out, a workaround is to specify the interface with : this should configure a dependency on the unit file.
Can you test my patch in ?
are you sure about that ticket number? It looks unrelated. (Edit: comment marked resolved by commenter)
Oops, sorry. I've corrected the number.
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. I can only suggest to specify the interfaces manually with , for now.
Maybe we should make a required attribute until this is fixed properly? 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 for 21.05, is still not applicable. I guess I'll do what domen suggested.
The problem should be "fixed" for now. When systemd-udev-settle is fully removed (only four modules left: ) 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. It would help If you could try it:
This should be completely resolved by (now in nixos-unstable).
You saved me: . I use that output for ephemeral OS instances on a flash drive. Before pinning to I was having the problem described here. Now, everything works. Thanks a lot!