For starters, I'll select the easiest case, plain luksFormat without special params: cryptsetup luksFormat /dev/md125 # Allocating crypt device /dev/md125 context. # Trying to open and read device /dev/md125. # Initialising device-mapper backend, UDEV is enabled. # Detected dm-crypt target of version 1.7.0. # Timeout set to 0 miliseconds. # Password retry count set to 0. # Iteration time set to 1000 miliseconds. # Password verification disabled. Enter LUKS passphrase: Verify passphrase: # Formatting device /dev/md125 as type LUKS1. # Initializing crypto backend (using secure memory). # Topology: IO (524288/1048576), offset = 0; Required alignment is 1048576 bytes. # Generating LUKS header version 1 using hash sha1, aes, cbc-essiv:sha256, MK 32 bytes Segmentation fault For the fun of it, I will now set the iteration time to 10 000ms. (-i 10000) # Allocating crypt device /dev/md125 context. # Trying to open and read device /dev/md125. # Initialising device-mapper backend, UDEV is enabled. # Detected dm-crypt target of version 1.7.0. # Timeout set to 0 miliseconds. # Password retry count set to 0. # Iteration time set to 10000 miliseconds. # Password verification disabled. Enter LUKS passphrase: Verify passphrase: # Formatting device /dev/md125 as type LUKS1. # Initializing crypto backend (using secure memory). # Topology: IO (524288/1048576), offset = 0; Required alignment is 1048576 bytes. # Generating LUKS header version 1 using hash sha1, aes, cbc-essiv:sha256, MK 32 bytes Segmentation fault The segfault comes way before the 10 seconds are over, that much I can tell already. For the other info: I'm on gentoo, 10.0, hardened profile, on amd64 arch. Currently no core file is created, can you give me a fast shot on how I force the system to write out a core? The alignment (btw) is obviously detected correctly, that much I can tell you too. Regards -Sven P.S.: Sorry it took some time to provide the additional info, I was away watching the soccer game :-). On Wed, 2010-07-07 at 22:44 +0200, Milan Broz wrote: > On 07/07/2010 10:19 PM, Arno Wagner wrote: > > On Wed, Jul 07, 2010 at 07:49:04PM +0200, Sven Eschenberg wrote: > >> Hummm, > >> > >> should I consider this geek humor or are you serious, the CPU is rather > >> slow (imho)? > > > > Par humor, part serious. But if the CPU is rather slow, then > > this is somethin else, I guess. > > Don't worry, it was optimized such way that even on slow machines > it crashes quickly :-) > > >> Well at least we know the crash happens in sigvtalarm, which I assume is > >> a signal handler of some sort within cryptsetup. > > The timer is there intentionally to calculate PBKDF2 iterations per second, > after one second is loop stopped. There is safe limit (IIRC 1000 > iterations) - so even on slow CPU it returns safe value. > (iteration count is unsigned 64bit number, it should not overflow, > ale least not in this century :-) > > Anyway, I need debug log and info I requested to analyse it. > > Milan > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt