Bugzilla – Bug 332057
Mounting LUKS encrypted device does not work after restore of home directory
Last modified: 2007-11-01 22:48:44 UTC
Created attachment 176929 [details] Screenshot of KryptoMedia dialog with error My problem is to decrypt an external LUKS encrypted Hard Disk with one XFS partition. After plugging in the HD, the dialog "Decrypt Strorage Device - KryptoMedia" appears but after entering the correct passphrase (tested with another user and in a shell) this error occurs: hal-storage-crypto-setup-removable no. This happens after restore of my home partition so maybe this is an error with MediaManager settings but i dunno where to setup. As i've said, the KryptoMedia dialog works with another user and root and i can decrypt the device with cryptsetup in a shell! Anyway i was searching for a corresponding hal script, but nothing like this! Regards Frank
Same error with mounting removable media like CDs or DVDs. After popup, which action i want to and klicking on open, the error "hal-storage-mount-removable no" occurs. A screenshot is attached!
Created attachment 177062 [details] Screenshot of Konqueror trying to open /dev/media/sr0 with error message
Hmm, the problem is gone, i dunno why. I've opened with emacs /etc/dbus-1/system/hal.conf but changed nothing and did not save the file. I leave this bug as a reminder.
The problem is up again. "hal-storage-mount-removable no" occurs after entering the passphrase into KryptoManager dialog. Shall i enable hal debugging? This was really hard to read!
Created attachment 178260 [details] Debug output of haldaemon Last line Denied by Policy is important i think but, there were no changes, only official updates.
I changed some things so that this is working for me now but i think this is only a workaround. Changed file /etc/PolicyKit/PolicyKit.conf to (be aware of my username "ffiene", cjange this to your user!): #########snip############ <?xml version="1.0" encoding="UTF-8"?> <!-- -*- XML -*- --> <!DOCTYPE pkconfig PUBLIC "-//freedesktop//DTD PolicyKit Configuration 1.0//EN" "http://hal.freedesktop.org/releases/PolicyKit/1.0/config.dtd"> <!-- See the manual page PolicyKit.conf(5) for file format --> <config version="0.1"> <match action="hal-storage-crypto-setup-removable"> <match user="ffiene"> <return result="yes"/> </match> </match> <match action="hal-storage-mount-removable"> <match user="ffiene"> <return result="yes"/> </match> </match> </config> #########snip############ Then call "polkit-reload-config" and everything is fine! So how has been changed the default settings and where to find them?
The problem is not HAL, it's ConsoleKit I think. Looks as consolekit wasn't running. The log show this error message: Error doing GetSessionForUnixProcess on ConsoleKit: org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ConsoleKit was not provided by any .service files Is there XDG_SESSION_COOKIE in the environment (env | grep XDG_SESSION) of your user? Btw. Don't add such file to PolicyKit, it only prevent to find the problem and cause security problems. I reassign this to the maintainer of consolekit
Please check if Dannys suspicion about ConsoleKit is right (rcconsolekit status). Thanks.
rcconsolekit status Checking for service ConsoleKit daemon unused But: chkconfig consolekit consolekit on I've started consolekit, edited PolicyKit.conf to an empty config. No success, same error message: "hal-storage-crypto-setup-removable no" I attach the debug output. Oh, and no, no XDG_SESSION in environment! Maybe because of a 10.2 homedir restore?
Created attachment 178407 [details] Debug output of haldaemon after starting consolekit
@Holger: looks to me as if for some reasons the complete update case from 10.2 to 10.3 doesn't work with ConsoleKit (and related KDE/GNOME/Basesystem parts). The same in bug #333706.
Sorry when i am interfering. Yes, maybe this is update case, but to narrow this down: I did only a backup and restore of my home directory and SCPM, i would say something is wrong with .profiles or any other local setup files in my home directory!
If you restart consolekit and restart X including login to your account: do you get now XDG_SESSION_COOKIE in your environment? One other thing: Did you a clean new 10.3 install and restored then your 10.2 home or did you update from 10.2 to 10.3. Could you try if insserv rcconsolekit (or insserv -f) help to get consolekit running with the next boot?
One additional question: How is the behaviour with a plain new user/home directory?
Sorry for delay, i am in Mumbai right now and my sh... expensive hotel is not able to provide internet access! :-( Anyway. So to Comment #13: ------------------ consolekit was running now, dunno why and yes, env | grep XDG_SESSION XDG_SESSION_COOKIE=705be2a3327b1d9d9b6a260047061000-1192549822.453485-1876329815 I have to test the decryption now! Yes, it was a clean 10.3 installation, i do this since SuSE 4.2. After setup, i've restored my home partition (after mounting my encrypted home partition, read later!). This was an updated (KDE-3.5.7) 10.2 home partition. Now to comment #14: ------------------- OK, some words about my config. My home partition is encrypted, i've created my user without the encrypted partition for backup purposes if no passphrase is entered at boot time. So this unencrypted home directory is from 10.3 base installation. So without mounting the encrypted home partition, i can encrypt the USB HD and mount the XFS partition. But to be sure iÄve created a new user and everything is fine also with this user!
Hmmm, now with ConsoleKit running since boot time, and this cookie and without the PolicyKit.conf workaround i can decrypt my home partition. Now i have to look if SCPM is the problem, maybe with another profile i will get the error again! :-( Confusing!
So, today consolekit was not running again, no idea why. Nor XDG_SESSION_COOKIE, too! Result: The error comes up again decrypting the device! After starting manually consolekit, logout and login to X session i have the cookie and decrypting the USB device is working again. So the problem relies on consolekit, sometimes it starts, sometimes not. But then the issue doesn't depend on restoring my home partition, right? But it was a clean 10.3-64bit installation! I've restored also the SCPM database, but the error with consolekit is coming up also without changing SCPM profile. Hmm, is there any log file where consolekit stores error messages during boot? syslog?
Ok, we actually have three bugs of which I think they are duplicates: 331002, 333735 and this (332057) one. It looks like a problem in the D-Bus init script. An update of D-Bus is tricky, however, so we need definitely make sure that it's really the culprit. Frank, please apply the changes mentioned in bug 333735 comment 12 and report back. Thanks!
Ha, here we are, i've read the other bug report, two totally different results for maybe the same error. But as i read this, i was wondering about also loosing sometimes my s2r and s2d in the KDE logoff screen. Maybe this is at the same the KryproMedia error comes up! I will test Comment #12 in bug 333735 but the same comment as the other poster, the error happens randomly! So the reason if it does not appear for a short time there is no guarantee the error is gone!
Update package candidates are here: ftp://ftp.suse.com/pub/people/hmacht/10.3/dbus-1/ Please test! Also make sure that when updating, the dbus daemon does not get restarted. As a result, you should _not_ get something like this in /var/log/messages: powersaved[30146]: ERROR (filter_function:99) DBus daemon disconnected. Trying to reconnect...
OK, update seems to work for x86_64: erwin:/home/ffiene/download/kernel # rpm -Uvh dbus-1-* Preparing... ########################################### [100%] 1:dbus-1 ########################################### [ 50%] 2:dbus-1-x11 ########################################### [100%] Update in progress, not restarting the D-Bus daemon What are the changes? Only not using startproc for background starting?
> What are the changes? Only not using startproc for background starting? Right. And as you might see, that the daemon is not restarted in the update case. So I think this is a dup of 331002, so closing as such. Thanks for your testing efforts! *** This bug has been marked as a duplicate of bug 331002 ***