Volume boot record

Source: Wikipedia, the free encyclopedia.

A volume boot record (VBR) (also known as a volume boot sector, a partition boot record or a partition boot sector) is a type of

partition table
.

The code in volume boot records is invoked either directly by the machine's firmware or indirectly by code in the master boot record or a

loaded the same way
.

Invoking a VBR via a boot manager is known as

boot loader for all releases of Microsoft's Windows NT-derived operating systems up to and including Windows XP and Windows Server 2003
), take copies of the bootstrap code that individual operating systems install into a single partition's VBR and store them in disc files, loading the relevant VBR content from file after the boot loader has asked the user which operating system to bootstrap. In .

In

FAT article
.)

Technical details

Signature

The presence of an IBM PC compatible boot loader for x86-CPUs in the boot sector is by convention indicated by a two-byte hexadecimal sequence called the boot sector signature (55h at fixed offset +1FEh and AAh at +1FFh) for sector sizes of 512 bytes or more.[nb 1] For 512 byte sectors, the boot sector signature also marks the end of the sector. VBRs on smaller and larger sectors may show signatures at the end of the actual sector size as well, however, the semantics described herein apply to the 16-bit signature at +1FEh only.

This signature indicates the presence of at least a dummy boot loader which is safe to be executed, even if it may not be able to actually load an operating system. It does not indicate the presence of a (or even a particular)

FAT16 media to be used also by very old versions of DOS must maintain the signature even if they do not contain an operating system or are meant to be bootable on other platforms only; consequently they must contain at least an x86 compatible (dummy) loader as well (for comparison, see examples of FAT on the Atari ST and with MSX-DOS
). Nevertheless, some media for other platforms erroneously contain the signature even without a x86 compatible dummy loader, making the check not 100% reliable in practice.

The signature is tested for by most System BIOSes since (at least) the

IBM PC and some other machines). Even more so, it is also checked by most MBR boot loaders before passing control to the boot sector. Some BIOSes (like the IBM PC/AT) perform the check only for fixed disk / removable drives, while for floppies and superfloppies it is enough to start with a byte greater or equal to 06h and the first nine words not to contain the same value, before the boot sector is accepted as valid, thereby avoiding the explicit test for 55h, AAh on floppies. Since old boot sectors (i.e. very old CP/M-86
and DOS media) sometimes do not feature this signature despite the fact that they can be booted successfully, the check can be disabled in some environments. This also reflects the fact that floppies can be formatted to use smaller sector sizes than 512 bytes.

If the BIOS or MBR code does not detect a valid boot sector and therefore cannot pass execution to the boot sector code, it will try the next boot device in the row. If they all fail it will typically display an error message and invoke

bootstrapping process until the next power-up.[1]

From decimal offset 72 to 79, an NTFS PBR contains the partition UUID volume ID serial number.

Invocation

The boot code in the VBR can assume that the BIOS has set up its data structures and interrupts and initialized the hardware. The code should not assume more than 32 KB of memory to be present for fail-safe operation;

SS:SP = 0000h:0400h, this is not a condition to rely on, as not all BIOSes and MBR codes follow this convention. Registers not mentioned below must be treated as not initialized. Direct hardware access is not normally allowed. While the Disk Parameter Table (DPT/FDPB) is typically set up at 0000h:0078h in memory already, the VBR must move (and possibly fix-up) the DPT pointed to by INT 1Eh
vector to this location (INT 1Eh not an interrupt, but a far pointer to the DPT).

Some conditions can be relaxed in controlled environments, for example, some boot loaders today assume to have up to 128 KB of memory to work with in normal operation (without querying for more), and some boot loaders using

CPU.

The VBR is loaded at memory location 0000h:7C00h[1] and with the following CPU registers set up when the prior bootstrap loader (that is, typically the BIOS or MBR, but possibly another boot loader) passes execution to it by jumping to 0000h:7C00h in the CPU's real mode.

  • IP
    = 0000h:7C00h (fixed)

Some Compaq BIOSes erroneously use 07C0h:0000h instead. While this resolves to the same location in real mode memory, it is non-standard and should be avoided, since VBR code assuming certain register values or not written to be relocatible may not work otherwise.

  • FAT16
    volumes only, if the BPB value is set to FFh.)
  • INT 13h
    ; else: don't care (should be zero). DH is supported by some IBM BIOSes. Some MBR and VBR codes preserve the value of DH.

Systems with

Plug-and-Play BIOS or BBS support will provide a pointer to PnP data in addition to DL:[2][4]

  • DL = boot drive unit (see above)
  • DI
    = points to "$PnP" installation check structure

This information allows the boot loader (in the MBR or VBR) to actively interact with the BIOS or a resident PnP / BBS overlay in memory in order to configure the boot order etc., however, this information is ignored by most standard MBRs and VBRs. Ideally, ES:DI is passed on, but PnP-enabled operating systems typically also have fallback methods to retrieve the PnP BIOS entry point later on so that most operating systems do not rely on this. Information in ES:DI can be used as a hint - according to the PnP BIOS specification, "$PnP" installation check structure could be found by searching for a signature of the ASCII string $PnP in system memory starting from F0000h to FFFFFh at every 16 byte boundary.

With partitioned media, when the VBR is launched by the MBR (or different boot loader) rather than the BIOS, many implementation pass additional information to the VBR besides just DL (and sometimes DH and ES:DI as well):

Under DR-DOS 7.07 an extended interface may be optionally used by the MBR and in conjunction with LOADER:

  • AX
    = magic signature indicating the presence of this extension (0EDCh)
  • DL = boot drive unit (see above)
  • DS:SI = points to the 16-byte MBR partition table entry used (see above)
  • ES:
    BX
    = start of boot sector or special "NEWLDR" sector image (typically 7C00h)
  • CX
    = reserved

In conjunction with

Hybrid MBR proposal recommends another extension to the MBR to VBR interface:[5]

See also

Notes

  1. big-endian
    representation. Since this has been mixed up numerous times in books and even in original Microsoft reference documents, this article uses the offset-based byte-wise on-disk representation to avoid any possible misinterpretation.

References

  1. ^ a b c d e Paul, Matthias R. (1997-10-02) [1997-09-29]. "Caldera OpenDOS 7.01/7.02 Update Alpha 3 IBMBIO.COM - README.TXT and BOOT.TXT - A short description of how OpenDOS is booted". Archived from the original on 2003-10-04. Retrieved 2009-03-29. [1]
  2. ^
    Intel Corporation (1996-01-11). BIOS Boot Specification 1.01 (PDF). 1.01. Archived from the original
    (PDF) on 2016-04-14.
  3. ^ a b Paul, Matthias R. (2017-08-14) [2017-08-07]. "The continuing saga of Windows 3.1 in enhanced mode on OmniBook 300". MoHPC - the Museum of HP Calculators. Archived from the original on 2018-05-01. Retrieved 2018-05-01. […] SYS […] /O[:nnn] Override IPL reported boot drive unit (n=0..126, 128..254). […] Preparing target disk... Choosing FAT12 CHS Boot Sector (requires IPL to report boot unit). Treating target as diskette or superfloppy medium (boot drive unit 0). Writing new Boot Sector... […]
  4. ^
    Intel Corporation (1994-05-05). Plug and Play BIOS Specification 1.0A (PDF). 1.0A. Archived from the original
    (PDF) on 2018-02-02.
  5. ^ Elliott, Robert (2010-01-04). "EDD-4 Hybrid MBR boot code annex" (PDF). Hewlett-Packard, T13 Technical Committee. e09127r3. Archived (PDF) from the original on 2018-05-01. Retrieved 2018-05-01.

Further reading