So what happened is the following. There was a previous ext4 file
system on the disk. You ran "cryptsetup luksFormat /dev/sda1" which
wiped out the primary superblock.
You then manually ran fsck.ext4 on the device. It noticed the primary
superblock was non-existent, and then asked permission to modify the
file system. So it would have required multiple sysadmin errors in
order get to this point.
If you want a process which is fool-proof against sysadmin errors, you
could run the following before you run cryptosetup:
dd if=/dev/zero of=/dev/callcc/scratch seek=32766 count=10 bs=4k
If you do this, then e2fsck won't find the backup superblock, and it
will print:
e2fsck 1.43.5 (04-Aug-2017)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/callcc/scratch
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193
or
e2fsck -b 32768
/dev/callcc/scratch contains a crypto_LUKS file system
So we could try to do the "is there another file system or LUKS" check before
falling back to the secondary superblock. I'd call this a feature request.
It also should be the case that the wipefs program should have wiped
enough to get rid of the backup superblock (it's considered best
practice to run wipefs before running cryptsetup).
Furthermore, crypsetup should have run wipefs, or done its own wiping.
Mke2fs will wipe sectors at the beginning and the end of the superblock
(otherwise it's possible for the device to get misidentified as part of
a RAID array).
Fundamentally, trying to use in-band signalling is fraught with peril.
All tools need to do a better job of preventing this kind of mis-
identification, especially at file system or LUKS creation/format time.
** Also affects: util-linux (Ubuntu)
Importance: Undecided
Status: New
** Also affects: cryptsetup (Ubuntu)
Importance: Undecided
Status: New
--
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:
fsck should check before running 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
