View previous topic :: View next topic |
Author |
Message |
sphakka Tux's lil' helper
![Tux's lil' helper Tux's lil' helper](/images/ranks/rank_rect_1.gif)
![](images/avatars/gallery/Futurama/cartoon_futurama_bender.gif)
Joined: 24 Jun 2003 Posts: 79
|
Posted: Mon Oct 05, 2020 9:53 am Post subject: cryptesetup convert LUKS1 => LUKS2: not enough space!? |
|
|
Ugh, it looks like my old LUKS1 device can't be upgraded to LUKS2, or I'm missing something -- using `sys-fs/cryptsetup-2.3.2` on kernel `5.4.66-gentoo`.
Code: | sphakka# cryptsetup --debug convert /dev/sdc --type=luks2
# cryptsetup 2.3.2 processing "cryptsetup --debug convert /dev/sdc --type=luks2"
# Running command convert.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.
# Allocating context for crypt device /dev/sdc.
# Trying to open and read device /dev/sdc with direct-io.
# Initialising device-mapper backend library.
# Trying to load any crypt type from device /dev/sdc.
# Crypto backend (OpenSSL 1.1.1g 21 Apr 2020) initialized in cryptsetup library version 2.3.2.
# Detected kernel Linux 5.4.66-gentoo x86_64.
# PBKDF pbkdf2-sha256, time_ms 2000 (iterations 0).
# Reading LUKS header of size 1024 from device /dev/sdc
# Key length 32, device size 1953525168 sectors, header size 2050 sectors.
WARNING!
========
This operation will convert /dev/sdc to LUKS2 format.
Are you sure? (Type 'yes' in capital letters): YES
# Converting LUKS device to type LUKS2
# Reusing open ro fd on device /dev/sdc
# Max size: 1052672, LUKS1 (full) header size 1052672 , required shift: 28672
Unable to move keyslot area. Not enough space.
# Releasing crypt device /dev/sdc context.
# Releasing device-mapper backend.
# Closing read only fd for /dev/sdc.
# Unlocking memory.
Command failed with code -1 (wrong or missing parameters). |
(I guess the last message about wrong/missing parameter is just bogus).
Indeed, "Max size: 1052672, LUKS1 (full) header size 1052672 , required shift: 28672" compared to
code:
Code: | required_size = luks1_size + luks1_shift;
if ((max_size < required_size) &&
device_fallocate(crypt_metadata_device(cd), required_size)) {
log_err(cd, _("Unable to move keyslot area. Not enough space."));
return -EINVAL;
} |
tells me that `max_size < required_size`, KO 1/2 . But what about `device_fallocate(crypt_metadata_device(cd), required_size))`: is it failing to allocate space on the device (there's plenty, actually)? |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
mikb Tux's lil' helper
![Tux's lil' helper Tux's lil' helper](/images/ranks/rank_rect_1.gif)
![](images/avatars/27127342365c9696689d2b.gif)
Joined: 14 Dec 2005 Posts: 124 Location: Sydney Australia
|
Posted: Thu Oct 08, 2020 8:21 pm Post subject: |
|
|
The question is, though, is there space where cryptsetup needs to write data. All the header data basically needs to go in the "empty" space at the start of the partition, and the header for LUKS2 is bigger and more complex than LUKS1. I can see that the reserved space on my LUKS2 partition is much bigger than on my unencrypted boot partition, for example.
Try:
Code: |
od -t xCz -N 4096 -v -w64 /dev/sdc
|
To see what I mean. _________________ With sufficient thrust, pigs fly just fine (RFC 1925, apparently talking about Gentoo) |
|
Back to top |
|
![](templates/gentoo/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|