Re: cryptsetup versions: cryptsetup 2.3.4 vs. cryptsetup 2.1.0 - thought I had data corruption!?!

On Wed, Nov 25, 2020 at 7:34 PM Milan Broz <[email protected]> wrote:

> On 25/11/2020 19:01, Michael Kjörling wrote:
> > On 25 Nov 2020 18:30 +0100, from [email protected] (Martin Jørgensen):
> >> I tried to look in version history but am not into the details of the
> >> difference in crypt-setup versions. Can anyone please tell why I got/get
> >> this error using 2.1.0 and not with 2.3.4?
> --- snip ---


Just a small update: Things are much better now... After writing the last
reply, I had another kernel upgrade (on the debian/proxmox, where the data
is), am now running 5.4.73-1 and fsck is clean:

# e2fsck /dev/mapper/hugeData
e2fsck 1.44.5 (15-Dec-2018)
/dev/mapper/hugeData: clean, 1706487/196608000 files, 724924235/786427904
blocks

My issue sounds more and more like a kernel/mount/ext4-fs issue than
actually a LUKS/cryptsetup-issue, that is really great to hear... I checked
my dmesg, here on the debian/proxmox-system (for EXT4-fs, should've done
that along the way):

1414:[Tue Nov 24 00:29:03 2020] EXT4-fs (loop0): warning: mounting fs with
errors, running e2fsck is recommended
1415:[Tue Nov 24 00:29:03 2020] EXT4-fs (loop0): mounted filesystem with
ordered data mode. Opts: (null)
1449:[Tue Nov 24 00:34:06 2020] EXT4-fs (loop0): error count since last
fsck: 2
1450:[Tue Nov 24 00:34:06 2020] EXT4-fs (loop0): initial error at time
1601769126: ext4_journal_check_start:61
1451:[Tue Nov 24 00:34:06 2020] EXT4-fs (loop0): last error at time
1601769126: ext4_journal_check_start:61
1453:[Wed Nov 25 01:50:10 2020] EXT4-fs (loop0): error count since last
fsck: 2
1454:[Wed Nov 25 01:50:10 2020] EXT4-fs (loop0): initial error at time
1601769126: ext4_journal_check_start:61
1455:[Wed Nov 25 01:50:10 2020] EXT4-fs (loop0): last error at time
1601769126: ext4_journal_check_start:61
1456:[Wed Nov 25 19:44:14 2020] EXT4-fs (dm-13): recovery complete
1457:[Wed Nov 25 19:44:14 2020] EXT4-fs (dm-13): mounted filesystem with
ordered data mode. Opts: (null)
1465:[Wed Nov 25 19:48:13 2020] EXT4-fs (dm-13): mounted filesystem with
ordered data mode. Opts: (null)

I googled and the "recovery complete" line seems to be "journal recovery
after an unclean shutdown", I'm not sure what triggered this "recovery" (as
I remember it, I couldn't mount /dev/mapper/...) - but the LUKS-device was
mounted successfully on an Arch Linux VM via Samba/CIFS/SMB-network and via
a new cryptsetup-util.

This makes me think that I've got a new idea about what could've happened
(I hope not, I should definately know better - but with those EXT4-fs
entries, I begin to believe I could've had a weak moment and done something
stupid):
It could maybe be possible (cannot remember it) that I had a luksOpen'ed
the container, e.g. having /dev/mapper/whatever and maybe one of 2 things
happened:

1) Maybe /dev/mapper/whatever existed, but it wasn't mounted (to
/mnt/something), but the LUKS container also wasn't closed and maybe I had
started making the backup here...?
2) Maybe /dev/mapper/whatever existed and at the same time it was mounted
(to /mnt/something) - the worst scenario...

These 2 scenarios (the first most likely), might've been what happened -
otherwise I have absolutely no idea what can explain this (been using
cryptsetup for around 5 years, haven't had such a problem before)... I've
had a terrible experience, but have hopefully learned my lesson, for the
future.

If nothing else comes up, I think I'm gonna assume that I've had a weak
moment and maybe did umount, but perhaps I didn't luksClose'd before
starting the backup (scenario 1 above) and this I think could've corrupted
the ext4-fs, which for some reason I couldn't mount for some days and that
was (for a reason I don't understand) fixed when I mounted the FS on the
arch linux (newer kernel, maybe better ext4-fs auto-correction code)... In
any case: Thanks for the feedback and good work.

Br,
M

_______________________________________________
dm-crypt mailing list
[email protected]
https://www.saout.de/mailman/listinfo/dm-crypt