ext4 reported as ext2

I have created Puppy on an SD card with a partition 4MB-aligned and ext4 f.s. without journal. For the record, it was created like this:

mke2fs -t ext4 -O ^has_journal -L puppy -m 0 -b 4096 -E stride=2,stripe-width=1024 ${SDDEVICE}2

I added that -E option after reading this link provided by mavrothal:

Puppy boots ok, but the problem is if I plug the SD card into my PC, the partition is identified as 'ext2'.

'disktype', 'guess_fstype' and 'blkid' all report it as ext2:

# disktype /dev/sdc2

--- /dev/sdc2
Block device, size 3.262 GiB (3502243840 bytes)
Ext2 file system
Volume name "puppy"
Last mounted at "/"
Volume size 3.262 GiB (3502243840 bytes, 855040 blocks of 4 KiB)

# guess_fstype /dev/sdc2

# blkid /dev/sdc2
/dev/sdc2: LABEL="puppy" UUID="f13cec24-bb3b-4bee-9c2c-bf4acd4e1bf0" TYPE="ext2"

It won't mount as ext2 though, gives this error:

EXT2-fs (sdc2): error: couldn't mount because of unsupported optional features (240)

However, it does mount as ext4, with the system log:

EXT4-fs (sdc2): mounted filesystem without journal. Opts: (null)

Anyone think of a solution for this?
Perhaps I should try to contact Jesse, the guy who wrote guess_fstype -- he is a super clever hardware programming guy. He moved on from Puppy involvement a long time ago.

Yes! I have already solved the problem. The full 'blkid' from the util-linux package (version 2.18) reports correctly:

# ./blkid /dev/sdc2
/dev/sdc2: LABEL="puppy" UUID="f13cec24-bb3b-4bee-9c2c-bf4acd4e1bf0" TYPE="ext4"

So, now I have to implement this correct detection into the 'probepart' utility.

Anyone want to volunteer to make a bug report to the the Busybox developers? The version of Busybox that I am using is 1.19.3.

A problem with 'disktype' is, last time I checked, the ext4 support is broken. I did report this, and informed that there is another ext4 patch available (created by the Pardus distribution, for disktype v9) that works, which is what we use. However, I don't think the official disktype has been corrected. So, if anyone feels like reporting the ext4-reported-as-ext2 bug, you would also have to remind them that their ext4 patch is broken and they should use the Pardus patch.

Posted on 5 Jul 2012, 17:36


Posted on 5 Jul 2012, 18:36 by BarryK
blkid in probepart
I think that it was technosaurus that recommended that the 'probepart' utility should use 'blkid' instead of 'guess_fstype', however blkid is very slow.

Just running 'blkid' without any parameters, it takes about 5 seconds on my laptop, which is too slow. The Busybox 'blkid' does not accept any parameters, however, now I have gone over to the full blkid utility (in util-linux), and it has a very interesting collection of command-line parameters.

This one is fast and is an excellent replacement for guess_fstype:

# blkid -p /dev/sdb1

...that will probe the partition, bypassing the blkid cache (which is what I want) and return the f.s. type, amongst other things.

Good, I will now rewrite 'probepart'!

Posted on 5 Jul 2012, 19:09 by BarryK
Busybox blkid
Oh, bother. The busybox blkid does accept some of the options, including '-p'. However, if you type "blkid --help" then it does not show any options supported.

I really hate it when the Busybox developers are so lazy, they don't correct the help to match the capabilities of the applet. This complaint applies to other applets as well.

I want to use "-o value", the Busybox applet does not support that.

Posted on 5 Jul 2012, 19:27 by BarryK
Still slow
Oh, I don't know, I think really need to try and fix 'guess_fstype'.

Running "blkid -p /dev/sda5" for example, which is my hard drive, takes about 3 seconds to return the information, whereas "guess_fstype /dev/sda5" does it virtually instantly.

Posted on 5 Jul 2012, 22:43 by BarryK
guess_fstype fixed
I have done it!
I examined the source of guess_fstype, and a bit of online study, and nailed it.
Basically, I added an extra test for the existence of extents:

#define EXT4_FEATURE_INCOMPAT_EXTENTS 0x0040 /* extents support */

So, if the f.s. is identified as ext2, if the above flag is set, then it must be ext4.

I have so far tested on one ext2, one ext4 (without journal), one ext4 (with journal) and a few ext3 filesystems and they all identified correctly.

Posted on 5 Jul 2012, 22:59 by maxerro
just out of curiosity
Was 'file -s' as confused as the trio?

Posted on 6 Jul 2012, 3:35 by mavrothal
stride, stripe etc
The blog setting are good for the specific card that had an 8MB allocation unit (1st "bump" in flashbench) and a page size of 8kb (2nd "bump" in flashbench).
However few cards actually have these characteristics.
In general you want "stride=page_size_in_KB/4" and "stripe=allocation_unit/page_size"
So for the (more common) configuration of a 4GB card with 4MB allocation units and 16KB pages
mke2fs -t ext4 -O ^has_journal -L puppy -m 0 -b 4096 -E stride=4,stripe-width=256 ${SDDEVICE}2
may be a better default (if a default must be set)

Posted on 6 Jul 2012, 5:21 by technosaurus
busybox blkid ext4
Fixed in busybox mid-May, but more importantly the commit may be useful to your guess_fstype patch.

Posted on 6 Jul 2012, 8:13 by BarryK
mavrothal, technosaurus,
Thanks for the info.

Posted on 6 Jul 2012, 8:32 by BarryK
file -s
Thank you for that, I didn't even know that 'file' can be used on a block device! -- well, I should know, I just overlooked it when considering candidates for detecting f.s.

Using 'file' version 5.03:

Flash drive, ext4 without journal:

# file -s /dev/sdc2
/dev/sdc2: Linux rev 1.0 ext2 filesystem data (extents) (large files) (huge files)

Flash drive, ext2:
# file -s /dev/sdd2
/dev/sdd2: Linux rev 1.0 ext2 filesystem data (large files)

Flash drive, ext3:
# file -s /dev/sdd1
/dev/sdd1: x86 boot sector, code offset 0x58

Hard drive, ext3:
# file -s /dev/sda9
/dev/sda9: Linux rev 1.0 ext3 filesystem data (errors) (large files)

SD card, ext4 with journal:
# file -s /dev/sdc2
/dev/sdc2: Linux rev 1.0 ext4 filesystem data (extents) (large files) (huge files)

The first one, sdc2, is ext4 without journal, reported as ext2 but with "(extents)" -- so you can infer this as ext4.

Notice, Flash drive with ext3 gets mis-reported. I tested another Flash pen drive, same thing.

Posted on 6 Jul 2012, 16:28 by maxerro
ext3 flash file -s
Ext3 flash drive reports fine here on Slacko's 'file' v5.04.
OK, this is a neverending story, or so it seems...