Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD

Note I confirmed that WiFi works fine when using nouveau on the same hardware.

Also I tried a minimal a nvidia-331 install with --no-install-recommends, just in case the problem is related to any of the optimus stuff, which isn't needed for System76 hardware... and still no dice. Installing nvidia-331 breaks WiFi, for whatever reason.

Status changed to 'Confirmed' because the bug affects multiple users.

This wouldn't be related in any way with the GPU or disks; I'm not sure why it's happening that way -- it might just be a matter of luck in this particular case.

Marking as Confirmed/High; there are other bug reports of similar issues. I'll merge them and try to figure out how to fix the underlying cause, which appears to be the secrets agent detection.

You'd think it wouldn't be related to the nvidia driver... but it definitely is.

At System76, we've frequently encountered scattered problems like this. The nvidia proprietary effects the boot sequence enough (for example, no kms) that it frequently exposes subtle problems in the overall structure of the upstart jobs, usually related to timing issues.

My hunch is some upstart job actually should depend on an event that it doesn't, but without the nvidia proprietary driver installed, this job works correctly by chance because this event will usually have already happened.

This might not be a network-manager problem, but that's where the symptom is occurring.

My current hunch is this might be related to nvidia-persistenced being started via udev in Utopic, vs Upstart in Trusty and older.

Oh, and a little more detail on why I'm certain this is related to the nvidia proprietary driver...

Part of our QA process after we image a system (before it's shipped to the customer) is to test WiFi. Since we started shipping Utopic, we've had 0% failure on systems with Intel graphics.

On hardware with an nvidia GPU (for which we always pre-install the proprietary driver), we've had 100% failure when the system has an SSD for the OS drive. When the OS is on an HDD, it often works, but sometimes there are failures there too.

You can work around this by going into "Edit connections" and entering your password for the wifi there. But the proper password dialog fails to pop-up when you just click on the wifi name in the indicator.

Okay, think I just found a lead in /var/log/upstart/lightdm.log:

/etc/modprobe.d is not a file
/etc/modprobe.d is not a file
/etc/modprobe.d is not a file
/etc/modprobe.d is not a file
update-alternatives: error: no alternatives for x86_64-linux-gnu_gfxcore_conf
Failed to get D-Bus connection
/etc/modprobe.d is not a file
/etc/modprobe.d is not a file
/etc/modprobe.d is not a file
/etc/modprobe.d is not a file
update-alternatives: error: no alternatives for x86_64-linux-gnu_gfxcore_conf
/etc/modprobe.d is not a file
/etc/modprobe.d is not a file
/etc/modprobe.d is not a file
/etc/modprobe.d is not a file
update-alternatives: error: no alternatives for x86_64-linux-gnu_gfxcore_conf

BTW, it was the "Failed to get D-Bus connection" bit above that seems problematic.

Also, looking in syslog, there are some interesting tidbits:

Nov 21 13:17:45 system76-pc NetworkManager[977]: <info> (wlan0): device state change: config -> need-auth (reason 'none') [50 60 0]
Nov 21 13:17:45 system76-pc NetworkManager[977]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Nov 21 13:17:45 system76-pc NetworkManager[977]: <warn> No agents were available for this request.
Nov 21 13:17:45 system76-pc NetworkManager[977]: <info> (wlan0): device state change: need-auth -> failed (reason 'no-secrets') [60 120 7]

No agents were available for this request... is the "agent" in a separate process, something you'd connect to through dbus?

Another update: I think I've ruled out nvidia-persistenced being started via udev as the possible culprit.

I tried Trusty with the nvidia-343 driver from the System76 PPA (which starts nvidia-persistenced with udev)... and I can connect to WiFi just fine.

I also tried an up-to-date Vivid install with the same nvidia-343 driver... and again, I can connect to WiFi just fine.

So something specific to Utopic is causing the problem (whether or not that problem is actually in NetworkManager itself, I still don't know).

Still no solution, but I've at least (hopefully) eliminated some more variables.

As I know this problem doesn't currently exist on Vivid, I tried back-porting `network-manager` and `network-manager-applet` from Vivid, but no luck... same problem still exists.

And on the off chance that this is kernel-related, I also tried the 3.16 kernel on Trusty... but connecting to WiFi still works fine, so it doesn't seem to have anything to do with the kernel version.

However, I have noticed some differences in the Dbus processes running an a system with Nvidia hardware vs a system with an Intel GPU, so I'm further investigating that today...

Also, I'm not that familiar with network-manager, so if you have any advice for how I could get you better debugging information, please let me know!

Hmm, after more careful investigation, I think my hunch about differences in the DBus related process was a dead end.

Also tried back-porting `policykit-1` (which needed a back-port of `glib2.0` and `gobject-introspection`)... still no luck.

But at this point, the delta between Utopic and Vivid is still pretty small, so I feel this is a promising avenue, at least as far as shot-gunning goes.

To eliminate more variables, I just tried xubuntu 14.10 (with nvidia-343 from ppa:system76-dev/stable)... and I can connect to password-protected WiFi just fine.

As Xubuntu and Ubuntu are using most of the same lower-level stack, this kinda suggests the problem is fairly high-level, potentially even Unity specific.

More variables eliminated: this bug does *not* occur on:

- Ubuntu GNOME 14.10
- Ubuntu MATE 14.10
- Kubuntu 14.10
- Xubuntu 14.10 (as mentioned above)

Another possible hint: some in this set of packages currently in vivid proposed breaks the WiFi password dialog:

Calculating upgrade... Done
The following NEW packages will be installed:
  libisl13
The following packages will be upgraded:
  apport apport-gtk btrfs-tools fontconfig fontconfig-config
  gir1.2-timezonemap-1.0 gnome-system-monitor libc-bin libc-dev-bin libc6
  libc6-dbg libc6-dev libc6-i386 libcloog-isl4 libdb5.3 libfontconfig1
  libjasper1 libqt5qml5 libqt5quick5 libtbb2 libtimezonemap-data
  libtimezonemap1 multiarch-support python3-apport python3-problem-report
  qml-module-qtquick-localstorage qml-module-qtquick-window2
  qml-module-qtquick2 qtdeclarative5-localstorage-plugin
  qtdeclarative5-qtquick2-plugin syslinux syslinux-common
32 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 21.4 MB of archives.
After this operation, 2,157 kB of additional disk space will be used.

As none of these packages seem directly related, but libc is being updated, I'm wondering if the issue is a ABI mismatch in a codepath only being triggered on Utopic Unity systems (as I also noticed that network-manager seemingly wasn't rebuilt at any time during Utopic).

So my next test is a no-change rebuild of network-manager for Utopic...

Er, I mean an ABI mismatched in policykit-1, not network-manager....

Okay, on vivid, unity-greeter 15.04.2-0ubuntu1 re-introduces this bug.

I have a vivid image that was up-to-date as of Fri 5 Dec. In this snapshot, with applying any updates, I can connect to protected WiFi just fine.

However, today something landing from proposed re-introduced this bug, and I noticed that unity-greeter was among the updates.

So I re-imaged and then upgraded only unity-greeter:

sudo apt-get update
sudo apt-get install unity-greeter

After a reboot, the password dialog wont show when I try to connect to protected WiFi (same symptom as Utopic).

Interestingly enough, unity-greeter was one of the many things I tried back-porting and it didn't fix this on Utopic, although now I can't recall whether I did that back-port in isolation or whether there were other backports I was testing at the same time.

Ah, also note that unity-greeter 15.04.2-0ubuntu1 does *not* break WiFi on Intel GPU systems. This is still only a problem on systems with Nvidia GPUs running the proprietary nvidia driver (might effect the nouveau driver too, not sure either way on that one).

It would really be quite surprising for unity-greeter to have any effect on nm-applet without breaking a whole lot of other things. The one thing pointed out that looked the most promising were the D-Bus errors, and the "no agent available" message in syslog -- that's really where we should be looking.

Please, see that your system is fully up-to-date, and if the bug can be reproduced there, then let's try to remove the nvidia proprietary drivers and see if this still has any effect on wifi.

The agent NetworkManager is looking for is almost always nm-applet (as from the network-manager-applet source package), except in conditions like in Gnome Shell. Perhaps there are logs in .xsession-errors (or now .cache/upstart/gnome-session-Unity.log?) that could explain issues on the nm-applet side if NetworkManager can't connect to it?

FYI, this bug wasn't initially present on the final 15.04 release, but has since raised it's ugly head again on 15.04.

Not sure what has changed, but from my previous experience, my bet is still on `unity-greeter`, even though I'm not sure how exactly it's causing it.

As with 14.10, this problem isn't happening with Ubuntu MATE 15.04. Haven't tried the other flavors yet, but I'm guessing that again this is only happening with Ubuntu/Unity.

I just want to confirm possible interaction between unity-greater and nvidia. And I have SSD too, not sure if this is related.

My previous Ubuntu Vivid install with Nvidia-346 was bricked, with boot ending at unity-greater.
I am not sure what caused it, I've attributed it to that I've played with compiz settings and installed some extra gnome packages.

Now (after reinstalling Ubundu), I am able to connect to my home wifi AP, but not to my phone AP (with error message as described in Bug: 1438003)