Re: Does luksFormat write the full size of the device?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Milan Broz <gmazyland@xxxxxxxxx> 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@xxxxxxxxxx>
Software, consulting, and services available at http://pyropus.ca/
------------------------------------------------------------------
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt



[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux