[pkg-cryptsetup-devel] Bug#809686: cryptsetup: --header plus UUID plus initramfs gives "Requested offset beyond size of device"

[Benjamin Moody]

On 1/2/16, Milan Broz <gmazyland at 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