Bug 1743585

Is it because of the size?
iwd is 425k but wpa_supplicant is 1.3M

I think we need a weak-dep: https://fedoraproject.org/wiki/Packaging:WeakDependencies

Wireless isn't working for me on Silverblue 31 and rawhide on two different ThinkPads and a USB stick. It is also broken for at least two additional people too (one a teammate and the other in the Fedra discussion forum). It's probably broken for everyone.

Installing wpa_supplicant as an overlay makes wireless work again.

More details @ https://discussion.fedoraproject.org/t/unable-to-update-gpg-signatures-found-but-none-are-in-trusted-keyring/2703/12?u=garrett


If Fedora is switching to iwd, then it needs to be fixed to work ASAP. If not, then this bug should probably be marked with priority and flagged as a release blocker.

Me too. iwd.service doesn't even start, it fails with a NAMESPACE error. This is the default F31 installation, two weeks before release. Thus moving the bug to F31 and increasing priority.

@martin - should you propose this as a f31 blocker or freeze exception? 
https://qa.fedoraproject.org/blockerbugs/milestone/31/beta/buglist

Proposed as a Blocker for 31-beta by Fedora user martinpitt using the blocker tracking app because:

 A default F31 installation (as of today) has broken wifi. It's unclear whether the dependency move to iwd was premature and unintended, but either the default installation needs to move back to wpa_supplicant, or iwd itself (which doesn't even start) and NM's integration of it need to be made to actually work.

So, just to clarify a bit here:

* NetworkManager-wifi actually Requires: (wpa_supplicant >= %{wpa_supplicant_version} or iwd). This is ambiguous and no supplementary weak dependency is provided to give dnf a hint as to which of the two is 'preferred', so dnf will simply pick one. DNF picks iwd (I forget the way DNF resolves ambiguous dependencies - yum had a whole heuristic for it, I don't recall if DNF does too - but anyway, fact is, it picks iwd).

* iwd appears to be completely broken.

So, we can fix this either by fixing iwd or changing NetworkManager-wifi to prefer wpa_supplicant. We could do both if that's desired, but doing just one or the other would be sufficient. Adding 'Suggests: wpa_supplicant  >= %{wpa_supplicant_version}' would probably be enough to make wpa_supplicant win the tie, but I won't do that because I'm not sure whether NM maintainers actually *want* wpa_supplicant to win the tie, or whether they want iwd to take over.

OK, so dug into this a bit more: this happens *when /var/lib/iwd does not exist*. If you touch that directory, the service starts fine. The iwd.service file has:

ReadWritePaths=/var/lib/iwd

It seems that, to put it generally, if you put 'ReadWritePaths=/some/nonexistent/path' in a systemd service file, systemd will fail with this slightly misleading error:

Failed to set up mount namespacing: /run/systemd/unit-root/some/nonexistent/path: No such file or directory

Here's an example of the same thing happening in Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923299

they 'solved' it by just dropping the ReadWritePaths line from the service file, in that case.

The intent here is that iwd actually *creates* /var/lib/iwd on first run. Zbigniew, is this something systemd ought to handle and not barf on?

I'm +1 blocker here, using the standard rationale that completely broken wifi violates all criteria that involve Internet access (e.g. package updating) for systems with only wifi connections.

Note that it's not just that failing unit. I tried to run iwd directly in a shell as root (the Exec= line), which starts up fine. Then I restarted NM, but even after that literally nothing happens -- NM still does not see any wifi devices or networks.

Actually, wpa_supplicant is still preferred as iwd is not capable to do any advanced WPA2 enterprise and 802.1x so we just need to add a dependency to pull wpa_supplicant together with NM-wifi, or just installing it with a basic system would make the trick too.

Martin, you need to add this to /etc/NetworkManager/NetworkManager.conf

[device]
wifi.backend=iwd

BTW, no WPA2 enterprise so will install wpa_supplicant

(In reply to Adam Williamson from comment #8)
> OK, so dug into this a bit more: this happens *when /var/lib/iwd does not
> exist*. If you touch that directory, the service starts fine. The
> iwd.service file has:
> 
> ReadWritePaths=/var/lib/iwd
> 
> It seems that, to put it generally, if you put
> 'ReadWritePaths=/some/nonexistent/path' in a systemd service file, systemd
> will fail with this slightly misleading error:
> 
> Failed to set up mount namespacing:
> /run/systemd/unit-root/some/nonexistent/path: No such file or directory

Let's ignore the slightly misleading error for now, I'll try to improve it.

Systemd doesn't know if the missing directory is important, so it refuses to
start. The unit would most likely fail anyway, so it's reasonable to do this.

There are a few options:
1. Replae ReadWritePaths=/var/lib/iwd by StateDirectory=iwd
2. Use tmpfiles.d to pre-create the directory
3. Remove the ReadWritePaths= lines as debian did
4. ask users to create the directory manually

Option 1. is what I would recommend. 2. is slightly worse. 3. and 4. are just bad.

So, I've tried this on Thinkpad P50 and T480s.

Creating /var/lib/iwd , manually starting iwd service and restarting NetworkManager didn't help. I still wasn't able to see any networks. (iwd service started successfully after creating /var/lib/iwd .)

Installing wpa_supplicant and restarting NetworkManager solved the issue.

@Frantisek: Did you do the wifi.backend=iwd thing from comment #12?

OK, so let's make this two bugs. Let's make this one 'NetworkManager should improve its deps to prefer wpa_supplicant over iwd'. I'll file a separate bug for 'iwd' should fix its service file'. Thanks, folks.

https://bugzilla.redhat.com/show_bug.cgi?id=1749430 filed for the iwd issue.

To fix the deps, something like this should work:

Requires: (wpa_supplicant >= %{wpa_supplicant_version} or iwd)
Recommends: wpa_supplicant >= %{wpa_supplicant_version}

or I just saw this changed in latest commit to hard 
Requires: wpa_supplicant ...
which works too obviously.

(In reply to Martin Pitt from comment #15)
> @Frantisek: Did you do the wifi.backend=iwd thing from comment #12?

Tried that right now (edited the NM conf as per #12, restarted NM), I still don't see any networks with iwd.

(In reply to Vladimir Benes from comment #1)
> Is it because of the size?
> iwd is 425k but wpa_supplicant is 1.3M

No, it is because `i` sorts before `w` in alphabet :)

(In reply to František Zatloukal from comment #19)
> (In reply to Martin Pitt from comment #15)
> > @Frantisek: Did you do the wifi.backend=iwd thing from comment #12?
> 
> Tried that right now (edited the NM conf as per #12, restarted NM), I still
> don't see any networks with iwd.

Please don't discuss iwd trouble here; it's totally unrelated to the issue with wpa_supplicant not getting installed.

That said, I've fixed the dep in f31 and rawhide, so I'm closing this now.

Thanks to everyone for reporting the issue and suggesting a fix.

Thanks, but I think your last commit to the package was incorrect:

https://src.fedoraproject.org/rpms/NetworkManager/c/5ef97724b1787461714ad3cae9be1c8e8b207a9b?branch=master

there's an "old Fedora or RHEL or no iwd support" conditional there. On the "old Fedora or RHEL or no iwd support" side, a non-boolean dependency on wpa_supplicant is supposed to be used, because old Fedora and RHEL don't support boolean dependencies (or just because we're not supporting iwd in this build at all). The boolean dep is supposed to be on the other "new Fedora and iwd support" side of the conditional.

However, in your commit, you put the boolean dependency on *both sides* of the conditional, but added the supplementary Suggests: only on the "old Fedora or RHEL or no iwd support" side of it.

I think this would fix it:

=====

--- a/NetworkManager.spec
+++ b/NetworkManager.spec
@@ -316,12 +316,12 @@ Requires: %{name}%{?_isa} = %{epoch}:%{version}-%{release}
 
 %if %{with iwd} && (0%{?fedora} > 24 || 0%{?rhel} > 7)
 Requires: (wpa_supplicant >= %{wpa_supplicant_version} or iwd)
+Suggests: wpa_supplicant
 %else
 # Just require wpa_supplicant on platforms that don't support boolean
 # dependencies even though the plugin supports both supplicant and
 # iwd backend.
-Requires: (wpa_supplicant >= %{wpa_supplicant_version} or iwd)
-Suggests: wpa_supplicant
+Requires: wpa_supplicant >= %{wpa_supplicant_version}
 %endif
 
 Obsoletes: NetworkManager < %{obsoletes_device_plugins}

=====

I also suggest adding a comment above the Suggests: that explains what it's for, as it'll probably be non-obvious to some readers.

Also, please don't close this bug just by sending Koji builds: Bodhi is active for F31 now and F31 is in Beta freeze, to get the fix into F31 you need to submit an update and mark it as fixing this bug and we need to push it stable manually, all that must happen before the bug is closed. Thanks!

Whoops, sorry, I indeed fucked up.

Fixed up earlier today though.

FEDORA-2019-39426d6328 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-39426d6328

Discussed during the 2019-09-09 blocker review meeting: [0]

The decision to classify this bug as an "AcceptedBlocker" was made as it violates of all criteria that rely on a remote network connection (e.g. package updates) for a system dependent on a wifi connection.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-09/f31-blocker-review.2019-09-09-16.00.txt

NetworkManager-1.20.2-3.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.