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  linux-cve-announce  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:   Fri, 2 Mar 2018 08:42:49 -0600
From:   Eric Sandeen <esandeen@...hat.com>
To:     Joakim Tjernlund <Joakim.Tjernlund@...inera.com>,
        "lczerner@...hat.com" <lczerner@...hat.com>
Cc:     "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: EXT4-fs (mmcblk0p1): couldn't mount as ext3 due to feature
 incompatibilities

On 3/2/18 8:30 AM, Joakim Tjernlund wrote:
> On Fri, 2018-03-02 at 13:56 +0100, Lukas Czerner wrote:

>>
>>
>> On Thu, Mar 01, 2018 at 12:48:58PM +0000, Joakim Tjernlund wrote:
>>> Could the above(for ext2 as well) be removed or changed to a non error msg ?
>>> It looks like a serious error msg as is now.
>>>
>>>  Jocke
>> You're trying to mount a file system with features that a kernel you're
>> currently using can't recognize or is incompatible with. So no, the
>> error can't be just removed, it's there to prevent any further damage.
> Not quite, I have a ext4 FS and fstab looks:
> LABEL=BOOT		/boot		auto		noatime		1 2
> 
> and then I always get this error as kernel tries ext3 first, reports a big fat error,
> then kernel tries ext4 and succeeds. I think this should be allowed without having
> an error msg printed.

Ah, that is much more useful context than the original short report.  ;)

ext3 is always going to print a message if mount fails for this reason; it
has no idea that ext4 will be tried next, all it knows is that it was told
to mount, and it can't.

This is how mount behaves when you specify 'auto':

              If  no  -t  option  is  given, or if the auto type is specified,
              mount will try to guess the desired type.  Mount uses the  blkid
              library  for guessing the filesystem type; if that does not turn
              up anything that looks familiar, mount will try to read the file
              /etc/filesystems, or, if that does not exist, /proc/filesystems.
              All of the filesystem types listed there will be  tried,  except
              for those that are labeled "nodev" (e.g., devpts, proc and nfs).

What does your blkid think /dev/mmcblk0p1 is?  If it thinks it's ext3, what
version is your blkid utility (or its owner package?)

If you specify it as ext4 rather than auto in fstab, you won't have the problem.

Another way to avoid this might be to put ext4 before ext3 in /etc/filesystems.

But I'd be curious to know if blkid thinks this is ext3, that may be a bug.

-Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ