Tux's lil' helper
Joined: 01 Apr 2005
Location: Minneapolis, MN, USA
|Posted: Mon Feb 24, 2014 4:26 am Post subject: NetworkManager & plasma-nm not talking to eachother- sys
I wanted to share an excruciating experience I had today setting up wireless networking on my Gentoo box.
First off, my box is an ASUS G750JW laptop with a Broadcom 43b1 chipset of some model or the other. I had avoided Linux on this laptop for ages because of the lack of support of its newer wireless chipset - though I didn't realize Gentoo had an ebuild for it the last time I messed around with the box. The ebuild solved compilation bugs I encountered in previous attempts to get wireless working, so USE IT! Emerging this and modprobeing wl activated the card with no hiccups. I elected to use wicd to manage networks as its ncurses interface is handy. This worked immediately and out of the box.
At some point in fiddling and after building a new kernel, wicd stopped working on me, disconnecting immediately after establishing an AP connection. For some reason, I was on the thought track that this had something to do with wicd, and I installed NetworkManager and plasma-nm. These didn't work, either, but in worse ways. I kept struggling with wicd's logs and eventually found some hint that it was an IP addressing issue. Checking dhcpcd's logs revealed that dhcpcd was responsible for bringing down the interface. Why, I'm not exactly sure, but I thought it had something to do with having enabled dhcpcd.service while wicd was starting another instance. I disabled dhcpcd.service, rebooted just to be safe, and no change.
The whole time, the only attempts I had given to NetworkManager were to try both of its KDE frontends, plasma-nm and networkmanagement. They both didn't want to work, only appearing to not connect with NetworkManager. After trying everything I could think of, googling away, emerging and re-emerging and unmerging and starting from scratch, I finally found the answer. Despite having changed the USE flags and trying to, among other things, emerge -Nuav world, I discovered that pam had not been recompiled with systemd support. Not only that, but per the instructions hidden in http://wiki.gentoo.org/wiki/Systemd , I found I needed to alter /etc/pam.d/system-auth to include pam_system.so. This was my magic bullet - I wonder why this configuration (including pam_system.so) is not the default.
The underlying issue that caused my problem was that, after emerging systemd, emerge -Nuav world for a variety of new USE flags set during the troubleshooting process, pam never got recompiled with systemd support. I realize this likely stemmed from emerging dbus with USE="-systemd" early on in the system setup, but I did not apply this USE flag to pam. I remembered to re-emerge dbus with USE="systemd" at some point after per instructions, but assumed emerge -N would deal with anything else. There has got to be a better way of dealing with this situation. The dbus-systemd install process is a tangled mess.
I hope this helps!