> You might want to read Wikipedia's articles about "FAT32" and "Designof the FAT file system", Good pointer. I spent far far too long on that page figuring out how fat32 is designed. But the reserved sectors, there is the key.> reserved sectorsRight! Immediately after the FSIS before the FAT.And it usually is 32 sectors for fat32. Take off the VBR and the FSIS, and you have 30 untouched sectors with which to play, or 15K. The still isn't enough for ldlinux.sys, which appears to be around 68K, but you can get a lot more in 15K than 512 bytes. So: 1. How much of ldlinux.sys gets loaded into the reserved sectors? Or is it nothing, and just use the VBR? 2. When loading the VBR, it skips over the bytes reserved for boot instruction, name, and FAT32 EBPB? Ah, right, I see it in the ldlinux.bin. First 11 bytes are jump instruction and SYSLINUX label, then all nulls where the EBPB would be. Nice. -- Avi Deitcher avi at deitcher.net Follow me http://twitter.com/avideitcher Read me http://blog.atomicinc.com
> > reserved sectors > > Right! Immediately after the FSIS before the FAT.And it usually is 32 > sectors for fat32. Take off the VBR and the FSIS, and you have 30 untouched > sectors with which to play, or 15K. The still isn't enough for ldlinux.sys, > which appears to be around 68K, but you can get a lot more in 15K than 512 > bytes.You are thinking GRUB-like, among (too) many others.> 1. How much of ldlinux.sys gets loaded into the reserved sectors? Or is it > nothing, and just use the VBR?Several points, FWIW and (hopefully) for the sake of clarity... A "sector" is not necessarily 512-bytes long. The VBR, or Volume Boot Record, is not necessarily 512-bytes long. Also, the VBR doesn't need to be restricted to the first sector of the volume alone. In FAT12 and FAT16, a typical VBR uses only the first sector of the volume. In FAT32, Microsoft's typical VBR uses more than just the first sector of the volume. All the sectors of the filesystem (meta)structure that include ("active", i.e. "usable", as opposed to "leftover") boot code are part of the VBR. At least, all those sectors conform (or are part of) the VBR, not just the first one. The first sector is not "the (whole) VBR", _all_ of them are part of it. Having said that, it is also very common to refer to the first sector of a boot partition as the VBR (although, strictly speaking, that would be inaccurate). The VBR in FAT12/16/32 is not part of the data area of the filesystem; i.e. "files" are not saved in, nor deleted from, the VBR, and the VBR is not counted as part of the total potentially-usable space within the filesystem. Although "ldlinux.sys" contains boot(able) code, it is still a file, and as such, in FAT12/16/32 it resides within the data area. In BIOS systems - please allow me a simplification here, or rather multiple simplifications - the boot chain goes from the BIOS to the first sector of the storage media. Typically, that first sector contains an MBR (Master Boot Record), which "typically" (at least in the context of this email thread in the Syslinux Mailing List) transfers the boot control to the VBR of the "active" (or "boot") partition. The SYSLINUX bootloader gets to be installed by means of a command line - there are several installers, see the wiki. When the partition in question was formatted as FAT32, SYSLINUX's installer puts (bootable) code within the VBR, and puts one or two files (including at least "ldlinux.sys", a file) onto the filesystem's data area. In FAT32, some additional actions might be taken by the SYSLINUX's installer, such as setting some filesystem attribute(s) on the just-transferred files (e.g. setting "ldlinux.sys" as "system" file). The above paragraph is not entirely accurate. In lame terms (and again, simplifying), the SYSLINUX'S installer for FAT32 first puts "ldlinux.sys" within the data area and then puts the corresponding (bootable) code in the VBR (and, to be clear, these are two different things). Now the VBR's boot code knows where / how to find "ldlinux.sys". So, when booting, this VBR will know where "ldlinux.sys" is located and will pass the boot control to it. But, as we already said, if the "ldlinux.sys" file is moved later-on from its location (for example, by the user), the code within the VBR won't know that such move happened - remember, these are two different separate things, and they are not aware of each other on a permanent basis; the code within the VBR just executes whatever ignorant code is in-there while booting. To solve such discrepancy, we just execute the same SYSLINUX's command line installer, once again. I hope this clarifies the basic terminology and reduces potential misunderstandings / confusion. For more on FAT12/16/32 and boot code, I have already suggested at least 2 Wikipedia articles and The Starman's Realm pages (all of which takes more than several hours to carefully read and digest). There is also the "ms-sys" source code to look into, among many other places/sites. Regards, Ady.
> You are thinking GRUB-like, among (too) many others.Heh, at least I am in good company.> A "sector" is not necessarily 512-bytes long.Fair enough, e.g. Advanced Format 4k sector disks.> The VBR, or Volume Boot Record, is not necessarily 512-bytes long. > Also, the VBR doesn't need to be restricted to the first sector of thevolume alone. The "Design" article in Wikipedia implies otherwise. I am not saying they are right, just that it implies otherwise. Boot sector = sector 0, FSIS sector 1, backup boot sector 6.> In FAT32, Microsoft's typical VBR uses more than just the first sector > of the volume. All the sectors of the filesystem (meta)structure that > include ("active", i.e. "usable", as opposed to "leftover") boot code > are part of the VBR. At least, all those sectors conform (or are part > of) the VBR, not just the first one. The first sector is not "the > (whole) VBR", _all_ of them are part of it.Meaning the other reserved sectors, therefore everything except the FSIS primary and backup?> Having said that, it is also very common to refer to the first sector > of a boot partition as the VBR (although, strictly speaking, that wouldbe inaccurate). Fair.> Although "ldlinux.sys" contains boot(able) code, it is still a file, > and as such, in FAT12/16/32 it resides within the data area.That is what I was asking. ldlinux.sys is handled entirely as a file in the filesystem, then? Except for a few hundred bytes that know how to find and load the exact sectors that contain that file on the filesystem (Gene had started to explain)?> The SYSLINUX bootloader gets to be installed by means of a command line > - there are several installers, see the wiki.Yup, I know that, having used it for a long time. This is the first time I am digging into its "guts". ("syslinuxoscopy"? Bad humour day...)> When the partition in question was formatted as FAT32, SYSLINUX'sinstaller puts (bootable)> code within the VBRThat being the few hundred bytes of difference between ldlinux.bin and ldlinux.sys (minus the nulls for the ebpb, and the all-nulls second 512-bytes, etc), and whose source is diskboot.inc (thanks again Gene).> and puts one or two files (including at least > "ldlinux.sys", a file) onto the filesystem's data area.Yup.> the SYSLINUX'S installer for FAT32 first puts "ldlinux.sys" within thedata area and then puts the corresponding (bootable) code in the VBR It has to, in order to tell the code in the VBR which blocks contain ldlinux.sys, since the tiny code on the VBR cannot contain an entire filesystem driver. Is that right?> Now the VBR's boot code knows where / how to find "ldlinux.sys". So, whenbooting, this VBR will know where "ldlinux.sys" is located and will pass the boot control to it. To keep out of your hair (unless you are enjoying this), the source that I need to look at then is: 1. diskboot.inc - which is the VBR assembly code 2. source to ldlinux.sys - which is what the VBR code loads - where in the source do I look? 3. "install" command code from syslinux - which is what embeds the VBR but also, install-time, tells it the list of blocks for ldlinux.sys - where in the source do I look?> I hope this clarifies the basic terminology and reduces potential > misunderstandings / confusion.Definitely. I had most of it, but was missing some nuances. I appreciate the extra effort!> For more on FAT12/16/32 and boot code, I have already suggested at least2> Wikipedia articles and The Starman's Realm pages (all of which takes morethan> several hours to carefully read and digest)Don't I know it! Been reading and re-reading and re-evaluating, etc. those articles for months. Challenged myself by writing a golang driver for fat32. ext4 is next on the list (some very odd design stuff in there, mostly because of ext2-3 legacy, I suppose). Thanks again, Ady Avi -- Avi Deitcher avi at deitcher.net Follow me http://twitter.com/avideitcher Read me http://blog.atomicinc.com
> > Although "ldlinux.sys" contains boot(able) code, it is still a file, > > and as such, in FAT12/16/32 it resides within the data area. > > That is what I was asking. ldlinux.sys is handled entirely as a file in the > filesystem, then? Except for a few hundred bytes that know how to find and > load the exact sectors that contain that file on the filesystem (Gene had > started to explain)?A simple test would suffice: execute the official installer and compare the "new" ldlinux.sys file (that the installer just put there) with the original one included in the official archive. This simple test could be performed on an empty, FAT12-formatted 1440KiB floppy image.> 1. diskboot.inc - which is the VBR assembly codePeople interested in boot code and low-level languages should take a look at Daniel Sedory's The Starman's Realm - I know, I know... I already mentioned it.> 2. source to ldlinux.sys - which is what the VBR code loads - where in the > source do I look?What about "core/ldlinux*.*"? Perhaps Gene might suggest others.> 3. "install" command code from syslinux - which is what embeds the VBR but > also, install-time, tells it the list of blocks for ldlinux.sys - where in > the source do I look?Please go to the Syslinux wiki and look for the "Install" wiki page. Based on a/the specific installer, you will find different locations under the "bios" subdirectory. With that location and filename in mind, search for the equivalent (or very similar) path under the root directory of the official archives (or browse the official git repository). Once again, perhaps Gene might suggest others.> Don't I know it! Been reading and re-reading and re-evaluating, etc. those > articles for months. Challenged myself by writing a golang driver for > fat32. ext4 is next on the list (some very odd design stuff in there, > mostly because of ext2-3 legacy, I suppose).This is the reason I also suggested taking a look at the "ms-sys" source code. It's not "perfect", but it might help. Regards, Ady.