Hi,
I am not sure why you cc so many people, most of lists are not relevant here.
Anyway, could you please test one thing below so the problem is better isolated?
On 10/23/25 1:29 PM, Askar Safin wrote:
...
Also I tried to add "--integrity-no-journal" to "format" and "open".
It didn't work, either. (I don't remember what exactly didn't work.
I can do this experiment again, if needed.)
Are you sure you used --integrity-no-journal both in activation before
hibernation and also in resume? If not, please try it.
This flag activates direct mode and and completely avoids dm-integrity journal.
You can verify it with "integritysetup status <device>" - it should say "journal:
not active".
And if it does not work, could you try to use -integrity-recovery-mode the same
way (both before hibernation and later in resume)? This will effectively ignore
checksums
providing no protection, but keeping dm-integrity device still in place.
You can verify it with "integritysetup status <device>" - it should say "mode:
read/write recovery".
Is the problem still in place with this setting?
You can also try to decrease journal commit time with --journal-commit-time
option,
but this is not a real solution.
...>
Then I tried to do "cryptsetup" instead of "integritysetup". I created
swap partition so:
cryptsetup luksFormat --type luks2
/dev/disk/by-partuuid/c4bbc73d-7909-42ea-8d96-eab82512cbe7 /tmp/key
cryptsetup open --type luks2 --key-file /tmp/key
/dev/disk/by-partuuid/c4bbc73d-7909-42ea-8d96-eab82512cbe7 swap
mkswap /dev/mapper/swap
swapon /dev/mapper/swap
And, of course, I did all necessary edits to initramfs.
And this time everything worked. This proves that I didn't do any mistakes in
my setup
(i. e. I got initramfs right, etc), and this is actual bug in dm-integrity.
Unfortunately, LUKS created such way doesn't have any redundancy. So this is
not solution for me.
Redundancy? You mean data integrity protection? There is no redundancy, only
additional authentication tag
(detecting integrity error but not correcting it).
Thanks,
Milan
