VOICE Home Page: http://www.os2voice.org
[Newsletter Index]
[Previous Page] [Next Page]
[Features Index]

July 2000

How to create a [complete] OS/2 system bootable off a CD-ROM

By Alfredo Fernández Díaz ©July 2000

Team OS/2 España : http://www.caballe.com/teamos2
 Original Spanish version of this article : http://caballe.com/teamos2/documentos/articulos/ArranqueCdRom/cdrom.htm


This is a translation of an article first published in the Team OS/2 Spain web page, (http://www.caballe.com/teamos2). It describes an old project of mine, which I started about 18 months ago. I got my first working WPS CD in August '99, but I never thought it would provoke so much interest. This is a project in which I have invested pretty much all of my spare (and some non-spare) time. the original article has changed quite a lot by now, and is somewhat outdated. so, this is not an exact translation, but an updated version.

    In the first place I'd like to make it clear that I have learned everything in this article by the ancient method of trial and error. Therefore, following these instructions could lead to totally unforeseen and absolutely destructive results on your particular system, for which I am in no way responsible. Having given this common sense warning, let's begin.

Why this article?

    The main goal of this article is somewhat diffuse, since it deals with a lot of different issues, but it spins around a common point: how to boot our beloved OS/2 from a CD-ROM.

    Though the instructions accompanying an essential filter by Allen Dermody in cdboot.zip (available at Hobbes) are quite clear and explicit, I'd like to make a few points:

They were in English (a problem I could solve just for Spanish users but isn't that really a point here :) ).
There are several little mistakes made by someone at IBM that were not covered in Mr. Dermody's instructions and may cause any non-English (and many English) OS/2 systems not to be able to boot from a CD. Why? I suspect compilation problems, but please direct any complains on this to IBM ;). For more information on this, see below.

I've just heard of a competitor :) who has acheived a text mode boot system after working for a long time on it. We go far beyond that in this article, with the hope that it will be useful for people out there and save them a lot of time.

In this article we do things that Mr. Dermody (without whom this article wouldn't have been possible) just dreamt of ;)

To reach our goal we need three tools. The first is the filter that allows OS/2 to boot OS/2 from the CD. It is on Hobbes, along with Allen Dermody's documentation in Hobbes, at ftp://hobbes.nmsu.edu/pub/os2/system/drivers/cdrom/cdboot.zip. Without this, we can do NOTHING. The second and third are LoadDskF and SaveDskF are two IBM disk utilities that allow to copy entire floppy images to hard disk and viceversa. As with almost everything we need, we can find them at ftp://hobbes.nmsu.edu/pub/os2/util/disk/loaddf.zip. Patience in huge quantities, a CD recorder and RE-writable CDs. Unfortunately, we can NOT find this in Hobbes ;-)

Some additional tools that we don't really need but are VERY helpful are:

Let the pain begin...

    What we need first is a clear idea of what files we need to boot an OS/2 system. We could use BootOS2 to do it, but the easiest (and longest, but safest) way to do this is to transfer the system to a bootable partition and see what files we need during the boot.

Note: We are using a hard disk partition instead of a floppy drive for space reasons: the minimum required files get easily beyond 1.44 MB in size and I have no idea about how to *manually* split the OS/2 boot into two floppies (please if anyone has an idea on this contact me).

    To do this, we have to type SYSINSTX X:, where "X" is the drive letter we want to boot. The program SYSINSTX.COM is in the OS/2 boot floppies if we don't already have it (I always add it manually to my system). This will create a file called OS2BOOT in the drive we are using to experiment with. As you may know, this alone won't allow us to do anything, since it is just the system boot record. Then we need to add, (using the copy command),the following files: OS2LDR, OS2LDR.MSG and OS2KRNL, which are the OS/2 kernel and loader.

    Now it's time to use WarpBoot so the kernel we are going to experiment with always shows the files it loads. If not, we'd have to press Alt+F2 each time we boot the system, which can get tiring.

    An important thing to keep in mind is that the first IFS loaded in config.sys has to match the partition type of the drive we boot. For example, if we boot an HPFS partition, the first IFS line has to be IFS=HPFS.IFS or OS/2 won't boot at all. As OS/2 FAT support is -unfortunately- hard-coded in the OS/2 kernel, there's no need of an IFS for FAT drives. So if we boot a FAT drive the order in which IFS are loaded is not relevant to the boot process. Incidentally, the OS/2 boot from a CD is made emulating a floppy. Under OS/2 a CD can only be FAT formatted. So it is not necessary to load HPFS.IFS first when booting the CD. The immediate consequence of all this is that the first IFS we'll load will be the CDFS to read the rest of the programs from the CD. But we'll get to this later.

    After many boot-ups in which a new OS/2 system complains about a new file (I strongly recommend all these tests on a maintenance partition; it's faster than a floppy) after adding all, we obtain a list of files like this. This is a list of the ***minimum*** files we need to boot an OS/2 system. Keep in mind the following considerations:

The CONFIG.SYS file for the system we have just created is here. As the file list and CONFIG.SYS have been built simultaneously, this config.sys is optimized from the beginning, except for the SET statements, which I'm not sure if are parsed at the beginning or the end ;-).

    The idea was to obtain the smallest possible OS/2 system that allows us to reach every corner of our system and run some simple text-mode applications. This system has to be as small as posible because we can't assume we have more than 2.88MB of space available, due to some CD-booting issues. But it's not logical to save space getting rid of floppy of hard disk drivers either, is it?

    The minimum system we have built accomplishes these two goals: it allow us access all the filesystems and it's pretty small. What is more, we can execute text-mode apps.

    Unlike for example Windows 98, the graphical environment in OS/2 has nothing to do with multitasking and memory protection, so even from a command line we can do some things at the same time (perhaps winusers still have some things to learn ;) ), e.g. editing the C: config.sys while CHKDSKing D: and so on. Here comes BootOS2. At a cost of just 9604 bytes it brings a protected mode interface, BOS2SHL.EXE, that can switch between sessions. So, we can choose to specify PROTSHELL=CMD.EXE in config.sys and have a real minimum system or PROTSHELL=BOS2SHL.EXE to have something "somewhat" better.    What is more, we can add REXX support to this minimum system just by copying BOS2REXX.EXE, 3 DLLs and a new line to config.sys. Everything at a cost of just 320 kilobytes.    We can even add the most basic tools to work: ATTRIB.EXE, CHKDKS.COM and the other files commented in the file list without reaching the 2.88 MB limit.

    Theoretically, we already have a system that boots, eats up little space and allows us to have a look at any part of our system except for now, serial and parallel ports and some other things. As I said, the system we have right now works. At least mine does. If someone is having difficulties this early he/she should contact me.

    It's time to transfer this system to a CD and see what happens. I had to do a lot of testing, and disturb a lot of people during the making and testing of this system, so I'd recommend to use RE-writeble CDs and have a CD drive able to read them. Needless to say, before transferring the system, add the line BASEDEV=CD_BOOT.FLT to the CONFIG.SYS and add the appropriate file which must be put in their right place.

    If someone has managed to get a *complete* bootable system on a single 1.44 MB floppy or split it in two 1.44 floppies, may he speak now or shut up forever ;). In order to boot an OS/2 CD, it has to contain a 1.44 or 2.88 floppy sector-by-sector image. How can we make such an image of our system?

If the mini system were on a floppy, it's enough to execute SAVEDSKF X: IMAGE.144 /D /A, where X: is the floppy drive we're using and IMAGE.144 the image file. We perform a similar procedure if we are working with a 2.88 MB floppy. If it were on two floppies I have no idea about how to do it. (EXPERIMENTAL PROCEDURE, NOT TESTED: it should be as easy as modifying the CONFIG.SYS line to say BASEDEV=CD_BOOT.FLT /2, creating an image of each of the two floppies and appending them typing COPY /B IMAGE_1.144 + IMAGE_2.144 ALLINEED.288, and we'd have the file ALLINEED.288 ready to go on.) If we're working in a hard disk partition, then we'll have to use Super Virtual Disk, in four easy steps:

-Once installed, we cfg it to simulate a 2.88MB floppy as drive X:.
-Execute SYSINSTX X: to put a system boot record on it.
-Copy to X:\ all of the boot system files *EXCEPT* OS2BOOT.
-Create an image of X: executing SAVEDSKF X: IMAGE.288 /D /A

    Once we have created an image file of our system, we mount it on a CD and mark it as bootable. In the Windows world there are several that allow us to do this, but we're not going to comment on them ;-). In OS/2 we can do this with RSJ, MakeIsoFS + CDRecord or Unite CD Maker.

Let the fun begin...

So, we have an ideal boot system (well, almost) mounted on a CD. Does it boot?. My first try didn't. Neither did my second one. After contacting Al Dermody, the author of cdboot.zip, I turned out to be doing everything OK. The only one difference between his system and mine was language. I tried lots of combinations of files from the original warp 4, FP 5, etc... Finally, with the DLLs and other files from FP10, along with the latest update for IDEASD.EXE, "everything" works OK. So it is very important to keep an eye on the date, time and size of the files in this list. What is more, this does not guarantee that everything works 100% for any other language/FP. As a curious note, the critical DLLs of Spanish warp 4 are always multiples of 256 bytes in size while the en_us ones seem to be arbitrarily long. Why is that? Perhaps someone compiled the files with his feet?

After this first hit, as always, came the second one. During my original experiments I followed Al Dermody's instructions exactly, so in the middle of the boot process the system tried to read things from the CD in the N: drive. Tha main disadvantage of this was that I had to test 5 differet versions of the CD-ROM driver OS2CDROM.DMD before I found one that worked. The others simply didn't load in memory. Although the CDFS.IFS loaded, there were no CD-ROM drives to access and the boot ended abruptly. The funniest thing is that during the previous tests, when everything was loaded from HD, none of the OS2CDROM.DMDs I tested complained about anything. Funny.

The solution I found is what we have done here a priori to avoid problems: the entire system we have built is self-contained, that is, there are no references nor we need external files. The advantage is quite clear: if OS2CDROM.DMD does not load during the boot process, this won't force the system to stop booting because it cannot acces this or that file, but will end up at a command prompt. What we have then is something like the utility disks, but mounted on a much faster disk (but we won't be able to access the CD-ROM drives). From here, if the system boots from CD and we can access the drive letter N:, everything is OK, we can go on. If not, there are more versions of OS2CDROM.DMD to test. The one I'm using (see the list) seems to be quite reliable, but who knows.

A real, complete, WPS? and more...

If we can boot a CD in good condition -that is, being able to access drive letter N:- the only thing that limits us is our imagination. A CD is 650 MB in size, that is far more than any OS/2 system I have ever installed on a HD (not counting data, of course). One can think of a complete graphical system, perhaps WPS, RAM (if there is enough) disks, XFolder, FDisk and why not Partition Magic 3, FAT32 support, a complete system that allows to choose which drivers to load and use as a work platform.

From now on we are going to detail a bit less on the necessary steps, in part because this is a very free field and anyone can find his/her own way to do everything as he/she likes the bestwhich has always been a fundamental part of OS2 users' philosophy, in part because I promised to translate this article a month ago. As always, if someone has any question, please contact me.

The first thing to do is add PM support. How to do it? Obviously, by adding the appropriate files. What are the appropriate files? The author of BootOS2 has the answer. This little wonder of modern technique allows to generate a "mantenance system" for every known version of OS/2, with as many components as we want, like WPS, DOS support, system editor... You can use some other shells for the system, such as MShell, Roman Stanglier's Program Commander/2, etc, but the BootOS2 method has the advantage of not introducing 'external' files. The idea now is to create a system as complex as we want using BootOS2 and then adapt this system what we have learnt while creating our 'poor' command line from the CD.

Once such a system has been generated, there are several considerations to make before getting it onto a CD. The first is that the system on the CD will be frozen, since CDs are read-only media. But we can store several 'system snapshots' in the CD to boot the one we like most. The second is the Desktop. The Desktop uses intensively a special feature of OS/2: the Extended Attributes, which are not supported by the CDFS.IFS. The solution I found is to use a RAM disk to store the system Desktop. If we store the system in the CD in such a way that the Extended Attributes are not altered (for example in a ZIP archive) and then we pass it to the RAM disk before the WPS starts everything is done, right? A baby could do that with one hand tied to his back. Well, it's not that easy, but almost.

The first thing we need is an adequate RAM disk; Super Virtual Disk has several disadvantages: it's not free, though it may block the allocated memory it's not dynamically allocated, and it isn't resizable. RAMFS64, on the other hand works quite well and I can't see any inconvenience. Let's add it to the WPS system created by BootOS2, and modify CONFIG.SYS so that during the boot the drive O: is created, just after N:, which is reserved for the CD drive. All the details are covered later, along with some other things.

Now we have to isolate what is to be stored in the RAM disk. Namely, only the INI files USER_INI, SYSTEM_INI and the Desktop directory tree. The initial INI files generated by BootOS2 are programmed to live in the destination drive, along with the Desktop. Changing this is very easy. As we already know what to do with the RAM disk, we are going to create a BootOS2 system from scratch and program it in such a way that these files live in the RAM disk from the beginning. Once we execute BootOS2, we must disassemble BOS2SYS.INI with INITools (now with INI2Rexx) and change the destination letter for the Desktop to "O:\", our RAM disk. (For non English users, this is a perfect moment to translate the whole system , since BootOS2 creates an English WPS.) We change the INI statements in CONFIG.SYS and we're ready to go. Before booting the BootOS2 system we have to create a ZIP archive to store the INI files and add a line to CONFIG.SYS to decompress them to O:\. Once done, our system should boot perfectly from its partition, copy the INI files to O:\ and create a new Desktop in the RAM disk we have prepared for it. Mine does it. Now, to "freeze" a snapshot of this system once it is configured as you like, all you have to do is a ZIP file form O:\ (it just contains the INI files and the Desktop: 100 Kb at most), overwrite the previous ZIP, et voilà. Next step.

Getting it on a CD. Anyone thought we were done?

Theoretically, now everything is as easy as creating the image of a boot floppy, making so that once CDFS.IFS is loaded everything is read from the N: drive and copying all the files in the BootOS2 system to the CD drive we will see as N:. The system boots, begins to load things, creates the RAM disk, unzips theres the INI files and the Desktop, the WPS starts and trap trap trap trap trap trap trap... ad nauseam.

So much work... what's up now? Fortunately, common sense helps us quickly: if everything works when this boots from HD and everything on the CD is read ok, what is going on? Of course: read-only media. Now the task is quite simple: isolate the files that can't be on the CD. I developed a program (for working, not software) that consisted in copying all the files from the CD to the RAM disk and work from there. Each time a one more file was copied to isolate the cause(s) of this new disaster. After *hundreds* of restarts, CD-burnings, etc (it was very funny, I'd recommend it as anti-stress therapy) I could finally isolate the three files that have to be copied to the RAM disk so everything works. As a detail, I'll say they can't be on the CD AND the RAM disk, or if they are, LIBPATH must point first to the RAM disk. Whatever you like. So, with 2 MB less free memory (I'd love to know why these files can't be in a read-only media; someone at IBM has something to say?), the system is as described here (I hope it is detailed enough):
CONFIG.SYS System files list.

Where, as can be seen, there's a *long* series of add-ons made by me. In short, they are:

Things I've added myself to the system generated by Bootos2:

- Zip / UnZip and RAMFS:

- BldLevel and RXQueue:

- Gradd 0.80 - I didn't write down a list for these ;-). Anyway I planned to changed this and use SDD 7.01SE. After the preliminary test of the version 2.0 of this CD system I found SDD failed with around 95% of the systems tested (cfg'ed as GENGRADD), systems where the GENGRADD 0.80 worked fine, so I'm afraid unless the SciTech people do something we're stuck with GRADD 0.80

- XFolder:


- INF viewer:


- WPS Background bitmaps:


- Additional support for DOS sessions:


- Support to [de]register Plug&Play classes and so on:

- This is to allow XFolder to reboot the computer:


- More things to get a decent help:


- To make OS/2 drives bootable:


- Partition Magic 3.0, now it's dead:


- Icon editor:


- SysBar/2 0.17:


- Advanced Power Management:


- To allow type x|more:


- Initial support for FAT32.IFS:


- UniCode support for FAT32.IFS:


- 3 button mice support:


Before going on, it is possible that such a complex system begins to face compatibility problems... the best thing to do would be to create the files AltF1.CMD, AltF1*.SCR in the boot image, copying those on the hard disk and a CONFIG.X that could be a slightly modified version of the one we used to get a command prompt (but this time it would load files from N: instead of being self-contained). So, we'd have a "safe boot" just in case things too much complicated with the macro-system. Now, let's go on with the decoration.

By now we have a pretty complicated thing, and maybe we don't need everything every time we boot. Wouldn't it be wonderful if we could choose what to load? Of course it would. It can be done. Veit Kaneggieser has developed a little program that added to the OS2LDR (BTW, there are no compatibility issues related to Daniela Engert's patch for this file) will allow us to create a complete menu with as many choices as we want, or almost.

A photograph (my old Spanish menu):

It's not the goal of this article to explain how this program works, so the changes needed in config.sys and the script to assign variables and so on are here.

Obviously, the red options WERE pending things. More on this later.

After all this, I imagine that there will be lots of ideas on what to add to the system and how to do that. We should begin with the items in red. So I want all the suggestions that all you great thinkers can come up with.

By now, before going on to the to-do list, projects and go on, we're going to perform a last acrobatic trick that will allow anyone to use this incredible and wonderful system we've just created by not sleeping for a few months. Just in case someone can't boot from CD (I have solved this in some machines by telling the floppy driver to load anyway), or OS2CDROM.DMD won't load on a certain system, or whatever, we're going to create an OS/2 boot floppy. Nothing new? It is new. Because this is A SINGLE 1.44 FLOPPY that will allow us to boot whatever we have loaded on the CD, and thus being infinitely superior to any 'Utility disks' set.

The method to use is rather simple: from the load of OS2CDROM.DMD and CDFS.IFS on, there's free access to the CD-ROM drive. So, it's useless to have lots of files in the boot image if we can get them from the CD file-system. This allows to free space in the boot system, get below the 1.44 MB barrier and put everything in a 1.44 MB floppy that we can use at any friend's home, in any machine capable of running OS/2. And the best part: it's the complete system, boot menu included. What changes do we need? Floppy files list. Floppy CONFIG.SYS.

Now it's time to convert some people ;-)

The future? the present...

What else? LOTS of things. By the time this article was written originally there were some things planned. They are a reality now. The resolution choice at startup is here. A customized SCSI support is in the way (it is here for me :)). Daniela's EIDE driver is here as a choice. COM and paralell port support was planned. It is implemented now also, though I haven't included any printer drivers yet. We can't use SD GRADD yet, but GENGRADD 0.80 seem to work very fine. I have sound support working for three sound cards and I'll implement MMOS/2 support very soon. I have used this reference that someone left on Hobbes to make an OS/2 system router in a 1.44 floppy. I have adpated it and now I have partial tcp/ip support for any ISA Ne2000 card and some PCI cards. Screenshots of the new menu by Veit Kaneggieser and new filelists coming soon - perhaps in a new article?

There's a limit to the sound cards we can support, because there's nothing like the GENGRADD for video cards, but there is much more freedom for network cards. By now I can only ping any host from a CD booted in a few systems but (and I need some help on this)perhaps soon we'll be able to boot a CD in any networked computer and start a small text-mode FTP client. Perhaps Netscape is too complex, but this FTP client would already be something no one else has anywhere I know of.

I have always thought the main handicap for OS/2 nowadays is the lack of a mechanism that allows to install the system, fixpacks and so on, all-in-one. Someone has already done this and put it at Hobbes. And if we can study the Aurora installer -which boots off a CD- and adapt it to install warp 4...

I'm already studying the way to do it, but I think these are VERY interesting projects...
If IBM can do it, I can do it, and if not, it can't be done.

Last words

Well, this is getting to the end. Not OS/2, of course, but the article. Someone doubts it? Get out of the room, please... Seriously, as anyone can see, this project is a big one; it is beyond the scope and capabilities of a single person, but leads to something which could be very useful and adpatable to almost any person.
I mean, if there's anyone interested in this issue, get up and let's do things.

Just in case it was not clear, or I didn't say it: I want to receive feedback, opinions, suggestions and comments. OK?

The author of this:

Alfredo Fernández Díaz studies Thorical Physics and Electronical Engineering at the Granada University, and owns an internet cafe where everything that can't fail is based on OS/2 warp. Perhaps some day in Aurora :-)

[Previous Page ] [ Index] [Next Page
VOICE Home Page: http://www.os2voice.org