Ext4 drive doesn't mount

[Zonkd]

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

Was this a question or comment?

 

[roidinev]

Was this a question or comment?

comment. Use the two method one can solve this issue.

 

[octado]

I ran into the same issue (although somewhat different since I am running a newer release with slightly less outdated e2fsprogs software). My linux desktop (where I created the ext4 fs) has version 1.44.1 (24-Mar-2018) and merlin 384.10_2 is at 1.42.13 (17-May-2015).

In order to mount successfully I only needed to:
1. On desktop, remove optional feature metadata_csum with tune2fs.
2. On merlin, run e2fsck and repair the "corrupted" journal (replacing it with a compatible version).

Disclaimer: The fs was empty at the time so I can not say for sure if any other file system changes would have been done if fs was populated. However, I do not see why replacing a corrupt journal (maybe only the superblock even) would damage data. You will have to judge yourselves from the output (included further down).

On merlin, when first trying to mount:

usb 1-1: new SuperSpeed USB device using xhci_hcd and address 2
xhci_hcd 0000:00:0c.0: WARN: short transfer on control ep
xhci_hcd 0000:00:0c.0: WARN: short transfer on control ep
xhci_hcd 0000:00:0c.0: WARN: short transfer on control ep
xhci_hcd 0000:00:0c.0: WARN: short transfer on control ep
xhci_hcd 0000:00:0c.0: disable burst on ep 1
xhci_hcd 0000:00:0c.0: WARN no SS endpoint bMaxBurst
xhci_hcd 0000:00:0c.0: disable burst on ep 2
xhci_hcd 0000:00:0c.0: WARN no SS endpoint bMaxBurst
scsi2 : usb-storage 1-1:1.0
scsi 2:0:0:0: Direct-Access SanDisk SDSSDHP256G 0 PQ: 0 ANSI: 6
sd 2:0:0:0: Attached scsi generic sg0 type 0
sd 2:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)
xhci_hcd 0000:00:0c.0: WARN: Stalled endpoint
sd 2:0:0:0: [sda] Write Protect is off
sd 2:0:0:0: [sda] Mode Sense: 43 00 00 00
sd 2:0:0:0: [sda] Assuming drive cache: write through
xhci_hcd 0000:00:0c.0: WARN: Stalled endpoint
sd 2:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
xhci_hcd 0000:00:0c.0: WARN: Stalled endpoint
sd 2:0:0:0: [sda] Assuming drive cache: write through
sd 2:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda1): couldn't mount RDWR because of unsupported optional features (400)

Checking fs on merlin

# e2fsck -pv /dev/sda1
/dev/sda1 has unsupported feature(s): metadata_csum
e2fsck: Get a newer version of e2fsck!

The last line speaks for itself (*Footnote).

Moving disk back to linux desktop and issuing the same check:

nas1ext: clean, 11/12558336 files, 1065848/50216193 blocks

Removing metadata_csum feature (like someone else mentioned, I was prompted to run "e2fsck -f /dev/sdb1" before I was allowed to execute the change below):

sudo tune2fs -O ^metadata_csum /dev/sdb1
tune2fs 1.44.1 (24-Mar-2018)
Disabling checksums could take some time.
Proceed anyway (or wait 5 seconds to proceed) ? (y,N) y<proceeding>

Moving the disk back to merlin where the error changed to:

xhci_hcd 0000:00:0c.0: WARN: Stalled endpoint
sd 3:0:0:0: [sda] Assuming drive cache: write through
sd 3:0:0:0: [sda] Attached SCSI disk
JBD: Unrecognised features on journal
EXT4-fs (sda1): error loading journal

Running e2fsck again:

# e2fsck -pv /dev/sda1
nas1ext: Journal superblock has an unknown incompatible feature flag set.


nas1ext: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)

Again (without -p) to fix journal:

# e2fsck -v /dev/sda1
e2fsck 1.42.13 (17-May-2015)
Journal superblock has an unknown incompatible feature flag set.
Abort<y>? no
Journal superblock is corrupt.
Fix<y>? yes
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information

nas1ext: ***** FILE SYSTEM WAS MODIFIED *****

11 inodes used (0.00%, out of 12558336)
0 non-contiguous files (0.0%)
0 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 2/1
1065848 blocks used (2.12%, out of 50216193)
0 bad blocks
1 large file

0 regular files
2 directories
0 character device files
0 block device files
0 fifos
0 links
0 symbolic links (0 fast symbolic links)
0 sockets
------------
2 files

Recheck shows OK:

# e2fsck -f /dev/sda1
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
nas1ext: 11/12558336 files (0.0% non-contiguous), 1065848/50216193 blocks

After that the fs mounts without error:

usb 1-1: new SuperSpeed USB device using xhci_hcd and address 2
xhci_hcd 0000:00:0c.0: WARN: short transfer on control ep
xhci_hcd 0000:00:0c.0: WARN: short transfer on control ep
xhci_hcd 0000:00:0c.0: WARN: short transfer on control ep
xhci_hcd 0000:00:0c.0: WARN: short transfer on control ep
xhci_hcd 0000:00:0c.0: disable burst on ep 1
xhci_hcd 0000:00:0c.0: WARN no SS endpoint bMaxBurst
xhci_hcd 0000:00:0c.0: disable burst on ep 2
xhci_hcd 0000:00:0c.0: WARN no SS endpoint bMaxBurst
scsi4 : usb-storage 1-1:1.0
scsi 4:0:0:0: Direct-Access SanDisk SDSSDHP256G 0 PQ: 0 ANSI: 6
sd 4:0:0:0: Attached scsi generic sg0 type 0
sd 4:0:0:0: [sda] 500118192 512-byte logical blocks: (256 GB/238 GiB)
xhci_hcd 0000:00:0c.0: WARN: Stalled endpoint
sd 4:0:0:0: [sda] Write Protect is off
sd 4:0:0:0: [sda] Mode Sense: 43 00 00 00
sd 4:0:0:0: [sda] Assuming drive cache: write through
xhci_hcd 0000:00:0c.0: WARN: Stalled endpoint
sd 4:0:0:0: [sda] Assuming drive cache: write through
sda: sda1
xhci_hcd 0000:00:0c.0: WARN: Stalled endpoint
sd 4:0:0:0: [sda] Assuming drive cache: write through
sd 4:0:0:0: [sda] Attached SCSI disk
EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: user_xattr

# mount | grep sda1
/dev/sda1 on /tmp/mnt/nas1ext type ext4 (rw,nodev,relatime,barrier=1,stripe=8191,data=ordered)

It also automounted without issues after reboot (using "service reboot" in SSH shell). Someone else reported that they ran into problems again after rebooting so I thought that was worth mentioning.

(*) Speaking of... does anyone know why e2fsprogs is not up-to-date? Incompatibility? To much other work prioritized? Not worth risking regressing stability? I am just curious. It would be great if it could be compatible with newer desktop linux distros so users could mount partitions already created and filled with media/whatever from desktops. Since I am using a SSD that requires windows SW to wipe properly (not risking damage or residual data) this would be great.

EDIT: removed bold style from question since it has been answered.

 

[RMerlin]

It's about work prioritization. I spend very little time these days on anything related to USB disk sharing, as I feel the networking side of the router is a better investment of my time.

An additional issue with e2fsprog is the limited amount of RAM on the router. The current version is already unable to deal with large partitions as there isn't enough RAM to validate the bitmap, making e2fsprogs already useless on the router with any modern disk capacity.

 

[sfx2000]

It's about work prioritization. I spend very little time these days on anything related to USB disk sharing, as I feel the networking side of the router is a better investment of my time.

An additional issue with e2fsprog is the limited amount of RAM on the router. The current version is already unable to deal with large partitions as there isn't enough RAM to validate the bitmap, making e2fsprogs already useless on the router with any modern disk capacity.

True, true...

One thing for folks - don't try to fix a mounted file system in Linux...

 

[octado]

It's about work prioritization. I spend very little time these days on anything related to USB disk sharing, as I feel the networking side of the router is a better investment of my time.

An additional issue with e2fsprog is the limited amount of RAM on the router. The current version is already unable to deal with large partitions as there isn't enough RAM to validate the bitmap, making e2fsprogs already useless on the router with any modern disk capacity.

Thanks for explaining. That is good to know before attempting to make my own build. I really appreciate all the work put into making and maintaining Merlin. Without it I would not be able to share my USB drive on the router at all since I would not want to use the SMBv1 offered by ASUS stock SW. I just bought the RT-AC66U_B1 so I have a feeling this is not my last post here I fully agree with the project's priorities by the way. See you around!