On Sat, 2009-10-10 at 17:13 +0300, Rogutės Sparnuotos wrote:
Hussam Al-Tayeb (2009-10-10 14:11):
Yes, I've reinstalled both the kernel and cryptsetup. luks is device blocks encryption if I'm not mistaken so filesystem type shouldn't matter.
Yes, the filesystem type shouldn't matter. Anyway, I'm running a custom built 2.6.31.3 and use an encrypted ext4 home partition with passphrases, and it works here.
In your previous mails you were saying that your home partition unlocks every time, but only after numerous consecutive tries, correct? That is, after booting,
dash -c 'echo "pass"|cryptsetup luksOpen dev name'
doesn't work, but
dash while ! echo "pass"|cryptsetup luksOpen dev name; do n=$((n+1)); test $n -ge 100 && break done
does?
If that is the case, it is really strange and I doubt I can help you.
Did you try simply booting up, waiting for a minute or two and trying to unlock the partition?
You didn't post the relevant part of your /var/log/pacman.log yet (the part with the update which broke cryptsetup).
You didn't say why and how did you update to 2.6.31.3. Are you running the testing repository?
You didn't say whether you tried downgrading your kernel: $ pacman -S kernel26 and/or $ pacman -S kernel26-lts
Did you try running /sbin/cryptsetup.static instead of cryptsetup?
Might module loading be delayed because of some obscure reason? $ lsmod|grep -i aes
Have you got some exocitc cpu with hardware AES encryption?
I'm on limited connectivity till Monday so I can't try the lts kernel before then. aes_generic and aes_i586 are loaded. The computer is an old AMD 2300+ I tried echo password | /sbin/cryptsetup.static luksOpen /dev/sdb1 home it worked after 17 tries.