With every version of dosfstools I've tried (3.0.9, 3.0.16, 3.0.24, 3.0.26), running dosfsck against the VFAT boot-partition of my MIPS ERLite-3 router (http://wiki.gentoo.org/wiki/MIPS/ERLite-3) results in the anticipated output: fsck.fat 3.0.24 (2013-11-23) fsck.fat 3.0.24 (2013-11-23) Checking we can access the last sector of the filesystem Boot sector contents: System ID "mkdosfs" Media byte 0xf8 (hard disk) 512 bytes per logical sector 4096 bytes per cluster 8 reserved sectors First FAT starts at byte 4096 (sector 8) 2 FATs, 16 bit entries 73728 bytes per FAT (= 144 sectors) Root directory starts at byte 151552 (sector 296) 512 root directory entries Data area starts at byte 167936 (sector 328) 36311 data clusters (148729856 bytes) 62 sectors/track, 120 heads 0 hidden sectors 290816 sectors total Starting check/repair pass. Checking for unused clusters. Starting verification pass. Checking for unused clusters. /dev/sda1: 5 files, 5064/36311 clusters However, the current stable version, 3.0.22, instead reports: fsck.fat 3.0.22 (2013-07-19) fsck.fat 3.0.22 (2013-07-19) Logical sector size (2 bytes) is not a multiple of the physical sector size. Whilst I realise that *all* MIPS packages are currently keyworded ~mips, the 3.0.22 version is otherwise stable - so I felt this was worth reporting in case it isn't solely a MIPS-specific issue.
So only 3.0.22 is affected, not later versions? Sounds like a bug they discovered and fixed then. Would be interesting to compare diffs between the affected and non-affected versions, but it seems like the best course of action would be to remove the ~mips keyword from 3.0.22's ebuild. If the exact diff that corrected the issue can be located, we could apply that to 3.0.22. No idea if it affects other archs, though.
Not a MIPS problem as far as I can tell. We probably need a newer dosfstools to stable.
arm stable
Stable for HPPA.
amd64 stable
x86 stable
ppc stable
alpha stable
ppc64 stable
ia64 stable
sparc stable. Closing.
