Using Netware for a CID Install of Warp
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