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

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

[PePa]

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

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

[Arno Wagner]

Hi,

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. 

The --reduce-device-size of cryptsetup-reencrypt can be used to 
enlarge the header by what is needed, but will just cut off the 
amount the data-area gets shifted from its endm, thereby likely 
damaging the filesystem in there and destroying data, or, in the
worst case, the while filesystem.
  
So in theory, you could use some tool to shrink the filesystem 
in the openend container and then use this option to shift and 
cut the data ares.

However, there are several high-risk operations in here that 
you should under no circumstances run without a full, good 
data backup. If you have that, it is a lot easier to just erase 
the old container, create a new one and restore your data into 
that.

FAQ Item 6.4 discusses how to do an encrypted data backup
with tar and GPG. 

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

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

[PePa]

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.

(I do have a backup of all the data, but not of the partition as one block.)

It seems like you're not recommending the use of cryptsetup-reencrypt in
general. I'm happy to give it a try once I have taken all the obvious steps
of doing it right.

> 
> The --reduce-device-size of cryptsetup-reencrypt can be used to 
> enlarge the header by what is needed, but will just cut off the 
> amount the data-area gets shifted from its endm, thereby likely 
> damaging the filesystem in there and destroying data, or, in the
> worst case, the while filesystem.
> 
> So in theory, you could use some tool to shrink the filesystem 
> in the openend container and then use this option to shift and 
> cut the data ares.
> 
> However, there are several high-risk operations in here that 
> you should under no circumstances run without a full, good 
> data backup. If you have that, it is a lot easier to just erase 
> the old container, create a new one and restore your data into 
> that.
> 
> FAQ Item 6.4 discusses how to do an encrypted data backup
> with tar and GPG. 
> 
> Arno

Thanks for pointing to the FAQ.

Peter

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

[Arno Wagner]

On Wed, Mar 12, 2014 at 22:29:09 CET, 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.

Hehe, LUKS has absolutely no way to tell how large the filesystem
in there is, so shrinking it does not help at all against the 
error message. Give it --reduce-device-size 1M. If your filesystem
is 4M smaller than the container _and_ starts at the beginning
of the data area, that should theoretically result in what you want.

Please report back on success or failure. Thanks! 

> (I do have a backup of all the data, but not of the partition as one block.)
> 
> It seems like you're not recommending the use of cryptsetup-reencrypt in
> general. I'm happy to give it a try once I have taken all the obvious steps
> of doing it right.

No. If your header is the same size (yours is not as you
enlarge the key), reencryption is simple and while you need that 
backup, reencryption can be less work than restoring said backup.

Arno

> > The --reduce-device-size of cryptsetup-reencrypt can be used to 
> > enlarge the header by what is needed, but will just cut off the 
> > amount the data-area gets shifted from its endm, thereby likely 
> > damaging the filesystem in there and destroying data, or, in the
> > worst case, the while filesystem.
> > 
> > So in theory, you could use some tool to shrink the filesystem 
> > in the openend container and then use this option to shift and 
> > cut the data ares.
> > 
> > However, there are several high-risk operations in here that 
> > you should under no circumstances run without a full, good 
> > data backup. If you have that, it is a lot easier to just erase 
> > the old container, create a new one and restore your data into 
> > that.
> > 
> > FAQ Item 6.4 discusses how to do an encrypted data backup
> > with tar and GPG. 
> > 
> > Arno
> 
> Thanks for pointing to the FAQ.
> 
> Peter
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

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

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

[Matthias Schniedermeyer]

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

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

[Arno Wagner]

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

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

[Milan Broz]

On 03/13/2014 02:31 AM, Arno Wagner wrote:
>> 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."

Yes, with --reduce-device-size it reencrypts "backwards" with optional
data shift.

If your fs supports shrinking and you want to be safe, just shrink fs
of twice size of needed LUKS extension (e.g. 8MB and then use 4MB
in reduce size option) and after reencryption just resize to full device.

Or with LVM just enlarge LV by 4MB (but this can fragment LV and
you need free space).

I described some crazy reencrypt operations here
http://asalor.blogspot.cz/2012/08/re-encryption-of-luks-device-cryptsetup.html

but as was already said: it is dangerous, backups are mandatory.

Milan

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

[PePa]

Milan Broz <gmazyland@...> writes:
> 
> Yes, with --reduce-device-size it reencrypts "backwards" with optional
> data shift.

> I described some crazy reencrypt operations here
> http://asalor.blogspot.cz/2012/08/re-encryption-of-luks-device-cryptsetup.html

Thanks for pointing to your post (which I had already read). Since the
extents at the end of the PV are unused, I'm going to assume all will be
well (out of device space is unused) and fix the PV after the
reduce-device-size with a pvresize.

I'll report back..!
Peter

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

[PePa]

Reporting back, I did:
cryptsetup-reencrypt -c aes-xts-plain64 -s 512 -h sha512
--reduce-device-size 4MiB /dev/sda4

It stopped here:
Progress: 99.4%, ETA 02:48, 710848 MiB written, speed 27.0 MiB/s
IO error during reencryption.

Curiously, I did:
cryptsetup luksOpen /dev/sda4 secret

Output>:
Device /dev/sda4 is not a valid LUKS device.

:-( Is there anything I can still try to salvage this situation??

Thanks,
Peter

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

[Arno Wagner]

I doubt it. Restore your backup. (And meditate on
the wisdom of those that have recomended it...).

The IO error is worrying though, it should _not_ happen.
Have a look into the system error log to see if this is 
some lower-level error. It may also be some problem 
with your LVM setup. (I cannot help there, in my opinion
LVM is too complicated and causes more trouble than it
has benefits.)

Arno

On Fri, Mar 14, 2014 at 08:59:28 CET, PePa wrote:
> Reporting back, I did:
> cryptsetup-reencrypt -c aes-xts-plain64 -s 512 -h sha512
> --reduce-device-size 4MiB /dev/sda4
> 
> It stopped here:
> Progress: 99.4%, ETA 02:48, 710848 MiB written, speed 27.0 MiB/s
> IO error during reencryption.
> 
> Curiously, I did:
> cryptsetup luksOpen /dev/sda4 secret
> 
> Output>:
> Device /dev/sda4 is not a valid LUKS device.
> 
> :-( Is there anything I can still try to salvage this situation??
> 
> Thanks,
> Peter
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

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

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

[PePa]

Arno Wagner <arno@...> writes:
> The IO error is worrying though, it should _not_ happen.
> Have a look into the system error log to see if this is 
> some lower-level error. It may also be some problem 
> with your LVM setup. (I cannot help there, in my opinion
> LVM is too complicated and causes more trouble than it
> has benefits.)
> 
> Arno

I have no idea what the IO error signifies, as the system is still
functioning normal (I left it on, in case).
But I am convinced this error cannot have anything to do with the LVM setup,
as it is happening on a lower layer. I have not had a bad experience with
LVM ever in the last 7 years since I started deploying it, and I don't know
what trouble you have had with it (or heard about), but I think for now I
will keep using it.

I am wondering though, if it would be a good idea to change the default luks
header size, even if only a smaller header is required according to the
parameters. If by default a header size is chosen that could accommodate a
reencrypt to a larger size, all the shifting doesn't need to happen, and it
will only cost you a few MiBs, which is a small price to pay when usually
you're dealing with at least GiB at this level.

Peter


> On Fri, Mar 14, 2014 at 08:59:28 CET, PePa wrote:
> > Reporting back, I did:
> > cryptsetup-reencrypt -c aes-xts-plain64 -s 512 -h sha512
> > --reduce-device-size 4MiB /dev/sda4
> > 
> > It stopped here:
> > Progress: 99.4%, ETA 02:48, 710848 MiB written, speed 27.0 MiB/s
> > IO error during reencryption.
> > 
> > Curiously, I did:
> > cryptsetup luksOpen /dev/sda4 secret
> > 
> > Output>:
> > Device /dev/sda4 is not a valid LUKS device.
> > 
> >  Is there anything I can still try to salvage this situation??
> > 
> > Thanks,
> > Peter
> > 
> > 
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@...
> > http://www.saout.de/mailman/listinfo/dm-crypt
> 

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

[PePa]

Arno Wagner <arno@...> writes:
> 
> The IO error is worrying though, it should _not_ happen.
> Have a look into the system error log to see if this is 
> some lower-level error.
> 
> Arno

By the way, the log/new/org files stayed the same sizes througout the almost
10 hours of running: 512/5242880/527848 bytes.

The .log file stayed the same from the beginning, no indication of any
error. The other files seem to start with the header, and then contain data
that I can't make sense of.

Any other pointers with regards to the log, is there another log kept
somewhere else??

Peter

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

[Milan Broz]

On 03/14/2014 05:46 PM, PePa wrote:
> Arno Wagner <arno@...> writes:
>>
>> The IO error is worrying though, it should _not_ happen.
>> Have a look into the system error log to see if this is 
>> some lower-level error.
>>
>> Arno
> 
> By the way, the log/new/org files stayed the same sizes througout the almost
> 10 hours of running: 512/5242880/527848 bytes.

Hi,

it is not updated until program is interrupted or you use --write-log.

Anyway, IO error is exactly the situation which cannot be handled correctly..

In theory, if you stop it with ctrl+c and then restart, it should try to continue
(log is updated in this case).

But first - what is in syslog? Is it really device error?

What version are you using? There were some fixes recently for 4k devices but
this really shout not happen in 99.4 % of device.

Please save files (log and two other) you cannot recover anything without them.
(If it really reencrypted 99% of device chances are that it can be manually fixed still.)

Please can you send me exact commands you run + device size of the device
(blockdev --getz <device>) and luksDump of your original image?
(either from temporary files or just send the whole temp. files with header)

It could be bug in reecryption so I would like to test it here.

Thanks,
Milan

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

[PePa]

PePa <peter@...> writes:
> I'll report back..!

So, I proceeded with:
cryptsetup-reencrypt -c aes-xts-plain64 -s 512 -h sha512
--reduce-device-size 4MiB /dev/sda4

The main problem was, at 99.4%, it stopped reencrypting due to I/O-errors... 

[The main way to catch this would be to do: badblocks -n /dev/sda4]

On Milan's advice I tried resuming:
cryptsetup-reencrypt --debug /dev/sda4
[Resuming is possible when the three .log .new .org files are still in the
running directory.]

It kept encountering I/O-errors. I used ddrescue to make a full copy, and
resumed on the copy, which finished fine, and all the file systems on the
LVM volumes were intact. I ended up copying this back to the original disk,
but I did a badblocks -n on it first, and it reported 5 errors.
This also opened fine with luksOpen, I fschecked the lvm volumes and they
were OK. I should probably do another badblocks -n to see if the write made
the drive firmware to deal with the badblocks.

Main take-aways:
- Check with "badblocks -n" before starting
- It would be great if after an I/O-error the bad block could be singled out
so that it can be read with ddrescue, and copied back.

Peter