You are correct, not running atleast wipefs before using luksFormat on the block device was a mistake on my part, but I barely remember making it. I half expected fsck to come up with some errors, so I let it make changes. It is not a volume that is always connected at startup, hence the manual check. It was just the wrong block device. An isLuks check would have returned yes and prevented fsck from running. Maybe libblkid could detect luks partitions?
This happened on a 2 drive raid 1 array, which I have dd backups of, if some how the array can be recovered. Hard lesson learned though. Thank you for the explanation. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1713175 Title: Obsolete backup ext2/3/4 superblocks can confuse e2fsck on an encrypted LUKS partition Status in cryptsetup package in Ubuntu: Confirmed Status in e2fsprogs package in Ubuntu: New Status in util-linux package in Ubuntu: New Bug description: fsck.ext4 runs on a LUKS partition and starts to correct inode entries, rendering the partition corrupted and useless. It seems like it should defensively check where it is an isLuks partition using "cryptsetup isLuks /dev/sda1" before continuing to modify it. I hope such a defensive check can be added. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1713175/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
