[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#392285: partman-crypto: Fails to cause cryptomount to be loaded

tags 392285 + confirmed pending

Hi James,

On Tue, Oct 10, 2006 at 07:40:18PM +0100, James Westby wrote:
> I had the first partition for / unencrypted, then two partitions, a
> random key for swap, and a GPG encrypted key for /home. I used
> twofish128 for minimum impact while testing. The install went
> fine, until I rebooted.

> I was asked for my passphrase, and when I entered it I was told /home
> couldn't be mounted. The following message accompanied it.

>   LOOP_SET_STATUS: Invalid argument, requested cipher or key length (128
>   bits) not supported by kernel.

> I googled the error, and found a message written by Max indicating that
> another module was needed. I modprobed cryptoloop, and it changed the
> error message. So it seems like some magic chould be done to load this
> module at boot time.

That's only partially correct. :-)

The above error is shown if the LOOP_SET_STATUS/64 ioctl failed for
the chosen combination of cipher/keysize. In this case, it indicates
that the kernel had no support for loopback crypto as neither the
cryptoloop nor a loop-AES module was loaded. As shown by the second
error you quoted below, however, the newer crypto modes of loop-AES 
are not supported by the old cryptoloop module, so it can not be 
used as a replacement for the loop-AES module.

> After adding cryptoloop I get the error message

>   LOOP_MULTI_KEY_SETUP_V3: Invalid argument

> #318944 suggests this is because a v3 key was used with a v2 module, but
> I have a v3 module installed. 

Yes, this indeed used to be a frequent cause for similar errors.
In this case though, I think the reason is likely to be that the
cryptoloop module doesn't know about multi-key modes and therefor
doesn't handle this particular ioctl. 

> Apologies if I am doing something stupid here, please punish me if I am.

> Also I don't know what version I am supposed to put for these, but I am
> using the daily image downloaded 8th October, and installed the day
> after. I have loop-aes-2.6.16-2-686 3.1d+3+3 installed by the installer.

I strongly suspect that this is the problem. The default kernel
currently installed by daily builds is 2.6.17-2, but loop-aes-* is
only available in testing for 2.6.16-2. The installer likely tried
to install the meta package loop-aes-2.6-686 and so ended up with
the old modules package. If you still have the VM, you should be 
able to verify by installing loop-aes-2.6.17-2-686 from unstable.

<time warp> So I have just completed a test install and can 
confirm that this is indeed reproducible and can be fixed by
installing the package loop-aes-2.6.17-2-686. The problem will
exist until we manage to migrate loop-aes modules for 2.6.17-2 to
testing (hopefully soon), or until the 2.6.18 kernel becomes the
default kernel in testing along with new loop-AES modules.


Reply to: