The CD Boot/2 home page

What is CD Boot/2

• the boot process continues to boot from the first harddisk instead of the removeable media

• the boot process continues to boot from the removeable media if you press the spacebar within a configurable period of time

Beginning with version 1.40 it should be possible to apply the same procedure on FAT-based removeable media that were not written by OS/2 but e.g. DOS. I strongly recommend to read the documentation as there is no guarantee that it will work, though according to my test it likely will (at least when 512-Byte bootsectors are used).

With such a CD-ROM you only have to ensure that during the initial boot process you press the spacebar to continue booting from the CD-ROM, for all subsequent reboots that are required during OS/2 installation you can just keep the CD-ROM inserted in the drive. A bootable OS/2 CD-ROM modified/created with CD Boot/2 will automatically continue booting from the first harddisk (which is what the BIOS would do if no bootable CD-ROM had been inserted into the CD-ROM drive), you no longer would have to care to remove and reinsert the CD-ROM timely during the phases of the installation process.

That means that if you press the 2-Key within the next (in this example configured to) 10 seconds (of course the countdown to 0 runs in real-time), the boot process continues to boot from the removeable media (probably a CD-ROM), or if you let that period expire or press the 1-Key, CD Boot/2 will continue to boot from the first harddisk.

To boot from the selected media (first harddisk in above example) you can also use the Enter-Key or to boot from the not selected media (removeable media in this case) you can also use the Spacebar-Key, alternatively.

So to install OS/2 from a bootable OS/2 CD-ROM prepared with CD Boot/2 you would just press the spacebar when the CD-ROM is booted to begin the OS/2 installation (possibly also for the second reboot too if you haven't run LVM before), you then just keep the CD-ROM inserted in the drive and let the period expire so that the first harddisk is booted.

Above screen was captured after the Spacebar was used to request CD Boot/2 to continue booting from the removeable media (one could have used the 2-Key instead), and as the customized instructions (they are just a sample, you can of course insert you own instead) show booting from the removeable media requires to enter a password which has been entered almost completely (just the last letter p is still missing at the cursor postion).

Note! If you want to use CD Boot/2 in a CID (Configuration, Installation, Distribution) environment where you want to run applications unattended, I recommend using the AVIO version CDBOOT.EXE instead of the PM version CDBOOTPM.EXE, because the first will not wait for any user input, whereas the second version will display message boxes waiting for the user to click them away in case of errors during execution. It will also wait for the user to close the application. However, both versions will set the return code appropriately.

Using CD Boot/2

This page concentrace on creating bootable OS/2 CD-ROMs, as this page is complex enough the details of using CD Boot/2 have been excluded here.

That page also allows you to download CD Boot/2 including its sources!

How OS/2 boots

In order to get an idea what CD Boot/2 does under the covers you first need to know how OS/2 boots from a removeable FAT media, a diskette drive being the most prominent example. The following things happen (using the same approach as in 1981 when IBM initially released the first IBM PC):

1. After you have powered on your PC or you have reset it via ALT+CTRL+DEL, BIOS (Basic Input Output System) gains control running in Real-Mode (so everything at this time happens within the first 640kB or memory) of Intel and compatible processors.

2. BIOS loads the absolutely first sector from the removeable media at the memory location 0000:7C00 and checks if that sector is a valid boot sector (a valid boot sector, as a valid partition table, ends with 0x55AA in the last 2 bytes).

3. If a valid boot sector was found, BIOS transfers control to it by jumping to 0000:7C00. A vaild boot may be created by DOS, OS/2, LINUX, WIN NT, W2K, ... but we concentrace on OS/2 here.

4. A OS/2 boot sector on a removeable media sets and checks a few things and tries to load the FAT (File Allocation Table) into memory at 1000:0000. Then the FAT is checked for the entry of the file "OS2BOOT " (and that file is different between FAT and HPFS drives, but HPFS can't be booted from removeable media anyway, so we can safely ignore that).

5. If "OS2BOOT " can be found in the FAT, the boot sector code loads the file "OS2BOOT " (the spaces are correct, as FAT has a 8+3 naming convention and shorter names are stored with padding blanks in a FAT) into memory at 0800:0000 and transfers control to it by jumping to 0800:0000. The stack typically points to 0000:7B00 then. If anything fails, then the famous OS/2 !! SYS02025 and OS/2 !! SYS02027 messages (which under DOS used to be Non-System disk or disk error. Replace and press any key when ready) are displayed. OS2BOOT must not be fragmented! CD2BOOT will display CD2BOOT is fragmented - System stopped! Press ALT+CTRL+DEL to reboot! when it detects being not written (by CDBOOT/CDBOOTPM) or loaded (by BIOS) correctly. In doubt I recommend you to run a defragmentation program. The requirement that the boot sector can not load a fragmented file is an inherent limitation, because the boot loader must fit into the 512 bytes of the boot sector and there is not enough space to handle fragmentation.

6. OS2BOOT (which on FAT is just a loader whereas on HPFS it is a Micro HPFS-Filesystem driver and loader) then continues the boot process by loading OS2LDR, the OS/2 loader which then loades OS2KRNL, the OS/2 Kernel.

How OS/2 boots after CD Boot/2 has been run

After you have run CD Boot/2 against a bootable removeable FAT media, the boot process is enhanced with a few steps which of course do not cause any harm to any other media. The following things happen:

1. Again, the starting point is in the BIOS running in Real-Mode.

2. Again, the absolutely first sector from the removeable media is loaded at the memory location 0000:7C00 and verified.

3. Again, control is transferred to 0000:7C00 by BIOS.

4. Again, the FAT is located and loaded into memory at 1000:0000. Now however, instead of searching the FAT for the entry of the file "OS2BOOT ", the boot sector code searches for entry of the file "CD2BOOT ", which is a small file that CD Boot/2 has added to the removeable media.

5. If "CD2BOOT " can be found in the FAT, the boot sector code loads "OS2BOOT " into memory at 0800:0000 and transfers control to it by jumping to 0800:0000. If anything fails, then the famous OS/2 !! SYS02025 and OS/2 !! SYS02027 messages are displayed.

6. CD2BOOT which is the additional step added to the boot process by CD Boot/2 then displays its messages and waits the configured period of time for the user to press the spacebar.

7. Depending on the user selection, CD2BOOT does either:
   • move the original OS/2 boot sector (the one that looks for "OS2BOOT ", and which CD Boot/2 has copied into the file CD2BOOT) to the memory location 0000:7C00 and transfers control to it by jumping to 0000:7C00.
     Again, CD2BOOT must not be fragmented! As CD2BOOT is larger than OS2BOOT it is more likely that it will be fragmented, to be on the safe side just run a defragmentation program after CD Boot/2 has been run! The media will not boot if CD2BOOT is fragmented! CD2BOOT will display CD2BOOT is fragmented - System stopped! Press ALT+CTRL+DEL to reboot! when it detects being not written (by CDBOOT/CDBOOTPM) or loaded (by BIOS) correctly.
     The original OS/2 boot sector code then continues to boot from the removeable media as outlined above (by loading OS2BOOT and transfering control to it, which then loads OS2LDR and finally OS2KRNL.
   or
   • load the partition table of the first harddisk at memory location 0000:7C00 and transfers control to it by jumping to 0000:7C00. Note, if no removeable media had been inserted into the drive, BIOS would have started to load the partition table of the first harddisk.
     Thus, with CD Boot/2 the effect as if having no bootable removeable media inserted can be achieved while still having inserted a bootable removeable media!

How DOS (or any FAT based boot loader) boots after CD Boot/2 has been run

First, how do you run CD Boot/2 against a FAT-based removeable media (e.g. written by DOS):

1. You can run CD Boot/2 against a removeable media that has been FAT-formatted by an operating system other than OS/2 as you would if the media had been formatted by OS/2.

2. However, you can run CD Boot/2 only once against that media, that is, if you need to rerun CD Boot/2 against it, you have to format it with the operating system before. Otherwise you won't destroy that media, but it will not boot (due to the limitations on how the boot process is modified to be partly based on OS/2).

3. If you have run CD Boot/2 against that FAT-base removeable media, you will receive the famous OS/2 !! SYS01475 and OS/2 !! SYS02027 messages instead of the usual e.g. DOS messages you might know: Non-System disk or disk error and Replace and press any key when ready.

Second, what does CD Boot/2 differently for a FAT-base removeable media like e.g. written by DOS compared to an OS/2 formatted media:

1. If CD Boot/2 detects that the removeable media is FAT-based, but not formatted with OS/2, it will replace the bootsector by a modified OS/2 bootsector. It will also patch the original bootsector found on the removeable media into CD2BOOT, and will write that file onto the removeable media.

   And that logic causes the limitation that you can run CD Boot/2 only once against a non-OS/2 formatted removeable media. If you would run it a second time, CD2BOOT will be patched by the modified OS/2 bootsector that CD2BOOT has installed in the previous run as the bootsector, instead of the orginial non-OS/2 (e.g. DOS) bootsector.

2. When that modified OS/2 bootsector gains control, it will load the CD2BOOT modified in above step from the removeable media and passes control to it.

3. The code within CD2BOOT will then display the same boot menu as you already know from OS/2, giving you the choice to continue booting from the removeable media (if you press the Spacebar before the timeout period expires) or continues booting from the first harddisk.

4. If you chose to continue booting from the removeable media, the code within CD2BOOT will load the original non-OS/2 FAT-based bootsector and passes control to it. It is then up to that bootsector code what will happen further, e.g. for DOS it will start booting DOS.

And third, some suggestions on where you might want to run CD Boot/2 against a non-OS/2 formatted FAT-based removeable media:

• You want to create a bootable DOS CD-ROM which you use to install DOS or to backup/restore partitions with tools like Partition Magic or Norton Ghost from a bootable DOS CD-ROM.

• You may want to create a bootable WINxx CD-ROM (it is quite possible to create a bootable CD-ROM where you use the bootable WINxx installation diskette as the bootimage for a CD-ROM, and to avoid swapping the CD-ROM during each reboot in the installation process, you might want to modify that diskette (hopefully a copy of it!) with CD Boot/2 previously).

• You want to make a bootable CD-ROM booting from an updated Linux boot diskette (AFAIK RedHat bootable diskettes are FAT-based, so modifying them with CD Boot/2 should work).

CD Boot/2 will tell you if it detects a non-OS/2 written bootsector. If it then detects that this bootsector is FAT-based (e.g. written by DOS or Linux in VFAT format) it will issue an informational message that it this will likely work. However, if it then detect that the bootsector is not FAT-base, it will issue a warning message that this will likely not work, but still does continue to modify it.

Preparing a diskette to create bootable OS/2 CD-ROMs

A bootable CD-ROM, and for OS/2 this is no exception, the El Torito specification is used. As you can easily find more details on the Internet, here just the principle in short.

During creation of a bootable CD-ROM, you have to specify the image of a diskette which the BIOS (and thus is only available as long a BIOS services are used) of a PC capable of booting from CD-ROMs then uses as a logical replacement of the physical diskette drive A: (in other words, all BIOS accesses to the diskette drive A: are rerouted into that diskette image). Thus, if that image is a bootable diskette, the CD-ROM BIOS replaces the diskette drive A: with the contents of that image as long BIOS is used in the boot process (e.g. if you create a bootable DOS CD-ROM, you will access that diskette image when doing a DIR A: as DOS is just a small add-on to BIOS, if you create a bootable OS/2 CD-ROM you need a special driver so that that diskette image is still used when BIOS services are no longer available, and the OS/2 drivers CD_BOOT.FLT supplied by IBM or DANIBOOT.FLT supplied by Daniela Engert are such a driver)..

In other words, to create a bootable CD-ROM you have not much more to do than to create a bootable diskette, create an image out of it and specify that image during CD-ROM creation. Usually, that image can be easily achived by imaging a 1.44MB diskette, however as the files required to boot OS/2 do not fit on a single 1.44MB diskette you have to use a 2.88MB diskette to boot OS/2 instead. Creating a bootable DOS CD-ROM, a 1.44MB diskette is quite enough, and that is also a good starting point if you haven't created a bootable CD-ROM (on a CD-R or CD-RW media) anyway.

Luckily, even as 2.88MB diskette drives didn't became standard, you can use a virtual drive under OS/2 instead, like e.g. from the IBM EWS Package VFDisk. To create a logical 2.88MB diskette drive, you would have to add DEVICE=d:\OS2\BOOT\VFDISK.SYS 4 into your CONFIG.SYS.

You can use the IBM EWS SAVEDSKF and/or LOADDSKF to fill that virtual diskette drive from an image or to create an image out of the virtual diskette drive. Under OS/2 you have another way to test if your virtual diskette is really bootable by creating an Image File of a DOS Startup Diskette with VMDISK, which is part of OS/2 to boot special DOS versions (of course a bootable OS/2 diskette image will finally fail somewhere while loading OS2LDR or OS2KRNL as OS/2 isn't really a DOS, but all steps of the boot process, including the modifications done by CD Boot/2, mentioned above can be tested that way!). Just use the command VMDISK x: d:\CD2Boot.Img to build an Image File of a DOS Startup Diskette out of the virtual 2.88MB diskette drive x: and then start it with DOS from Drive A: which you can find in OS/2's Command Prompts folder.

Alternatively you may test is in a virtual machine such as VirtualPC or under Linux or Windows with VMWare (though it does not support a OS/2 guest, so booting a bootable OS/2 media will finally fail. They once had a beta supporting a guest OS/2 operating system, but that never went into a product, probably due to some pressure from MS as VMWare seems to have close relations to them. You can still use it to test the first steps of e.g. a bootable OS/2 CD-ROM, and while you can download the program from VMWare itself, you can find the necessary cracks (for their non OS/2 support revenge is sweet, that's why I mention the crack though generally I suggest you buy the programs you find useful and are using more frequently than just for test purposes, especially to support the remaining OS/2 vendors!).

Using CD Boot/2 to create/modify a bootable OS/2 diskette for a bootable OS/2 CD-ROM

As said above, a bootable OS/2 diskette requires the use of a 2.88MB diskette, which may be a virtual drive in case you lack of a physical 2.88MB diskette drive (which would be very slow anyway compared to a RAM disk). In principle, there are 2 ways how you can get to a bootable 2.88MB OS/2 diskette (the original one in the configuration IBM ships with bootable OS/2 CD-ROMs):

• If you own Aurora or the Aurora/Merlin Convenience Pack (ACP/MCP) then you have received (beside others) 2 CD-ROMs to install OS/2 from, a bootable OS/2 CD-ROM which after loading the OS/2 Kernel and drivers prompts you to replace it by a non bootable OS/2 CD-ROM containing the OS/2 installation code.

  On those CDs you can find the image of the 2.88MB diskette that is used to boot from CD-ROM. Usually you can find it in the directory \BOOTIMGS, so to extract the image onto a (physical or virtual) bootable 2.88MB diskette, you could run LOADDSKF Disk_0_1.Img x: /y where x: is the (physical or virtual) diskette drive.

• Be sure that the media is not fragmented! If you doubt run a defragmentation program, preferably an OS/2 one that can handle extended attributes (though I doubt that a bootable OS/2 diskette needs extended attributes, so even a DOS defragmentation program should be sufficient)!

You may notice that CD Boot/2 tells that CD Boot/2 has already been run once. That happens when you run CD Boot/2 multiple times against the same media in a (physical or logical) diskette drive, CD Boot/2 will take care of that situation so you can ignore that warning.

In above example, CD Boot/2 was requested to install on drive Q: and CD Boot/2 will configure the period where the user can decide to continue booting from the removeable media or from the first harddisk with 10 seconds.

You can see above that CD Boot/2 detected that the diskette looks like a FAT based diskette without an OS/2 bootsector.

Of course, you can do the same with the GUI version of CD Boot/2 CDBOOTPM!

Some words about the CD_BOOT.FLT and DANIBOOT.FLT filter drivers

The driver CD_BOOT.FLT is somewhat problematic to use, as I'm not sure if it can be freely distributed as some packages do (that's why I do not include it in the CD Boot/2 package), and it's not really documented.

You could of course use DANIBOOT.FLT instead, another great driver from Daniela Engert. It not only implements what the IBM driver does, but has even added flexibility and certainly chances getting support from her are much better then from IBM.

Some things you may consider are from my experience:

• CD_BOOT.FLT is a driver that allows OS/2 to refer to the CD-ROM drive, from BIOS has started booting from, to the same drive letter A: in Protected-Mode as BIOS does in Real-Mode.
  You may have already heard that OS/2 partly boots in Real-Mode (e.g. some types of drivers are loaded in Real-Mode) and switches to Protected-Mode at a later stage in the boot process and still uses the drivers loaded in Real-Mode. It's not too difficult to imagine that if BIOS under Real-Mode simulates drive A: from the bootable image on the CD-ROM that OS/2 under Protected-Mode still must rely on that being valid. CD_BOOT.FLT is a filter driver that continues to represent drive A: from the bootable image on the CD-ROM in Protected Mode (you then can refer to the physical diskette drive A: by using B: instead), while the normal CD-ROM driver still assigns the CD-ROM drive a normal drive letter (that of course can be influenced by the SET RESERVEDRIVELETTER=d: statement).
• Once CD_BOOT.FLT has been loaded 2 things hold true:
  1. Drive A: refers to the bootable image on the CD-ROM
  2. As OS/2 CD-ROM support must have been already loaded, you can refer the the drive letter of the CD-ROM drive (e.g. for loading other drivers from CD-ROM).
  For example, to load OS/2 CD-ROM support you need to specify CDFS.IFS before CD_BOOT.FLT, however if you specify to load the HPFS and JFS filesystem drivers after OS/2's CD-ROM Support and after CD_BOOT.FLT, you can load both drivers from the CD-ROM (thus getting rid of some space from the boot disks).
• If you need to boot OS/2 from more than one disk image (e.g. like MCP/ACP does by having a 2.88MB disk_0_1.img and a 1.44MB disk_2.img), those images need to be adjacent on the CD-ROM, the name of the images however does not matter.
  If the disks are listed in the same order as needed in the boot process OS/2 will boot instead of displaying messages of not being able to operate your harddisk or finding COUNTRY.SYS. CD_BOOT.FLT will only find the next disk image if it immediately follows the previous disk image, no file is allowed in between.
• If you want to have multiple bootable images on the CD-ROM, then I strongly recommend of putting images that belong together into different subdirectories, e.g. make a subdirectories like \BOOT1, BOOT2,...
• On the commandline of CD_BOOT.FLT you have to tell it how many disk images it should expect, and that seems to be counted in 1.44MB sizes. For example the MCP/ACP bootable CD-ROM contains a 2.88MB image containing the contents of the installation diskettes 0 and 1, and a 1.44 MB image of diskette 2, in sum you need 3 1.44MB, thus you need to specify /D:3. For example, if all you need is a single 2.88MB diskette image (as all other things will be loaded from the CD-ROM's driver letter after OS/2's CD-ROM support has been loaded from that 2.88MB image), then you need to specify /D:2.
  If you specify /D:n incorrectly, symptoms are that OS/2 tells you not being able to operator your harddisk or not finding COUNTRY.SYS and the boot halts.

So, here are some examples of the output of isoinfo -i cdromimage.iso -l (the sequence number just denotes the order the data is listed and thus the order the data will be burn onto the CD-ROM, not necessarily that the ordinal number of the files on the CD-ROM) and the consequences:

• The first and second OS/2 diskette images are in the correct order, OS/2 thus can boot:
  1. DISK_0_1.IMG
  2. DISK_2.IMG
• The second image precedes the first one, OS/2 will not be able to boot:
  1. DISK_2.IMG
  2. DISK_0_1.IMG
• Another image (e.g. bootable DOS image) is between the first and second image, OS/2 won't find OS/2 code on it:
  1. DISK_0_1.IMG
  2. DLS.IMG
  3. DISK_2.IMG
• Similar to above, if a file is between the first and second image, OS/2 won't be able to boot too:
  1. DISK_0_1.IMG
  2. DISK_1.DOC
  3. DISK_2.IMG

What CD Boot/2 does

CD Boot/2 (with the executables CDBOOT and CDBOOTPM) performs the following things after it has started up:

1. CD Boot/2 prompts the user (when running interactively, otherwise the drive specified on the commandline is taken instead) which removeable media should be modified by CD Boot/2 and recommends the drives CD Boot/2 thinks are removeable. Allowed are A to Z.
2. CD Boot/2 prompts the user (when running interactively, otherwise the timeout specified on the commandline is taken instead) how many seconds the period for the user to decide if boot should continue booting from the removeable media or from the first harddisk should last. Allowed are 1 to 60 seconds.
3. CD Boot/2 then reads the boot sector from the removeable media into memory.
4. CD Boot/2 then reads the file CD2BOOT from the directory CD Boot/2 was installed into and replaces a buffer with the boot sector read in the previous step.
5. CD Boot/2 writes the modified CD2BOOT file onto the removeable media the user specified.
6. CD Boot/2 then replaces the original boot sector on the removeable media by a modified one that tries to load CD2BOOT instead of OS2BOOT.

Creating bootable OS/2 CD-ROMs

Now that you have created a bootable 2.88MB media and run CD Boot/2 against it to add the boot menu, you need to burn a bootable OS/2 CD-ROM. While you could use most WIN based CD-ROM authoring programs as they usually support creation of bootable CD-ROMs I hope you don't need to switch to the evil empire as you can also use excellent OS/2 Freeware for the same purpose!

P.S. I'm a native German speaker, so please excuse my intermittent misuse of the English language in my programs and documentations.