cryptsetup won't unlock my /home disk

hussam · 2009-10-08 17:10:44

I have both root disk and /home disk (different hard disks) encrypted with luks.
starting today, only the root "/" encryption passphrase is accepted.
it won't accept my /home passphrase. it worked only once in the last over 300 attempts and stopped working entirely after last kernel update reboot.
I did manage to unlock /dev/mapper/home but after over two hours of trying and it's really random.
Any idea what I can do?

Last edited by hussam (2009-10-08 17:22:18)

eWoud · 2009-10-13 14:10:49

I'm experiencing the same problem. "/" mounts without problems, all other partitions fail.

I can eventually get them to mount by repeating the cryptsetup command. There doesn't seem to be any logical cause for this, the amount of needed tries is completely random.

Downgrading the kernel to 2.6.30 doesn't help. There must be some package responsible for this, but I haven't found it.

hungerfish · 2009-10-13 14:26:53

+1 Add me in, something is very wrong...see
http://bbs.archlinux.org/viewtopic.php?id=82175

there's a list of the packages that I've recently updated, go and have a look, maybe check your own /var/log/pacman.log, and see if we can narrow this down!

Last edited by hungerfish (2009-10-13 14:28:41)

milomouse · 2009-10-13 16:04:42

After upgrading, and then reading this, I was worried I would have the same problem, but I had to reboot and [to my relief] all went well. I have both /root and /home encrypted with aid of LUKS, as well, but they're both on the same disk (if that matters).

I'm not sure if I'll continue to follow this topic but since I'm on the same basic setup and I didn't encounter the problem, I thought I'd throw out what I did and didn't do. So, since we're talking packages; yesterday I upgraded the kernel, and then today I upgraded these with "yaourt -Sb":

10:26:17 AM 10/13/2009: extra/atk 1.28.0-1
10:35:41 AM 10/13/2009: core/openssh 5.3p1-1
10:43:36 AM 10/13/2009: extra/poppler 0.12.0-1
10:48:16 AM 10/13/2009: extra/libsigc++2.0 2.2.4.2-1
10:49:47 AM 10/13/2009: extra/zenity 2.28.0-1
10:52:25 AM 10/13/2009: extra/pango 1.26.0-1
10:53:33 AM 10/13/2009: extra/pygobject 2.20.0-1
10:57:04 AM 10/13/2009: extra/pygtk 2.16.0-1
11:33:54 AM 10/13/2009: extra/gtk2 2.18.2-1
11:34:43 AM 10/13/2009: extra/gtk-engines 2.18.4-1

It still wants to upgrade:

==> Software upgrade (new version) :
extra/consolekit 0.3.0-5 -> 0.3.1-1
extra/poppler-glib 0.10.7-1 -> 0.12.0-1

==> New package :
extra/eggdbus 0.5-1  (required by polkit)
extra/polkit 0.94-1  (required by consolekit)

But I was weary of these new dbus & consolekit related packages because when I try building them from pkgbuild+source it keeps wanting me to use that eggdbus experimental d-bus bindings (which I see you've installed hungerfish). Sooo, I'm not sure where the problem lies, but figured I'd say I was questioning some of these New Packages, and didn't install them. I'm no expert, though. :/

hungerfish · 2009-10-13 21:36:19

Ok, I've tried to rollback a few other packages, but sadly I had little success
I tried to go back to consolekit 0.3.0-5 from 0.3.1-1, but that didn't help. I can't remove or go back anything much else, due to dependency issues.
So I'm hoping this will just 'blow-over', if not I'll need to further investigate...
I'm on x64 milomouse, are you on 686?

Last edited by hungerfish (2009-10-13 21:36:41)

hungerfish · 2009-10-15 13:26:48

So has anyone had any luck recently??? Cryptsetup (or whatever) is still broken for me!
Currently it only randomly accepts my pass-phrase and unlocks the drive.
This can happen the first time, or after 40 retries

Could you check if you have devicekit-disks installed. I read somewhere, that it was causing trouble for users trying to hook up their external drives, and since my problems started after installing gone2.28 (which pulled in devicekit-disks among others..) this maybe related.

For some reason, although I've disabled gdm, and start my openbox session via cli, gvfs along with devicekit and others start when I log in...

Last edited by hungerfish (2009-10-15 13:36:54)

vacant · 2009-10-15 14:13:17

I'd think it was something like keymap, but then it would never let you in.

hungerfish · 2009-10-15 15:27:47

No, sadly it doesn't seem to be that simple

celilo · 2009-10-17 00:38:20

I'm not dealing with the issue, but came across this post while working on a likely related issue.

Check from the gnome menu, System > Preferences > Authorizations

There is a policy under Storage for encrypted disks. Perhaps this is preventing your desired action since it defaults to admin authorization required.

okcarch · 2009-10-18 18:57:47

If anyone solves this, please post back. It appears that there are numerous users locked out of encrypted partitions after updating within the last few days. My laptop has been installed and working perfectly with encrypted disks since August of last year. My keyfiles in /etc/luks-keys are unchanged and still have the correct size and datestamp from that old install, but after my last round of updates, my disks are completely inaccessible at boot.

Like some posters above, I've found that if I loop the cryptsetup command over and over, it eventually succeeds:

i=1 ; until cryptsetup status home >/dev/null ; do echo Attempt number $i ; cryptsetup luksOpen -d /etc/luks-keys/home /dev/mapper/lvm-home home ; let i=$i+1 ; done

Might take 5 attempts, might take 50, there's never any way to know. Tailing /var/log/everything.log while it's making attempts, there is an endless flow of "kernel: Buffer I/O error on device dm-6, logical block X" (where X is 0-9) errors.

I can replicate the issue by creating a new volume and trying to get it set up and running:

lvcreate -L500M -n testing lvm
dd if=/dev/urandom of=/etc/luks-keys/testing bs=512 count=1
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/mapper/lvm-testing /etc/luks-keys/testing
cryptsetup luksOpen -d /etc/luks-keys/testing /dev/mapper/lvm-testing testing

It will always get "Command failed: No key available with this passphrase", and there will be errors in everything.og about "Buffer I/O" as above. I can leave things at the default rather than specifying a cipher, and I can use a password instead of a keyfile, the results are the same, it doesn't work.

tkdfighter · 2009-10-19 07:32:34

Filed a bugreport here. I have the same problem as you guys, it seems.

hungerfish · 2009-10-19 14:52:37

The bug-report mentions i686, I'm on x86-64 so its not limited to that 'arch'...
Lets hope somebody can figure this out, and fast!

okcarch · 2009-10-20 23:05:30

Just to close this out, the bugreport linked two posts above has the fix for this issue.

nexus7 · 2009-11-08 14:44:48

hi folks!

I don't know if this still of interest, but I solved it by recreating /dev/mapper/home using a randomly made keyfile instead of a passphrase on the root's console with / remounted rewritable after booting crashed once again. -- You may give it a try this way then. But because the partiton will be formatted, all import stuff there must be backed up somewhere else before (and copied back afterwards)!!

I just followed this section and omitted the "/mnt"-part of the paths given here, because I used this for my existing system, so e.g. /mnt/root/crypto becomes /root/crypto etc. Though the language is German you guys can figure out this easily, I guess; the subsection starts with "Für die home-Partition wollen wir kein extra Passwort verwenden, sondern ein Keyfile, ..." as an textual orientation -- but just follow the code lines.

Additionally I added MODULES="dm-mod xts aes-i586 aes_generic" to my mkinitcpio.conf (and rebuild the kernel) though I think this isn't necessary. -- But I'm that glad my box is booting again and I have no sparetime at all, that I don't have the urge to test this again now without it. Maybe somebody else will

edit:// @okcarch: what links with bugfixes did you mean? I couldn't see any, though I cleaned my glasses thoroughly...

Last edited by nexus7 (2009-11-08 14:50:39)

Arch Linux

#1 2009-10-08 17:10:44

cryptsetup won't unlock my /home disk

#2 2009-10-13 14:10:49

Re: cryptsetup won't unlock my /home disk

#3 2009-10-13 14:26:53

Re: cryptsetup won't unlock my /home disk

#4 2009-10-13 16:04:42

Re: cryptsetup won't unlock my /home disk

#5 2009-10-13 21:36:19

Re: cryptsetup won't unlock my /home disk

#6 2009-10-15 13:26:48

Re: cryptsetup won't unlock my /home disk

#7 2009-10-15 14:13:17

Re: cryptsetup won't unlock my /home disk

#8 2009-10-15 15:27:47

Re: cryptsetup won't unlock my /home disk

#9 2009-10-17 00:38:20

Re: cryptsetup won't unlock my /home disk

#10 2009-10-18 18:57:47

Re: cryptsetup won't unlock my /home disk

#11 2009-10-19 07:32:34

Re: cryptsetup won't unlock my /home disk

#12 2009-10-19 14:52:37

Re: cryptsetup won't unlock my /home disk

#13 2009-10-20 23:05:30

Re: cryptsetup won't unlock my /home disk

#14 2009-11-08 14:44:48

Re: cryptsetup won't unlock my /home disk

Board footer