[dm-crypt] [charlesc at pyropus.ca: Re: Does luksFormat write the full size of the device?]

Charles Cazabon charlesc at pyropus.ca
Mon Jun 27 21:16:19 CEST 2016


This message of yesterday doesn't seem to have gone through to the list,
trying again...

Milan Broz <gmazyland at gmail.com> wrote:
> On 06/26/2016 05:39 AM, Charles Cazabon wrote:
> 
> No, format doesn't write the whole device.

Ok, thanks.  That explains why I don't remember it taking this long before.

> Can you please post output of running commant with added --debug switch?

Sure:

---------------------------
# cryptsetup --debug luksFormat /dev/md0
# cryptsetup 1.4.3 processing "cryptsetup --debug luksFormat /dev/md0"
# Running command luksFormat.
# Locking memory.

WARNING!
========
This will overwrite data on /dev/md0 irrevocably.

Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/md0 context.
# Trying to open and read device /dev/md0.
# Initialising device-mapper backend, UDEV is enabled.
# Detected dm-crypt version 1.14.1, dm-ioctl version 4.34.0.
# Timeout set to 0 miliseconds.
# Iteration time set to 1000 miliseconds.
# Interactive passphrase entry requested.
Enter LUKS passphrase: 
Verify passphrase: 
# Formatting device /dev/md0 as type LUKS1.
# Crypto backend (gcrypt 1.5.0) initialized.
# Topology: IO (524288/3145728), offset = 0; Required alignment is 3145728
# bytes.
# Generating LUKS header version 1 using hash sha1, aes, cbc-essiv:sha256, MK
# 32 bytes
^C
---------------------------

I aborted it after a couple of minutes this time.

I've compiled 1.7.2 from the source tarball, and it does the same thing,
spinning on one CPU.  One difference is that it doesn't seem to respond to a
ctrl-C; it's still running after trying to abort it.  I haven't tried to kill
it with other signals yet.  Here's the output from it:

---------------------------
# ~xxxxxxx/software/cryptsetup-1.7.2/src/.libs/cryptsetup --debug luksFormat /dev/md0
# cryptsetup 1.7.2 processing
# "/home/xxxxxxx/software/cryptsetup-1.7.2/src/.libs/cryptsetup --debug luksFormat /dev/md0"
# Running command luksFormat.
# Locking memory.
# Installing SIGINT/SIGTERM handler.
# Unblocking interruption on signal.

WARNING!
========
This will overwrite data on /dev/md0 irrevocably.

Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/md0 context.
# Trying to open and read device /dev/md0.
# Initialising device-mapper backend, UDEV is enabled.
# Detected dm-crypt version 1.14.1, dm-ioctl version 4.34.0.
# Timeout set to 0 miliseconds.
# Iteration time set to 2000 miliseconds.
# Interactive passphrase entry requested.
Enter passphrase: 
Verify passphrase: 
# Formatting device /dev/md0 as type LUKS1.
# Crypto backend (gcrypt 1.5.0) initialized.
# Topology: IO (524288/3145728), offset = 0; Required alignment is 3145728
# bytes.
# Generating LUKS header version 1 using hash sha256, aes, xts-plain64, MK 32
# bytes
---------------------------


> > Is this long runtime normal for initialization of a device of this size?
> 
> No. If the default iteration time (1 or 2 seconds) is not changes, format
> should be done in max 4-5 seconds.

Ok, then something is definitely still wrong here.  I'm guessing the newish
kernel is related?

Thanks,

Charles

-- 
------------------------------------------------------------------
Charles Cazabon                              <charlesc at pyropus.ca>
Software, consulting, and services available at http://pyropus.ca/
------------------------------------------------------------------


More information about the dm-crypt mailing list