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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]