[syslinux] Structure of VBR in FAT32?

Avi Deitcher avi at deitcher.net
Fri Jan 5 00:00:01 PST 2018

> 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 the
volume 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 would
be inaccurate).


> 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's
installer puts (bootable)
> code within the VBR

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


> the SYSLINUX'S installer for FAT32 first puts "ldlinux.sys" within the
data 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, when
booting, 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 least
> Wikipedia articles and The Starman's Realm pages (all of which takes more
> 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 Deitcher
avi at deitcher.net
Follow me http://twitter.com/avideitcher
Read me http://blog.atomicinc.com

More information about the Syslinux mailing list