DHCP/PXE Boot of Diskless OS/2 Machines From OS/2 Warp and eComStation

From EDM2
Jump to: navigation, search

Original Work by Micho Durdevich


In this note we shall explain how to convert a given eComStation system into a powerful remote-boot server, so that we can remote-boot diskless eComStation and OS/2 Warp computers from such a "server". There are also interesting possibilities in setting up clients with a local HDD, remote-booting from our eComStation server. For example, in such a way we can "install" OS/2 over a non-bootable JFS volume.

The procedure we shall describe here does not depend of any RIPL-type components found in OS/2 Warp Server, and actually it is completely independent of any OS/2 Warp Server stuff. All necessary daemons are found in the TCPIP4.3 package, and the principal files to boot OS/2 diskless from eComStation can be obtained from Q-Systems, as a part of our UAME2 management system.

Let us start by describing, very briefly, the client boot process:

  • After POST, the client network adapter communicates with the boot server and downloads (via TFTP) the boot loader ECSBOOT.COM;
  • The boot loader downloads the machine configuration file, and figures out what are the basic machine configuration parameters;
  • The boot loader downloads (in the client RAM) a kind of OS/2 nucleus--the minimal set of files needed to initiate the boot process properly. Among these files are mini/micro filesystem drivers, MICROFSD.4 and MINIFSD.OS2;
  • A very primitive file system is constructed in the client memory;
  • The control is then transferred to the OS/2 loader, which uses the information from mini and micro FSDs to load the kernel and BASEDEV files, and access some critical DLL and EXEs downloaded in the system memory.
  • Finally, NETWKSTA.200 replaces the mini filesystem driver from the IFS chain, and constructs the full-blown redirected filesystem (using the information supplied in the machine FIT-file). From this moment on, the boot process continues normally.

The redirected filesystem is built over NETBIOS or TCPBEUI.

The above procedure can be easily modified to allow local boot, and then switching to network boot. In such a way we can bypass DHCP/PXE stuff, start the client locally in DOS mode, and then switch to OS/2 dynamically! This requires using a slightly different loader, and an interesting problem appears related to changes that DOS introduces into the original interrupt vector Table. All this is discussed in Appendix A. In Appendix B we have collected basic information on DHCP/PXE booting from Aurora (does not require any UAME2 files).

The methods described here are applicable, with simple modifications, to remote booting OS/2 from Linux/FreeBSD (using SAMBA) and Windows servers.

Server Setup

Defining Shares

We will have to introduce two shares on our remote-boot server: The first and read-only share PXEFILES (to be accessed by all clients) and a read-write share WFILES (where client-specific files should be stored). For each client, the actual redirected filesystem is defined in the corresponding FIT-file. The syntax of these files is almost the same as for diskless RIPL/WSoD requesters. There is one important difference, however: The main share (PXEFILES, in this discussion) is not declared in the FIT file (as the first line), but in the machine configuration file (see below). In such a way we achieve extra flexibility in defining the location of the principal read-only operating system share. In this discussion, the share PXEFILES points to the folder \IBMLAN\DHCP. Both shares should be updated each time the corresponding tree structure is changed.

DHCP Server

The DHCP daemon is started by executing DHCPSD. The main configuration file for this daemon is DHCPSD.CFG, located in the \MPTN\ETC subdirectory. Here is a sample DHCPSD.CFG file:

 servertype pxedhcp

 leaseTimeDefault        120                 # Time in minutes
 leaseExpireInterval     20 seconds
 supportBOOTP            yes
 supportUnlistedClients  yes

 vendor PXEClient
 option 2 2
 option 3 3
 option 4 4
 option 5 5

 option 135 "-i" 

 client 1 0x00025590CA1F        # Options can be specified         
 {                                           # for individual clients...
 option 1                   
 option 3
 option 5 
 option 67 \dhcpboot\bpbatch.B               # If using BOOTP, use BPBATCH.     
 option 135 "-i"                             # Interactive mode!    

Image Negotiation Layer Server

The BINL daemon is started by executing BINLSD. The main configuration file for BINLSD is BINLSD.CFG, by default located in the \MPTN\ETC subdirectory. The Binary Image Negotiation Layer server should be always started after DHCPSD. Here is a sample configuration file:

 bpname dhcpboot\ecsboot.com

 nit 2
 { # Fields can be left blank!

Trivial File Transfer Protocol Daemon

This daemon is started by executing TFTPD C:\IBMLAN\DHCP (assuming here that the eComStation system is installed on drive C). Besides this "root path", there are no other configuration parameters.

Client Setup

Here we shall describe the client setup by discussing two sample configurations: NETBEUI-clients and TCPBEUI-clients running eComStation diskless. Clearly, for this to work properly, both boot server and the client should speak the same network protocol.

In the simplest setup, all client-related files are placed in the subfolder \IBMLAN\DHCP (identifying shares WFILES and PXEFILES, suitable for initial single-client experiments only).

Adjusting OS2LDR

It is strongly recommended to replace the client OS2LDR file supplied with eComStation, by another, somehow simplified, loader executable. This OS2LDR can be found in FixPak.26 (there are 2 OS2LDR files in the full FixPak.26 distribution, the size of the correct OS2LDR is 45056 bytes). This OS2LDR works fine with both remote-booted and HDD-booted eComStation systems.

Main Client Tree

Create a subdirectory uame2 of \IBMLAN\DHCP. Copy (preserving the tree structure) all files that the client will access in read-only mode into this subdirectory. The simplest way to do this is to use a similar HDD-equipped client, on which a full-blown version of eComStation is installed, and then copy the entire contents of the main eComStation drive to uame2 (except OS2LDR, which should be taken from FixPak.26, and Desktop, CONFIG.SYS, PROTOCOL.INI, IBMLAN.INI +other client-specific files, of course).

Principal Configuration Files

For each DHCP/PXE client, there should be a text file of the form <mac-addr>.PXE, where <mac-addr> is the 12-digits hexadecimal MAC address of the client. This file contains basic machine configuration parameters, that should be fixed at the time of PXE-boot. It should be placed in \DHCP\MACHINES\MACADDR subdirectory of the main IBMLAN folder. Here is a sample PXE-file:


Observe that the name of the FIT-file is completely independent of the machine name.

Each client is identified by its name (the command mname), and the accordingly named user should be created at the remote-boot server. This "user" should have read-only privilege to PXEFILES and read-write privilege to WFILES. The command bfile points to the so-called boot block. This is a listing of all files necessary to download into the client memory, in order to boot the machine properly. Boot block files should be placed into directory \DHCP\MACHINES\BBLOCKS. The command qlogo controls the timeout of a beautiful magic square, before the standard eComStation logo appears.

Here is a sample BBF-file, in the case of a client using NETBIOS to connect to the remote-boot server:








The idea is to include all possible files that OS/2 would need before loading the main IFS (in this case, NEWKSTA.200). In particular, all BASEDEV files must be included in the boot block listing. For example, if we are using TCPBEUI as the main protocol, then the boot block file should include:




And for clients that initiate the boot from the network, but continue booting from a local HDD, using a JFS volume (in such a way we can install OS/2 on a non-bootable JFS partition) we would have to include:


The micro filesystem driver MICROFSD.4, mini filesystem driver MINIFSD.OS2, and the OS/2 loader OS2LDR are treated in a special manner by the PXE loader (and therefore they are not listed in the boot block). These files must be stored in the subfolder OS2INIT of \IBMLAN\DHCP.

The command ffile points to the client FIT-file. The FIT-file should not be listed in the BBF-file.

Since NETWKSTA.200 is the principal IFS for diskless systems, the client CONFIG.SYS should begin with the network section. Here is the network section for the NETBIOS-type clients:


In the case of TCPBEUI-type clients we would write:


Here we have assumed that the client is using a network adapter from the Intel Pro series.

Installing the corresponding PXE Loader and Mini/Micro Filesystem Drivers

Our PXE-boot package contains files ECSBOOT.COM (PXE loader for OS/2 Warp and eComStation) MICROFSD.4 (a 4-point entry micro filesystem driver) and MINIFSD.OS2 (the corresponding mini filesysystem driver). Just place these files in the appropriate directories. In the example we discussed above, ECSBOOT.COM is placed in \DHCP\DHCPBOOT subfolder, while mini/micro fsds together with OS2LDR are placed in \DHCP\OS2INIT.

Appendix A: Transforming DOS into OS/2 on the Fly

As we have already indicated, it is possible to modify the boot procedure so that instead of DHCP/PXE calls, the client uses local DOS functions to load the OS/2 nucleus and transfer the control to OS2LDR.

However, a challenging and interesting problem appears here:

Since OS2LDR starts in real mode and uses the interrupt vector table supplied by the system BIOS, it is not possible to initiate it within the standard DOS environment. This is because DOS itself modifies the interrupt vector table, introducing various hooks, together with its own interrupt vector 0x22. Let us recall that the interrupt vector table consists of 256 dword entries occupying first 1024 bytes of physical memory. Each entry gives us the memory address of the corresponding interrupt procedure. The table is initialized by BIOS, to its default values.

The solution to the problem is to save the original interrupt vector table before DOS loads. In order to achieve this, we must either:

  • Modify the DOS boot sector, to save the table before loading the DOS kernel;
  • Write a custom "DOS kernel" without modifying the boot sector.

Here we shall present the second solution, which is somewhat more complicated but does not require changing the boot sector. Our custom DOS kernel will:

  • Copy the entire interrupt vector table to a safe location in extended memory, using Int 0x15.
  • Transfer the control to the original DOS kernel.

Obviously, for this to work as expected, we should not load programs that manipulate extended memory, in any DOS session in which we plan to start OS2LDR (otherwise, the saved interrupt vector table could be accidentally overwritten).

The procedure for patching DOS goes as follows. Let us assume that DOS comes from Win95. Similar procedure works with other versions of DOS (including PCDOS7, for example).

At first, copy the core kernel file KERNEL.NEW (from UAME2 distribution) into the root directory of the DOS partition. Furthermore, save the original boot sector in a file, say w95boot.sec. Binary edit this boot sector file, and replace "IO.SYS" by "IO.WIN". Rename the original IO.SYS into IO.WIN. Then execute:

copy /b kernel.new+w95boot.sec io.sys

Now the system should boot normally into DOS, however the original interrupt vector table will be saved, as required. After patching DOS in such a way, we can proceed in a very similar way as in the case of DHCP/PXE boot. Instead of the PXE-loader ECSBOOT.COM we should use a different one, it's ECSBOOT2.COM within UAME2 package. This is a DOS program that will proceed in similar way as the PXE loader, creating a temporary "RAMDrive" and placing the files from the DOS partition there. Before transfering the control to OS2LDR, our DOS loader will restore the original interrupt vector table. From this moment on, the boot process continues in the same way as DHCP/PXE version. Further important points:

  • All variables coming from *.PXE files should be defined as standard DOS variables.
  • The boot block should include OS2LDR and mini/micro filesystem drivers (no OS2INIT directory).

Appendix B: Using Aurora as a Boot Server

The confuguration for DHCP, BINL and TFTP servers is the same as discussed in this article. The PXE boot loader is the file RPLBOOTP.SYS, while the micro and mini filesystem drivers are BPUFSD.SYS and BPMFSD20.SYS respectively. By default, these 3 files are placed in \RPL\DOS\DHCPBOOT subdirectory of the main IBMLAN folder.

The following are the main differences between a "pure" OS/2 Warp Server setup, and the one described in this article.

At first, the main share (for read-only files) must be always named RPLFILES. Naturally, this should be also reflected in the client FIT file.

Secondly, instead of the <macaddr>.PXE file, we should construct files of the form yyyyyyyy.INF, where yyyyyyyy are last 8 digits of the client MAC address. For each client, this file should be placed in the subdirectory \RPL\MACHINES\MACADDR\xxxx, where xxxx are the first 4 digits of the client MAC address. Each INF-file is basically a listing of the files the client needs to download in memory from the DHCP/PXE server. There is nothing similar to OS2INIT folder, so the loader and micro/mini fsds should be listed there. The first line of the file, however, must be of a very particular form:

<mac-addr> <clientname> <ffile-location> ~ <servername> <boot-drive>

To simplify further the management of INF-files, WSOD designers introduced yet another listing file, the name of which is of the form BPCOMMON.zzz, where zzz=ISA, MCI or some other 3-letter combination. This file must be listed in the client INF-file. It defines the common files for all clients belonging to a certain class (and the class is identified by the file extension: ISA, MCI or something else). Only one BPCOMMON file can be included in the main listing. More information can be found in WSOD Administration Guide.