*BSD News Article 14948


Return to BSD News archive

Xref: sserve comp.os.386bsd.misc:211 comp.os.linux:35554
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!gatech!news.byu.edu!cwis.isu.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Linux/386bsd on a diskless workstation
Message-ID: <1993Apr22.214040.27674@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University  (Ogden, UT)
References: <C5sACr.Jp2@sleeper.apana.org.au>
Date: Thu, 22 Apr 93 21:40:40 GMT
Lines: 121

In article <C5sACr.Jp2@sleeper.apana.org.au> raz@sleeper.apana.org.au (Roland Turner) writes:
>hart@flash.pax.tpa.com.au (Leigh M Hart) writes:
>
>>In a "DOS" based network, diskless workstations boot (either with special
>>software or a firmware chip in the network card) from a server.  The server
>>downloads via ethernet a boot image file (previously setup on the server)
>>which the PC then uses as a virtual drive A.  The PC then boots from this
>>disk image, which then sets up all the network o/s specific stuff in the 
>>config.sys and autoexec.bat that resides in the boot (disk) image.
>
>This is not strictly correct (at least not if the server is running 
>Netware 3.11 and thus by implication (I assume) all other Novell boot 
>PROMs.): In fact, a DOS image is loaded (any version - depends what 
>was used to generate the boot disk file) with some sort of trick that 
>causes attempts to access the A: to be rediredted to the server. 

It's a virtual A: drive.  The reason for the lockup is that a small IPX
stack is brought up by the boot ROM with a drive A: redirector to the
image on the NetWare server; when you reset the card, the connection is
lost using the ROM stack.

The simplest way to switch from the ROM stack to a DOS-based stack is to
use RPLODI (not an option when 386BSD or Linux resets the card during
probe or boot) or to copy all of the files you are interested in to a
DOS RAM disk and boot from there (DOS has a hard time with losing even
the smallest amounts of memory to a RAM disk because of its 640K limit).
But copying the autoexec.bat, config.sys, and other files to the RAM
disk, and then cd'in over to the RAM disk and continuing with the copy
of autoexec.bat (batch files are always read from the current directory
and current disk) will allow you to boot without RPLODI.  The main issue
then is whether or not you can recover the RAM for use by DOS; many of
the modern RAM disk programs will allow you to empty out the RAM disk
and will automatically recover space.

The problem of reset on driver load is precisely the problem of loading
a driver for one packet frame type from a server using boot ROMs that use
another packet frame type... the connection is lost when the card
configuration is changed, and the batch file can't continue to be read.

>To make what you are suggesting work it would be EASIER to write a DOS
>boot loader for Linux, place the bootloader (and Linux boot image) in the
>server's login directory, then have an AUTOEXEC something like this:
>
>	LSL
>	RPLODI
>	NE2000
>	IPXODI
>	NETX
>	F:
>	LINUX -flinux_boot_image

This will fail unless the image is read in it's entirety over the network
before it starts to run, and the image must be placed in memory at a
location that doesn't interfere with the operation of the download.  This
is the first good argument I have heard for a DOS boot-loader for 386BSD
or Linux... but I would change the process as follows:

	LSL
	RPLODI
	NE2000
	IPXODI
	NETX
	F:
	COPYHIGH BOOT_IMAGE
	DETACHER
	EXECHIGH <options>
>The other reason for this is tied up with the number of "open" remote
>boot sessions that a Netware 3.11 server will support - no more than 3.
>I believe that when a remote boot session starts, a special connection
>is opened for this purpose. I suspect that the special status of this 
>connection is dumped when DOS successfully connects to the server (ie
>AFTER NETX loads and runs.) Only 3 connections in this special state may
>exist to a given server at any one time.

Nope, nope, and nope -- there should be no 3-connection limit... however,
you could easily write "DETACHER" above using the APIs and it would make
the connection go away before the 15Min watchdog timeout if you were real
close on the number of connections you had left on a server.

>	1. I suspect that even after using NETX to revert the connection
>		to its standard state, the workstation will remain
>		connected (in Netware's eyes) and perhaps tie up one
>		of the licensed users of the server. This will only 
>		be an issue if someone wishes to boot a lot of 
>		machines of if they are close to their licensed 
>		limit. (NB connections are refused by Netware servers
>		if you attempt to exceed your licensed limit.)

This is true.  There is an idle period, after which watchdog packets are
sent, and after a number of failed consecutive responses (sent closer
together) the connection is dropped and made available.  This is actually
documented in the server docs.  By default, the whole process takes about
15 Minutes, but I believe it can be reconfigured (not looking at docs now,
so I can't tell you exactly).

>>I don't think it would be terribly hard to write a low-level ethernet
>>listening daemon that listens out for the remote-boot requests that the
>>ethernet card sends out - from there it could send a Linux boot disk
>>image to the PC, which would then proceed to boot from that image.  The
>
>:-) I failed to read your initial article carefully before followup. It
>may be trickier than you think - anyone have a copy of the Netware API
>docco?

You'd need an IPX stack on your responder; you may be able to respond from
a dedicated NetWare runing PC with difficulty (after all, there are such
things as standalone print servers).  The easiest thing to do would be
running a file server as the remote boot server so you don't have to
support the subset of the file server services needed by the boot ROMs.


					Terry Lambert
					terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------