On Wed, Nov 25, 2020 at 7:34 PM Milan Broz <gmazyland@xxxxxxxxx> wrote:
On 25/11/2020 19:01, Michael Kjörling wrote:
> On 25 Nov 2020 18:30 +0100, from mjoerg@xxxxxxxxx (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 ---
# 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,
Br,
M
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
