Bug#392285: partman-crypto: Fails to cause cryptomount to be loaded
tags 392285 + confirmed pending
thanks
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.
cheers,
Max
Reply to: