My intention was to attempt to recover a filesystem. It just happened to be the wrong block device on which there was a functioning LUKS partition.
Being defensive to prevent such a circumstance would call for two things: cryptsetup forcing a user to write zeros so such a situation isn't created in the future, and e2fsck checking for a LUKS partition and re-verifying the user really wants to continue despite there being a LUKS header and backup superblocks on the partition. If such checks can be added without additional dependencies, I think they just might prevent future similar mishaps. Maybe this mistake doesn't commonly happen, but this configuration of layering ext4 on LUKS is the default for most linux distributions, even for USB and external drives. In fact, e2fsck could've figured out through lsblk what I was really trying to do and corrected me. I had a relatively simple configuration. It wouldn't have been that hard to figure out what I was doing was wrong. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to util-linux 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: Invalid 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 : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
