Arch Linux

I have this exact same error after the most recent upgrade. I note that pmount fails before prompting for a password, too - unless it is run with sudo, it generates that error immediately and without further prompting. Also, my system is x86_64.

Interestingly, this does NOT affect mounting my whole-disk encryption. Only my external drives.

That most recent upgrade included a lot of programs, but after sorting through it, I believe it included cryptsetup (1.0.7-1 > 1.1.0-1), device-mapper (2.02.53-1 > 2.02.60-2), and lvm2 (2.02.53-1 > 2.02.60-2). I suspect one of those might be the culprit, but I'm not knowledgeable enough to do more than hold that hunch (though I'm going to try process of elimination on another computer when I have a chance and report back). A Google search for "pmount cryptsetup luksopen failed" likewise resulted in what appears to be a multiply-mirrored Debian bug report from 2009 that I'm not smart enough to understand.

Frank, I agree with you. I don't use pmount, but I had the same problem.
I reinstalled the old versions of cryptsetup, device-mapper and devicekit-disks and the problem was resolved.
For now, they will be on the list of ignored packages (IgnorePkg = cryptsetup device-mapper devicekit-disks)

@mitre: That causes a ton of other problems and is not a good idea if you use encryption in your base system! The main problem is that the new device-mapper (and devicekit-disks) prevents udev from messing with the devices cryptsetup creates when it shouldn't, thus avoiding a ton of race conditions. The fact that it works as root tells me that something must be wrong in pmount - unfortunately, strace/ltrace will negate setuid and debugging is difficult.

Sorry it's taken me so long to get back to this.

Using the latest version of devicekit-disks (009-4) has no effect on my systems. I don't think it was included in the batch of upgrades after which I saw this issue, so it didn't occur to me that it might be a problem.

Anyway, I can confirm that the issue is NOT in the latest version of device-mapper or lvm2. I held back both of those on my other box and upgraded ONLY cryptsetup (as noted, 1.0.7-1 to 1.1.0-1), and after a reboot, this issue appeared. So something changed in cryptsetup to cause this. So, mitre, holding back device-mapper and devicekit-disks is probably pointless.

I don't know anything about the race conditions brain0 discusses. Nor do I have any idea about whether this is a problem in cryptsetup or a problem in pmount. But it's the cryptsetup upgrade that does this on my system.

If the issue is unrelated to device-mapper and only related to cryptsetup, then it can only be that pmount uses some cryptsetup option that has been removed, or changed (in particular, this has nothing to do with the device-mapper changes and thus is no timing issue as I suspected). This has to be fixed in pmount then.

I don't have time to do this now, but you could try this (if you know how to): See if pmount has a "verbose" option that prints the cryptsetup command it executes. If not, go into the source and patch pmount such that it always prints the cryptsetup command to stderr before executing it. That will bring us a step closer to the problem.

@brain0: I don't use encryption in my base system. I read something about how it avoids some problems in another topic.

@frankspace: I thought the device-mapper influence the cryptsetup. In fact, I should have tested it.

Some small test with --debug:

spawnv(): executing /usr/sbin/cryptsetup '/usr/sbin/cryptsetup' 'isLuks' '/dev/loop0'
spawn(): /usr/sbin/cryptsetup terminated with status 0
spawnv(): executing /usr/sbin/cryptsetup '/usr/sbin/cryptsetup' 'luksOpen' '/dev/loop0' '_dev_loop0'
spawn(): /usr/sbin/cryptsetup terminated with status 234
Internal error: cryptsetup luksOpen failed

It works as root, like reported earlier.

I also patched pmount so that it doesn't redirect stdout and stderr, the error message is 'Cannot open device /dev/loop0.' (I am testing with /dev/loop0)

http://code.google.com/p/cryptsetup/issues/detail?id=47#c14

pmount 0.9.22 finally fixes this.
But now there's http://bugs.archlinux.org/task/19463