Return to BSD News archive
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
Subject: Linux/386bsd on a diskless workstation
Message-ID: <C5sACr.Jp2@sleeper.apana.org.au>
Date: Tue, 20 Apr 1993 13:19:37 GMT
Organization: Desolation Road Railfan BBS
Lines: 97
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.
(My evidence for this distinction is simply that if the above weren't
true, RPLODI would be unneccesary - it stops the ODI driver from resetting
the network card (and thus stuffing the server connection) when it is
loaded by AUTOEXEC.BAT. If the whole image were loaded, it wouldn't
matter and RPLODI would be non-existant.)
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
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.
(My evidence for this last assertion is this: I built a boot image without
RPLODI and then attempted to boot 16 machines from it. 3 started to boot
and locked up when NE2000 loaded, the other 13 reported that no server
could be found. My tests were actually a little more exhaustive than this,
but this is the thrust of it.)
This last constraint leads me to suspect that the approach of connecting
to the server and loading the Linux image from F:\LOGIN may in fact be
the ONLY way to use a Netware server to rboot Linux.
If anyone constructs a loader and Linux boot image of this type (with luck it
should be possible to load a standard boot image?), I have the
resources (and will make the time) to test it.
Two final thoughts:
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.)
2. All of the above is equally relevant for 386bsd, thus
the cross-post and changed subject line.
>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?
>To quote a silly robot - INPUT!
My machine's namesake! (RSN I'll be raz@number5.apana.org.au :-))
>The Fluffy Rabbit rides again
Hmm...
--
Bye for now.
- Raz. (Roland Turner)
raz@sleeper.apana.org.au VK2ZRT Raz@3:712/413.1 (OH) 61 2 319 5700
--
Bye for now.
- Raz. (Roland Turner)
raz@sleeper.apana.org.au VK2ZRT Raz@3:712/413.1 (OH) 61 2 319 5700