FAT broken in 2.6.7-bk15
Quoted 6 lines
Quoted 5 lines
The recent changes in 2.6.7-bk15 broke FAT support. I am doing some rescue backup systems here using tools like syslinux and mtools to format a normal msdos disk (for el-torito). I figured out that after creating and formating of these disks that it is impossible to mount them with 'msdos' or 'vfat'.
Quoted 7 lines
You may be able to check for yourself precisely which change caused trouble for you. The only very recent change is one that makes the kernel more permissive.
Give details on what versions work for you, what versions don't. Give the exact error messages. Give the first few sectors of the filesystem that you cannot mount but can mount with an earlier kernel.
Ok after some further research I figured this out. My last working version of the Linux Kernel was 2.6.7 which worked with my rescue system. I now applied the bk* patches upwards to check which one caused the issue and I figured that this happened between bk3 to bk4 (so the problem occoured with the bk4 patch). The diskimage was created with mtools 3.9.9 and worked perfectly before.
export MTOOLSRC=".mtools.conf"
echo "drive a: file=\"/tmp/bootflop.img\" mformat_only" > .mtools.conf dd if=/dev/zero of=/tmp/bootflop.img count=5760 bs=512 mformat -t 80 -h 2 -s 36 A:
rm .mtools.conf
The diskimage was created that way for countless months without any problems. You find the image as attachment. After bunzip'ing it you receive a 2,88 mb file (don't worry about the tiny size now) with the
md5sum: dc27cfe332cf96238e80d148c9955b9e
Quoted 6 lines · Ali Akcaagac
Ok after some further research I figured this out. My last working version of the Linux Kernel was 2.6.7 which worked with my rescue system. I now applied the bk* patches upwards to check which one caused the issue and I figured that this happened between bk3 to bk4 (so the problem occoured with the bk4 patch). The diskimage was created with mtools 3.9.9 and worked perfectly before.
Ah, my fault. I changed the handling of "codepage" options, but it wasn't mentioned on changelog at all. (Sorry, I didn't notice this changes.)
Now, the codepage option recognizes only real NLS codepage module. (It uses FAT_DEFAULT_CODEPAGE, not NLS_DEFAULT. And FAT_DEFAULT_CODEPAGE only recognizes the numbers.)
Previously, it recognized/loaded all NLS modules via CONFIG_NLS_DEFAULT, if it can't load the nls_cp437.ko or specified codepage.
But this is seriously wrong. For example, if fatfs using the nls_utf8.ko for codepage, it will store the wrong 8.3-alias to disk. (At least, windows can't read this. And several peoples reported this problem.)
Anyway, could you please check FAT_DEFAULT_CODE/FAT_DEFAULT_IOCHARSET and NLS_xxx in your .config.
Yes, this should be done automatically by config system. However...
Signature · 1 line
OGAWA Hirofumi <[email protected]>