Xfce LUKS handling randomly fails

TwinReverb · 05-24-2010, 09:50 PM

Anyone else experiencing the random LUKS fails? Anyone know of a solution?

http://bugzilla.xfce.org/show_bug.cgi?id=6457

I filed a bug. Basically I have a USB hard drive with two LUKS partitions on it (sdb2, sdb3). When plugged in, it asks for the password in Xfce (like it did in Slackware 13.0), but instead of the previous "asks twice for password" bug, now it asks once, but nothing pops up on the desktop. It's rare to see either of them put an icon on the desktop (usually nothing results).

I see /dev/mapper/luks_crypto_{UUID} get populated, so they are successfully being unlocked (LUKS), but no icon appears, and no mount point for the volume label (i.e. /media/BACKUP /media/ASUS) is populated.

Does anyone know how I could produce a more useful bug report? I'm wondering if "strace startxfce" would produce anything useful or if I should alias Thunar to "strace -o /tmp/thunar-`date`.txt" would be in order.

rworkman · 05-25-2010, 12:22 AM

More discussion here: http://www.linuxquestions.org/questi...urrent-809730/

Sadly, I don't have time to investigate more at this point, but maybe mention the bug report in that other thread and you guys see what you can dig up. I've got a new baby set to arrive any day now, so I'm a bit busy :-)

mlangdn · 05-25-2010, 12:54 AM

Congrats on the new arrival!

Ilgar · 05-25-2010, 02:57 AM

First of all, congratulations Robby!

The bug on the other thread was reported to occur after the cryptsetup upgrade. Did anyone try downgrading to the version in 13.0? Or do we absolutely need the latest version for 13.1?

Rupa · 05-25-2010, 04:05 AM

Yes, downgrading to the cryptsetup version from 13.0 does solve this. But I would consider that rather an ugly workaround than a solution...

GazL · 05-25-2010, 06:54 AM

Yes, good luck Robby. Hope Mrs. Workman has a smooth time of it.

The problem is fixed upstream in the just released cryptsetup 1.1.1.

TwinReverb · 05-25-2010, 09:48 PM

Today I tried bypassing Xfce and instead mounting the device manually. I found some interesting info:

Code:

bash-4.1# cryptsetup luksOpen /dev/sdb2 BACKUP
Enter passphrase for /dev/sdb2: 
device-mapper: remove ioctl failed: Device or resource busy
Key slot 0 unlocked.
bash-4.1# ls /media
README       cdrecorder1  cdrom1  dvd1     floppy1  hd1      memory1  zip1
cdrecorder   cdrom        dvd     floppy   hd       memory   zip
cdrecorder0  cdrom0       dvd0    floppy0  hd0      memory0  zip0

Therefore the problem may not be Xfce in the first place.

TwinReverb · 05-25-2010, 10:00 PM

Quote:

Originally Posted by GazL

Yes, good luck Robby. Hope Mrs. Workman has a smooth time of it.

The problem is fixed upstream in the just released cryptsetup 1.1.1.

I downloaded the Slackware 13.1 official slackbuild and the cryptsetup 1.1.1 tarball and it built without errors. However, in Xfce the problem is still not fixed. I get the same error situation: I give the password but nothing happens (yet /dev/mapper/luks_crypto_$UUID gets populated for both sdb2 and sdb3).

However, when I manually open the device in a terminal as root, it appears on the desktop in Xfce.

rworkman · 05-26-2010, 01:36 AM

Okay, comment out this line completely in /lib/udev/rules.d/10-dm.rules

Code:

ACTION=="add", ENV{STARTUP}!="1", NAME="", GOTO="dm_end"

Then do

Code:

/etc/rc.d/rc.udev reload

and see if it works for you. It didn't here, but maybe it will for you.
I just upgraded the lvm2 package to the latest 2.02.66, and my MMC card with LUKS device works fine. However, my usb thumbdrive still does not. My next trial will be commenting out these two lines:

Code:

ENV{DM_UUID}=="CRYPT-TEMP-?*", GOTO="dm_disable"
ENV{DM_UUID}!="?*", ENV{DM_NAME}=="temporary-cryptsetup-?*", GOTO="dm_disable"

but that's going to have to wait until tomorrow.

GazL · 05-26-2010, 04:44 AM

@TwinReverb, Yes, sorry about that I was a little too quick to call 'fixed'. It was working on my box but then it broke again. Whatever the problem is it's intermittent, but frequent. At least it fixes the symlink issue though, so it's a step in the right direction.

@Robby, I tried removing that STARTUP!='1' line last night. Had no effect here either.

Found this 'defect' report for the "resource busy" thingy. The last entry is interesting:

Quote:

I've upgraded to Linux 2.6.34-rc5 and sys-fs/udev-151-r2. I don't know what made the
difference.

We're already running higher than udev 151 and the guy who posted that doesn't say what version of lvm2/mapper he was running so I'm not sure how reliable that is.

I might try going to 2.6.34 to see if it's a kernel issue or not.

GazL · 05-26-2010, 05:55 AM

Just tried 2.6.34 and it's the same. (wasn't really expecting it to be otherwise to be honest)

TwinReverb · 05-26-2010, 11:31 AM

Quote:

Originally Posted by rworkman

Okay, comment out this line completely in /lib/udev/rules.d/10-dm.rules

Code:

ACTION=="add", ENV{STARTUP}!="1", NAME="", GOTO="dm_end"

Then do

Code:

/etc/rc.d/rc.udev reload

and see if it works for you.

Worked like a charm on my Core2 Duo laptop (Sony Vaio VGN-C140G).

On my netbook it had an adverse affect on all devices. (LUKS SD card and USB hard drive with 2nd and 3rd partition as separate LUKS partitions both give me the error "special device /dev/mapper/luks_crypto_$UUID does not exist.)

Oh well, nothing is perfect I guess.

Rupa · 05-26-2010, 02:22 PM

Quote:

Originally Posted by rworkman

Okay, comment out this line completely in /lib/udev/rules.d/10-dm.rules

Code:

ACTION=="add", ENV{STARTUP}!="1", NAME="", GOTO="dm_end"

If I do this (after upgrading to cryptsetup-1.1.0 again), my internal crypto partitions like /home are not mounted anymore. cryptsetup seems to work but after unlocking the device there is no link or file in /dev/mapper at all (besides 'control' of course). So I'm back at cryptsetup-1.0.7 once more...

Rupa · 05-26-2010, 02:24 PM

Quote:

Originally Posted by TwinReverb

LUKS SD card and USB hard drive with 2nd and 3rd partition as separate LUKS partitions both give me the error "special device /dev/mapper/luks_crypto_$UUID does not exist.

Yes, same here. And the message is telling the truth as there is no file in /dev/mapper at all.

TwinReverb · 05-28-2010, 04:31 PM

Downgrading back to Slackware 13.0. Problem solved.