Hi Milan,
I tried getting the logs but not much help. I have included all the modules
related to dm_crypt and dm_verity. 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@gmail.com> 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
> >
> > 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@saout.de
> To unsubscribe send an email to dm-crypt-leave@saout.de
>