Comment 1 for bug 1713175
Revision history for this message
| Theodore Ts'o (tytso) wrote Re: fsck should check before running on an encrypted LUKS partition | #1 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
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/
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 <device>
or
e2fsck -b 32768 <device>
/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.