On 25/03/2021 00:51, Aditya Prakash wrote: > Hi Milan, > I tried getting the logs but not much help. I have included all the modules related to dm_crypt and dm_verity. It is not only about only dm-verity, you need perhaps some crypto modules. Do you have correct root hash and data offset there? Anyway, try verification in other system - not the cryptsetup userspace verify, but try to actually open the device in kernel and check it. (Cryptsetup verify doesn't to use kernel crypto at all.) If it works there, it should work with ther same parameters for boot too. Compare "dmsetup table --showkeys" parameters with the boot you are using (root hash, offsets, ...). m. Also, I see this error in dmesg: > > /device-mapper: verity: X:Y data block 0 is corrupted/ > /EXT4-fs (dm-0): bad geometry: block count 1048567 exceeds size of device (796069 blocks)/ > > Note that the verity target is loaded and is in a corrupt state. Since the data device is being used for storing a hash tree, the boot process is not able to identify the complete filesystem size. > > > Regards, > Aditya > > On Wed, Mar 24, 2021 at 2:48 AM Milan Broz <gmazyland@xxxxxxxxx <mailto:gmazyland@xxxxxxxxx>> wrote: > > > On 24/03/2021 09:57, Tom Eccles wrote: > > Hi Aditya, > > > > On 3/20/21 11:22 AM, Aditya Prakash wrote: > >> Hi, > >> I am using the same device (/dev/sda2) for data and hash with --hash-offset > >> set. The hash offset is set to 4096 added to the total space used in > >> /dev/sda. When I verify the verity target without activating, it succeeds > >> and gives valid (V) status. However, when I try to load it during boot, it > >> gives an error with corruption at 0 and 1 block and is stuck in the boot > >> loop. > >> > >> Is there something wrong I am doing with the hash-offset? Any help or > >> guidance would be really appreciated. > > > > This sounds similar to https://gitlab.com/cryptsetup/cryptsetup/-/issues/462 <https://gitlab.com/cryptsetup/cryptsetup/-/issues/462> > > > > That issue should be fixed with Linux 5.12. > > That bug is for forward error correction only (that's optional), I think this is not the case here. > > My guess is that kernel is missing some module (crypt hash or so) in the boot phase. > > Please check syslog, there should be some error messasage. > > Milan > _______________________________________________ > dm-crypt mailing list -- dm-crypt@xxxxxxxx <mailto:dm-crypt@xxxxxxxx> > To unsubscribe send an email to dm-crypt-leave@xxxxxxxx <mailto:dm-crypt-leave@xxxxxxxx> > _______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
