The update to sys-fs/mdadm-3.1.3 broke cryptsetup on my system. Whenever invoking "crystsetup create" it fails with the message "device-mapper: reload ioctl failed: invalid argument". For instance, creating encrypted swap partitions during bootup fails: * crypsetup will be called with : -s 256 -d /dev/urandom -c twofish-cbc-essiv:sha256 -h sha256 create crypt-swap-1 /dev/sdb2 device-mapper: reload ioctl failoed: invalid argument * failure running cryptsetup Manually calling "cryptsetup ... create ..." doesn't work either. I've also tried the default arguments from /etc/conf.d/dmcrypt (-c aes -h sha1 -d /dev/urandom) which fail in the same way. A downgrade to sys-fs/mdadm-3.1.1-r1 fixed the problem (version 3.1.2 is broken due to bug #322711). Reproducible: Always Steps to Reproduce: see above
Created attachment 241941 [details] paludis --info cryptsetup
Created attachment 241943 [details] paludis --info mdadm
I found the time to do further testing. Here's the output of a manual call of 'cryptsetup create': Garten ~ # cryptsetup create crypt-swap-1 /dev/sdb2 -v --debug -s 256 -d /dev/urandom -c twofish-cbc-essiv:sha256 -h sha256 # cryptsetup 1.1.2 processing "cryptsetup create crypt-swap-1 /dev/sdb2 -v --debug -s 256 -d /dev/urandom -c twofish-cbc-essiv:sha256 -h sha256" # Locking memory. # Allocating crypt device /dev/sdb2 context. # Trying to open and read device /dev/sdb2. # 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 3. # Iteration time set to 1000 miliseconds. # Password verification disabled. # dm status crypt-swap-1 OF [16384] # Calculated device size is 15647310 sectors (RW), offset 0. # DM-UUID is CRYPT-PLAIN-crypt-swap-1 # Udev cookie 0xd4d17b0 (semid 458753) created # Udev cookie 0xd4d17b0 (semid 458753) incremented # Udev cookie 0xd4d17b0 (semid 458753) incremented # Udev cookie 0xd4d17b0 (semid 458753) assigned to dm_task type 0 with flags 0x0 # dm create crypt-swap-1 CRYPT-PLAIN-crypt-swap-1 OF [16384] # crypt-swap-1: Stacking NODE_ADD (253,1) 0:0 0600 # dm reload crypt-swap-1 OF [16384] device-mapper: reload ioctl failed: Invalid argument # Udev cookie 0xd4d17b0 (semid 458753) decremented # Udev cookie 0xd4d17b0 (semid 458753) incremented # Udev cookie 0xd4d17b0 (semid 458753) assigned to dm_task type 2 with flags 0x0 # dm remove crypt-swap-1 OF [16384] # crypt-swap-1: Stacking NODE_DEL (replaces other stacked ops) # Udev cookie 0xd4d17b0 (semid 458753) decremented # Udev cookie 0xd4d17b0 (semid 458753): Waiting for zero # Udev cookie 0xd4d17b0 (semid 458753) destroyed # Releasing crypt device /dev/sdb2 context. # Releasing device-mapper backend. # Unlocking memory. Command failed with code 22: Invalid argument BTW: I'm sure my kernel supports all requested ciphers, because my home partition is encrypted with the same ciphers and unlocking that partition works well. Only creating partitions fails. I've also tested several combinations of mdadm- and cryptsetup-versions: Downgrading cryptsetup doesn't help (and cryptsetup-1.0.6-r2 doesn't compile, so I can only test 1.1.* versions), but it looks like it works every version of mdadm *except* when mdadm-3.1.3 is involved.
Same problem with mdadm-3.1.4. Please let me know, what information you need!
i dont see how mdadm can affect cryptsetup at all. it installs no libs, so it isnt like cryptsetup could be linking against it. how exactly are you testing ? you run `emerge =mdadm-xxx`, run `cryptsetup` and then emerge a different version of mdadm and try `cryptsetup` again ? what if you `emerge -C mdadm` ?
(In reply to comment #5) > i dont see how mdadm can affect cryptsetup at all. it installs no libs, so it > isnt like cryptsetup could be linking against it. I wish I knew... > how exactly are you testing ? you run `emerge =mdadm-xxx`, run `cryptsetup` > and then emerge a different version of mdadm and try `cryptsetup` again ? Yes, just like that (except that I replace emerge by paludis). Update mdadm ~> 'cryptsetup create' fails. Reinstalling luks doesn't help. > what if you `emerge -C mdadm` ? I cannot safely remove mdadm when / and /home are raid partitions, can I?
mdadm merely tells the kernel what to do. after that, mdadm isnt running, so having it installed is irrelevant.
(In reply to comment #7) > mdadm merely tells the kernel what to do. after that, mdadm isnt running, so > having it installed is irrelevant. I did some more testing: 1) initial configuration: mdadm-3.1.1-r1 installed "cryptsetup create" works 2) uninstalled mdadm completely "crypsetup create" still works 3) installed mdadm-3.1.4 "cryptsetup create" still works 3) reboot "cryptsetup create" doesn't work anymore, it fails just like before with "device-mapper: reload ioctl failed: invalid argument" 4) downgrade back to mdadm-3.1.1-r1 "cryptsetup create" still doesn't work 5) reboot "cryptsetup create" works again
has mdadm claimed the device ? look at /proc/mdstat
(In reply to comment #9) > has mdadm claimed the device ? look at /proc/mdstat Oh s**t it did! The old version didn't... Adding an "AUTO -all" line to /etc/mdadm.conf solved the problem. Thanks a lot and sorry for the trouble.
np ... this little sh*t did the same thing on one of my systems and it took me a little while to track down why. i think it's because the disk (which is now formatted as NTFS) used to be part of a RAID and mdadm is able to find the old signature. i certainly didnt do "due diligence" after pulling it from the raid in nuking its previous contents. probably because the drive is still in my possession and i dont worry about data leakage until i give it to someone else. you might want to try using `mdadm --zero-superblock` on it.
