SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I have several external hard disks with one encrypted partition (using cryptsetup luks).
In both KDE and XFCE, if I connect one of those drives, a window pops up to enter my passphrase. After entering the passphrase the filesystem inside the crypto partition became availabe to KDEs or XFCEs volume- and/or filemanager with it's label and one was able to mount or dismount it.
This stopped working after the cryptsetup upgrade from April 30. The window to enter the passphrase does appear and after entering the passphrase the drive gets 'unlocked' (it's listed in /dev/mapper), but nothing appears in dolphin or thunar or those panel plugins to manage drives.
It seems that HAL is not notified anymore about the new filesystem available. Restarting HAL and then restarting the DE does help.
Reverting back to cryptsetup before April, 30, does solve this issue.
One difference between those versions is that cryptsetup 1.0.7 names the decrypted devices as /dev/dm-N (where N is a sequential number) and puts a softlink in /dev/mapper whereas verion 1.1.0 makes the decrypted device directly available in /dev/mapper. Don't know if this might has something to do with the regression in DEs...
lukssda5 was unlocked by cryptsetup in the initrd.
lukssda3 was unlocked manually by root using /usr/sbin/cryptsetup on a running system.
I'm also a little concerned about that others 'read' permission that seems to have crept in on lukssda3. Filesystem block devices don't normally allow that.
On my setup Dolphin shows a "encrypted device container" entry in the 'places' sidebar for my already unlocked lvm PV, with an option to unmount it. That really seems dodgy to me and it needs to filter these out somehow in the same way that it doesn't list partitions mounted from /etc/fstab. Maybe a check to see if an open luks mapping name refers to a pv in an active lvm vg needs to be added. Not sure how you'd go about making it that intelligent though. Might have a dig.
I've got a spare partition sitting about so I'll give unlocking a try from dolphin and report back.
Thx GazL for your reply. Do you run -current with cryptsetup from after April, 30th? It doesn't seem so for me... The behaviour in dolphin you describe is what it used to be. After this upgrade my internal (already mounted) crypto partitions disappeared from dolphin. But as I don't care much about this, the problem reported here was only about external (removable) media which HAL isn't notified about.
After digging around in the internals of hal/udev a little this afternoon, I think I'm going back to WINDOWS!!! MY GOD! What a convoluted, tangled up ball of string it is!
The concept of udev is fine, but the implementation and how the various rules files indirectly affect each other by setting/passing obscure variables, cookies, calling external programs etc is just ugliness incarnate! And that's before you even get to the ugliness that is hal!
Anyway, from what I can see the udev rules that handle dm devices seem to be creating two device nodes: the usual one /dev/dm-n and then another one in /dev/mapper that should be a symlink to it.
gazl@nix:~$ ls -l /dev/dm-8 /dev/mapper/lukssda3
brw-rw---- 1 root disk 253, 8 2010-05-24 15:54 /dev/dm-8
brw-rw-r-- 1 root disk 253, 8 2010-05-24 15:54 /dev/mapper/lukssda3
And as you can see the additional node in /dev/mapper has the wrong permissions (probably because it shouldn't be being created there in the first place)
Looks like this is fixed upstream in cryptsetup 1.1.1.
udev support was new in 1.1.0. Looks like a few bugs crept in.
I also tried adding the --disable-udev configure option, but that just seemed to break it again.
If you're running your rootfs on an encrypted volume and unlocking anything in your initrd, don't forget to rebuild your initrd and rerun lilo after updating as that also contains a copy of cryptsetup.
Pardon the posting from Windows, but I'm at work and that's all I can get online with here, but I just upgraded cryptsetup on my laptop and it still doesn't work for me. There's some improvement in that I'm only asked for the passphrase *once* instead of twice, but I still get no icon and no automount in Xfce.
I think this might be an issue with thunar-volman actually, but I don't know C well enough to wade through all of it.
If someone is on IRC and can join #claws-mail on freenode, see if colinl (Colin Leroy) is around and might be willing to help -- he wrote the initial patches to get encrypted device support in Xfce.
I tried it under KDE/dolphin and the upgrade certainly seemed to fix volume unlocking on that, plus it fixed the permissions and the symlink was back again in /dev/mapper.
I don't use XFCE and I assumed it would be the same issue. My bad.
Do you get a symlink again in /dev/mapper for the mapping device or is it still showing a device node?
One thing I did notice was that if you'd used the old version of cryptsetup prior to the new then it tended to cause problems. I think it must leave some sort of 'state' in the kernel somewhere. It wasn't until after I'd rebuilt mkinitrd (to take a fresh copy of cryptsetup) and rebooted that it seemed to settle down for me.
My encrypted partition is on my fixed disk and I can't see a way to unlock that from XFCE. It seems the volume manager thingy is only for "removable" media.
Hrm, I have an idea (from talking quite some time ago with Kay Sievers). Basically, upstream lvm/dm guys and upstream udev guys disagree on some implementation details, and we might be seeing some fallout from that.
In one of the lvm udev rules (10-dm.rules iirc), there's line that has STARTUP=1 in it that sets NAME="" (this is from memory) -- try commenting out that line completely. If that doesn't make sense right now, don't do anything until I can actually sit down in front of a machine and see the text...
Yes, I was wondering about that stuff too when I was looking at it yesterday and it was that file that triggered my little mini-rant about udev getting way too complicated. I wasn't really comfortable changing it though as I didn't understand how it all fit together. I think you're right on this being a bad interaction between cryptsetup and the dm/lvm udev rules.
Just as a final bit of info on this. I just rebooted and did a cryptsetup from the command line straight away and still got the:
device-mapper: ioctl: unable to remove open device temporary-cryptsetup-1830
So, whether it works or not seems somewhat random at the moment.