Ext4 drive doesn't mount

[miguelroboso]

Hello all,

I encountered the "unsupported features" error while trying to mount an EXT4 partitioned USB 3.0 drive on my RT- AC68P with Merlin V384.4_2 installed.

The drive was formatted in Raspbian as ext4 with the mkfs.ext4 command, with a GPT partition table. Sector size is 4096.

Fdisk -l shows the drive, but I cannot mount it in any of the ways I tried, mostly mount -t ext4 /dev/sdb1 ./whateverfolderIjustcreated

dmsg shows that some sort of tnfs fail-safe is active, and that the drive cannot be mounted.

Since I have about 100G of stuff on that drive, I'd prefer not to use the solutions I found here and elsewhere, as they are mostly "reformat the drive with the router".

The router web page shows it as "unmounted" and the health scan finishes in a few seconds without errors (compared to an 8GB usb drive that takes about two minutes).

Is there maybe something I forgot to install?

Edit: I went over the logs and this is what happens:

Mar 25 14:18:07 kernel: usb 1-1: new high speed USB device using ehci_hcd and address 4
Mar 25 14:18:08 kernel: scsi2 : usb-storage 1-1:1.0
Mar 25 14:18:09 kernel: scsi 2:0:0:0: Direct-Access Seagate Expansion Desk 0712 PQ: 0 ANSI: 6
Mar 25 14:18:09 kernel: sd 2:0:0:0: Attached scsi generic sg1 type 0
Mar 25 14:18:17 kernel: sd 2:0:0:0: [sdb] Spinning up disk...........ready
Mar 25 14:18:17 kernel: sd 2:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
Mar 25 14:18:17 kernel: sd 2:0:0:0: [sdb] Write Protect is off
Mar 25 14:18:17 kernel: sd 2:0:0:0: [sdb] Assuming drive cache: write through
Mar 25 14:18:17 kernel: sd 2:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
Mar 25 14:18:17 kernel: sd 2:0:0:0: [sdb] Assuming drive cache: write through
Mar 25 14:18:17 kernel: sdb: sdb1
Mar 25 14:18:17 kernel: sd 2:0:0:0: [sdb] 732566645 4096-byte logical blocks: (3.00 TB/2.72 TiB)
Mar 25 14:18:17 kernel: sd 2:0:0:0: [sdb] Assuming drive cache: write through
Mar 25 14:18:17 kernel: sd 2:0:0:0: [sdb] Attached SCSI disk
Mar 25 14:18:18 kernel: EXT4-fs (sdb1): couldn't mount RDWR because of unsupported optional features (400)
Mar 25 14:18:18 kernel: EXT3-fs (sdb1): error: couldn't mount because of unsupported optional features (2c0)
Mar 25 14:18:18 kernel: EXT2-fs (sdb1): error: couldn't mount because of unsupported optional features (2c0)
Mar 25 14:18:18 hotplug[2929]: USB /dev/sdb1(ext) failed to mount at the first try!
Mar 25 14:18:18 usb: USB /dev/sdb1(ext) failed to mount at the first try!
Mar 25 14:18:18 kernel: EXT3-fs (sdb1): error: couldn't mount because of unsupported optional features (2c0)
Mar 25 14:18:18 kernel: EXT4-fs (sdb1): couldn't mount RDWR because of unsupported optional features (400)
Mar 25 14:18:18 kernel: EXT2-fs (sdb1): error: couldn't mount because of unsupported optional features (2c0)
Mar 25 14:18:18 kernel: tfat: fail_safe is enabled
Mar 25 14:18:18 kernel: tntfs info (device sdb1, pid 2938): ntfs_fill_super(): fail_safe is enabled

 

[Protik]

I faced this earlier. I suspect Raspbian formats into a newer version of EXT4 which is not recognized in Asus routers.

Rather format it from command line of Asus. It should work fine. That's what I did.

Sent from my Moto G (5) Plus using Tapatalk

 

[miguelroboso]

Darn. I was hoping that I wouldn't have to transfer 100GB back and forth...

 

[sfx2000]

It's not a Pi/Raspbian problem, it's a partitioning problem with the drive itself.

Go to fdisk (or parted), list the partitions, blow them away, and start with a new Linux partition - one can use GPT or MBR there, but create a new linux partition, and then do the mkfs.ext4 as needed to create something of a volume.

Like Orges and Onions - in Linux, drives have layers, and if done correctly, everything works.

 

[sfx2000]

I encountered the "unsupported features" error while trying to mount an EXT4 partitioned USB 3.0 drive on my RT- AC68P with Merlin V384.4_2 installed.

See above - back up the data on the drive that has been copied to it, and start over...

Sometimes one has to get into the metal and get pretty medieval with it - the off the shelf USB backup drives are typically formatted as either NTFS or exFAT, and this can get things into a weird place with the partition map, esp, if the vendor is offering cross platform support.

 

[miguelroboso]

It's not a Pi/Raspbian problem, it's a partitioning problem with the drive itself.

Go to fdisk (or parted), list the partitions, blow them away, and start with a new Linux partition - one can use GPT or MBR there, but create a new linux partition, and then do the mkfs.ext4 as needed to create something of a volume.

Like Orges and Onions - in Linux, drives have layers, and if done correctly, everything works.

Thing is, the current partitioning has been done with disk, mkfs.ext4 and all. From scratch, I did:

- fdisk /dev/sda (it was sda on the Rpi)
- removed all the partitions
- created a linux partition
- exited from fdisk
- formatted the partition with mkfs.ext4 (sudo mkfs.ext4 /dev/sda1)

I thought I wrote that on the original post, but maybe I was not clear.

I think Protik is right. Either way, I am backing up and starting over from the router itself.

 

[ColinTaylor]

It's not a Pi/Raspbian problem, it's a partitioning problem with the drive itself.

Not true. It's not a partitioning problem, it's an issue (I wouldn't say problem) with the Pi's version of mkfs.ext4 (it's too new ).

Like Orges and Onions - in Linux, drives have layers, and if done correctly, everything works.

To use your analogy, the partition layer is OK, but the ext4 core contains features the router's version of ext4 doesn't understand. Making the ext4 filesystem using the router's own utility will fix it.

Filesystem formatted on Pi and then plugged into router:

Mar 26 01:25:32 kernel: usb 2-1: new high speed USB device using ehci_hcd and address 9
Mar 26 01:25:32 kernel: scsi7 : usb-storage 2-1:1.0
Mar 26 01:25:33 kernel: scsi 7:0:0:0: Direct-Access     Multi    Flash Reader     1.00 PQ: 0 ANSI: 0
Mar 26 01:25:33 kernel: sd 7:0:0:0: Attached scsi generic sg1 type 0
Mar 26 01:25:33 kernel: sd 7:0:0:0: [sdb] 3842048 512-byte logical blocks: (1.96 GB/1.83 GiB)
Mar 26 01:25:33 kernel: sd 7:0:0:0: [sdb] Write Protect is off
Mar 26 01:25:33 kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
Mar 26 01:25:33 kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
Mar 26 01:25:33 kernel:  sdb: sdb1
Mar 26 01:25:33 kernel: sd 7:0:0:0: [sdb] Assuming drive cache: write through
Mar 26 01:25:33 kernel: sd 7:0:0:0: [sdb] Attached SCSI removable disk
Mar 26 01:25:34 kernel: EXT4-fs (sdb1): couldn't mount RDWR because of unsupported optional features (400)
Mar 26 01:25:34 kernel: EXT3-fs (sdb1): error: couldn't mount because of unsupported optional features (2c0)
Mar 26 01:25:34 kernel: EXT2-fs (sdb1): error: couldn't mount because of unsupported optional features (2c0)
Mar 26 01:25:34 hotplug[14643]: USB /dev/sdb1(ext) failed to mount at the first try!
Mar 26 01:25:34 kernel: EXT3-fs (sdb1): error: couldn't mount because of unsupported optional features (2c0)
Mar 26 01:25:34 kernel: EXT4-fs (sdb1): couldn't mount RDWR because of unsupported optional features (400)
Mar 26 01:25:34 kernel: EXT2-fs (sdb1): error: couldn't mount because of unsupported optional features (2c0)

Re-make the filesystem on the router (leave the partitioning alone):

# mkfs.ext4 /dev/sdb1
mke2fs 1.42.13 (17-May-2015)
/dev/sdb1 contains a ext4 file system
        created on Mon Mar 26 01:25:11 2018
Proceed anyway? (y,n) y
Creating filesystem with 479934 4k blocks and 120000 inodes
Filesystem UUID: 47e1359b-751e-4562-8a8a-702e4c2b32bd
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

Re-plug the drive into the router:

Mar 26 01:28:38 kernel: usb 2-1: new high speed USB device using ehci_hcd and address 10
Mar 26 01:28:38 kernel: scsi8 : usb-storage 2-1:1.0
Mar 26 01:28:39 kernel: scsi 8:0:0:0: Direct-Access     Multi    Flash Reader     1.00 PQ: 0 ANSI: 0
Mar 26 01:28:39 kernel: sd 8:0:0:0: Attached scsi generic sg1 type 0
Mar 26 01:28:39 kernel: sd 8:0:0:0: [sdb] 3842048 512-byte logical blocks: (1.96 GB/1.83 GiB)
Mar 26 01:28:39 kernel: sd 8:0:0:0: [sdb] Write Protect is off
Mar 26 01:28:39 kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Mar 26 01:28:39 kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Mar 26 01:28:39 kernel:  sdb: sdb1
Mar 26 01:28:39 kernel: sd 8:0:0:0: [sdb] Assuming drive cache: write through
Mar 26 01:28:39 kernel: sd 8:0:0:0: [sdb] Attached SCSI removable disk
Mar 26 01:28:39 hotplug[16124]: USB ext4 fs at /dev/sdb1 mounted on /tmp/mnt/sdb1
Mar 26 01:28:39 kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: user_xattr

 

[miguelroboso]

No true. It's not a partitioning problem, it's an issue (I wouldn't say problem) with the Pi's version of mkfs.ext4 (it's too new ).

To use your analogy, the partition layer is OK, but the ext4 core contains features the router's version of ext4 doesn't understand. Making the ext4 filesystem using the router's own utility will fix it.

Filesystem formatted on Pi and then plugged into router:
...

So, in other words, nothing can save me those 8 hours of transferring data...I just found 89 more GB...

 

[sfx2000]

Filesystem formatted on Pi and then plugged into router:

Did you blow away the old partition?

ext4 is ext4 - nothing new, nothing borrowed - just is...

It's mature, and should be from Pi to Asus - unless Asus isn't doing ext4 correctly - which might be.

In any event - common guidance with AsusWRT is ext3 or ext2 even - I'm suggesting that ext3 is a good choice there.

 

[ColinTaylor]

Did you blow away the old partition?

When plugged into the Asus? No, as I said "leave the partitioning alone".

ext4 is ext4 - nothing new, nothing borrowed - just is...

Except it isn't. The error message is quite clear:

EXT4-fs (sdb1): couldn't mount RDWR because of unsupported optional features (400)

Making the filesystem (not the partition) using Windows' MiniTool Partition Wizard or Centos6's mkfs.ext4 creates a filesystem that is compatible with Asus.

We've had this issue reported before when a Pi was used to create the filesystems.

 

[ColinTaylor]

So, in other words, nothing can save me those 8 hours of transferring data...I just found 89 more GB...

You might be able to remove the incompatible features (by plugging it back into the Pi) with tune2fs. I've done it in the past, removing the journal because it was corrupted. But it's not really something I know a lot about.

# tune2fs -l /dev/sda1 | grep features
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

You can use the -O option:

       -O [^]feature[,...]
              Set or clear the indicated filesystem features (options) in the filesystem.  More than one filesystem feature can be cleared or set by sepa‐
              rating  features  with  commas.   Filesystem  features prefixed with a caret character ('^') will be cleared in the filesystem's superblock;
              filesystem features without a prefix character or prefixed with a plus character ('+') will be added to  the  filesystem.   For  a  detailed
              description of the file system features, please see the man page ext4(5).

              The following filesystem features can be set or cleared using tune2fs:

                   dir_index
                          Use hashed b-trees to speed up lookups for large directories.

                   dir_nlink
                          Allow more than 65000 subdirectories per directory.

                   encrypt
                          Enable file system level encryption.  Tune2fs currently only supports setting this filesystem feature.

                   extent Enable  the  use  of  extent trees to store the location of data blocks in inodes.  Tune2fs currently only supports setting this
                          filesystem feature.

                   extra_isize
                          Enable the extended inode fields used by ext4.

                   filetype
                          Store file type information in directory entries.

                   flex_bg
                          Allow bitmaps and inode tables for a block group to be placed anywhere on the storage media.  Tune2fs will  not  reorganize  the
                          location  of  the inode tables and allocation bitmaps, as mke2fs(8) will do when it creates a freshly formatted file system with
                          flex_bg enabled.

                   has_journal
                          Use a journal to ensure filesystem consistency even across unclean shutdowns.  Setting the filesystem feature is  equivalent  to
                          using the -j option.

                   huge_file
                          Support files larger than 2 terabytes in size.

                   large_file
                          Filesystem can contain files that are greater than 2GB.

                   metadata_csum
                          Store a checksum to protect the contents in each metadata block.

                   mmp    Enable or disable multiple mount protection (MMP) feature.

                   project
                          Enable project ID tracking.  This is used for project quota tracking.

                   quota  Enable internal file system quota inodes.

                   read-only
                          Force the kernel to mount the file system read-only.

                   resize_inode
                          Reserve  space  so the block group descriptor table may grow in the future.  Tune2fs only supports clearing this filesystem fea‐
                          ture.

                   sparse_super
                          Limit the number of backup superblocks to save space on  large  filesystems.   Tune2fs  currently  only  supports  setting  this
                          filesystem feature.

                   uninit_bg
                          Allow the kernel to initialize bitmaps and inode tables lazily, and to keep a high watermark for the unused inodes in a filesys‐
                          tem, to reduce e2fsck(8) time.  The first e2fsck run after enabling this feature will take the full time, but subsequent  e2fsck
                          runs will take only a fraction of the original time, depending on how full the file system is.

              After  setting or clearing sparse_super, uninit_bg, filetype, or resize_inode filesystem features, the file system may require being checked
              using e2fsck(8) to return the filesystem to a consistent state.  Tune2fs will print a message requesting that the system  administrator  run
              e2fsck(8) if necessary.  After setting the dir_index feature, e2fsck -D can be run to convert existing directories to the hashed B-tree for‐
              mat.  Enabling certain filesystem features may prevent the filesystem from being mounted by kernels which do not support those features.  In
              particular, the uninit_bg and flex_bg features are only supported by the ext4 filesystem.

EDIT: A quick comparison of the man pages on the Pi vs. Centos shows some likely missing features:

dir_nlink, encrypt, extent, extra_isize, huge_file, 64bit, metadata_csum, mmp, project, quota, read-only

 

[ColinTaylor]

@miguelroboso Just to follow up on this...

The features that the Raspberry Pi adds that are incompatible with Asus are 64bit and metadata_csum.

To remove these two features you need to plug the drive back into the Pi and run resize2fs to convert from 64bit to 32bit, and run tune2fs to remove metadata_csum.

# tune2fs -l /dev/sda1 | grep features
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

# resize2fs -s /dev/sda1
resize2fs 1.43.3 (04-Sep-2016)
Converting the filesystem to 32-bit.
The filesystem on /dev/sda1 is now 479934 (4k) blocks long.

# tune2fs -O ^metadata_csum /dev/sda1
tune2fs 1.43.3 (04-Sep-2016)
Disabling checksums could take some time.
Proceed anyway (or wait 5 seconds) ? (y,n) y

# tune2fs -l /dev/sda1 | grep features
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

The drive will now mount on the Asus.

 

[miguelroboso]

Alright, everything was backed up, so I tried that.

For reference, resize2fs asked me to

Please run 'e2fsck -f /dev/sda1' first.

It found that some "extent trees" could be narrower, and I allowed it to "fix" them.

Then I ran what @ColinTaylor suggested, but no luck, still "unsupported optional features".

Features BEFORE:

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum

Features AFTER tune2fs:

Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize

I am debating if I should just format it from the router and restore the backup, although it is going to take another 9 hours...

I wonder if there is a way to ask the system WHICH ONES are the unsupported optional features, exactly.

 

[ColinTaylor]

Then I ran what @ColinTaylor suggested, but no luck, still "unsupported optional features".

You have to run the commands on the Pi, not the Asus. Did you do that?

EDIT: Strange. Comparing your features to mine, they are identical.

 

[miguelroboso]

You have to run the commands on the Pi, not the Asus. Did you do that?

EDIT: Strange. Comparing your features to mine, they are identical.

Yes, all was ran on the Pi.

This was around the features' error:

Mar 28 19:01:37 kernel: JBD: Unrecognised features on journal
Mar 28 19:01:37 kernel: EXT4-fs (sdb1): error loading journal

 

[ColinTaylor]

I wonder if there is a way to ask the system WHICH ONES are the unsupported optional features, exactly.

Try:

e2fsck -pv /dev/sdb1

EDIT: Some information here about the journal problem.

 

[miguelroboso]

I guess you mean on the router. If so, that's weird. There seem not to be any /dev/sdb1

e2fsck -pv /dev/sda1

/dev/sda1: clean, 23/489600 files, 35065/1955579 blocks

oh wait, that was for sda

 e2fsck -pv /dev/sdb1

/dev/sdb1: Journal superblock has an unknown incompatible feature flag set.

/dev/sdb1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.

    (i.e., without -a or -p options)

So I guess there is no way to know it

 

[sfx2000]

Yep - just thinking - RPi is a fairly current kernel, so that might be a problem for 2.6 based devices like AsusWRT when working with ext4 - for most, not an issue.

back up the data, and make it ext3, and one is probably good there.

 

[ColinTaylor]

So I guess there is no way to know it

Well I suggest you do as it says and run the command again without the -p. Failing that you can remove the journal and recreate it (IIRC).

 

[roidinev]

whether do as ColinTaylor told, or format by an low version system such centos 6 .