Cannot connect to WiFi with Nvidia GPU using nvidia-331, SSD
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | System76 |
Critical
|
Jason Gerard DeRose | ||
| | network-manager (Ubuntu) |
High
|
Mathieu Trudel-Lapierre | ||
Bug Description
For some strange reason, we cannot connect to WiFi on hardware with a descrete Nvidia GPU (using the nvidia-331 driver) when the system is running off a fast SSD.
Swap the SSD for a platter drive, and things work fine. Likewise, on Intel GPU systems, with either an SSD or a platter drive, WiFi works fine.
The failure message is:
"""
Connection activation failed.
(1) Creation of object for path '/org/freedeskt
"""
See the attached screenshot.
ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: network-manager 0.9.8.8-0ubuntu28
ProcVersionSign
Uname: Linux 3.16.0-24-generic x86_64
NonfreeKernelMo
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
CurrentDesktop: Unity
Date: Fri Oct 31 08:58:25 2014
IfupdownConfig:
# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback
IpRoute:
default via 10.17.76.1 dev eth0 proto static
10.17.76.0/24 dev eth0 proto kernel scope link src 10.17.76.193 metric 1
NetworkManager.
[main]
NetworkingEnab
WirelessEnable
WWANEnabled=true
WimaxEnabled=true
SourcePackage: network-manager
UpgradeStatus: No upgrade log present (probably fresh install)
nmcli-con:
NAME UUID TYPE TIMESTAMP TIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH
system76_5g d7cafbd5-
Wired connection 1 c52af28c-
nmcli-dev:
DEVICE TYPE STATE DBUS-PATH
wlan0 802-11-wireless disconnected /org/freedeskto
eth0 802-3-ethernet connected /org/freedeskto
nmcli-nm:
RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
running 0.9.8.8 connected enabled enabled enabled enabled disabled
| Jason Gerard DeRose (jderose) wrote : | #1 |
| Changed in system76: | |
| status: | New → Triaged |
| importance: | Undecided → Critical |
| assignee: | nobody → Jason Gerard DeRose (jderose) |
| Jason Gerard DeRose (jderose) wrote : | #2 |
| Launchpad Janitor (janitor) wrote : | #3 |
Status changed to 'Confirmed' because the bug affects multiple users.
| Changed in network-manager (Ubuntu): | |
| status: | New → Confirmed |
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.
| Changed in network-manager (Ubuntu): | |
| importance: | Undecided → High |
| assignee: | nobody → Mathieu Trudel-Lapierre (mathieu-tl) |
| Jason Gerard DeRose (jderose) wrote : | #5 |
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.
| Jason Gerard DeRose (jderose) wrote : | #6 |
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.
| Jason Gerard DeRose (jderose) wrote : | #7 |
Okay, think I just found a lead in /var/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-
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-
/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-
| Jason Gerard DeRose (jderose) wrote : | #8 |
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[
Nov 21 13:17:45 system76-pc NetworkManager[
Nov 21 13:17:45 system76-pc NetworkManager[
Nov 21 13:17:45 system76-pc NetworkManager[
No agents were available for this request... is the "agent" in a separate process, something you'd connect to through dbus?
| Jason Gerard DeRose (jderose) wrote : | #9 |
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).
| Jason Gerard DeRose (jderose) wrote : | #10 |
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-
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!
| Jason Gerard DeRose (jderose) wrote : | #11 |
Hmm, after more careful investigation, I think my hunch about differences in the DBus related process was a dead end.
| Jason Gerard DeRose (jderose) wrote : | #12 |
Also tried back-porting `policykit-1` (which needed a back-port of `glib2.0` and `gobject-
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.
| Jason Gerard DeRose (jderose) wrote : | #13 |
To eliminate more variables, I just tried xubuntu 14.10 (with nvidia-343 from ppa:system76-
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.
| Jason Gerard DeRose (jderose) wrote : | #14 |
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)
| Jason Gerard DeRose (jderose) wrote : | #15 |
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.
libc6-dbg libc6-dev libc6-i386 libcloog-isl4 libdb5.3 libfontconfig1
libjasper1 libqt5qml5 libqt5quick5 libtbb2 libtimezonemap-data
libtimezonemap1 multiarch-support python3-apport python3-
qml-module-
qml-module-
qtdeclarative
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...
| Jason Gerard DeRose (jderose) wrote : | #16 |
Er, I mean an ABI mismatched in policykit-1, not network-manager....
| Jason Gerard DeRose (jderose) wrote : | #17 |
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-
| description: | updated |
| Jason Gerard DeRose (jderose) wrote : | #19 |
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.
| Jason Gerard DeRose (jderose) wrote : | #20 |
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)
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-