On Tue, Jan 26, 2021 at 12:10:20AM +0100, Christoph Biedl wrote:
> Package: e2fsprogs
> Version: 1.44.5-1+deb10u3
> Severity: normal
>
> Dear Maintainer,
>
> at first, I am sorry to tell I cannot provide the raw data. I was quite
> in a hurry and overwrote it before realizing its high value for
> debugging.
>
> Story: An ext2 file system, actually a boot partition, suffered severe
> damage for whatever reason, possibly controller issues. After massive
> repair done by e2fsck (on amd64, from Debian testing), the file system
> was clean and usable again (also, no damage to the important files but a
> lot of garbage in lost+found), *but* the kernel no longer recognizes it
> as ext2:
>
> EXT4-fs (sdf3): mounted filesystem without journal. Opts: (null)
>
> Expected:
>
> EXT4-fs (sdf3): mounting ext2 file system using the ext4 subsystem
That's just a matter of how it was mounted. If you mount with -t
ext2, you'll get:
# mke2fs -t ext2 /tmp/foo.img 2M
# mount -t ext2 /tmp/foo.img /mnt
[39916.330690] EXT4-fs (loop0): mounting ext2 file system using the ext4
subsystem
If you mount the same file system with ext4, you'll get:
# mount -t ext4 /tmp/foo.img /mnt
[39880.180962] EXT4-fs (loop0): mounted filesystem without journal. Opts:
(null). Quota mode: none.
> Therefore I assume e2fsck, while repairing the damage, by accident
> enabled some feature bits that made the kernel think it is dealing with
> an ext4....
>
> As I said, the raw image is destroyed. However I kept the output of
> "tune2fs -l" (again, from testing), possibly this provides enough hint
> to investigate?
You didn't actually include the output of tune2fs -l in your bug
report. Given that you named them "broken" and "okay" I assume you
meant to attach them, but forgot to do so?
That being said, I'm pretty sure e2fsck enabled file system features;
in general, it doesn't do that, and certainly not with any of the
features added since the ext4 era.
My best guess is that I/O errors resulted in garbage getting written
to the inode table, and e2fsck wasn't clearly the fscrypt inode flag
when the fscrypt feature flag was not set; that would explain the
fscrypt kernel error message that you saw.
Cheers,
- Ted
