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. 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. 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. -- Matthias _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
