Control: tag -1 - moreinfo
Control: found -1 + 2:2.3.4-2
Hi,
I am sorry for the misleading guesses from my previous messages.
I finally got to running some more tests and it is not a 32bit or arm
problem.
Long-keyed volumes created by 2.0.2 cannot be opened by 2.2.2 and vice
versa.
I tested
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
Control: tag -1 + moreinfo
On Mon, 20 Jan 2020 at 21:25:56 +0100, Milan Broz wrote:
> but 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.
> (Debug log will provide all versions I need - kernel and dm targets
On 20/01/2020 14:11, Guilhem Moulin wrote:
> Milan, should I forward that upstream (verbatim)?
Sure, put it to the upstream, issue tracker , but 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.
(Debug log will
Control: tag -1 upstream
Hi,
On Sun, 19 Jan 2020 at 23:41:15 +, n...@waifu.club wrote:
> clarification: I am testing it with a volume I created and used with
> cryptsetup 2:2.0. With 2:2.1 and 2:2.2 integritysetup-open seems to succeed,
> but the embedded ext4 filesystem cannot be used.
Package: cryptsetup-bin
Version: 2:2.1.0-5+deb10u2
Severity: important
Dear Maintainers,
this is an unfortunate folowup to #935702. I thank Milan Broz very much
for fixing that one so quickly.
Unfortunately, even though the mapped size is now correct,
integritysetup still silently
6 matches
Mail list logo
