1 Jan 96
Having identified the first hard disk, the ROM initialization code now reads the first record from that disk into storage. This is the Master Boot Record or MBR. The first 446 bytes of this record are a program that is to be executed. The rest of the record is a two byte header and four 16-byte table entries to define up to four partitions. These can be four Primary Partitions or three Primary Partitions and one Extended Partition containing Logical Volumes.
The MBR has become somewhat famous because of a number of "boot sector virus" programs that replace the MBR with another program that damages your system. Developing a program to detect MBR changes can be difficult because there is no universally accepted version of the MBR program. In ancient times, vendors with a special disk architecture would supply their own disk format program and write an MBR that handled the peculiarities of the disk. Advances in technology should have solved that problem, and today all IDE and SCSI disks are fairly standard. However, IBM's OS/2 and Microsoft's Windows NT develop different and sometimes conflicting new MBR features.
A proper MBR will look at the partition table and choose the Primary Partition that is marked Active (a DOS word) or Startable (an OS/2 word for the same thing). The Extended Partition is never startable, and the MBR doesn't even know about the Logical Volumes contained in it. The MBR program reads the first 512 byte sector from the Startable Primary Partition into storage. It then jumps to the program in that sector.
The reader may experience deja vu at this point. The ROM Initialization logic read the 512 byte sector at the beginning of the hard disk to load the MBR. The MBR then reads the first 512 byte sector from the beginning of the active partition to bring in an operating system loader program.
Without some non-standard extension, the MBR only supports four disk partitions. Furthermore, some IBM systems (particularly recent PS/2 systems) use one of the entries for a System Partition containing the utility to configure the system and I/O bus (what used to be the "Reference Diskette"). This is not a serious problem, because DOS traditionally has only supported two partitions.
The first primary partition that contains a DOS file structure (a FAT file system) is called the Primary DOS Partition for that disk. If it is on the first hard disk, it becomes the C: drive. Microsoft is partial to the C: drive and requires that DOS, Windows 95, and Windows NT store their bootable system files on this drive. The three Microsoft operating systems always start by loading files off the C drive. Of course the \WINDOWS or \WINNT35 directories can be on another disk letter. However, a couple of megabytes of hidden files in the root of the C: drive are used to start loading DOS, Windows 95, or NT.
One of the four partitions on the disk can be the Extended Partition. It can be subdivided into logical volumes. Each logical volume is assigned a disk letter and can be formatted with a separate file system. There is no limit on the number of logical volumes other than the fact that there are only 26 letters in the alphabet and A, B, and C have been taken.
The MBR identifies the location and size of the Extended Partition, but the MBR has no information about the logical volumes. Neither the Extended Partition nor any of its volumes can be marked Active or Startable. An operating system can be installed on a logical volume, but it cannot be booted directly from the MBR. The trick is then to install a boot sector and some sort of Loader utility on one of the three Primary Partitions. The MBR then boots the Loader utility. The Loader utility can have information about the logical volumes and find an operating system stored in them.
OS/2 has Boot Manager. IBM tried to give this the abbreviation MOST, but like it or not, Boot Manager is unfortunately going to be shortened to BM. The OS/2 FDISK utility installs BM in a separate minimal (1 meg) non-DOS Primary Partition somewhere on the first disk. BM takes up one of the four entries in the MBR. It does not have a DOS file system, and is not assigned a disk letter. But it can be marked active/startable, and when it is the MBR loads the Boot Manager code into memory and runs it.
Boot Manager can load an operating system from any partition or logical volume on any of the first two disks. BM is not a full operating system, and it does not have advanced support for specific SCSI adapters. So it is limited to disks accessible through the ST506 emulation. Since most SCSI adapters only provide BIOS mappings for the first two hard disks on the SCSI bus (and frequently only for devices with ID 0 and 1), it may not be possible to use BM to load an operating system off a third SCSI disk. One should at least examine the specifications of the SCSI adapter card before planning to install any operating systems on a third disk. The BIOS on older systems with IDE (instead of EIDE) disks may only support the first 528 megabytes on each disk. BM itself would have to be contained within this area, and any operating system that it was supposed to start would have to be on a partition or logical volume within the first 528 megs of the disk.
Guess what Boot Manager does to load an operating system from another partition or logical volume? Right! It reads the first 512 byte sector from that partition or volume into storage and runs whatever program is contained there. To recap, the ROM Initialization code reads the first 512 byte sector off the first hard disk (the MBR) and runs the code in it. The MBR then reads the first 512 byte sector from the active partition and runs the code in it. If the active partition is the Boot Manager, it then reads the first 512 byte sector from some other partition or logical volume and runs the code in it. With some luck, the process stops and you have found a real operating system.
Boot Manager cannot be installed on the second or third hard disk, because the ROM will not load an MBR from anything except the first disk. Until BM is installed on the first hard disk, the OS/2 installation process will not allow any partition other than the C: drive to be selected as the target for the operating system. After installing BM somewhere on the first disk, then the OS/2 installation process will allow any other logical drive to be marked "installable". If Boot Manager is installed on an IDE disk, it should be in the first 528 megabytes to ensure that the MBR and BIOS can find it.
Boot Manager is installed onto the disk by the OS/2 FDISK utility. It is also configured by attributes that FDISK assigns to the various partitions. BM and FDISK are dependent on the structure of the MBR. Unfortunately, change made to the MBR by Windows NT or Chicago can make BM or OS/2 FDISK "ill". Initially, FDISK may refuse to mark a partition installable or startable. Eventually, BM may refuse to start.
Partitions and volumes are managed by a system utility. In DOS and OS/2 the utility is called FDISK. In Windows NT it is the Disk Administrator. There are also a number of separate utilities that manage partitions on behalf of Unix-like operating systems. The MBR logic described above places certain restrictions on all disk management utilities, but some are more flexible than others.
OS/2 doesn't seem to recover well when BM is damaged by changes to the MBR made by Microsoft installation utilities. It is important, however, to realize that BM contains almost no real information. It simply assigns a name to all of the partitions that contain bootable operating systems. When BM or OS/2 FDISK start refusing requests to change partitions or parameters, the best response is to delete the BM partition entirely (using either OS/2 or DOS). Then reboot the two OS/2 installation diskettes, create a new BM partition, and reenter the names of the operating systems on any other partitions.
The order of the Partition definition entries in the MBR does not necessarily correspond to their physical location on the hard disk. The Extended Partition (if it exists) is always in the fourth and last MBR table entry. When DOS searches for its Primary DOS Partition, it searches the table entries in the order in which they appear in the MBR, not the order in which they are arranged on disk. One trick used by some disk management utilities is to create two alternate versions of the DOS C: drive on two Primary Partitions of the same hard disk. DOS will accept the one which is defined in the first MBR table entry. By swapping the two entries, alternate versions of DOS can be booted. Neither DOS system can access files in the other system partition, because DOS does not assign any disk letter or provide access to other primary partitions.
Some disk management utilities require that you create the Extended Partition on some part of the disk, then subdivide it into logical volumes. However, the MBR algorithm can be more flexible. The Extended Partition must occupy one area of the hard disk. While it is defined by the last entry in the MBR table, it does not have to occupy the last area of space on the disk. Some of the FDISK-like utilities allow the Extended Partition to grow or shrink as new logical volumes are created from free space immediately in front or behind its previous area on disk. The real restriction is that a Primary Partition cannot be placed between two logical volumes, because that would imply that a Primary Partition overlaps the Extended Partitions.
NT allows disk letters to be arbitrarily assigned to disk volumes. DOS and OS/2, however, assign disk letters at boot time to the partitions that exist. First, a disk letter is assigned to the first Primary Partition with a DOS "FAT" file system found on each disk. Then disk letters are assigned to all the logical volumes on the first disk, then to logical volumes on the second disk, and so on until the system either runs out of disks and volumes or runs out of letters.
A user has an IDE hard disk divided into a Primary DOS Partition (C:) and a logical volume (D:). She then goes to Diskorama and buys a second IDE disk, installs it in the machine, and creates another Primary DOS Partition and another logical volume. After rebooting, the Primary DOS Partition on the new disk has become D: while the old logical volume has changed to the E: drive. The DOS and OS/2 algorithm assigns letters first to all the Primary Partitions on all the disks. This will, in general, mess up all the disk letters stored in INI files and other configuration data. To avoid trouble, the second disk should be configured with no Primary Partition. It should only have an Extended Partition with two logical volumes. Then the old disk will continue to have drive letters C: and D: and the new disk will get letters E: and F: as was probably intended.
Copyright 1995 PC Lube and Tune -- Das Boot -- H. Gilbert