Bug 42617 - Unable to mount some old disk image files
Summary: Unable to mount some old disk image files
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: FAT/VFAT/MSDOS (show other bugs)
Hardware: All Linux
: P1 enhancement
Assignee: OGAWA Hirofumi
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-01-20 19:28 UTC by Mark
Modified: 2016-03-23 18:16 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.0
Subsystem:
Regression: No
Bisected commit-id:


Attachments
Gzipped, MS-DOS 1.1-formatted 320k floppy image (1.33 KB, application/x-tar)
2014-03-28 03:17 UTC, Conrad Meyer
Details

Description Mark 2012-01-20 19:28:00 UTC
I recently tried to mount some image files which were created from 1985-vintage 5.25" 360KB MS-DOS format disks. (40 tracks, 2 heads, 9 sectors/track, so each image is 368640 bytes long.)

Attempting to mount them using commands like
  mount -o ro,loop -t msdos imagefile.bin /media/test
was unsuccessful, giving this dmesg output:
  FAT-fs (loop1): bogus number of reserved sectors
  FAT-fs (loop1): Can't find a valid FAT filesystem

In the image files, the fields at offsets 0x0B-0x17 in the boot sector are all zero. Has anyone else encountered similar disks/images?

To allow such images to be mounted directly without needing to patch the boot sector data, the kernel could assume default values if those fields are all zero. The default values would depend on the image (loopback device) size and correspond to those used by the default MS-DOS format.

In the case of my image files, size 368640 => assume 512 bytes/logical sector, 2 sectors/cluster, 1 reserved sector, 2 FATs, 112 root directory entries, 720 sectors, media descriptor 0xFD, 2 sectors/FAT.

A hex dump of the boot sector data:
00000000  eb 1c 90 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 fa 33  |...............3|
00000020  c0 8e d0 bc 00 06 fb 0e  e8 46 00 b4 06 b0 00 b7  |.........F......|
00000030  07 b9 00 00 ba 4f 18 cd  10 b4 02 ba 00 00 b7 00  |.....O..........|
00000040  cd 10 be b8 10 2e 8a 04  0a c0 74 f9 56 b4 0e bb  |..........t.V...|
00000050  07 00 cd 10 5e 46 eb ed  07 4e 6f 74 20 73 79 73  |....^F...Not sys|
00000060  74 65 6d 20 62 6f 6f 74  20 66 6c 6f 70 70 79 2e  |tem boot floppy.|
00000070  00 58 5b ba 8b 10 8b ca  2b d0 d1 fa d1 fa d1 fa  |.X[.....+.......|
00000080  d1 fa 2b da 53 51 cb 00  00 00 00 00 00 00 00 00  |..+.SQ..........|
[remaining bytes all 00]

After examining the layout of data in the image file, I figured out the correct values. Making the changes shown below to the boot sector allowed the image file to be mounted.

Offset	Change 	Comment
00C	02	Bytes per logical sector, 0x200 = 512
00D	02	Logical sectors per cluster; 2 means 1024 bytes/cluster
00E	01	Reserved logical sector count
010	02	Number of FATs
011	70	Maximum number of root directory entries; 0x70 = 112
013	D0 02	Total logical sectors; 0x2D0 = 720
015	FD	Media descriptor; 0xFD means 5.25" double-sided, 40 tracks, 9 sectors/track
016	02	Logical sectors per FAT
Comment 1 Mark 2014-01-26 15:01:38 UTC
From Wikipedia http://en.wikipedia.org/wiki/File_Allocation_Table#BPB support for the BIOS Parameter Block was first implemented in MS-DOS 2.0. So disks written using early MS-DOS versions don't have valid values in the BPB fields.

Ideally the Linux FAT/VFAT code would use sensible default values if the BPB fields are empty.
Comment 2 Conrad Meyer 2014-03-28 00:20:55 UTC
Mark, can you provide an image file we can use for test purposes? I'm not sure I
can make mkfs.fat spit out something similar to the pre-DOS 2.0 format (even with post-processing to zero 0x0b -> 0x17).

Thanks!
Comment 3 Conrad Meyer 2014-03-28 03:17:42 UTC
Created attachment 130931 [details]
Gzipped, MS-DOS 1.1-formatted 320k floppy image

Mark,

If you can provide a real image, that would be awesome, but meanwhile I have created a franken-floppy image from scratch.

I found an old "bochs" machine running MS-DOS 1.1, ran FORMAT on an old 5.25in 320k floppy (note: Bochs write track <-> FORMAT only seemed to accept 320k or other 8-sectors-per-track geometries, not 360k) that I had preformatted with mkfs.fat for some reason, and came up with the attached image. It seems to demonstrate the right header issues (lots of zeroes from 0x0B to 0x17).

The image should be empty; I haven't touched it since FORMAT. It may still have a mkfs.fat volume label in it since bochs crashed in the middle, but the header appears to demonstrate the issue.
Comment 4 Conrad Meyer 2014-03-28 22:53:10 UTC
Submitted: https://lkml.org/lkml/2014/3/28/467
Comment 5 Conrad Meyer 2014-03-29 00:30:46 UTC
(In reply to Conrad Meyer from comment #3)
> Created attachment 130931 [details]
> Gzipped, MS-DOS 1.1-formatted 320k floppy image

For what it's worth, I'm not sure this test image is especially valid, given that it was initially created with mkfs.vfat, and I'm not sure how much FORMAT actually overwrote, and bochs did crash partway through. Mark's examples work well under the submitted patch.
Comment 6 Conrad Meyer 2014-04-10 00:57:59 UTC
Well, latest version of the patch is here:

https://lkml.org/lkml/2014/3/31/558

I think it addresses all issues brought up during review, but I haven't heard back from Hirofumi or anyone in over a week. I'll wait a week and re-send.
Comment 7 Conrad Meyer 2014-05-10 18:46:55 UTC
In Andrew Morton's tree, slated for 3.16 via linux-next:

http://ozlabs.org/~akpm/mmots/broken-out/fs-fat-add-support-for-dos-1x-formatted-volumes.patch

Note You need to log in before you can comment on or make changes to this bug.