Hi Milan, >Any message in syslog? Failed mount should print something there... >Can you paste output of "dmsetup status" (just ot check that dm-verity reports proper status) ? >Does it work for other block devices? (You can try loopback to file etc.) Unfortunately, I am not able to login to the console to run some commands. It fails with error, 'login: can't set groups: Operation not permitted'. But once I get past this problem, I will follow the steps suggested by you above. >It should work, but to better diagnose it we need some data. You are already running --debug there, so could you paste output? (It should provide me version of kernel, utility, device-mapper targets, architecture etc.) I am pasting the output of the debug from the veritysetup create and the cryptsetup open commands below. Regards, Vidyesh # cryptsetup 1.6.7 processing "veritysetup create vroot /dev/mmcblk0p13 /dev/mmcblk0p14 aa70f8669af0ea1bea2e3e672a2715a7f1d97ee1077f5885f1af8871af724f36 --debug" # Running command create. # Allocating crypt device /dev/mmcblk0p14 context. # Trying to open and read device /dev/mmcblk0p14 w[ 1.013479] device-mapper: verity: 179:13: metadata block 1 is corrupted ith direct-io. # Initialising device-mapper backend library. # Trying to load VERITY crypt type from device /dev/mmcblk0p14. # Crypto backend (OpenSSL 1.0.2j 26 Sep 2016) initialized. # Detected kernel Linux 4.1.15 armv7l. # Reading VERITY header of size 512 on device /dev/mmcblk0p14, offset 0. # Setting ciphertext data device to /dev/mmcblk0p13. # Trying to open and read device /dev/mmcblk0p13 with direct-io. # Activating volume vroot by volume key. # dm version OF [16384] (*1) # dm versions OF [16384] (*1) # Detected dm-verity version 1.2.0. # Detected dm-crypt version 1.14.1, dm-ioctl version 4.31.0. # Udev is not running. Not using udev synchronisation code. # Device-mapper backend running with UDEV support disabled. # dm status vroot OF [16384] (*1) # Trying to activate VERITY device vroot using hash sha256. # Calculated device size is 1126392 sectors (RW), offset 0. # DM-UUID is CRYPT-VERITY-c073dc9490d2423bb0de2aec798b24f9-vroot # dm create vroot CRYPT-VERITY-c073dc9490d2423bb0de2aec798b24f9-vroot OF [16384] (*1) # dm reload vroot OFRW [16384] (*1) # dm resume vroot OFRW [16384] (*1) # vroot: Stacking NODE_ADD (254,0) 0:0 0600 # vroot: Stacking NODE_READ_AHEAD 256 (flags=1) # vroot: Processing NODE_ADD (254,0) 0:0 0600 # Created /dev/mapper/vroot # vroot: Processing NODE_READ_AHEAD 256 (flags=1) # vroot (254:0): read ahead is 256 # vroot: retaining kernel read ahead of 256 (requested 256) # dm status vroot OF [16384] (*1) # Verity volume vroot status is V. # Releasing crypt device /dev/mmcblk0p14 context. # Releasing device-mapper backend. Command successful. veritysetup create vroot is SUCCESS with return value 0 Calling cryptsetup open # cryptsetup 1.6.7 processing "cryptsetup --type=plain open /dev/mapper/vroot plainMap --debug" # Running command open. # Locking memory. # Installing SIGINT/SIGTERM handler. # Unblocking interruption on signal. # Allocating crypt device /dev/mapper/vroot context. # Trying to open and read device /dev/mapper/vroot with direct-io. # Trying to open device /dev/mapper/vroot without direct-io. # Initialising device-mapper backend library. # Timeout set to 0 miliseconds. # Password retry count set to 3. # Formatting device /dev/mapper/vroot as type PLAIN. # Crypto backend (OpenSSL 1.0.2j 26 Sep 2016) initialized. # Detected kernel Linux 4.1.15 armv7l. # STDIN descriptor passphrase entry requested. # Activating volume plainMap [keyslot -1] using passphrase. # dm version OF [16384] (*1) # dm versions OF [16384] (*1) # Detected dm-verity version 1.2.0. # Detected dm-crypt version 1.14.1, dm-ioctl version 4.31.0. # Udev is not running. Not using udev synchronisation code. # Device-mapper backend running with UDEV support disabled. # dm status plainMap OF [16384] (*1) # Plain: hashing passphrase using ripemd160. # Calculated device size is 1126392 sectors (RO), offset 0. # Trying to activate PLAIN device plainMap using cipher aes-cbc-essiv:sha256. # DM-UUID is CRYPT-PLAIN-plainMap # dm create plainMap CRYPT-PLAIN-plainMap OF [16384] (*1) # dm reload plainMap OFRW [16384] (*1) # dm resume plainMap OFRW [16384] (*1) # plainMap: Stacking NODE_ADD (254,1) 0:0 0600 # plainMap: Stacking NODE_READ_AHEAD 256 (flags=1) # plainMap: Processing NODE_ADD (254,1) 0:0 0600 # Created /dev/mapper/plainMap # plainMap: Processing NODE_READ_AHEAD 256 (flags=1) # plainMap (254:1): read ahead is 256 # plainMap: retaining kernel read ahead of 256 (requested 256) # Releasing crypt device /dev/mapper/vroot context. # Releasing device-mapper backend. # Unlocking memory. Command successful. cryptsetup open is SUCCESS with return value 0 Mounting dm-crypt + dm-verity block device in newroot mount: mounting /dev/mapper/plainMap on /newroot/ failed: Invalid argument Mount failed with a return value 255 -----Original Message----- From: Milan Broz <gmazyland@xxxxxxxxx> Sent: Wednesday, June 13, 2018 6:11 PM To: Nabar, Vidyesh <Vidyesh.Nabar@xxxxxxxxxx>; dm-crypt@xxxxxxxx Subject: [EXTERNAL] Re: DM-Verity + DM-Crypt error On 06/13/2018 05:52 PM, Nabar, Vidyesh wrote: > I am trying to use a combination of DM-Verity and DM-Crypt (plain Mode) in Linux. > > This is an embedded system on the IMX6. > > When my system boots up, in the init script, the DM-Verity check is carried out first , and if successful the DM-Crypt check is carried out. > > So the script looks somewhat like what I have pasted below my mail. I have removed the error handling below to make is readable. > > The calls "veritysetup create .." and "cryptsetup open" succeed. So the DM-Verity and DM-Crypt devices are created. > > However, the mounting of DM-Crypt device (/dev/mapper/plainMap) on the path /newroot fails with the following error. > > /mount: mounting /dev/mapper/plainMap on /newroot/ failed: Invalid > argument/ > > But I don't see what argument is invalid in : /mount -t ext4 -o ro > /dev/mapper/plainMap /newroot// Any message in syslog? Failed mount should print something there... Can you paste output of "dmsetup status" (just ot check that dm-verity reports proper status) ? Also try to add --readonly parameter to your cryptsetup command. > Does anybody have any pointers on why this error might be coming. > > I have seen this error before while working with just DM-Verity but it went away on its own and I could not figure out why it came or why it went away. > > Presently DM-Verity works independently and so does DM-Crypt on this very setup. But the combination has this problem. > > However, even this combination has worked at some point before on a different setup. > > But I would like to figure out the root cause of this error if I can. It should work, but to better diagnose it we need some data. You are already running --debug there, so could you paste output? (It should provide me version of kernel, utility, device-mapper targets, architecture etc.) Does it work for other block devices? (You can try loopback to file etc.) Thanks, Milan p.s. Please try to avoid sending html mails to this list, just use plain messages. _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
