Re: [dm-crypt] cryptsetup-reencode: LUKS-${UUID}.new is too small

[Arno Wagner <arno@wagner.name>]

On Thu, Mar 13, 2014 at 01:29:38 CET, Matthias Schniedermeyer wrote:
> On 12.03.2014 21:29, PePa wrote:
> > Arno Wagner <arno@...> writes:
> > > 
> > > On Wed, Mar 12, 2014 at 00:16:19 CET, PePa wrote:
> > > > I'm a big fan of dm-crypt/luks.
> > > > I'm trying to reencode a crypto_LUKS partition from -c aes-cbc-plain -s 128
> > > > -h sha1
> > > > like this:
> > > > cryptsetup-reencrypt -c twofish-xts-plain64 -s 512 -h sha512 -i 2000 -B 32
> > > > /dev/sda4
> > > > 
> > > > Output I'm getting:
> > > > Device LUKS-71a94fa6-9c84-45d7-80e8-ee61be3887e0.new is too small.
> > > > Creation of LUKS backup headers failed.
> > > > 
> > > > On it is a Physical lvm2-volume that could be shrunken. Is it just a matter
> > > > of doing that? How much more space is needed??
> > > 
> > > If you look at FAQ Item 6.2, you an see that you go from a herader
> > > size a little over 1MB to one thet is 2MB in size. The difference
> > > does not sound like much and is indeed not much, but it has to 
> > > be available. 
> > 
> > I shrunk the PV twice by 1 4MB extend, each time, but .new is still too
> > small. Does that mean that the PV somehow needs to be shifted to the
> > beginning of the luks partition? I don't want to use --reduce-device-size
> > before I know that the PV is not occupying that area.
> 
> Your problem is that you gain the space on the "wrong side".
> 
> If you imagine disc sectors/blocks as a stack, growing/shrinking 
> adds/removes(or frees) blocks at the top.

That was my first take also, but the manpage for cryptsetup-
reencrypt option --reduce-device-size says 

"This means that last sectors on the original device will be 
lost, ciphertext data will be effectively shifted by specified 
number of sectors."

This operation seems to shift the payload data towards the end by
the specified amount. So having enough space at the end inside the 
LUKS container should work.
 
> In your case you would need to add blocks to the underside of the 
> current stack or inbetween the current-header and the LUKS-payload-area.
> 
> That would be possible if there is free space before sda4 and you could 
> extend sda4 downward by decreasing the start of the partition by the 
> amount needed for the bigger header. 

That should also work. Make sure there is 2MiB space for the 
header, and shift the start of the data payload area in the 
repective header field.

> Or you would need to extend the 
> partition or shrink the filesystem and then move the whole payload-area 
> by the needed amount of blocks upwards (IOW copy each block the needed 
> offset upwards, beginning from the top and working downwards) to 
> accomodate the bigger header.
> 
> But as Arno has already said, all that is not for the faint of heart and 
> rather high-risk. "Backup & Restore" is a MUCH safer procedure.

Indeed. Reencryption is already crtical. Enlarging the header
in the barkain is another cirical thing on top that is in
addition error prone as youneed to to it exactly right.

You could do trial-runs on a smaller mock-up using a loop-file,
see FAQ Item 2.5 and only do the reencryption when you are sure.

Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -  Plato