linux-ext4 - Re: EXT4-fs (mmcblk0p1): couldn't mount as ext3 due to feature incompatibilities

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]

Message-ID: <3751e8a5-4f4e-1ed2-f4c1-7e6b4744258a@redhat.com>
Date:   Fri, 2 Mar 2018 09:34:19 -0600
From:   Eric Sandeen <sandeen@...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 9:20 AM, Joakim Tjernlund wrote:
> On Fri, 2018-03-02 at 08:42 -0600, Eric Sandeen wrote:

...

>> 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.
> 
> But I don't hav ext3, only ext4 in kernel:
> # CONFIG_EXT2_FS is not set
> # CONFIG_EXT3_FS is not set
> CONFIG_EXT4_FS=y
> 
> ext4 know's ext3 and complains as is today. In this config one should not have to see
> this error.

ext4.ko was told to mount your disk /as an ext3 filesystem/, and ext4.ko issued an
error saying that was not possible.  It is doing the right thing.

>>
>> 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.
> 
> yes, but I don't want to do that and I should not have to.

*shrug* up to you I guess.
>>
>> 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.
> 
> Nope, it is ext4:
> blkid /dev/mmcblk0p1
> /dev/mmcblk0p1: LABEL="BOOT" UUID="f0a6a649-ce97-4d82-b190-eb1fc3e348a2" TYPE="ext4" PARTLABEL="M-dM-0M-^@...M
> -$M-^@...M-8M-^@...M-^TM-^@...M- M-^@...M-^@M-^@...M-^HM-^@...M-<M-^@...M-<M-^@...M-^PM-^@"
> PARTUUID="d65a22c5-be4c-410b-ab6e-89d732edd569

Then I'm not sure what to tell you, perhaps blkid isn't used by mount in your
boot environment?  In any case - there really is no ext[234] bug here.  Something
explicitly told ext4.ko to mount /dev/mmcblk0p1 /as ext3/, and ext4.ko issued
a message saying that is not possible.  It is the correct response from the
driver.

-Eric