Return to BSD News archive
Xref: sserve comp.os.386bsd.misc:234 comp.os.linux:35997
Path: sserve!newshost.anu.edu.au!munnari.oz.au!ariel.ucs.unimelb.EDU.AU!werple.apana.org.au!posgate!pos.apana.org.au!pos!sleeper!raz
From: raz@sleeper.apana.org.au (Roland Turner)
Newsgroups: comp.os.386bsd.misc,comp.os.linux
Subject: Re: Linux/386bsd on a diskless workstation
Message-ID: <C62u58.3Du@sleeper.apana.org.au>
Date: Mon, 26 Apr 1993 06:03:06 GMT
References: <C5sACr.Jp2@sleeper.apana.org.au> <1993Apr22.214040.27674@fcom.cc.utah.edu>
Organization: Desolation Road Railfan BBS
Lines: 104
terry@cs.weber.edu (A Wizard of Earth C) writes:
>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.
Thank you for a more eloquent description of what I meant to say :-)
>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.
Is a situation likely to occur where you wish to remote boot a Novell
client that doesn't talk the default frame type? (Is the concern
wasted orkstation memory? If so, how much? I know this is not so relevant
to Linux/386bsd users - but I'm curious anyway...)
[Roland's proposed AUTOEXEC.BAT.]
>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
Indeed, I assumed that any such loader would run to completion, then
pass control to the kernel of the loaded OS which presumably would
not only be unable to utilise DOS's fileserver connections, but would
probably trash most of DOS in very short order.
>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>
Involves a little more work (all of the last three would ned to be written,
yes?) but I like it. Complete immediate detachment is a little neater than
having to reconfigure your server to accomodate Linux workstations, perhaps.
A further thought - won't that REQUIRE that you utilise a RAM disk, given
that the last command is AFTER DETACHER?
>>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.
There most definitely is a 3 connection limit. Try the following:
Set up a 3.11(20+u) server with a remote boot image (DOS 5.0 - RPLFIX
after DOSGEN of course) with NO RPLFIX in AUTOEXEC.BAT.
More or less simultaneously boot 16 machines with boot PROMS.
(Thinking about it, 4 would be sufficient, as would a 5
user license.)
You wil see the following:
3 of the workstations will start booting and lock up after loading
the MLID driver (eg NE2000)
n-3 of the workstations will report "no fileserver found" and
continually retry
The fileserver will show 3 NOT-LOGGED-IN-YET connections.
The fileserver will also show that these three connections have the
boot image file open and (if present) BOOTCONF.SYS
I am confident that this 3 remote boot session limit exists.
[Leigh M Hart's suggestion about having a machine listen for remote
boo requests then send a boot image]
>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.
Indeed, however if you have no access to a server, a dedicated DOS PC
would be the simplest option - an option I'd not even considered.
--
Bye for now.
- Raz. (Roland Turner)
raz@sleeper.apana.org.au VK2ZRT Raz@3:712/413.1 (OH) 61 2 319 5700