On 1/2/16, Milan Broz <gmazyl...@gmail.com> wrote: > Note >> # Userspace crypto wrapper cannot use aes-xts-plain64 (-95). >> # Using dmcrypt to access keyslot area. > > The reason is that you are missing kernel userspace crypto API modules > in initram (af_alg, algif_skcipher, ...), then cryptsetup fall back to > using > dmcrypt-device for keyslot processing (that requires loop driver).
Ah, this makes sense now. Adding 'algif_skcipher' instead of 'loop' to /etc/initramfs-tools/modules does the trick. The cryptsetup error reporting could be improved, though - I don't recall the exact message, but it was originally complaining about not being able to create a loop device. It might be sensible for the cryptsetup package to add the algif_skcipher module (or any others that might be needed?) to the initramfs automatically if a header file is used. > But the real problem: >> === broken cryptsetup log === >> Enter passphrase for >> /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e: >> Requested offset is beyond real size of device >> /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e. > > ... >> # Key length 64, device size 4040 sectors, header size 4036 sectors. > > Here apparently device size 4040 sectors is wrong (too small). No, this message seems to refer to the size of the header file; the same size is shown when it works properly. > Please check where link > /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e is pointing, > check with blockdev --getsz <dev>. > > I would say that udev created link to used loop device instead of your > ciphertext device. You're probably right. Good old udev just doesn't miss a trick. Of course, if I actually run 'ls -l /dev/disk/by-uuid/003b718b-69a5-4974-9a56-54fc07f3835e', either before or after running cryptsetup, it will be pointing to /dev/sda2... but DURING cryptsetup it presumably points to that loop device. It might be wise for cryptsetup to chase the symlink passed on the command line before doing anything else, or for the initramfs scripts to do so. > (In fact, your command is wrong. If the underlying device has no LUKS header > on it, there cannot be link with LUKS UUID to it! I would guess you have old > LUKS header on it as well so witout loop activated it work by chance..) Yep. I originally created these partitions using a normal luksFormat, and then made copies of the headers (which, naturally, doesn't change the UUID.) As I said before, I like having the header on the disk for recovery purposes; and I also think it's probably a good idea to identify the source partition by UUID or some similar labelling mechanism, though I see how this can be problematic. I suppose one option, to avoid problems in the future, would be to change the UUID stored in the header file. Benjamin