FluiddPi cannot connect to wifi

[LuigiBrito]

Used the raspberrypi imager and set the SSID and PW correctly.

I checked the wpa_supplicant files in /etc/wpasupplicant/ and in /boot/fluiddpi-wpa-supplicant.txt and both are showing the correct ssid and a hexadecimal pw

On boot, literally nothing happens. I'm waiting on my unifi to pickup even an attempt but nein. Nothing.

[LuigiBrito]

if I connect to it manually and do a sudo wpa_supplicant -c <conf file> -i wlan 0 it works. But the device it self doesn't seem to do this on its own on reboot

[TheFanatr]

Same problem for me, except I couldn't even get SSH.

[rodrigo2019]

same for me, I got this problem with the V1.17 image, I have another fluidd running with the V1.16.2 image and it's fine

[ressu]

Assuming that this is the same case that we were troubleshooting recently then the issue should be a race condition with mounting boot volume. For some reason systemd finds a cyclic dependency somewhere and removes some local-fs dependencies and that messes up the order of how services come up. Not having the wpa configuration present means that dhcpcd never starts wpa supplicant.

So with that long explanation, the workaround is rather simple. Creating an override for dhcpcd systemd unit with the following contents forces the service to wait for boot.mount

[Unit]
After=boot.mount

Easiest way to create the override in the correct location is to use systemctl edit dhcpcd.service. The actual file location is /etc/systemd/system/dhcpcd.service.d/override.conf

That all being said, we were unable to find the cause for the circular dependency.

[Drkmttr82]

Assuming that this is the same case that we were troubleshooting recently then the issue should be a race condition with mounting boot volume. For some reason systemd finds a cyclic dependency somewhere and removes some local-fs dependencies and that messes up the order of how services come up. Not having the wpa configuration present means that dhcpcd never starts wpa supplicant.

So with that long explanation, the workaround is rather simple. Creating an override for dhcpcd systemd unit with the following contents forces the service to wait for boot.mount

[Unit]
After=boot.mount

Easiest way to create the override in the correct location is to use systemctl edit dhcpcd.service. The actual file location is /etc/systemd/system/dhcpcd.service.d/override.conf

That all being said, we were unable to find the cause for the circular dependency.

Is there a reason why I would be denied when trying to use this workaround? I've gotten to ssh into my pi and I can log in. But the web service doesn't start. Checked the supplicant file and all that is good. But when trying this command I get access denied. Not sure how I'm not the SU but it's frustrating.