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@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
>
> 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
To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
_______________________________________________ dm-crypt mailing list -- dm-crypt@xxxxxxxx To unsubscribe send an email to dm-crypt-leave@xxxxxxxx
