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

[Milan Broz]

On 01/03/2016 12:48 AM, Benjamin Moody wrote:
> On 1/2/16, Milan Broz <gmazyland at gmail.com> wrote:

> 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.

IMHO it should be added there always if cryptsetup is in initram.

> 
>> 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.

Yep, you are right, I mishandled own debug print :)

...

> 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.

Managing links is completely dynamic and asynchronous work of udev threads,
close-on-write causes rescan (so even cryptsetup cannot be sure that
the link points to the same device as in the beginning).

There can be perhaps more debug info (just it should not say too much info
about your device in debug log, it can be private info (HW UUID etc).)
 
>> (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.

You can keep LUKS header on device and wipe (kill) all keyslots.
In this case the device has still UUID but you cannot open it without external
header.
(But you cannot rely on uuid symlinks apparently here. Or you can change UUID,
luksUUID command allows that.)

Milan