1

I am in the process of writing a simple OS bootloader (first booting in legacy mode). After understanding the boot process (MBR loading the VBR, etc) I began looking into the specifications for different filesystems to understand how they handled this old style of booting.

This is necessary because the Volume Boot Record (VBR) is, by design, located on disk in the first sector of the "active" partition. In other words, the first sector's worth of bytes (normally 512 bytes) is not actually filesystem data structures, but boot code for the operating system.

First, I looked at FAT for its simplicity. To my surprise I found references to the "Boot Sector" built right into the specification. Specifically, when you format a disk with the FAT filesystem one is able to "reserve" some number of sectors at the beginning for special blocks of code, like the VBR. In this case, all filesystem data structures are displaced by this number of reserved blocks. Great! This is exactly what I was looking for.

However, I was not able to find something similar in other filesystems (specifically ext). These other filesystems must support the "legacy" style of booting (e.g. space for the VBR to bootstrap the OS) because they were available well before the UEFI boot specification.

Improve this question
5
  • You’re mistaken about how the Linux boot process works. There’s no need for a VBR if the MBR code understands enough of the filesystem to load the next stage, which is not subject to space constraints.
    – Daniel B
    Commented Feb 24, 2018 at 18:55
  • 1
    Also, ext2 does have a 1024-byte boot code area.
    – Daniel B
    Commented Feb 24, 2018 at 19:05
  • Btrfs seems to have 64KiB.
    – Kamil Maciorowski
    Commented Feb 24, 2018 at 19:09
  • @DanielB The process is not specific to Linux. DOS was booted this way. The process is well known. The MBR gets execution at 0x0000:0x7c00, it relocates itself, determines the "active" partition and loads its VBR (first sector) it at the same address, 0x0000:0x7c00. This VBR was the first stage of the bootloader specific to the installed OS. Of course, this is how it was originally done, and the process has evolved over the last 40 years. You certainly do not need a VBR, especially if your installed bootloader, like GRUB, overwrites the MBR with its own code specific to its boot scheme
    – sherrellbc
    Commented Feb 24, 2018 at 19:23
  • @DanielB There are only 512 bytes to work with in the MBR and VBR (if present), so I expected the implementation to be fairly simplified. Also, thanks for the link about ext. I poked around the wiki and could not find it there.
    – sherrellbc
    Commented Feb 24, 2018 at 19:33

1 Answer 1

Reset to default
2

These other filesystems must support the "legacy" style of booting (e.g. space for the VBR to bootstrap the OS) because they were available well before the UEFI boot specification.

No, they don't need to. See GNU GRUB Manual 2.02:

The partition table format traditionally used on PC BIOS platforms is called the Master Boot Record (MBR) format; this is the format that allows up to four primary partitions and additional logical partitions. With this partition table format, there are two ways to install GRUB: it can be embedded in the area between the MBR and the first partition (called by various names, such as the "boot track", "MBR gap", or "embedding area", and which is usually at least 31 KiB), or the core image can be installed in a file system and a list of the blocks that make it up can be stored in the first sector of that partition.

Each of these has different problems. There is no way to reserve space in the embedding area with complete safety, and some proprietary software is known to use it to make it difficult for users to work around licensing restrictions; and systems are sometimes partitioned without leaving enough space before the first partition. On the other hand, installing to a filesystem means that GRUB is vulnerable to its blocks being moved around by filesystem features such as tail packing, or even by aggressive fsck implementations, so this approach is quite fragile; and this approach can only be used if the /boot filesystem is on the same disk that the BIOS boots from, so that GRUB does not have to rely on guessing BIOS drive numbers.

The GRUB development team generally recommends embedding GRUB before the first partition, unless you have special requirements. You must ensure that the first partition starts at least 31 KiB (63 sectors) from the start of the disk; on modern disks, it is often a performance advantage to align partitions on larger boundaries anyway, so the first partition might start 1 MiB from the start of the disk.

It means a bootloader may reside before the first VBR or even inside a filesystem itself.

Improve this answer
4
  • Well, sure. I did not intend to imply this was the only way to boot. It just used to be how it was done before GRUB attempted the whole "unified bootloader" thing. I can also verify that this is implemented in practice. I spent some time last week stepping through the GRUB code in QEMU. I extracted its three stages (Download from my post in this thread). I found that GRUB overwrote the MBR in the 0th sector and had its equivalent of the VBR in the 1st sector, and then its second stage in the 2nd sector.
    – sherrellbc
    Commented Feb 24, 2018 at 19:29
  • Thanks for the link and quote. My investigation into this led to my finding that GRUB has its MBR and stage stages stored in the first sectors on disk (after the MBR but before the first partition), but I could not find references to this anywhere. This led me to wonder how it would compensate for the case where the user attempted to install into an existing system that did not have this "reserved" space. This quote shows that it requires it, unless the files are riskily stored in the filesystem. I also found that fdisk reserves the first 2048 sectors and cfdisk reserves the first 63.
    – sherrellbc
    Commented Feb 24, 2018 at 19:32
  • @sherrellbc: I believe some bootloaders (e.g. Lilo) would put stage 2 in a file, and then hardcode that file's LBA location in the MBR code. Perhaps risky but very widespread. (Didn't MSDOS have something like that?)
    – grawity_u1686
    Commented Feb 24, 2018 at 19:48
  • An interesting technique is to make sectors 2-63 a partition and give it a type. (Like say Hidden FAT-12) Modern Windows doesn't allow scribbling on \\PHYSICALDRIVE0 to write inside a partition anymore; you have to use the partition's device.
    – Joshua
    Commented Apr 1, 2021 at 17:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .