cryptsetup-reencode: LUKS-${UUID}.new is too small
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??
Hi,
Quoted 7 lines · PePa
I'm a big fan of dm-crypt/luks.
I'm trying to reencode acrypto_LUKSpartition 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
Quoted 6 lines
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
Signature · 4 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
Quoted 13 lines · Arno Wagner
Quoted 11 lines · PePa
I'm a big fan of dm-crypt/luks.
I'm trying to reencode acrypto_LUKSpartition 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/sda4Output I'm getting:
Device LUKS-71a94fa6-9c84-45d7-80e8-ee61be3887e0.new is too small. Creation of LUKS backup headers failed.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 17 lines
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.
Quoted 4 lines
FAQ Item 6.4 discusses how to do an encrypted data backup with tar and GPG.
Arno
Thanks for pointing to the FAQ.
Peter
Quoted 22 lines · PePa
Quoted 13 lines · Arno Wagner
Quoted 11 lines · PePa
I'm a big fan of dm-crypt/luks.
I'm trying to reencode acrypto_LUKSpartition 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/sda4Output I'm getting:
Device LUKS-71a94fa6-9c84-45d7-80e8-ee61be3887e0.new is too small. Creation of LUKS backup headers failed.Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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!
Quoted 5 lines
(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
Quoted 29 lines
Quoted 16 lines
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.
Quoted 4 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 4 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
Quoted 22 lines · PePa
Quoted 13 lines · Arno Wagner
Quoted 11 lines · PePa
I'm a big fan of dm-crypt/luks.
I'm trying to reencode acrypto_LUKSpartition 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/sda4Output I'm getting:
Device LUKS-71a94fa6-9c84-45d7-80e8-ee61be3887e0.new is too small. Creation of LUKS backup headers failed.Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Signature · 1 line
Matthias
Quoted 28 lines · Matthias Schniedermeyer
Quoted 22 lines · PePa
Quoted 13 lines · Arno Wagner
Quoted 11 lines · PePa
I'm a big fan of dm-crypt/luks.
I'm trying to reencode acrypto_LUKSpartition 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/sda4Output I'm getting:
Device LUKS-71a94fa6-9c84-45d7-80e8-ee61be3887e0.new is too small. Creation of LUKS backup headers failed.Quoted 7 lines
Quoted 2 lines
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.
Quoted 4 lines
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.
Quoted 4 lines
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.
Quoted 6 lines
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.
Quoted 8 lines
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
Signature · 4 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
Quoted 9 lines · Arno Wagner
Quoted 2 lines
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
Quoted 6 lines · Milan Broz
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
Quoted 1 line · PePa
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
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
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
Quoted 24 lines · PePa
Reporting back, I did:
cryptsetup-reencrypt -c aes-xts-plain64 -s 512 -h sha512 --reduce-device-size 4MiB/dev/sda4It 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/sda4secretOutput>:
Device/dev/sda4is not a valid LUKS device.:-( Is there anything I can still try to salvage this situation??
Thanks,
Peter_______________________________________________
dm-crypt mailing list
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Signature · 4 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
Quoted 8 lines · Arno Wagner
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
Quoted 26 lines · PePa
Quoted 24 lines
Reporting back, I did:
cryptsetup-reencrypt -c aes-xts-plain64 -s 512 -h sha512 --reduce-device-size 4MiB/dev/sda4It 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/sda4secretOutput>:
Device/dev/sda4is 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
Quoted 6 lines · Arno Wagner
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
Quoted 10 lines · PePa
Quoted 6 lines · Arno Wagner
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