Using Netware for a CID Install of Warp

From OS2World.Com Wiki
Jump to navigation Jump to search

Return to The Warp Pharmacy:Software

Last update: 6th November, 1995

Symptoms

When using the Netware Requester v. 2.10 or 2.11, CID remote install fails because PMWIN.DLL cannot be found.

Hardware

Any networked environment supporting Netware.

Problem

Starting with the 2.10 Netware Requester, Novell migrated from full screen VIO messaging to Presentation Manager pop-up messaging. They did this in such a way that the requester code depended upon PMWIN.DLL and would not run without it.

Procedure

Use the Netware 2.01 requester code. This code is shipped with the Netware 3.12 server, and can also be found the Hobbes CD-ROMs from 1993. This code works adequately for the purpose of a CID install.

Notes

A detailed explanation of remote installation using Netware can be found in IBM's red book, OS/2 Version 2.x Remote Installation and Maintenance (GG24-3780-xx). An outline of the procedure for a fully attended install with some personal insight follows:

The Netware server should have the OS/2 utilities in the sys:public\os2 directory and the OS/2 login utilities in the sys:login\os2 directory. A directory structure needs to be created on the Netware server that contains the OS/2 installation diskette contents. You can do this with the seimage.exe utility (found in the CID file on diskette 7) or, if you have Warp on CD-ROM, you can simply xcopy the install images from the CD-ROM to your Netware server.

To build the Disk0 and LT (LAN Transport or Disk1) diskettes use sedisk.exe. Sedisk.exe can be unpacked from the CID file on diskette 7 or in the corresponding directory on the CD. Sedisk.exe has to be executed from a machine already running the version of OS/2 you will be installing.

And with OS/2 2.1 they stopped putting mouse.sys on the LT disk so for an fully attended install you need to put that back on the diskette and in the config.sys.

In the config.sys, set it up so that the OS/2 shell is sysinst2.exe the redirected install image drive. (Note: Sysinst2.exe is the attended install program, rspinst.exe is for unattended response file driven installs.) Then use a call statement to run a command file that will map the appropriate drives. When the resources are set up correctly the .cmd file exits and sysinst2.exe takes over.

For Windows support with Warp w/o WinOS2, you can copy all the Windows install diskettes onto a directory on the server. Then, when the install program asks you for the individual Windows diskettes to be put into drive a:, simply change the "A:\" to the network path of your Windows directory. For example if you are installing OS/2 from z:\warp, you could have the Windows install diskettes on z:\win31. The install program will beep at you and ask you to put the next Windows install diskette into z:\windows, simply press the enter key and the install program will find the files it is looking for. The beeps are annoying, but it works.

*** OS2_SHELL line *******
REM set os2_shell=cmd.exe  /* original line/*
set os2_shell=z:\warp\disk_1\sysinst2.exe z:\warp
**** z: is the drive where the install image is stored *****

**** added lines to the config.sys ****
device=\mouse.sys

DEVICE=\LSL.SYS
DEVICE=\token.SYS
device=\route.sys board=1
DEVICE=\IPX.SYS
DEVICE=\NWREQ.SYS
IFS=\NWIFS.IFS
RUN=\NWDAEMON.EXE

call=cmd.exe /k loop.cmd
************ end of config.sys added lines ***

*********** loop.cmd *****************
@echo off
set path=%path%;l:\os2;z:\warp\disk_1;z:\warp\disk_2;
set dpath=%dpath%;l:\os2;z:\warp\disk_1;z:\warp\disk_2;
set sourcepath=z:\warp

rem sys:cid\warp is where the warp install images have been put
rem put map.exe on sys:loing\os2 or the LT diskette

echo use a login id with appropriate rights to the sys:cid directory
map z:=fs1/sys:cid

if errorlevel 0 exit

echo.
echo problems with LAN connectivity
echo break out of this cmd file and use t2.exe to
echo examine and edit config.sys or appropriate files
echo.
pause

*********** end of loop.cmd *********

************** list of minimal Netware requester files****
nwconfig.dll
ipxcalls.dll
nwcalls.dll
lsl.sys
token.sys (or the corresponding OS/2 ODI driver for your adapter)
route.sys (if using token ring in a source routed environment)
ddaemon.exe
nwdaemon.exe
nwreq.sys
nwifs.ifs
netapi.dll
ipx.sys
nwreqos2.msg
net.msg
neth.msg
************** end of list **********************

************** syntax *********************
SEIMAGE /S:<drive> /T<Drive><Path>
     example: seimage /S:A: /T:Z:\warp

SEDISK /S:<source path> /T:<target drive>
     example: sedisk /S:z:\warp /T:A:
****************************************
List of relevant IBM redbooks
GG24-3780 OS/2 V2.0 and V2.1 Remote Installation and Maintenance
GG24-3781 Automated Installation for CID Enabled ES, LAN Server V3.0 & NTS/2
GG24-3783 Automated Installation for CID Enabled OS/2 V2.x
GG24-3977 CID for RIPL, TCP/IP and Novell NetWare 3.11 Environments
GG24-4073 Workstation LAN File Services/VM LANRES/VM AS/400
GBOF-2224 OS/2 Version 2.0 Remote Installation and Maintenance
GG24-4295 OS/2 Installation Techniques: The CID Guide (Latest red book - Dec '94)

One thing I noticed with Warp was that it was migrating extraneous lines from the config.sys on the LT diskette into the the config.sys of the installed OS/2. So I have gotten in the habit of making as few changes as possible to the config.sys created by sedisk.exe and putting that function into my loop.cmd. E.g. set sourcepath, path and dpath changes go in the loop.cmd.

Another thing I've done is avoid the login scripts. I've found that LAN administrators tend to make changes to their login scripts that can screw things up for the LT diskette. So I either use the s parameter to define a local script or just use the map command and not login at all.

After the graphical phase of the install is over - and before you reboot, you can take advantage of the Warp install's ability to multitask by running the Netware 2.11 install from the server.

There is a caveat here. Sysinst.exe will migrate the NW 2.01's dlls on to the root of your install drive and these will not be cleaned up until the first reboot after the completion of the install. If your next bootup is as a full-fledged Netware 2.11 requester the 2.11 requester will grab the 2.01 dlls in the root on bootup in preference to the 2.11 dlls in the Netware directory. This cripples the requester and locks the dlls in the root as being in use - so you can't delete them.

So when doing the requester install, save the config.sys the Netware 2.11 install creates as config.lan. After the next install, cleanup is done automatically, then copy the config.lan to config.sys and boot up as a Netware requester the next time 'round.

If you install the Netware requester the way descibed above, it builds its folders and objects on the maintenance desktop. You may want to migrate them to your production desktop.

By Matt Hickman

Return to The Warp Pharmacy:Software