[Home] [Up] [Windows Series] [JFS Way] [Assembly/2] [Unix PXEBoot] [OS/2 PXEBoot] [Configurations]

JFS Way

Installing eComStation on a JFS Volume

1. Introduction

In this article we shall explain how to install a full eComStation system on a JFS volume. Such configurations exhibit a considerable performance boost, over standard HPFS installations. In Download area of this site, there is a highly experimental program to install a fresh eComstation system in such JFS-way. 

Since JFS partitions are not bootable (yet!) we have to use more subtle methods in order to start the system.  There are 2 possibilities in doing this:

•  Use an auxiliary bootable (FAT or HPFS) mini-partition;
•  Start booting from network (RIPL or DHCP/PXE).

The first method requires constructing a small bootable partition, which contains a bare minimum (about 4M) of critical OS/2 files necessary to properly start the system.

The second solution does not require the existence of non-JFS volumes (for example, we can have the only one volume, formatted in JFS). In the managed-client context, we can even take advantage of non-bootability of JFS, as it brings us an additional security feature--there is no way to boot such JFS clients without an authorization from the server.

2. Auxiliary Boot Partition

As already mentioned, this partition is used to "fire up" the system. It can be FAT or HPFS. Using LVM, we should assign a volume and drive letter to this partition. Using SYSINSTX the partition should be made bootable. The program SYSINSTX adjusts the boot sector, the sectors constituting the micro file-system driver (in case of HPFS) and copies the mini file-system driver OS2BOOT into the root directory.

Besides this, the root of the partition should contain the following files:

•  The boot drive letter is "C"
•  The main JFS volume = "D"

The CONFIG.SYS File

We can borrow the CONFIG.SYS file from a standard eComStation install on the same hardware, and change, if necessary, the references of the main OS/2 drive letter to "D".

This is true for almost all drive letter references in CONFIG.SYS. However, the following special lines should refer to files on the boot drive C:

• All DEVINFO statements;
• The COUNTRY line;
• The IFS statements (at least for HPFS and JFS).

Finally we should add C:\OS2\DLL at the end of LIBPATH statement, and add C:\OS2 at the end of PATH and DPATH statements.

The contents of BOOT

Here, we should put all BASEDEV drivers with COUNTRY.SYS. In addition, appropriate SNP-files should be included, together with SNOOP.LST.

The contents of DLL

The following critical system DLLs should be present:

ANSICALL BDCALL32 BDCALLS BKSCALLS BMSCALLS BVSCALLS DOSCALL1
MONCALLS KBDCALLS MOUCALLS QUECALLS VIOCALLS
LVM UCONV UHPFS UJFS
BVHSVGA BVHVGA MSG NLS OS2CHAR SESMGR

If the video is SDD then sddgradd.DLL and sddpmi.DLL should be present in DLL, too.

The contents of OS2

I recommend putting the following files into the main OS2 folder:

JFS.IFS JFS.MSG JFSH.MSG CACHEJFS.EXE JFSCHK32.EXE
OSo001.MSG OSo001H.MSG CHKDSK.COM CHDDSK32.EXE
KEYBOARD.DCP VIOTBL.DCP HPFS.IFS <extra>.IFS

In addition, the SDD video subsystem requires the following files:

3. Main JFS Volume

File/Directory Structure

This is created by simply copying all relevant folders from a standard full-blown eComStation HPFS install. In addition, the root directory of D-drive should contain the binary file IBMLVL.INI, in order for MPTS to work properly. 

Configuration Files

To reflect the main OS/2 drive letter change, we should manually edit a number of configuration files. Some of these files are binary and some are ASCII. The most important are:

By the way, we can use EPM to edit binary files (to a quite limited extent, of course!) the only thing is that the insert mode should be always off and every edit step should be overwrite only.

Variations

Instead of editing the existing OS2.INI and OS2SYS.INI files, perhaps it is better to create the new files starting from the appropriate INI.RC and INISYS.RC scripts and using MAKEINI. Of course, RC-files should be composed appropriately, with the JFS drive letter "D" pre-incorporated. Our experimental installation package contains such RC-files, if you like to play with them manually you should replace all occurrences of letter "@" by the main JFS volume letter "D". Of course, in this case the desktop folder should not be copied, as it gets created during the first WPS-boot.

Another procedure that completely avoids changing the drive letter in various configuration files:

•  Install normally eCS on a third HPFS partition;
•  Boot from the install CD;
•  Copy everything to the JFS volume;
•  Use LVM to twist drive letters between eCS and JFS volumes.

4. Network Boot

As already mentioned, remote-booting allows us to eliminate auxiliary boot partitions, so that the system HDD could be formatted with JFS-only volumes.

RIPL Method

If we are using RIPL to start booting an eComStation system, the role of boot partition is given by a network drive (usually Z) that gets constructed after the boot block processing is completed. This drive corresponds to our boot drive. Its contents can be fine-tuned using FIT configuration files, as usual in RIPL context. 

PXE Way

If we are using DHCP/PXE as the boot method (in which case the boot server could be a standard eComStation system) there is much more flexibility in designing our "boot drive". This is because during the pre-boot PXE phase, a pseudo-drive is being created in the computer memory (see the PXE series for more details on PXE booting from eComStation). This structure should contain all files of our bootable partition, in addition to the files necessary to properly establish network connections later (and remap the "pseudo boot drive" into a network drive, usually Z). An interesting phenomenon is that the critical boot files are used during "pseudo boot drive" stage only, so we can leave the network boot drive Z completely empty. This ensures that the system would use exclusively the files from the main JFS volume, in all subsequent operations.

5. Concluding Remarks

The most common cause of problems with some programs is that they demand the existence of certain files or folders on the boot drive. But our "boot drive" consists of a minimal set of files necessary to properly initiate the boot, and hence such a program would fail. A solution (recommended) is to change the program, if possible, so that it stops worrying about the boot drive. Or (a non-elegant way) simply put the required files/folders in the boot partition :)

If fact, it is much more likely the program itself would work fine, only the corresponding installation routine would get confused. A simple and elegant way to install such programs is to use WiseManager.

Appendix: Some Numbers

Here are comparison results for  a ThinkPad 765D, which is P166 MMX with 88M of RAM. In both cases the standard eComStation installation was used, with all MWAVE drivers loaded. Video driver was SciTech Display Doctor. The time is in seconds.

Here are similar tests performed on an old Compaq Proliant 2000, which is P66 Classic, 160M RAM with 5-disk CPQArray EISA RAID controller. 

[Home] [Up] [Windows Series] [JFS Way] [Assembly/2] [Unix PXEBoot] [OS/2 PXEBoot] [Configurations]

Copyright 2009 Quixo News