linux-ext4 - Re: e2fsck fails on non journalled partition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 17 Mar 2019 23:51:28 +0100
From:   Ede Wolf <listac@...elschwaden.de>
To:     linux-ext4@...r.kernel.org
Subject: Re: e2fsck fails on non journalled partition

 > I'm still really wondering how this could have happened, though...

Not sure wether this is an explanation, but I suspect the SSD to be in a 
dying state. It's really old (5 years at least, probably even more) and 
has been used for tempfiles and caching for at least the last 3 years, 
so it has seen quite a bit of IO by now.

Further, currently after each mount tune2fs reports a "not clean" 
Filesystem state. I can fsck it all I want, mount it and after not too 
long time the state changes from clean.

Smartctl however logs no errors so far.

But, the journal inode and UUID are still at zero - or non existing - 
and it mounts cleanly even with a unclean state:

  EXT4-fs (sdd1): mounted filesystem without journal. Opts: noacl

In case it helps, one more tune2fs output, otherwise sorry for the noise:


tune2fs 1.44.5 (15-Dec-2018)
Filesystem volume name:   USERDATA
Last mounted on:          /mnt/userdata
Filesystem UUID:          241d6272-a004-44ef-9998-7fbc3ef98972
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      ext_attr resize_inode dir_index filetype 
extent 64bit large_dir sparse_super large_file
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         not clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              4669440
Block count:              9338880
Reserved block count:     0
Overhead blocks:          1536
Free blocks:              5576918
Free inodes:              4246457
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16384
Inode blocks per group:   1024
Filesystem created:       Wed Jan 30 18:42:35 2019
Last mount time:          Sun Mar 17 15:08:30 2019
Last write time:          Sun Mar 17 15:08:30 2019
Mount count:              2
Maximum mount count:      -1
Last checked:             Sun Mar 17 01:17:43 2019
Check interval:           0 (<none>)
Lifetime writes:          206 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:	          256
Required extra isize:     32
Desired extra isize:      32
Default directory hash:   half_md4
Directory Hash Seed:      2416ec00-bef9-437a-a3b1-f626303d72a2



However, I am quite thankful that the kernel has let me mount this drive 
until the issue was resolved.  And I am aware I can remove the noacl 
option from fstab.

Thanks again.


Ede


Am 17.03.19 um 22:53 schrieb Theodore Ts'o:
> I'm really curious how the superblock got into this configuration:
> 
>>>> ~ # tune2fs -l /dev/sde1
>>>> tune2fs 1.44.5 (15-Dec-2018)
>>>> Filesystem volume name:   USERDATA
>    ...
>>>> Filesystem features:      ext_attr resize_inode dir_index filetype extent 64bit large_dir sparse_super large_file
> 
> There is no journal features here at all
> 
>>>> Journal UUID:             00000000-1b00-0000-0000-000000000000
>>>> Journal inode:            131072
> 
> A journal UUID and inode should never be set at the same time.  But
> this is a lot more than a single bit flip.  The rest of the sueprblock
> looks sane, so it's not a matter of someone writing garbage over the
> on-disk copy.
> 
> Maybe a wild pointer smashing two bytes in the middle of the
> superblock?
> 
> In any case, this is something where we should probably add sanity
> checks so kernel will refuse to mount a file system like this --- and
> e2fsck should also try to see if the backup superblock is sane and try
> using it.  (We could also teach e2fsck to offer to clear these fields so
> a user won't have to use debugfs's ssv command if falling back to
> backup superblock doesn't work.)
> 

> 
>      	  	 	       	    	  - Ted
> 					
>