> What did your mkdosfs patch do? The patch, authored by Sam Bingner <[EMAIL PROTECTED]> allows a user to provide a bootsector image; mkdosfs then extracts the executable boot code from that file and inserts it at the appropriate offset of the new bootsector on disk. It makes all appropriate tweaks to the Bios Parameter Block so that a windows system can boot.
http://sources.redhat.com/ml/binutils/2003-06/msg00727/dosfstools-2.8-bootcode.patch Sam describes the patch briefly here: http://sources.redhat.com/ml/binutils/2003-06/msg00727.html (See below, where I ponder what is either a bug in Sam's patch or a misunderstanding on my part.) Note that it requires a file "at least" 13 sectors long instead of just the bootsector for FAT32. I wrote my own bootsector editor in python, the FAT32 viewer component is attached, and can be used like so: $ ./bootsect.py bootsector.img HiddenSectors : 63 FSVersion : 8444 RootDirectoryStart : 538976288 BigNumberOfSectors : 8192608 BytesPerSector : 512 SectorsPerCluster : 128 SectorsPerFAT : 251 BigSectorsPerFAT : 724107392 NumberOfSectors : 0 ReservedSectors : 1 RootEntries : 512 HeadsPerCylinder : 255 ExtFlags : 11865 MediaDescriptor : 248 BackupBootSector : 8224 NumberOfFats : 2 SectorsPerHead : 63 OEM ID : FDOS_1.0 FSInfoSector : 8224 Note that this bootsector comes from a blade server with funky geometry: XX/251/63 The offsets and descriptions come from: http://averstak.tripod.com/fatdox/bootsec.htm I had given up on editing BIB's when I stumbled accross Sam's patch. It gave me renewed hope, and as it turns out my original boot sector editor would have worked just fine. The mkdosfs approach is much more elegent for what I'm working on though. > I followed the links you sent, but I did not see where in the boot > sector any absolute sector numbers appear. Could you elaborate? "HiddenSectors is the number of sectors between the beginning of this partition and the partition table. This field should be the same as "number of sectors preceding the partition" in the partition table. Note that it is not necessarily the physical LBA address of the first sector because there exist secondary partitions. If HiddenSectors is not the same as in the partition table, boot sector was corrupted and the partition should not be used. Also note that the high word contains garbage for old versions of DOS." This is a little confusing, but I think the author (Alex Verstak) means that HiddenSectors is (usually) the absolute offset of the partition in sectors. This is where I think Sam's patch might have a bug: - __u32 hidden; /* hidden sectors (unused) */ + __u32 hidden; /* hidden sectors (one track) */ It sounds like he's assuming that HiddenSectors should be one track. That's what I've always observed, but I assumed it was because I _always_ install to the first partition. I expect Sam's patch to break if you try to install to a partition other than the first. > > You also said: > > Second, the geometry of the drive is stored in the bootsector, and > used to get from the begining of the partition to the root > directory. > > I certainly believe this, given the dual-boot problems experienced by > people installing Fedora Core 2. But where did you find this > information? It, too, was not in the links you sent. Yes, well I had to sift through a bit of contradictory information. In my testing, I certainly couldn't boot a system if it had the wrong setting for either SectorsPerHead or HeadsPerCylinder (that is if it didn't match the values returned by your way cool entries in linux's sysfs.) I think I also had to get NumberOfSectors(for FAT16) or BigNumberOfSectors(for FAT32) right, but some of that research is getting hazy. > OK, now *that* is cool. > > If you feel like writing this up in some detail, I would love to put > it on our "testimonials" page. (We have no "testimonials" page. But > if you write this up, I will make one.) I will most certainly. Clearly we've gone on our own, higly hacked up path, but I have to say that I have the distinct feeling of standing on the shoulder of a giant. > > > I'll dig up that patch and post it as soon as I get a second. The > > other posted it to the binutils mailing list in an attempt to get > > Redhat's attention. > > I was unable to follow that last sentence. Come again? :) s/other/original author/ I plan to figure out whether Sam's script or my understanding has a bug, and then figure out who might be able to update the standard mkdosfs distribution.
bootsect.py
Description: bootsect.py
