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
I have to disagree; the only tool that uses the backup superblock is
e2fsck, and if you accidentally run wipefs on the volume, you should be
able to recover it with e2fsck.
If you don't want to attempt to recover a filesystem there, then don't
run e2fsck.
** Changed in: util-linux (Ubuntu)
Ah, well, the whole thing is more of a stupid lesson learned.
--
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
FYI libblkid/blkid detects LUKS for years already.
--
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
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
** Summary changed:
- fsck should check before running on an encrypted LUKS partition
+ Obsolete backup ext2/3/4 superblocks can confuse e2fsck on an encrypted LUKS
partition
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
