LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 05-24-2010, 03:08 AM   #1
Rupa
Member
 
Registered: Apr 2008
Location: Berlin, Germany
Distribution: Slackware, Debian, NetBSD
Posts: 80

Rep: Reputation: 25
cryptsetup bug in -current


Hello!

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...

Can anyone confirm this issue?
 
Old 05-24-2010, 04:23 AM   #2
GazL
Senior Member
 
Registered: May 2008
Posts: 3,383

Rep: Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915
Hmm, /dev/mapper is definitely different.
Code:
gazl@nix:~$ ls -l /dev/mapper
total 0
crw-rw---- 1 root root  10, 61 2010-05-24 09:39 control
brw-rw-r-- 1 root disk 253,  8 2010-05-24 10:02 lukssda3
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 lukssda5 -> ../dm-0
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvhome -> ../dm-6
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvlocal -> ../dm-7
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvopt -> ../dm-3
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvroot -> ../dm-1
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvtmp -> ../dm-5
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvusr -> ../dm-2
lrwxrwxrwx 1 root root       7 2010-05-24 09:39 rootvg-lvvar -> ../dm-4
gazl@nix:~$ ls -l /dev/dm-0
brw-rw---- 1 root disk 253, 0 2010-05-24 09:39 /dev/dm-0
gazl@nix:~$
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.
 
Old 05-24-2010, 04:42 AM   #3
Rupa
Member
 
Registered: Apr 2008
Location: Berlin, Germany
Distribution: Slackware, Debian, NetBSD
Posts: 80

Original Poster
Rep: Reputation: 25
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.
 
Old 05-24-2010, 04:44 AM   #4
GazL
Senior Member
 
Registered: May 2008
Posts: 3,383

Rep: Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915
Update:
Yes, the filesystem doesn't show up once the container is unlocked here either.


Rupa, I'm running a fully uptodate 64current.

Last edited by GazL; 05-24-2010 at 04:48 AM.
 
Old 05-24-2010, 10:00 AM   #5
GazL
Senior Member
 
Registered: May 2008
Posts: 3,383

Rep: Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915
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.

Code:
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 a udev bug.
 
Old 05-25-2010, 06:40 AM   #6
GazL
Senior Member
 
Registered: May 2008
Posts: 3,383

Rep: Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915
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.
 
Old 05-25-2010, 01:05 PM   #7
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,913

Rep: Reputation: Disabled
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.
 
Old 05-25-2010, 01:54 PM   #8
GazL
Senior Member
 
Registered: May 2008
Posts: 3,383

Rep: Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915
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.
 
Old 05-25-2010, 02:09 PM   #9
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,913

Rep: Reputation: Disabled
The /dev/mapper/ file is indeed a symlink. This was with a rebuilt initrd and a reboot. Yes, the volume manager only deals with removable devices.

I'll try to catch Colin online soonish and hope he's not swamped too :/
 
Old 05-25-2010, 02:24 PM   #10
GazL
Senior Member
 
Registered: May 2008
Posts: 3,383

Rep: Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915
Ok, It looks like there's multiple problems going on here. I just tried again under KDE/dolphin and the first 2 times it worked, but then it stopped working again.

I've noticed that when it stops working syslog contains the following right after the 'open' from dolphin.
Code:
May 25 20:12:50 nix kernel: device-mapper: ioctl: unable to remove open device temporary-cryptsetup-2175
and once it's got in this state, trying to do a luksOpen (after closing the previous mapping) from the commandline gives a
Code:
oot@nix:~# cryptsetup luksOpen /dev/sda3 lukssda3
Enter passphrase for /dev/sda3: 
device-mapper: remove ioctl failed: Device or resource busy
Key slot 0 unlocked.
root@nix:~#
So, 1.1.1 fixes the symlink thingy, but there's still something very broken going on, and it doesn't look like it's a kde or xfce issue.

Last edited by GazL; 05-25-2010 at 02:27 PM.
 
Old 05-25-2010, 02:54 PM   #11
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,913

Rep: Reputation: Disabled
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...
 
Old 05-25-2010, 03:10 PM   #12
GazL
Senior Member
 
Registered: May 2008
Posts: 3,383

Rep: Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915
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:
Code:
device-mapper: ioctl: unable to remove open device temporary-cryptsetup-1830
So, whether it works or not seems somewhat random at the moment.
 
Old 05-26-2010, 05:41 AM   #13
conraid
Member
 
Registered: Feb 2008
Location: Leghorn, Tuscany, Italy
Distribution: Slackware
Posts: 78

Rep: Reputation: 28
For usb crypt partition
Code:
# cryptsetup luksOpen /dev/sdb2 hdcrypt
Enter passphrase for /dev/sdb2: 
device-mapper: remove ioctl failed: Device or resource busy
Key slot 0 unlocked.

In a lvm partition i have similar error, only if I run cryptsetup while booting, (/etc/crypttab) everything is ok, but if I try to open it later by mistake
 
Old 05-28-2010, 03:39 PM   #14
GazL
Senior Member
 
Registered: May 2008
Posts: 3,383

Rep: Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915Reputation: 915
Right, I've managed to get this working by:

upgrading cryptsetup to 1.1.1 and udev to 156.

It still throws out the ioctl remove failed: device is busy message, but that seems to be a known problem upstream and doesn't actually affect the locking/unlocking.

I'd also upgraded lvm to 2.02.66 but I don't think that actually mattered.


Anyway, I've dropped Pat a line about this, so hopefully we might see some patches to fix this turn up.
 
Old 05-28-2010, 10:06 PM   #15
rworkman
Slackware Contributor
 
Registered: Oct 2004
Location: Tuscaloosa, Alabama (USA)
Distribution: Slackware
Posts: 1,913

Rep: Reputation: Disabled
Still the same here, so udev isn't the magic bullet.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
cryptsetup problem on -current BCarey Slackware 5 05-06-2010 03:45 PM
Slackware64-current Segmentation Fault in cryptsetup Ron Parker Slackware 2 08-19-2009 02:04 PM
[BUG] Current pkgtools installpkg bug jazzor Slackware 7 04-16-2009 05:30 AM
A bug about QT in current zhoun Slackware 5 03-15-2009 09:14 PM
Is this a bug in current? slackware_newbie Slackware 3 09-19-2006 01:46 PM


All times are GMT -5. The time now is 02:35 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration