Hi,
I won't be able to help debugging this as I don't have a >2TiB disk
around. (Could fake the size and format with --no-wipe, but ...
I recall integrity checks failing on all sectors. It should be enough
to format only a part of the device with 32-bit 2:2.0.
e.g.
prepare# head -c 4096 /dev/urandom >/IDISK.ikey
2:2.0.x# integritysetup --sector-size 4096 --tag-size 32 --integrity
hmac-sha256 --integrity-key-size=4096 --integrity-key-file=/IDISK.ikey
format /dev/sda
2:2.0.x# ^C after a gigabyte
2:2.2.2# integritysetup --integrity hmac-sha256
--integrity-key-size=4096 --integrity-key-file=/IDISK.ikey open /dev/sda
IDISK
I definitely need a clear reproducer (with the latest stable
- 2.2.2 or 2.3.0-rc0) - ideally with attached debug and system log.
I don't have that system at hand, but I am sure it was running on latest
stock linux-image-armmp from testing.
I upgraded/downgraded between 2:2.2.2-1 and some old 2:2.0.x multiple
times to try rule out the kernel version.
The result was always the same. When I use 2:2.2.2-1, the disk seems to
return only checksum errors. When I use 2:2.0.x, it works as expected.
How do I add testing's 2:2.2.2-1 to affected versions?
Something like "Control: found -1 2:2.2.2-1"?
Any idea how is dm-integrity supposed to interact with truncation?
Does device size or device blocksize affect checksum layout?
If the underlying device is truncated, should checksums of remaining
sectors stay valid?
If the mapped length gets truncated like in #935702, should checksums of
available sectors stay valid?
Best,
n.b.f.
