The OS/2 boot sequence


This is intended to be a fairly complete description of the mechanisms involved in booting OS/2, right from basics.

Note that decimal numbers are written 'as is', and hexadecimal numbers are written with a trailing H except where otherwise noted.

Due to lack of space in some areas of the boot sequence, error messages are often limited to rather cryptic OS/2 error numbers, e.g. SYS01234. For the meanings of the specific messages likely to be encountered at boot time, see the Boot Message Summary.

Hardware and BIOS initialisation

On system reset, the BIOS is given control by the CPU. After performing tests and system initialisation, the BIOS starts the system boot operation; this all takes place in real mode, generally using 16 bit code, although some 32 bit instructions may be used. The actual sequence of operation depends on the BIOS options selected, but in most cases the BIOS will attempt to boot from the first diskette drive; if this fails, it will attempt to boot from the first hard drive. In both cases, the basic operation is the same, although the following is primarily about booting from a hard drive.

The boot operation consists of reading the first sector (cylinder 0, head 0, sector 1) from the boot device, and placing it into memory starting at address 0000:7C00H (segment 0, offset 7C00). Control is then transferred to address 0000:7C00H, i.e. with CS (the code segment register) set to 0000H, and IP (the instruction pointer) set to 7C00H. Note that this is functionally different to having CS set to 07C0H, and IP set to 0000H!

Hard drives and partitions

The master boot record

The PC/XT was the first IBM machine to be fitted with a hard drive. At that time, it was unclear whether users would prefer PC-DOS, or one of the other available systems (such as CP/M-86 or the UCSD p-system). Thus, it was made possible to divide the disk into up to four areas (named partitions) and to select which partition should be made active; i.e., the one which should be booted. The mechanism to make this selection was embedded within each system (inside FDISK in the case of PC-DOS), and selection of system at boot time was not possible.

The first sector on a hard drive is generally known as the Master Boot Record (often abbreviated to MBR). It consists of three basic parts:

Other information may also be stored in the MBR by particular systems.

The boot code

The actual boot code varies according to the system which created it; generally, this would be the system which originally partitioned the disk, but systems may choose to update the code to suit themselves. Although the area between offsets 000H and 1BDH is technically available for use by the boot code, some systems store other information in this area as well.

On OS/2 Warp 4 and before, one can use the command:


to rewrite the boot code without touching the partition table. The equivalent command for Warp Server for e-Business, or for one of the OS/2 Convenience Packs, is:


where n is the drive number (starting at 1 for the first drive).

On DOS, one can use the command:


Although the boot code may vary, its basic function remains the same:

The partition table

In order to understand the boot process fully, it is essential to know how the partition table works. Its format is now described.

The partition table starts at offset 1BEH in the MBR. It consists of four entries, each of which is 16 (10H) bytes in length. The format of one entry is as follows:

Offset Size (bytes) Description
00H 1 Status indicator
01H 1 Head number for start of partition
02H 2 Sector and cylinder numbers for start of partition
04H 1 Partition type indicator
05H 1 Head number for end of partition
06H 2 Sector and cylinder numbers for end of partition
08H 4 Relative starting sector for partition
0CH 4 Size of partition, in sectors

Partitions normally occupy an integral number of cylinders; the exception is the first partition on the disk, which normally starts at the second track of the first cylinder, since the first track is partially occupied by the MBR. The rest of the first track is sometimes used for special hardware initialisation code, disk managers, or multiboot systems. Most utilities tend to fill the table 'backwards', using the last entry first; this is not, however, universal.

Note that the order of partitions in the partition table may not reflect their physical order on the disk.

Head numbers

Head numbers run from 0 to n-1, where n is the total number of heads on the drive. The starting head number is the first head used by the partition, and the ending head number is the last head used by the partition.

Sector and cylinder numbers

Sector and cylinder numbers are packed into a single 16 bit word, but in a non-obvious way. The sector number occupies the least significant 6 bits of the first byte, and the cylinder number occupies the second byte, but is concatenated at its high end with the spare two bits from the sector byte. This strange arrangement reflects the fact that, originally, the cylinder number was only 8 bits; the extra two bits were added later when it was realised that larger values were needed.

Cylinder/sector bytes

Sector numbers run from 1 to n, where n is the number of sectors per track. Cylinder numbers run from 0 to n-1, where n is the total number of cylinders on the drive. The starting sector/cylinder numbers describe the first sector used by the partition, and the ending sector/cylinder numbers describe the last sector used by the partition.

Relative starting sector, and size in sectors

This is an alternative way of describing the location of the partition. The relative starting sector is the offset of the start of the partition, in sectors, from the MBR itself (i.e. from the start of the whole disk). The size is simply the number of sectors which make up the actual partition.

The status indicator

This is used to indicate the status of a partition (i.e. whether or not it is the active partition). There are only two legal values; 80H flags an active partition, and 00H flags all other partitions. Any other value may cause the partition table to be treated as corrupt.

The partition type indicator

This is used to indicate the type of partition to an operating system. This may be interpreted in whichever way an operating system chooses, and there is no truly official standard. However, the following values are in common use:

0 00 Unused partition table entry
1 01 FAT-12
2 02 XENIX root filesystem
3 03 Xenix /usr filesystem
4 04 FAT-16 (< 32MB)
5 05 Extended partition
6 06 FAT-16, 'BigDOS' (> 32MB)
7 07 OS/2 installable file system (HPFS, ...); NTFS; QNX-2 (16 bit); Advanced UNIX
8 08 OS/2 1.x; AIX boot partition; SplitDrive; Commodore DOS
9 09 AIX data partition or Coherent
10 0A OS/2 Boot Manager; Coherent swap partition; OPUS
11 0B FAT-32 (< 2048GB)
12 0C FAT-32, LBA
14 0E FAT-16, 'BigDOS' (> 32MB), LBA
15 0F Extended partition, LBA
17 11 Hidden FAT-12
18 12 COMPAQ configuration partition
20 14 Hidden FAT-16 (< 32MB)
22 16 Hidden FAT-16, 'BigDOS' (> 32MB)
23 17 Hidden OS/2 installable file system (HPFS, ...); NTFS; QNX-2 (16 bit); Advanced UNIX
24 18 AST Windows swapfile
27 1B Hidden FAT-32
28 1C Hidden FAT-32, LBA
30 1E Hidden FAT-16, 'BigDOS' (> 32MB), LBA
36 24 NEC DOS 3.x
53 35 OS/2 JFS
56 38 THEOS ver 32 2gb partition
57 39 Plan 9; THEOS V4 spanned partition
58 3A THEOS V4 4gb partition
59 3B THEOS V4 extended partition
60 3C PartitionMagic recovery partition
61 3D Hidden Novell Netware
64 40 Venix 286
65 41 LINUX/MINIX (sharing disk with DRDOS); Personal RISC boot; Power PC Reference Platform boot
66 42 LINUX swap (sharing disk with DRDOS); Secure File System
67 43 LINUX native (sharing disk with DRDOS)
69 45 Boot-US Boot Manager; Priam
76 4C Oberon
77 4D QNX 4.2 Primary
78 4E QNX 4.2 Secondary
79 4F QNX 4.2 Tertiary; Oberon
80 50 OnTrack Disk Manager; Lynx RTOS; Oberon
81 51 OnTrack Disk Manager; Novell Netware
82 52 CP/M; Microport SysV/AT
83 53 Disk Manager 6.0
84 54 Disk Manager 6.0 Dynamic Drive Overlay
85 55 EZ-Drive
86 56 Golden Bow VFeature
87 57 DrivePro
92 5C Priam EDisk
97 61 SpeedStor
99 63 UNIX System V (SCO, ISC Unix, UnixWare, ...); Mach; GNU Hurd
100 64 PC-ARMOUR; Novell Netware 2.xx
101 65 Novell Netware 3.xx or 4.xx
102 66 Novell Netware
103 67 Novell Netware
104 68 Novell Netware
105 69 Novell Netware
112 70 DiskSecure Multi-Boot
116 74 Scramdisk
117 75 PC/IX
120 78 XOSL multiboot loader
128 80 Minix 1.1 ... 1.4a
129 81 Minix 1.4b ... 1.5.10; early Linux; MITAC Disk Manager
130 82 Linux swap; Solaris x86; Prime
131 83 Linux filesystem; NT stripe and mirror set
132 84 OS/2 hidden type 04 partition; hibernation partition
133 85 Linux extended partition
134 86 NT FAT-16, 'BigDOS' (> 32MB) volume set
135 87 NTFS volume set
139 8B NT FAT-32 (< 2048GB) volume set
140 8C NT FAT-32 (< 2048GB) LBA volume set
142 8E Linux Logical Volume Manager partition
147 93 Amoeba filesystem; hidden Linux filesystem
148 94 Amoeba bad block table
159 9F BSD/OS
160 A0 Hibernation partition
161 A1 Hibernation partition
165 A5 BSD/386; FreeBSD/NetBSD/386BSD
166 A6 OpenBSD
167 A7 NextStep
169 A9 NetBSD
170 AA Olivetti FAT-12 service partition
183 B7 BSDI BSD/386 filesystem
184 B8 BSDI BSD/386 swap
190 BE Solaris 8 boot partition
192 C0 CTOS; REAL/32
193 C1 DRDOS/secured (FAT-12)
196 C4 DRDOS/secured (FAT-16, < 32M)
198 C6 DRDOS/secured (FAT-16, >= 32M); Windows NT corrupted FAT16 volume/stripe set
199 C7 Windows NT corrupted NTFS volume/stripe set; Syrinx boot
216 D8 CP/M-86
219 DB CP/M; Concurrent CP/M; Concurrent DOS; CTOS
223 DF BootIt
225 E1 SpeedStor FAT-12 extended
227 E3 SpeedStor
228 E4 SpeedStor FAT-16 extended
235 EB BeOS
241 F1 SpeedStor
242 F2 DOS 3.3+ Secondary
244 F4 SpeedStor large partition
251 FB VMWare file system
252 FC VMWare swap
253 FD Linux RAID
254 FE PS/2 IML partition; SpeedStor; LANstep
255 FF BBT (Bad Blocks Table)
Hidden partitions

The OS/2 Boot Manager ensures that only one primary partition is visible when a system is booted. It does this by adding 10H to certain partition types to make them 'invisible', but still make the change reversible by subtracting 10H at a later time.

Disk addressing

The disk addresses in the partition table may seem to have a strange format; as already explained, the packing of the cylinder number is done for historical reasons. In fact, this format was first used in the fixed disk BIOS for the PC/XT, and it is the exact format required by the BIOS calls to access the disk. This helps to simplify the boot code in the MBR. The format is commonly called Cylinder/Head/Sector, or CHS, addressing

Unfortunately, this form of disk address has fairly severe limitations. With only 6 bits for a sector number (max 64), 10 for a cylinder number (max 1024), and 8 for a head number (max 256), the total number of addressable sectors is thus 64*1024*256, making 16777216 sectors. With sectors usually being 512 bytes in size, this limits the entire physical disk to only 8,388,608 kilobytes, in other words, 8 gigabytes. Modern disks are much larger than this, so a new approach has to be used.

The new approach is known as Logical Block Addressing, or LBA. Very simply, this means that every sector on the disk is given an individual number, and that is the only address that is used to access it. Inside the disk system, this can be translated in whichever way is necessary to reflect the reality of the physical disk. The good thing is that the numbers needed for LBA are already present in the partition table, although there are still some limitations. These numbers are the relative starting sector number, and size in sectors of the partition. Each of these is 32 bits in size, thus storing a maximum sector count of 4294967296; this corresponds (with 512 byte sectors) to a total size of 2 terabytes, or 2048 gigabytes.

Some file systems (notably on Windows) have special partition types in order to specify use of LBA rather than CHS addressing; this can cause problems with other systems.

The validation pattern

To guard against booting an MBR when it has never been set up, the BIOS checks for a special pattern (AA55H) in the last word of the MBR (immediately following the partition table). Thus, all valid MBRs will contain this pattern.

Extended partitions

The size of the partition table limits the number of partitions to four. Indeed, it was originally expected that only one of these would be in use at a time. However, this has proved to be a serious limitation, so a way was found, very early on, to extend the number of partitions without changing the size of the partition table.

This is done by introducing a special type of partition known as an extended partition (generally, only one extended partition is present on each physical disk, and much software assumes this limitation). More partitions are then created within the extended partition, in such a way that there is no practical limit on the number of partitions, except for running out of space or drive letters (on systems where these are used).

The partitions defined in the MBR are known as primary partitions, and those inside the extended partition are often known as logical partitions. The extended partition is thus, itself, a primary partition. Most disks that are dedicated to one system will have one normal primary partition and one extended partition. The extended partition will normally occupy the whole of the disk, except for the space occupied by the other partition(s).

The first sector of an extended partition looks a bit like an MBR. There is no boot code, but there is a partition table and there is a validation pattern. Generally, this extended MBR (for want of a better name) contains exactly two entries:

If there is an 'inner extended partition', it too will have an extended MBR, and that will have the same kind of format; once again, actual partitions will start at the beginning of the next track.. So, the set of extended MBRs forms a linked list, headed by the real MBR and terminated by an extended MBR with just one entry. It is worth noting that the OS/2 Boot Manager assumes that the extended MBRs will look just like this, with no additional entries; it also expects the normal partition entry first, with the entry for the further extended partition second.

An important point is the format of the partition table entries in the extended MBRs. The CHS values are as one would expect, but the relative starting sector number entry is just that; it specifies the starting sector number of the partition relative to the extended MBR, not the start of the physical disk.

A particular problem occurs when some Windows systems share a disk with OS/2; although they may have separate 'system' partitions, they will often share an extended partition. These Windows systems need to know whether the extended partition is to be addressed in CHS or LBA mode, and they tell by using a different partition type; type 05H is used for the (older) CHS addressing, and type 0FH is used for LBA addressing. Windows (and certain utilities such as PartitionMagic) will sometimes silently change the type of an extended partition from 05H to 0FH. Since OS/2 does not normally recognise a type 0FH partition, this causes OS/2 to lose sight of all logical drives/volumes within such an extended partition. Caution should be exercised in changing this value back to 05H, as it is likely to cause major disk corruption if Windows is subsequently allowed to access the partition.

The INT 13H extensions

At boot time, access to the disk is via the BIOS calls invoked by the INT 13H instruction. The original versions of these BIOS calls required disk addresses in the CHS format; however, this limits booting to the first 8GB of a hard drive due to the addressing limitations mentioned in the Disk Addressing section above.

There are now enhanced calls available via INT 13H, and these will be found in nearly all modern BIOSes. These use LBA addressing, and thus do not have the same limitations. However, for the INT 13H extensions to be useful, the boot code in the MBR (and elsewhere) must support the use of these calls. Later versions of OS/2 do so; see the section on versions of the MBR for details.

Finding space for Boot Manager

One issue with using Boot Manager is that it occupies a primary partition. This can cause problems, since there are only four slots available in the partition table; by the time one is also used for an extended partition, only two slots are left.

This is not always a problem, however, since OS/2 can boot from a logical partition or volume as long as Boot Manager is used. DOS, and all versions of Windows to date, need to boot (at least initially) from drive C, which means another primary partition. It is easy to see a situation when the presence of Boot Manager is a liability.

It is a relatively little known fact that, with modern versions of OS/2, Boot Manager does not need to be on the first physical drive; it can instead live on the second physical drive (but not the third, fourth, ...). This is transparent to the user, once it has been set up; of course, it does require a second drive, but this can be a small, old, drive. To see which versions of the MBR support the presence of Boot Manager on a second drive, see the section on versions of the MBR.

It is not immediately obvious how Boot Manager can be placed on the second drive, but it can be done using the following steps. These assume that Boot Manager is currently installed on the first physical drive, and that the partition table on that drive is full. Naturally, there must be space for a partition on the second drive.

  1. Remove Boot Manager from the first physical drive.
  2. Create the new partition that is required on the first physical drive.
  3. Attempt to reinstall Boot Manager. This will work, and silently place Boot Manager on the second drive.
  4. Add the names of bootable partitions back into Boot Manager.
  5. Re-enter any Boot Manager options.

Versions of the MBR

Different versions of the MBR support different facilities. The following table summarises the support provided in various versions.

System Fixpack level INT 13H extensions Boot Manager on second drive
Warp 3 GA No Yes  †
Warp 3 XR_W040 No Yes  †
Warp 4 GA No Yes
Warp 4 XR_M012 No Yes
Warp 4 XR_M013 Yes Yes
Warp 4 XR_M015 Yes Yes
Warp 4 XR_M016 Yes Yes
Warp 4 XR_M017 Yes Yes
MCP1 GA Yes Yes
MCP1 XR_C001 Yes Yes
MCP1 XR_C002 Yes Yes
MCP1 XR_C003 Yes Yes
MCP1 XR_C004 Yes Yes
MCP2 GA Yes Yes
MCP2 XR_F001 Yes Yes
MCP2 XR_C003 Yes Yes
MCP2 XR_C004 Yes Yes
WSeB GA Yes Yes
WSeB XR_E001 Yes Yes
WSeB XR_E002 Yes Yes
WSeB XR_E003 Yes Yes
ACP1 GA Yes Yes
ACP1 XR_C001 Yes Yes
ACP1 XR_C002 Yes Yes
ACP1 XR_C003 Yes Yes
ACP1 XR_C004 Yes Yes
ACP2 GA Yes Yes
ACP2 XR_F001 Yes Yes
ACP2 XR_C003 Yes Yes
ACP2 XR_C004 Yes Yes

†  Although the MBR supports Boot Manager on the second drive, FDISK does not support installation of Boot Manager on any drive but the first.

Note that the MBR is not automatically updated when installing a new version or fixpack. It is necessary to run FDISK or LVM, and use /NEWMBR (see above) to update the boot code.

The next stage

Once the boot partition has been selected and its boot sector has been read in to 7C00:0000H, the MBR boot code jumps to 7C00:0000H with registers set to contain useful information. To recap:

What happens next depends on if OS/2 is being booted directly, or Boot Manager is being used; in the latter case, Boot Manager will be the active partition. Since the purpose of Boot Manager is to get to the same point as booting OS/2 directly, its action will be considered before the actual booting of OS/2 is covered.

Boot Manager

Boot Manager is expected to reside in a primary partition, so it has an entry in the partition table in the MBR. It occupies exactly one cylinder on the disk, which can be wasteful since it can be a lot smaller than this space allocation implies; however, this is the smallest partition size that is commonly supported by most software.

Boot Manager is usually installed by using the FDISK or LVM utilities, although early versions of PartitionMagic were also capable of installing a copy. As such, the actual code of Boot Manager is updated by using a newer version of FDISK or LVM.

The boot sector

Different versions of the boot sector support different facilities. The following table summarises the support for the INT 13H extensions provided in various versions.

System Fixpack level INT 13H extensions
Warp 3 GA No
Warp 3 XR_W040 No
Warp 4 GA No
Warp 4 XR_M012 No
Warp 4 XR_M013 Yes
Warp 4 XR_M015 Yes
Warp 4 XR_M016 Yes
Warp 4 XR_M017 Yes
MCP1 XR_C001 Yes
MCP1 XR_C002 Yes
MCP1 XR_C003 Yes
MCP1 XR_C004 Yes
MCP2 XR_C003 Yes
MCP2 XR_C004 Yes
WSeB XR_E001 Yes
WSeB XR_E002 Yes
WSeB XR_E003 Yes
ACP1 XR_C001 Yes
ACP1 XR_C002 Yes
ACP1 XR_C003 Yes
ACP1 XR_C004 Yes
ACP2 XR_C003 Yes
ACP2 XR_C004 Yes

The boot sector is generally updated by using the SYSINSTX command.

Boot Message summary

As explained earlier, many components in the boot sequence can produce rather cryptic error messages. This is mainly for reasons of restricted space, and possibly to avoid problems producing national language variants. Messages are generally of the form SYSxxxx, where xxxx is a standard OS/2 error number. If a working OS/2 system is available, simply type the command:


or just:

HELP xxxx

at a command prompt, obviously replacing the xxxx with the appropriate number.

Many of the more common boot time error messages are explained here.

The partition table on the startup drive is incorrect. Generally, this means either that more than one partition is marked active, or one of the partitions has a status byte with a value other than 00H or 80H, which are the only legal values.
The operating system cannot be loaded from the startup drive. This is caused by a disk read error, while reading the boot sector of the active partition.
The operating system is missing from the startup drive. A valid boot sector for a partition should contain the values 055H and 0AAH in its last two bytes, in that order. This is a simple validation check, intended to prevent attempts to boot from a corrupt or unformatted partition. This message is generated if the validation check for these two bytes fails.
The file OS2BOOT cannot be found. OS2BOOT is the second stage boot program, and it must be present on a bootable partition; it may be a hidden file. This message appears if the directory entry for OS2BOOT cannot be found in the root directory of the boot drive.
A disk-read error occurred. This means exactly what it says. There was an error (generally hardware) while attempting to read the disk during the loading of OS2BOOT, the second stage boot program.
Insert a system diskette and restart the system. This is merely an advisory message.

Back to Tavi OS/2 main page

Last Updated: 7th November 2004
© 2004 by Bob Eager, Tavi Systems