I managed to kill KNetworkManager today and I’m not sure what I did. This is a netbook running openSUSE 11.4 with all updates applied and KDE 3.5 (from the openSUSE repository). Normally, I use knetworkmanager to connect to the Internet. Everything was working fine this morning and today I decided to apply whole disk encryption (using cryptsetup and luks) to it.
So, I backed up the files, encrypted the partitions, made some adjustments to /etc/fstab and /boot/grub/menu.lst, and copied the files back. Everything is working fine, except for knetworkmanager. When it goes to connect, it starts off with the “gray Earth” (to represent no connection) and then it switches to the “connecting” icon for a fraction of a second, and then it’s back to the “gray Earth”. Looking at the output of iwconfig, it hasn’t connected to the router at all (the essid is blank).
The connection works fine using ifup. I tried using cnetworkmanager (the console version) and it spits out errors like this:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Property "ActiveAccessPoint" of interface "org.freedesktop.NetworkManager.Device" ins't exported (or may not exist)
DBus is up and running (according to “rcdbus status”).
I’m just confused as to what I could have done to cause this and what I might need to do to fix it. I’m not sure if this is a NetworkManager problem, a DBus problem, or a problem associated with the encryption. The only thing I did do today that might possibly be an issue is that I rebuilt the initial ramdisk in order to add support for boot-time decryption (mkinitrd -f “dm luks”), but I’ve done this on other similar systems and have never had a problem.
Any ideas are appreciated! I’m totally lost on this one!
It’s hard to say what the problem is, base on your description.
I am using KDE 4.6, so perhaps my experience is different.
On two computers, I have both “/home” and swap encrypted. On a third computer, I setup as an LVM system. So only “/boot” is unencrypted. Everything else is inside the encrypted logical volume.
I have not noticed any NetworkManager problems that are due to encryption. It is hard to imagine how encrypted disks or partitions would affect anything.
Hi nrickert, thanks for the reply. I have / and /home encrypted, I don’t use swap, and /boot is unencrypted. I set this all up not using LVM but using a combination of tutorials on opensuse.org. I agree that encryption shouldn’t be the issue, unless NetworkManager somehow relies on initrd.
I did realize that I had this same problem (knetworkmanager instantly giving up trying to connect) before and it was related to connecting to an WPA-protected network. On that other computer, I ended up wiping out knetworkmanagerrc and starting over, but on this machine, that hasn’t worked.
Here is the tail of /var/log/NetworkManager - this is the output from NetworkManager when I try to connect:
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> Activation (wlan0) starting connection 'Home'
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> (wlan0): device state change: 3 -> 4 (reason 0)
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) scheduled...
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) started...
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) scheduled...
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> Activation (wlan0) Stage 1 of 5 (Device Prepare) complete.
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) starting...
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> (wlan0): device state change: 4 -> 5 (reason 0)
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> Activation (wlan0/wireless): access point 'Home' has security, but secrets are required.
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> (wlan0): device state change: 5 -> 6 (reason 0)
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> Activation (wlan0) Stage 2 of 5 (Device Configure) complete.
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> (wlan0): device state change: 6 -> 9 (reason 7)
Jul 23 07:41:00 Nikko NetworkManager[1395]: <warn> Activation (wlan0) failed for access point (Eureka1)
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> Marking connection 'Home' invalid.
Jul 23 07:41:00 Nikko NetworkManager[1395]: <warn> Activation (wlan0) failed.
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> (wlan0): device state change: 9 -> 3 (reason 0)
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> (wlan0): deactivating device (reason: 0).
Jul 23 07:41:00 Nikko NetworkManager[1395]: <info> (wlan0): reset MAC address to 00:00:00:00:00:00
I’m pretty sure that there is nothing network related in “initrd”. You would need something for the network if you were mounting the root partition via NFS, but otherwise there shouldn’t be anything network related until the normal init scripts run.
I compared my output to yours. It is about the same up to the state chave 4 -> 5. Beyond that, it is different.
Unfortunately, it’s a bit hard to compare. I also installed XFCE and LXDE, which can use the gnome nm-applet. And I used nm-applet to setup a system wide wifi connection. So the connection is started before KDE even starts. So all the KDE applet is doing, is reporting that I am connected.
Hopefully, somebody more familiar with the connection steps is also reading this and can jump in.
Okay, I have partially solved this. First, I realized that NetworkManager would only not connect to encrypted networks. Then, I discovered that wpa_supplicant (as per /etc/wpa_supplicant/wpa_supplicant.conf) uses /var/run as a control directory. I then wiped out /var/run (rm -rf /var/run) and rebooted and now everything seems to be working.
Now, my question is that when I was encrypting the disk, I moved the files from the unencrypted partitions to the encrypted ones using:
rsync -ASHXax src dest
Should I have used different options to rsync? Should I not have transferred /var?
I would have avoided “rsync” for this. I don’t think it properly handles links.
I would have used
cd src
tar cf - . | ( cd dest && tar xpf - )
nrickert wrote:
> quantamm;2368155 Wrote:
>> Should I have used different options to rsync?
> I would have avoided “rsync” for this. I don’t think it properly
> handles links.
What specifically do you think it doesn’t handle?
I don’t have any trouble and I make extensive use of hard and soft links.
Let me put that differently. “rsync” has lots of option flags. It takes some study of the options to do it right. On the other hand, “tar” usually gets links right by default, though at the cost of extra copying.
I use “rsync” a lot for synchronizing files between systems. But for copying/installing a complete directory tree, “tar” seems easier and safer to use.
On 2011-07-25 14:06, quantamm wrote:
> Code:
> --------------------
> rsync -ASHXax src dest
> --------------------
I use "–archive --acls --xattrs --hard-links --del --stats --human-readable "
> Should I have used different options to rsync? Should I not have
> transferred /var?
Some files in there have names related to the inode they use. Or something
like that. They can not be copied. I don’t know if this your case, but it
affect mail queues, for instance.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
nrickert wrote:
> djh-novell;2368190 Wrote:
>> What specifically do you think it doesn’t handle?
>
> Let me put that differently. “rsync” has lots of option flags. It
> takes some study of the options to do it right.
I can certainly agree with that 
> I use “rsync” a lot for synchronizing files between systems. But for
> copying/installing a complete directory tree, “tar” seems easier and
> safer to use.
I can agree with that too. But in practice I just cut and paste a
known-working rsync command-line from an existing script 
Thanks everyone. Next time I convert a system to encrypted disks, I’ll be sure to try out the suggested tar and rsync options.
If you want root encrypted, it is easier to do that as part of an LVM install. And if you do it with the initial install, then the most you would be copying would be the “/home” file system. See my blog report on encryption.