Mount hangs while trying to mount luks partitions after upgrade to 12.2

MeatPuppet · 03-07-2009, 08:04 AM

Hello

After upgrading to 12.2 and the new 2.6.27-7 kernel I can no longer mount my luks encrypted partitions.

Code:

root@box:~# cryptsetup luksOpen /dev/sdd1 sdd
Enter LUKS passphrase: 
key slot 0 unlocked.
Command successful.
root@box:~#

Unlocking the drive is successful, and everything seems to be fine

Code:

root@box:~# mount /dev/mapper/sdd /mnt/crypt0/

At this point it will hang forever.

Code:

root@box:~# ps aux | grep mount
root      2725  0.0  0.0   2044   656 pts/1    D+   23:00   0:00 mount /dev/mapper/sdd /mnt/crypt0/

And I'm forced to manually kill the process..

However, doing that results in the following:

Code:

root@box:~# cryptsetup luksClose /dev/mapper/sdd
Command failed: Device busy
root@box:~#

The same happens with all my luks encrypted partitions, while unencrypted partitions mounts just fine.

The kernel update has been accomplished using "make oldconfig" so there should really be nothing missing from the new one.

What has happened? Anyone experienced the same with 12.2?

MeatPuppet

Drakeo · 03-07-2009, 08:28 AM

depends if you used the config to the 2.6.27.huge smp. any reason why you did not just install the stock kernel from slackware I custom build my own so I do understand. but there is a big defference between the kernel-huge-smp-2.6.24.5_smp-i686-2 and kernel-huge-smp-2.6.27.7_smp-i686-1 and also for further notice huge difference with the 2.6.28 kernel.
so if the crypt section of the tree has been moved make oldconfig should ask you to do some updating. But if you used the regular 2.6.24.5 generic config most likley you used the wrong config. if you think you have everything correct then make sure that crypt module is being loaded at boot. otherwise reconfigure and build.

update your modules init to 12.2 or current.

Quote:

http://packages.slackware.it/search....ent&t=1&q=init

this loads parts of the kernel and has been updated for the last three slackware kernels kernel.
I am a little lost you updated or upgraded to 12.2 then built the kerel ? why.

MeatPuppet · 03-07-2009, 08:51 AM

Quote:

Originally Posted by Drakeo

depends if you used the config to the 2.6.27.huge smp. any reason why you did not just install the stock kernel from slackware I custom build my own so I do understand. but there is a big defference between the kernel-huge-smp-2.6.24.5_smp-i686-2 and kernel-huge-smp-2.6.27.7_smp-i686-1 and also for further notice huge difference with the 2.6.28 kernel.
so if the crypt section of the tree has been moved make oldconfig should ask you to do some updating. But if you used the regular 2.6.24.5 generic config most likley you used the wrong config. if you think you have everything correct then make sure that crypt module is being loaded at boot. otherwise reconfigure and build.

update your modules init to 12.2 or current.
this loads parts of the kernel and has been updated for the last three slackware kernels kernel.

While running the 2.6.24-4 kernel I was running the OCF (Open Cryptographic Framework) to support my HiFn crypto accelerator, but the driver for this card is implemented into the kernel itself in 2.6.27, otherwise I would have been running .24 for quite longer. However, the HiFn card (while technically able to do so) should not inflict with cryptsetup, and the crypt-modules for the card is independent.

Code:

name         : cbc(aes)
driver       : cbc-aes-hifn0
module       : hifn_795x
priority     : 300
refcnt       : 2
type         : ablkcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

Code:

name         : aes
driver       : aes-generic
module       : kernel
priority     : 100
refcnt       : 1
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

So in theory, luks should use the built in kernel driver, rather than my crypto-accelerator. But the crypto accelerator does work, so even if it did, there should be no issues linked to that.

The reason I run a custom kernel and not the standard one is that I quite simply prefer to make my own, and this computer (which is actually a server) has some quite exotic hardware, and the SCSI raid controller must be configured and added manually for the system to boot at all.

I suppose the issue here might be that the previous OCF from my old kernel might interfere with the new framework, but that is a good question in itself since it seems all the crypto stuff (except for mounting of luks) is working properly. And I cannot see why OCF should do that considering the only way it could interfere would be through the moving of .config from the old tree to the new one.

And since you say there are a massive difference between 2.6.24-4 and 2.6.27-7 I might have been a little over-enthustiastic in regards to just doing an "oldconfig" and expecting everything to work like the good old times. Damn my slack attitude

I am really at a loss here,

MeatPuppet · 03-07-2009, 06:44 PM

Same results after completley clean kernel from kernel.org, 2.6.28-7 is doing the same thing. This seems to be related to slack 12.2 rather than the actual kernel itself.

Anyone has any ideas on what might cause it?

Drakeo · 03-08-2009, 07:36 AM

look at your /etc/modprobe.d folder and see if it the old module is set to load and conflicting with the kernel module.

Quote:

While running the 2.6.24-4 kernel I was running the OCF (Open Cryptographic Framework)

check your scripts and see if this program is set to run at boot conflicting with the kernel.
it could be in your /etc/rc.d or look at the /etc/rc.d/rc.M script
from what I have been reading this has been an issue since the 2.6.26 kernel. and it seems to be a hal issue with the scripts.
you know more than I do about the program I know hardware. but key word this in google.

Quote:

linux hal crypt 2008

MeatPuppet · 03-08-2009, 07:57 AM

Quote:

Originally Posted by Drakeo

look at your /etc/modprobe.d folder and see if it the old module is set to load and conflicting with the kernel module.check your scripts and see if this program is set to run at boot conflicting with the kernel.
it coould be in your /etc/rc.d or look at the /etc/rc.d/rc.M script

I did a complete wipe of the system, installing fresh from a 12.2 cd, still the same issues. Tried newest kernel from kernel.org and not the slack repository, same issues.

My next step (the kernel is compiling now..) is to disable the HiFn card entirely from the kernel, and see if it works then, if it does, this might just be a kernel bug.. the kernel-inbuilt OCF framework is quite new after all...

MeatPuppet