mount_msdosfs anomaly

[Mark Ovens]

Malcolm Kay wrote:

> On Saturday 15 May 2004 12:04, hoe-waa at hawaii.rr.com wrote:
> 
>> Here is the output of fdisk when ran from FBSD:
>> frankie# fdisk
>> ******* Working on device /dev/ad0 *******
>> parameters extracted from in-core disklabel are:
>> cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl)
>>
>> Figures below won't work with BIOS for partitions not in cyl 1
>> parameters to be used for BIOS calculations are:
>> cylinders=155061 heads=16 sectors/track=63 (1008 blks/cyl)
>>
>> Media sector size is 512
>> Warning: BIOS sector numbering starts with sector 1
>> Information from DOS bootblock is:
>> The data for partition 1 is:
>> sysid 11 (0x0b),(DOS or Windows 95 with 32 bit FAT)
>>     start 63, size 10249407 (5004 Meg), flag 0
>>         beg: cyl 0/ head 1/ sector 1;
>>         end: cyl 637/ head 254/ sector 63
>> The data for partition 2 is:
>> sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
>>     start 10249470, size 40949685 (19994 Meg), flag 80 (active)
>>         beg: cyl 638/ head 0/ sector 1;
>>         end: cyl 1023/ head 254/ sector 63
>> The data for partition 3 is:
>> sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA))
>>     start 51199155, size 5863725 (2863 Meg), flag 0
>>         beg: cyl 1023/ head 254/ sector 63;
>>         end: cyl 1023/ head 254/ sector 63
>> The data for partition 4 is:
>> sysid 5 (0x05),(Extended DOS)
>>     start 57062880, size 99233505 (48453 Meg), flag 0
>>         beg: cyl 1023/ head 254/ sector 63;
>>         end: cyl 1023/ head 254/ sector 63
>> frankie#
>> As you can see, I still have 98SE on partition 1 and partition 3 shows as
>> fat32. Slackware was re-installed and is working on P-8 with linux-swap 0n
>> P-9.
>>
>> Is this weird that I cannot mount ad0s3?
>>
> 
> Does someone out there know the significance of "sysid 12" versus "sysid 11"?
> 

According to the fdisk output sysid 11 is
      DOS or Windows 95 with 32 bit FAT
and sysid 12 is
      DOS or Windows 95 with 32 bit FAT (LBA)

The difference is LBA although I thought that if you needed to use LBA 
then the _whole disk_ was LBA but since slice 3 is visible in Win98 I 
guess it's correct (probably just a case of FreeBSD reporting 
_accurately_ what's on the disk).

It's a few years since I messed with FAT so I may not have remembered 
this correctly, but originally DOS could only support a single _active_ 
primary partition (which is why extended was invented). Somewhere in the 
Win9x line that changed; the OS still had to be on the first primary 
partition but other primary partitions were visible in the OS.

The OP says that Win98 can see /dev/ados3 and write to it but, if you 
look at the fdisk output only slice 1 is flagged 'active'.

The last time I had a machine with multiple OSes (Win98, W2K, and 
FreeBSD) I used BootMagic that comes with PartitionMagic which had a 
config option to choose which partitions/slices each OS could see. With 
FreeBSD the default setting hid _all_ the FAT & NTFS slices (I got the 
same problem you have) so I had to change the settings. The first one or 
two bytes in each entry in the partition table determine whether the 
partition is 'active' (i.e. the one that is booted from) but also 
whether the partition is visible or hidden. When you choose an OS from 
BM's menu it edits the PT "on the fly" (which will set the BIOS boot 
sector anit-virus alarm off if it's enabled) and then continues the boot 
process.

IIRC Win9x can see adso3 (in this case) by simply ignoring the visible 
flag, i.e. a kludge, in typical MS fashion.

As to how to resolve it, if you are really brave you can edit the 
partition table flags directly but the changes may not hold (I have a 
feeling that Win98 may "fix" them next time you boot Win98) or install a 
boot manager like BM that allows you to set the visibility.

If you run this

# dd if=/dev/ad0 of=/tmp/foo bs=512 count=1
# hd /tmp/foo > /tmp/foo.hd

and post the last 6 lines of foo.hd it will help identify which byte is 
set wrong; I've a load of notes here about partition tables so I'll dig 
them out.

HTH

Regards,

Mark