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.
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!
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 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:
FDISK /NEWMBRto 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:
LVM /NEWMBR:nwhere n is the drive number (starting at 1 for the first drive).
On DOS, one can use the command:
FDISK /MBRAlthough the boot code may vary, its basic function remains the same:
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 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 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.
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.
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.
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.
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:
Type (decimal) |
Type (hex) |
Description |
---|---|---|
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 3�2 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) |
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.
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.
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.
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.
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.
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.
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.
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 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.
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 | GA | Yes |
MCP1 | XR_C001 | Yes |
MCP1 | XR_C002 | Yes |
MCP1 | XR_C003 | Yes |
MCP1 | XR_C004 | Yes |
MCP2 | GA | Yes |
MCP2 | XR_C003 | Yes |
MCP2 | XR_C004 | Yes |
WSeB | GA | Yes |
WSeB | XR_E001 | Yes |
WSeB | XR_E002 | Yes |
WSeB | XR_E003 | Yes |
ACP1 | GA | Yes |
ACP1 | XR_C001 | Yes |
ACP1 | XR_C002 | Yes |
ACP1 | XR_C003 | Yes |
ACP1 | XR_C004 | Yes |
ACP2 | GA | Yes |
ACP2 | XR_C003 | Yes |
ACP2 | XR_C004 | Yes |
The boot sector is generally updated by using the SYSINSTX command.
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:
HELP SYSxxxxor just:
HELP xxxxat a command prompt, obviously replacing the xxxx with the appropriate number.
Many of the more common boot time error messages are explained here.