fsck in pre-mount w/mixed file system types (EXT2 & FAT32)

[redhat27]

I believe you are correct. A question for @RMerlin perhaps?

A workaround could be entware package dosfstools and symlink fatfsck to fsck.fat

EDIT: Of course then the whole process becomes messy as it cannot be implemented on pre-mount (all mounts are not available then, and entware may not be available) even though entware is on a non-fat mount.

 

[latenitetech]

hello...
weird weird...none of what you advise seem to make sense to my router!

trying to run fatfsck

ASUSWRT-Merlin RT-AC66U 380.65-4 Wed Mar 29 04:40:30 UTC 2017

admin@RT-AC66U-FF48:/jffs/scripts# fatfsck
-sh: fatfsck: not found

admin@RT-AC66U-FF48:/jffs/scripts# which fatfsck
admin@RT-AC66U-FF48:/jffs/scripts#

Given the RT-AC66U doesn't include a FAT-compatible fsck tool, my other suggestion would be to install the 'dosfstools' package from Entware. "The dosfstools package includes the mkfs.fat and fsck.fat utilities, which respectively make and check MS-DOS FAT filesystems." But if you're still going to want to run the check at boot, once you've installed that package via Entware, copy over the 'fsck.fat' file (it will be installed in /opt/sbin) to the /jffs filesystem, and edit your script to explictly call that command instead of 'fatfsck' there now. [Running it from /jffs is required because /opt (Entware) is not available during the boot sequence; it is mounted and linked as part of boot.]

I *think* that should work for you. Let me know if you need more details on how to accomplish all that.

 

[ColinTaylor]

app_fsck.sh calls 'fatfsck' for FAT filesystems

Not quite. fatfsck is called for FAT filesystems on routers using the tuxera driver - tfat. fatfsck appears to be supplied by tuxera. For other FAT implementations (vfat, msdos, fuseblk) there is no comparable utility. My guess is that as the 66U is MIPS-based it does not use the tuxera driver and is therefore omitted from the firmware at build time.

 

[ColinTaylor]

I *think* that should work for you.

It might work provided that fsck.fat is statically linked and therefore not dependent on any Entware libraries.

 

[john9527]

I don't know why, but ASUS definitely disabled checking for fat/fat32 on other than tuxera. I see how to re-enable it, and will run a few tests.

 

[ColinTaylor]

I don't know why, but ASUS definitely disabled checking for fat/fat32 on other than tuxera.

Something to do with licencing perhaps?

 

[latenitetech]

It might work provided that fsck.fat is statically linked and therefore not dependent on any Entware libraries.

Colin, you are right. I retract what I previously suggested about copying fsck.fat to /jffs. It is dynamically linked, so won't run without the Entware lib directory available. Thanks for catching that.

 

[john9527]

Something to do with licencing perhaps?

No, don't think so....dosfstools under GNU license was there. It's just not being compiled/included.

 

[john9527]

Well, it seems to work OK. I also tweaked the symlinks as well....can be called as dosfsck, fatfsck or fsck.vfat

xxxxxxxxx@AC68P-06650:/tmp/home/root# fatfsck -pn -v /dev/sdb1
dosfsck 3.0.12 (29 Oct 2011)
dosfsck 3.0.12, 29 Oct 2011, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
      4096 bytes per cluster
       528 reserved sectors
First FAT starts at byte 270336 (sector 528)
         2 FATs, 32 bit entries
   1961984 bytes per FAT (= 3832 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 4194304 (sector 8192)
    490464 data clusters (2008940544 bytes)
63 sectors/track, 255 heads
       255 hidden sectors
   3931905 sectors total
Reclaiming unconnected clusters.
Checking free cluster summary.
/dev/sdb1: 9 files, 5/490464 clusters

 

[Chiny91]

I've just bought an RT-N66U and as with my previous routers, looked around for better firmware and have very recently installed -Merlin which looks good. I wedged in the nearest USB stick to hand and looked at what was going on, chancing on this post but couldn't get the script to work. Taking a closer look:

fdisk -l
[Snip dull stuff]
Device     Boot Start      End  Sectors  Size Id Type
/dev/sdb1  *     8064 15364415 15356352  7.3G  c W95 FAT32 (LBA)

So, standard Windoze stuff, no surprise.

mkfs.ext4 -L KingstonAsus /dev/sdb1
mke2fs 1.42.12 (29-Aug-2014)
/dev/sdb1 contains a ext3 file system
    last mounted on /media/wibble123 on Tue Apr 25 12:03:42 2017
Proceed anyway? (y,n)

Hang on, its Linux not Windoze... oops.

Fix for my random USB stick was to stamp on the "Id" with fdisk and force it to 83. It appears that fdisk is a bit dim; the Id in the partition table does not have to correspond with what is actually in the partition. Probably not a problem for well-managed USB sticks but a limitation to be noted.