[syslinux] Structure of VBR in FAT32?

[Ady Ady]

> > 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.