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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1713175 Title: Obsolete backup ext2/3/4 superblocks can confuse e2fsck on an encrypted LUKS partition To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1713175/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
