Friday, March 10, 2017

20 Years Ago: My Start with Technology Writing

 
...and so it began...

20 years ago, I wrote my first substantial piece of "forensic" technology documentation.

There's a very long back story, which is something that I'll explore in another document.

But the short version is this: My two best friends from University and I put in a bid on a
huge lot of then-obsolete technology from our old school, Concordia University...and we
won!  I think our bid was for $72.00, which was way cheaper than the school would 
have had to pay a garbage disposal company to come and haul the stuff away. Anyway,
the upshot of our victory was that it put one of the computer systems we had all earned
our degrees on in our hands, along with about a ton (literally) of wires, cables, adapters
and other bits and pieces of mysterious and compelling computer and telephone gear.

When it was in service, this machine was called rigel.concordia.ca. While at
school, my friends and I had spent hundreds of hours working on rigel. The staff at
Concordia treated rigel like a precious thing (which it was). This was still back in 
the days of the "high priests" of computing, when computing departments were still
somewhat remote, and the people who worked there even remoter.  You could often
only deal with them through a pane of glass, or a slot in a wall.

When we bought it, rigel was, even then, horribly obsolete (1985 - 1987 tech). Its
hardware was based on a Sun Microsystems 4/380 platform, which was actually 
an upgraded Sun Microsystems 4/280. The staff at Computing Services (that's what it 
was called back then, now it is called IT Services) had tried to keep it alive as best 
they could, and had achieved an absolutely incredible ten year service period. But 
when it suddenly stopped working one day, they left it to sit in the rack.  Eventually, 
they decided it was time to liquidate it, probably to make room for new gear.

Original Configuration (4/280)

Model:          4/280
Codename:       Sunrise
CPU Board:      Sun 4200
CPU:            Fujitsu SF9010 IU
                Weitek 1164/1165 FPU
CPU Mhz:        16.67 MHz
RAM (max)       128 MB
Chassis:        12-slot VME (rackmount) 

Upgraded Configuration (4/380): 

Model:          4/380
Codename:       Stingray
CPU Board:      Sun 4300
CPU:            Cypress Semiconductor CY7C601
                Texas Instruments 8847 FPU
CPU Mhz:        25 MHz
RAM (max):      224 MB
Chassis:        12-slot VME (rackmount) 


Anyway, I was somehow amazed that we now owned rigel, a "real" computer, and I 
was quite eager to put it in service at our company The Imperators Group.  But there 
was a  problem; rigel arrived DOA.   

This is the story of how I got rigel working again, and how it got named sphere.

This document is/was a kind of homage to my alma mater and a big thank you to them
for providing me with the amazing machine that I got to play with work with every day.

At the time this document was produced (1997), there was very little help available online.
I literally spent weeks working on that machine in my basement.  First, I needed to figure 
out how to take it apart, so I could understand why it no longer turned on.  That repair 
was pretty fast:  The machine had blown a fuse in its power supply and needed some
other small stuff done (that I no longer remember) to be able to power up.  

The BIGGEST problem I had was making the machine useful after it powered on.  This
required me to figure out how to get the machine to boot a kernel without a functional tape
drive or disk drive. It took a long time to accomplish this goal and I learned a lot on the way.
One thing that compounded my trouble was that the machine did not have a disk drive, or
the tapes that arrived with rigel were the wrong ones.  In the end, the whole tape thing
was a false trail that wasted a lot of time.  I never did get the tape drive to work.

As a code name for this pre-production project and machine (and from sheer frustration), 
I broke convention with our standing rule of naming our computers after conquerors.  I 
(re)named the machine sphere, after the book by Michael Crichton, which deals with
humans exploring an alien spacecraft, and how that experience ignited the imagination, 
but not always in a good way.  sphere (the computer) was quite a trippy experience for
me.  Up to that point, I had only dealt with Apple, Mac and PC technology, Sun technology
was totally alien to me, hence the code name.  

This is what sphere looked like:



Here are some pictures of a similar machine.  The only difference between this machine

and sphere is that sphere had a tape drive (front) and SCSI ports (back) installed.

Front:


Back:



Here's what the SCSI option installed in sphere looked like:


When we bought it, sphere was the biggest and heaviest computer that any of us had 
ever owned.  It was 12U high, and it weighted over 100 pounds.  

Here's the saga of how I got sphere working again, literary warts and all. 

NOTEThis document was originally formatted or easy reading on a Linux console
(80 x 25) because it was originally prepared for distribution via USENETA more 
beautiful and compact PDF version of this document is also available.


--------------------------------------------------------------------
TITLE:  
--------------------------------------------------------------------
 
HOWTO:  Netboot a Sun 4/380 on NetBSD via Linux
 
--------------------------------------------------------------------
Copyright
--------------------------------------------------------------------
 
This document is Copyright (c) 1997, Graham Leach.
 
--------------------------------------------------------------------
Disclaimer:
--------------------------------------------------------------------
 
I have made every effort to guarantee that the information within this 
document is correct.  However, errors do creep into documentation and the 
written word is subject to interpretation.  Therefore, this document makes no 
claims, express or implied, as to any relevance to any particular purpose or 
pursuit within the realm of human behaviour.  
 
Should you choose to follow the information contained within this document
you do so in the full knowledge that it is at your own risk.  By continuing
to read this document you acknowledge that without proper precautions and/or 
corroboration of the facts proposed herein it is within the realm of 
possibility that the possible results of this document may be anything,
including but not limited to:  Your machine going up in smoke, your spouse 
leaving you, your dog biting you and your machine not netbooting.
 
By continuing to read this information you agree to release me from any and
all possible legal pursuits, of any kind - imagined or real.
 
--------------------------------------------------------------------
Index
--------------------------------------------------------------------
 
Topic 01.  Intent
Topic 02.  Online Resources
Topic 03.  Resources Locations:
Topic 04.  Do resources already exist that concern netbooting Suns?
Topic 05.  What is required to get a Sun to boot over the network?
Topic 07.  A Sample Sun - Hardware Configuration
Topic 08.  A Sun Boot Sequence
Topic 09.  What is This > Prompt?  What's a MONITOR Program?
Topic 10.  What devices can a Sun 4/380 boot from?
Topic 11.  How do I automatically boot the Ethernet Interface?
Topic 12.  What is a PSBL?  Why do I need one?
Topic 13.  Why TWO boot loaders?  Why isn't one enough?
Topic 14.  What's RARP?
Topic 15.  How do ensure that the network interface is functioning?
Topic 16.  My Sun only has an AUI port.  What about a Thin/UTP network?
Topic 17.  How do I verify that RARP requests are being broadcast?
Topic 18.  What do ARP and RARP stand for?  What do they do?
Topic 19.  How do I install ARP on a Linux machine?
Topic 20.  How do I configure ARP?
Topic 21.  How do I know that ARP is working properly?
Topic 22.  How do I install RARP on a Linux machine?
Topic 23.  Building a RARP-enabled kernel
Topic 24.  How do I Compile a Linux Kernel?
Topic 25.  How do I Install a Linux Kernel?
Topic 26.  FAQ this, FAQ that!  Too much reading!  Isn't There a Faster Way?
Topic 27.  Using Modules to RARP-Enable a kernel
Topic 28.  How do I configure RARP?
Topic 29.  What does it look like when RARP is NOT working properly?
Topic 30.  How do I know that RARP is working properly?
Topic 31.  What is TFTP?  What does it do?
Topic 32.  How do I install TFTP on a Linux computer?
Topic 33.  What IS this file that TFTP is being asked to provide?
Topic 34.  O.K.  Now I know what TFTP is looking for.  Where do I put it?
Topic 35.  TFTP Security - A Contradiction in Terms
Topic 36.  What does it look like when TFTP is NOT working properly?
Topic 37.  How do I know that TFTP is working properly?
Topic 38.  What is bootparamd?
Topic 39.  How do I get bootparamd to work on a Linux machine?
Topic 40.  What is NFS?
Topic 41.  How does NFS fit together with bootparamd?
Topic 42.  What happens when bootparamd and NFS do their thing?
Topic 43.  How do I get bootparamd and NFS to work together?
Topic 44.  How do I know that bootparamd is NOT working?
Topic 45.  How do I know that bootparamd is working?
Topic 46.  This is all about Sun and Linux.  Where does NetBSD fit in?
Topic 47.  What is NetBSD?
Topic 48.  Where do I get NetBSD?
Topic 49.  Which NetBSD is the right NetBSD?
Topic 50.  Is it Dangerous to Install Sparc Executables on an Intel box?
Topic 51.  How do I install Sparc NetBSD on a Linux system?
Topic 52.  What is TAR?
Topic 53.  Why do I potentially need a more recent version of TAR?
Topic 54.  Where do I get TAR 1.1.2?
Topic 55.  How do I install TAR 1.1.2 on my computer?
Topic 56.  How do I use TAR 1.1.2 to install NetBSD on Linux?
Topic 57.  What does it look like when everything works properly?
 
-----------------------------------------------------------------------------
Topic 01.  Intent
-----------------------------------------------------------------------------
 
This document details steps required to produce the following results:
 
     "To enable a Sun computer to boot the NetBSD Operating System over
      its Ethernet interface via services provided by Linux host(s)."
 
-----------------------------------------------------------------------------
Topic 02.  Online Resources
-----------------------------------------------------------------------------
 
This is an online document.  Please view the latest version, along
with supporting information, at:
 
http://www.imperators.com/sun/netboot/index.html
 
Here are the other necessary resources required:
 
Component                      Resource                       Note
 
ARP server                     Linux Kernel           built-in
RARP server                    Linux Kernel           must be enabled
TFTP server                    Linux inetd daemon     must be enabled
BOOTPARAMD server              Xkernel package        Must be installed
NFS server                     Linux nfsd daemon      built-in
                               Linux mountd daemon    built-in
TAR archive utility            GNU TAR                must be installed
NetBSD OS                      NetBSD base.tgz        must be installed
 
 
-----------------------------------------------------------------------------
Topic 03.  Resources Locations:
-----------------------------------------------------------------------------
 
The packages necessary to enable these resources are available from:
 
1)  Linux Xkernel
 
    ftp://sol.ctr.columbia.edu/Xkernel
 
 
2)  Tar
 
    ftp://ftp.fsf.org
 
 
3)  NetBSD base.tgz    
 
    ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.3.2/sparc/binary/sets/base.tgz
 
 
4) Linux Operating System
 
    http://www.linux.org
 
-----------------------------------------------------------------------------
Topic 04.  Do resources already exist that concern netbooting Suns?
-----------------------------------------------------------------------------
 
YES. 
 
There are many websites surrounding the topic of netbooting Suns. Sadly,
they almost exclusively concern netbooting Sun 3/50 computers as Linux 
X-Terminals.
 
NOTE:   A Sun 3/50 is not a very powerful computer.  They have little
        Motorola 68020 processors.  They only support a maximum of 16Mb 
        of RAM.  Not very exciting.  But they do make very nice X-Terminals.
        Why?  They have lovely big 19" displays, the "right" keyboard and 
        they are CHEAP.
  
        ftp://sol.ctr.columbia.edu/Xkernel contains a bunch of interesting 
        and useful information on netbooting Sun 3/50s.  The object of the 
        Xkernel project is to enable enterprising computer-type people to 
        recycle Sun 3/50 machines as Linux X-Terminal clients.  
 
While the Xkernel effort doesn't exactly match what this document is trying 
to outline, the resources collected by the maintainers turned out to be very
useful to the writer of this HOWTO.
 
As it turns out, many of the tools presented here are those also used to boot
Sun 3/50 Xkernel machines.  When it comes to netbooting, there is no big 
difference between Sun 3 and Sun 4 series computer.  The difference is WHAT 
they boot, now HOW.
 
-----------------------------------------------------------------------------
Topic 05.  What is required to get a Sun to boot over the network?
-----------------------------------------------------------------------------
 
Before I get into the specifics of how to get a particular Sun to attempt a 
netboot, let's outline the conditions that must be satisfied for any successful 
Sun netboot:
 
1)  You must have a Sun computer.
2)  The Sun network interface must be specified as its boot device.
3)  The Sun network interface must be functioning properly.
4)  The Sun network interface must be connected to the network.
5)  You must have a Linux computer. 
6)  Linux must be functioning correctly.
7)  Linux must be connected physically to the network.
8)  Linux networking must be configured properly.
9)  Linux must have a properly configured RARP server.
10) Linux box must have a properly configured TFTP server.
11) Linux box must have a properly configured bootparams server.
12) Linux must have a properly configured NFS server.
13) Linux must have the required boot file(s) in place for Sun.
14) Linux must have the required Operating System in place for Sun.
 
-----------------------------------------------------------------------------
Topic 07.  A Sample Sun - Hardware Configuration
-----------------------------------------------------------------------------
 
Here is the hardware profile of my Sun:
 
Sun 4/380 
Ethernet Card
32Mb RAM
A Wyse Terminal attached to serial port "A"
 
-----------------------------------------------------------------------------
Topic 08.  A Sun Boot Sequence
-----------------------------------------------------------------------------
 
Here is what I saw when I booted my Sun on for the first time:
 
_______________________________________________________________________
        FDX         8:01a    1-  1
-----------------------------------------------------------------------
EEPROM:  Using RS232 Port A as input device
Selftest Completed.
 
Sun SPARCsystem 3XX
ROM Rev 3.0.3, 32MB memory installed, Serial #15234.
Ethernet address 8:0:20:8:FA:51, Host ID 23003B82
 
Testing 1 Megabytes of Memory ... Completed.
 
Auto-boot in progress...
 
EEPROM boot device... sd(0,0,0)
 
sd: Device not found.
 
_______________________________________________________________________
 
Allow me to explain what is going on:
 
1) The first thing the Sun does when it boots is look for a means by
   which it can interact with the operator.  Once it finds a valid 
   input/output device (this is called the console), it displays that 
   information on the console.  This results in the message "EEPROM: 
   Using RS232 Port A as input device" appearing on the display.
2) The computer then performs a Power On Self Test (POST).  Successful 
   completion of this test is indicated by the message: 
   "Selftest Completed."
3) The computer then attempts to load the Secondary Stage Boot Loader 
   from its default boot device. In this case, the default device is not 
   the Ethernet interface.  It is a SCSI disk.  The fact that it is 
   looking for a SCSI disk is indicated by the message: "b sd(0,0,0)".
4) The SCSI disk was not found, creating a fault condition.  This is 
   indicated by the error message "sd: Device not found." 
5) A fault condition exists.  At this point the Sun boot sequence terminates 
   and the machine requests operator intervention.  This is indicated by the 
   MONITOR prompt ">".  
 
Obviously the first thing that needed to be changed was the default boot 
device.  I wanted my Sun to boot from the Ethernet interface.  
 
Presumably you want to do this too.  Configuring a Sun to automatically boot 
from the Ethernet interface requires that its internal settings be changed.  
Sun computers store settings such as that of their default boot device in a 
special type of non-volatile memory called Electronically Erasable and 
Programmable Read Only Memory, or EEPROM.  
 
Like all Read Only Memory (ROM), EEPROM memory can be programmed.  Like 
all ROM, EEPROM memory retains its values when the host in which it 
resides is turned off.  What distinguishes EEPROM from other ROM memory 
is that it can be re-programmed.  Most ROM technology is a one-shot 
affair and can only be programmed once. If anything changes the ROM chip 
has to be physically changed.
 
In the Sun, EEPROM settings can be changed at the ">" prompt of the 
MONITOR program.
 
-----------------------------------------------------------------------------
Topic 09.  What is This > Prompt?  What's a MONITOR Program?
-----------------------------------------------------------------------------
 
The ">" prompt is the MONITOR program in action.  
 
Just about every computer ships with some kind of MONITOR program, 
although some implementations are more complete than others.  In 
general, think of the MONITOR as a bare-bones OS with small set of 
tasks:
 
1) Perform a hardware system check.
2) Enable interaction between the computer and the operator.
3) Load an Operating System from the default boot device.
 
The Sun MONITOR program is very cryptic and utilitarian.  That is because its 
sole purpose is to prepare the computer for the "real" Operating System - to 
whom it relenquishes control immediately upon load.  When everything goes right 
you don't even notice that the MONITOR is there.
 
-----------------------------------------------------------------------------
Topic 10.  What devices can a Sun 4/380 boot from?
-----------------------------------------------------------------------------
 
There are a lot of boot devices available within the MONITOR program.  
These boot devices can be listed at the MONITOR prompt with the "b?" 
command: 
 
 
Here is what my Sun displays when I enter that command:
 
_______________________________________________________________________
 
>b?
Boot syntax: b [!][dev(ctlr,unit,part)] name [options]
Possible boot devices:
  id:  PANTHER (ipi) controller
  xd:  Xylogics 7053 disk
  xy:  Xylogics 440/450 disk
  sd:  SCSI disk
  le:  Sun/Lance Ethernet
  gn:  Sun Generic Network
  xt:  Xylogics 472 Tape
  st:  SCSI tape
  sr:  SCSI CDROM
 
_______________________________________________________________________
 
As you can see, a Sun can boot from tape, disk, CD-ROM and two different 
Ethernet devices.  That's a pretty astonishing number of choices.
 
There are two ways to boot a Sun.  One is to specify the device as the 
default boot device in the EEPROM, the other is to specify the interface 
at the MONITOR prompt.  Let's look at these choices in turn:
 
-----------------------------------------------------------------------------
Topic XX.  How can I boot a Sun on the Lance Ethernet Interface?
-----------------------------------------------------------------------------
 
One of the boot options listed is "le (Sun/Lance Ethernet)".  Using the 
syntax notation that is displayed at the beginning of the list of boot 
devices to phrase the boot command, use:
 
b le(0,0,0)
 
To instruct your Sun to boot the Ethernet interface.  If your EEPROM has 
been programmed to boot from the first device on the first controller, 
you can omit the 0,0,0 of the boot command and just enter:
 
b le()
 
And it will boot just as if you had typed in the full command.
 
-----------------------------------------------------------------------------
Topic 11.  How do I automatically boot the Ethernet Interface?
-----------------------------------------------------------------------------
 
Automating the boot process so that the Lance Ethernet interface is used 
as the default boot device when time the Sun is started is accomplished 
by altering two values in the EEPROM, at locations 0x019 and 0x01A.  
Here is a listing of the steps I performed to change my default boot 
device from the SCSI disk to the Lance Ethernet device:
 
 
>q 119
019:73 ?? 6C
01A:64 ?? 65
01B:00 ?? q
 
NOTE:   The EEPROM memory location and its value is always displayed 
        when you enter the EEPROM editor by pressing "q" at the MONITOR 
        prompt.  Pressing  without typing any values at the ?? 
        prompt allows you to view the EEPROM value of that location 
        WITHOUT CHANGING it.
 
        Had I not entered new values for locations 0x019 and 0x01A they
        would have remained at values 0x73 and 0x64 - SCSI disk.
 
Refer to the document "Sun3 BOOTROM Page" in your favorite www search index 
to find more interesting values that concern Sun EEPROM (re)programming.  
Much of this section has been derived from that document.
 
NOTE:   The "Sun3 BOOTROM Page" is c Heiko Krupp, 1996.
 
Once the EEPROM has been altered you can restart the Sun by entering k2 
at the MONITOR prompt.  This requests a "cold reboot" from the MONITOR 
program.  You no longer need to power cycle your Sun, unless of course
that is what you want to do.
 
>k2
 
If you do choose to power cycle your machine do it like this:
 
1)  Turn the machine off.
2)  Wait 10 seconds or so.
3)  Turn the machine on. 
 
Either way, when you boot the Ethernet interface will be the default boot
device and you will see the first step of your task completed.  
 
The first step of a Sun network boot looks like this:
_______________________________________________________________________
FDX         8:01a    1-  1
-----------------------------------------------------------------------
EEPROM:  Using RS232 Port A as input device
Selftest Completed.
 
Sun SPARCsystem 3XX
ROM Rev 3.0.3, 32MB memory installed, Serial #15234.
Ethernet address 8:0:20:8:FA:51, Host ID 23003B82
 
Testing 1 Megabytes of Memory ... Completed.
 
Auto-boot in progress...
 
EEPROM boot device... le(0,0,0)
Requesting Internet address for 8:0:20:8:FA:51
/
_______________________________________________________________________
 
Let me describe what is happening.  The Sun is:
 
1)  Loading the MONITOR program from EEPROM
2)  Running self-checks to guarantee machine "ready" state
3)  Executing the Primary Stage Boot Loader (PSBL) Program
4)  Asking for its IP address via a RARP request
 
 
-----------------------------------------------------------------------------
Topic 12.  What is a PSBL?  Why do I need one?
-----------------------------------------------------------------------------
 
Primary Stage Boot Loaders exists to help computers load their Operating 
System.  They are also known as "bootstrap routines".  They are usually 
implemented in non-volatile memory (in our case, EEPROM).  Their sole 
purpose is to locate and load the Secondary Stage Boot Loader and then 
execute it.
 
-----------------------------------------------------------------------------
Topic 13.  Why TWO boot loaders?  Why isn't one enough?
-----------------------------------------------------------------------------
 
The PSBL is not very flexible - don't forget that it has been burned 
into ROM.  It is limited to the devices and routines that existed when 
it was created.  It is limited in terms of space.  ROM and EEPROM memory 
are expensive and small in terms of memory capacity. To address these 
limits someone smart came up with the Secondary Stage Boot Loader (SSBL) 
concept. 
 
A SSBL is implemented in software.  It can be re-written to take 
advantage of new algorithms and devices.  It can be used to extend the 
life and usefulness of the PSBL by expanding upon its basic boot 
process.  The best feature of the SSBL is that it can be maintained 
through software because it IS software.  It can be distributed and 
installed like software.  
 
NOTE:   This solved an old problem.  In older times, installing a more 
        flexible bootstrap routine required operators to re-program the 
        entire thing.  Take it from someone who has keyed in a fairly 
        large bootstrap routine using toggle switches just to add a few 
        more bits of information, SSBL programs are a wonderful idea!
 
-----------------------------------------------------------------------------
Topic 14.  What's RARP?
-----------------------------------------------------------------------------
 
RARP stands for Reverse Address Resolution Protocol.  I will discuss 
what it is once we have guaranteed that the Ethernet interface on the 
Sun is functioning correctly.  Without functioning hardware a discussion 
of RARP is premature.
 
-----------------------------------------------------------------------------
Topic 15.  How do ensure that the network interface is functioning?
-----------------------------------------------------------------------------
 
Chances are your network interface is functioning correctly until proven 
otherwise.  I say this because you may not have any tools to troubleshoot the 
Ethernet card on your Sun aside from the status LED's on the CPU card itself.
 
The only message that the Sun can give you with these LED's is that the box 
is functioning correctly on a hardware level.  This is indicated by the
fifth LED in the series flashing.  This means the system is in a NORMAL
state and that no hardware errors have been detected by the self-check that
the Sun normally executes on power-on.
 
Sun ethernet interfaces don't have status LED's like in the Intel world. 
The only way you can GUARANTEE that the network interface is working right
is to connect it to a network and use another computer to verify that the
Sun is issuing packets onto the network media.  That comes up later.
 
-----------------------------------------------------------------------------
Topic 16.  My Sun only has an AUI port.  What about a Thin/UTP network?
-----------------------------------------------------------------------------
 
You may not be able to connect your Sun to your network physically if it 
has an old Ethernet connector and your network is of a more recent 
variety.  
 
I was faced with this problem.  My Sun featured two Ethernet interfaces, 
but both were of the AUI variety (a fifteen-pin "D" type connector).  
This connector is indicative that the machine came from a Thick-Ethernet 
environment.
 
My home Ethernet environment is either Thin-Ethernet (Coaxial-BNC) or 
Twisted-Pair-Ethernet (UTP-RJ45).  To connect my Sun to the network I 
had to obtain a MEDIA CONVERTER.  My Media Converter came from a local 
computer salvage store.  
 
NOTE:   If you're not lucky like me and have a salvage store nearby, you 
        can obtain a new unit from Black Box at http://www.blackbox.com  
        or hit the Internet and look around for one.  Keywords to use
        are AUI, Ethernet, Media Converter, UTP, BNC.
 
Let me describe to you what a media converter looks like, and what it 
does. My CABLETRON Media Converter is a square box about the size of a 
Big Mac.  It has a fifteen-pin AUI connector on one side and a coaxial 
(BNC) connector on another.  It has a line of LED's on its face.  
 
Here is what is written on it:
 
-----------------------------------------
ST-5XX with LANVIEW(tm)
ETHERNET/IEEE 802.3 TRANCEIVER UNIT (MAU)
FCC ID: F4T4K9-ST-5XX
CABLETRON/DIV OF THE COLLINGSWORTH CORP.
CERTIFIED TO COMPLY WITH CLASS B LIMITS,
PART 15 OF FCC RULES.
SEE INSTRUCTIONS IS INTERFERENCE TO RADIO
IS SUSPECTED.
-----------------------------------------
POWER REQUIRED: DC 10-15V, 3XXmA MAX
NEC 725 2(b) U.L. 910
-----------------------------------------
SQE IS USER SELECTABLE SEE USER MANUAL
 
There is writing beside the LED's that indicate the following:
 
PWR (green)
SQE (unlit)
XMT (flashing green when operating)
RCV (flashing amber when operating)
CP  (red)
-----------------------------------------------------------------------
 
Installation of the CABLETRON Media Converter was simple.
 
1) I turned the Sun off.
2) I connected the BNC connector to the Thin-Ethernet network.
3) I connected the AUI connector to the Thick-Ethernet network.
4) I turned the Sun on.
 
When I powered on the Sun, the power light on the CABLETRON lit up.  It 
glowed a steady green.  The CP light also came on.  It glowed a steady 
red.  When the Sun tries to boot the Ethernet interface the XMT and RCV 
LED's flash.
 
To me the flashing of the LED's showed that the unit was functioning.  
It also showed that the Ethernet card of the Sun was operating properly 
and signals were being issued through the Media Converter to the 
network.  But this was just a guess.  The only thing I knew for sure was
that the CABLETRON unit was detecting and sending Ethernet frames on the
network media.
 
-----------------------------------------------------------------------------
Topic 17.  How do I verify that RARP requests are being broadcast?
-----------------------------------------------------------------------------
 
RARP packets have a signature - the value 0x8035 is in the Ethernet Type 
field of RARP packets.  To GUARANTEE that RARP traffic is flowing on your 
Ethernet network from your Sun you will need to install a "packet 
sniffer" on the Linux box to look for packets with that signature.  
 
There are quite a few "packet sniffer" programs available on the 
Internet.  What these packages do is capture ALL traffic flowing over 
the Ethernet Interface of the machine they are installed on, regardless 
of who the packet is addressed to.  This is quite unlike the normal 
Ethernet mode where traffic not addressed for that particular card is 
ignored.
 
This special mode of the Ethernet interface is called "promiscuous 
mode".  Running a card in this mode represents a VERY big security 
hazard.  Please read the following:
 
***SECURITY ALERT***
 
Do NOT allow users access to packages like sniffit, tcpdump, etherpeek or 
any other Ethernet sniffer programs.  Firstly, these programs run suid root.
This is because they must access the Ethernet device in "raw" mode.  
 
If the user manages somehow to "break" the sniffer program and go to a
shell, they do so as _root_.   Secondly, these programs allow users to
monitor network traffic.  It allows would-be hackers to reconstruct 
unencrypted traffic (like telnet passwords and http traffic).  They allow
users to and "eavesdrop" on all other sessions, even those of root!
 
That said, here is how to use  to detect the RARP broadcast packets
being issued by your Sun.
 
(17)-----> This is the perfect place to put a "packet sniffer" section.
 
Now that we have verified that RARP requests are indeed flowing over the 
Ethernet network, the next logical step is to configure a RARP server to  
be able to answer.  It's time to start discussing the Addressing 
Protocols in the Linux (Unix) world.
 
-----------------------------------------------------------------------------
Topic XX.  ARP, RARP and /etc/hosts.  What's the connection?
-----------------------------------------------------------------------------
 
The connection between them is that all three are implicated in locating, 
naming and accessing hosts on the network.  Most of the time when people 
think of resolving names in the TCP/IP world they immediately think of DNS.  
 
DNS didn't always exist.  In the old days of the Internet there was no need 
for complex name services like DNS.  Every computer in the world (don't forget 
that at one point you could count them on your fingers) just looked at a
local file called /etc/hosts if it wanted to resolve the IP address of another 
machine.  
 
The file /etc/hosts held entries for all of the computers in the world, their 
IP address, and any "nicknames" that they may have.  The /etc/hosts file was 
maintained by people at Stanford University and distributed from that
central place to all the hosts that needed it.
 
(18)-----> VERIFY where uucp came from and where /hosts was maintained
 
This system worked for some time, but failed to scale beyond a certain number 
of hosts.  Soon it was time to re-think the solution.  DNS is the flexible, 
powerful answer to that problem. It solved all of the issues faced by the 
centrally distributed /etc/hosts approach.
 
DNS is complicated.  It is relies on full network connectivity.  It doesn't 
work well during the initial phase of a computer (re)boot when network 
interfaces may be unavailable.  As a result, many machines who use DNS once 
they have achieved FULL network connectivity still use entries in the 
/etc/hosts file at boot time to get things going. This explains why the 
/etc/hosts is still in use even though DNS is now the primary tool for Fully 
Qualified Domain Name (FQDN) to Internet Protocol (IP) address translation.  
 
The /etc/hosts file also gets used for other things.  One of the things that 
it is used for is to support the Address Resolution Protocol (ARP) and the 
Reverse Address Resolution Protocol (RARP). For RARP to work properly, the IP 
address of a RARP client must exist in the /etc/hosts file of the RARP server.
This is because RARP needs an "authority" to consult. The other thing that 
RARP needs is a value to return to the RARP client - an IP address.  
 
You must choose an IP address for your netbooting machine.  
 
For my Sun I chose 192.168.0.150
 
To enable RARP to help the Sun boot, I had to edit the /etc/hosts file 
on my Linux box.  I added an entry for my Sun, as follows:
 
# hosts         This file describes a number of hostname-to-address
#               mappings for the TCP/IP subsystem.  It is mostly
#               used at boot time, when no name servers are running.
#               On small systems, this file can be used instead of a
#               "named" name server.  Just add the names, addresses
#               and any aliases to this file...
#
# By the way, Arnt Gulbrandsen  says that 127.0.0.1
# should NEVER be named with the name of the machine.  It causes
# problems for some (stupid) programs, irc and reputedly talk. :^)
#
 
# For loopbacking.
127.0.0.1 localhost
192.168.0.150  sphere         sphere.network.domain
192.168.0.1    linux          linux.network.domain
# End of hosts.
 
Let me explain the entries in this file:
 
The first entry is for the loopback device.  The loopback device is a very 
special device.  It is used by various kernel processes.  It is used to help 
the machine refer it itself.  DNS uses it.  It's special.  Leave it alone.
 
The second entry is for the Sun machine.  The first value on the line is 
the IP address.  The second value is the name by which I wish the 
computer to be known (The name sphere refers to a movie where a group of 
people attempt to explore and make sense of an alien artifact -  exactly 
what I considered this computer when I got it!).  The third value is a
fuller name (FQDN) of the computer.  As a result the Linux computer would 
resolve either "sphere" or "sphere.network.domain" to the IP address 
192.168.0.150.
 
The third entry is for the Linux machine.  The entry is there so Linux knows 
its own IP address even when named (DNS) is not running.  It is also important 
for an upcoming step that involves NFS and bootparamd.  Due to the
limitations of some of the networking protocols involved in netbooting Suns,
the short name of the computer is sometimes the only value that can be used
- because of the size of buffers being allocated during the netboot process,
the FQDN of a computer can sometimes be too long.
 
-----------------------------------------------------------------------------
Topic 18.  What do ARP and RARP stand for?  What do they do?
-----------------------------------------------------------------------------
 
Address Resolution Protocol (ARP) is a pretty important protocol.  It is used 
for TCP/IP packet delivery.  It does this by performing an important service: 
IP to Ethernet address translation.
 
Let us look at this from the point of a scenario.  Say a machine is acting as 
a router, or "gateway" for some network.  It receives an IP packet with an 
address in the range of the network for which it is responsible, but not
addressed to itself.  To deliver the IP packet, it consults its ARP cache and
looks for the MAC address that corresponds to that IP address.
 
If it doesn't find the MAC address within its internal tables, it sends out
an ARP query.  The ARP query effectively says "Hey!  Whatever machine has
the IP address xxx.xxx.xxx.xxx please tell me their MAC address, I have
something for you...".  The machine for which the packet is destined says:
"If you're looking for IP address xxx.xxx.xxx.xxx you want me.  My MAC
address is XX:XX:XX:XX:XX:XX".
 
The gateway machine then formats a frame based on the media type that the
destination machine is on, puts the MAC address in the appropriate spot and 
releases the frame onto the media.  It also caches the ARP reply in case
more packets for that machine come in the near future.
 
NOTE:   That's one of the reasons why TCP/IP is portable.  While Ethernet 
        addresses are media specific, IP addresses are not.  So TCP/IP
        traffic can flow over such media as Token-Ring, Arcnet, FDDI and 
        bunches of other exotic networking technologies without worrying 
        about media-specific address limitations.  That's one of the most 
        powerful features of TCP/IP in a nutshell.
 
Here's a web citation that discusses ARP and RARP:
 
        http://www.cs.arizona.edu/classes/cs525/manual/node73.html
 
        "D. Plummer. An Ethernet Address Resolution Protocol. Request 
         for Comments 826, USC Information Sciences Institute, Marina 
         del Ray, Calif., Nov. 1982. 
 
         ARP translates IP addresses into Ethernet addresses, and vice 
         versa (i.e., it also implements RARP)."
 
Reverse Address Resolution Protocol, or RARP, does the opposite of ARP. 
RARP broadcasting enables a machine to request its IP address by telling 
the RARP server its Ethernet Address.
 
RARP is a less commonly used facility, especially in a Linux context.  It is 
used primarily to enable diskless workstations (like Sun 3/50 Xterminals) to 
netboot.  As a result it is not ordinarily compiled into a Linux kernel - 99% 
of the time it would add code that would never be used.  In the interests of 
efficiency and kernels that fit within 1.44Mb of space it is usually left out.  
 
Let us make clear what is going on when sphere issues a RARP broadcast, and 
why RARP is so important to the netboot process in general:
 
When ANY computer boots it doesn't know much about itself.  That is, other 
than what is in its non-volatile memory (EEPROM or ROM).  Aside from that 
collection of information, there may be other values in the machine in 
expansion equipment (like network cards) that has been "burned in" 
during its manufacture.  It's pretty bare-bones.
 
NOTE:  One of the things "burned in" to a network enabled machine is the 
        Ethernet Address of its Ethernet Interface.  The Ethernet Address 
        is burned into the Ethernet circuitry during its manufacture.  
 
        Furthermore, Ethernet addresses are guaranteed to be unique because 
        their assignment is governed by a central authority.  Ethernet card 
        manufacturers are given exclusive classes of Ethernet addresses to
        "burn" into their devices.  This practically eliminates the possibility
        of a duplicate Ethernet Address existing in two different Ethernet cards 
        at the same time (barring human intervention or error).
 
A protocol was developed to enable network booting of diskless computers 
based upon using the Ethernet Addresses of that machine.  Why the 
Ethernet Address? The designer(s) of the protocol were very confident 
that no confusion would result over the identity of the netbooting 
client if Ethernet Addresses were used.  They built a framework to 
support netbooting based upon the following assumptions:
 
Another system on the network (say, a server) can respond to a boot 
request (RARP) by using the broadcast Ethernet address as a  "key" to 
identify resources specific to the machine issuing the request.  The 
server could then present those resources to that machine over the 
Ethernet medium because one of the values embedded within the broadcast 
is the destination address.  This mechanism allows one computer to help 
another boot through the use of a single 48-bit number.  Pretty neat.
 
Let's use sphere to illustrate RARP in action:
 
sphere boots and issues the following information over its Ethernet 
interface:
 
"My Ethernet address is 8:0:20:8:FA:51.  What is my IP address?"
 
The RARP server consults its internal RARP cache and responds:
 
"Ethernet address 8:0:20:8:FA:51 maps to IP address 192.168.0.150"
 
The netbooting computer accepts that information.  Armed with its IP 
address, it can now move on to the next stage of its boot process.  It 
uses the IP address it was given to identify itself from that point onward.  
 
Now that the technology has been explained, let's get it working!
 
-----------------------------------------------------------------------------
Topic 19.  How do I install ARP on a Linux machine?  How do I configure it?
-----------------------------------------------------------------------------
 
ARP is one of the rare resources mentioned in this paper that comes without
any thought or effort whatsoever.  ARP is built in to Linux and it takes care 
of itself.
 
-----------------------------------------------------------------------------
Topic 20.  What does it look like when ARP is NOT working properly?
-----------------------------------------------------------------------------
 
Your packets won't get delivered properly.  Your network will be dead.  Ping 
and TELNET will not work.  In fact, nothing will work.
 
-----------------------------------------------------------------------------
Topic 21.  How do I know that ARP is working properly?
-----------------------------------------------------------------------------
 
Your network will function correctly.  Packets will be delivered.  Ping and 
TELNET will work.  
 
-----------------------------------------------------------------------------
Topic 22.  How do I install RARP on a Linux machine?
-----------------------------------------------------------------------------
 
RARP is trickier to get going than ARP.  RARP has to be enabled. In my case 
(Slackware) RARP is an optional component that can be compiled into the 
kernel, or a module that must be compiled so it can be inserted into a 
running kernel.
 
You have a choice to make.  You can either build a kernel that has RARP 
built-in, or you can choose to insert the RARP module into your running 
kernel and see what happens.
 
-----------------------------------------------------------------------------
Topic 23.  Building a RARP-enabled kernel
-----------------------------------------------------------------------------
 
There are two ways to do a kernel build.  Both involve altering the 
/usr/src/linux/.config file:
 
1) Run the /usr/src/linux/menuconfig program.  This script acts as a 
front end tool and uses your responses to (re)write the 
/usr/src/linux/.config file. 
2) Edit the /user/src/linux/.config file directly.  
 
Here are the two methods:
 
(1)
:/#cd /usr/src/linux
:/usr/src/linux#make menuconfig
Networking options                                                                 
< > IP: Reverse ARP
 
You must say "Y" in the appropriate place.  An asterisk must appear 
between the GT/LT "<*>" for this option be on.
 
(2)
:/#cd /usr/src/linux
:/usr/src/linux#joe .config
Change:
"CONFIG_INET_RARP is unset"    =>      "CONFIG_INET_RARP=y"
 
-----------------------------------------------------------------------------
Topic 24.  How do I Compile a Linux Kernel?
-----------------------------------------------------------------------------
 
Telling you how to compile a kernel is beyond the scope of this 
document. Look at the Kernel HOWTO for a very complete discussion of how 
to compile and install a new kernel on your Linux computer.  On my 
system I would read it with the following command:
 
zless /usr/doc/faq/howto/Kernel-HOWTO.gz
 
-----------------------------------------------------------------------------
Topic 25.  How do I Install a Linux Kernel?
-----------------------------------------------------------------------------
 
After building the new RARP-enabled kernel, It must be installed using 
LILO.  The system must then be rebooted.  LILO is another topic that is 
beyond the scope of this document.  Please look at the LILO HOWTO.  On 
my system I would read it with the following command:
 
zless /usr/doc/faq/howto/mini/LILO.gz
 
-----------------------------------------------------------------------------
Topic 26.  FAQ this, FAQ that!  Too much reading!  Isn't There a Faster Way?
-----------------------------------------------------------------------------
 
OK.  Here's something for the daredevils!
 
---------------------------------------------------------
FOR THE IMPATIENT!  NO GUARANTEES!  I AM NOT RESPONSIBLE!
---------------------------------------------------------
******I would have a boot disk ready if I were you!******
---------------------------------------------------------
 
 
:/#cd /usr/src/linux
:/#usr/src/linux#make dep ; make clean ; make zImage ; \
make modules ; make modules_install
 
:/#usr/src/linux#cp ./arch/i386/boot/zImage /vmlinuz
:/#usr/src/linux#lilo
:/#usr/src/linux#shutdown -r now
 ?
 
-----------------------------------------------------------------------------
Topic 27.  Using Modules to RARP-Enable a kernel
-----------------------------------------------------------------------------
 
If you're lucky, you can enable RARP simply by issuing the following 
command(s):
 
:/#insmod rarp
:/#lsmod
Module:     #pages:     Used by:
rarp            1               0
iBCS           25               0
ds              2               0
pcmcia_core     7       [ds]    0
ppp             5               0
slip            2               0
slhc            2       [ppp slip]      0
lp              2               0
 
:/#
 
Note that on line one (1) of the output of the "lsmod" command, rarp has been 
loaded as a module and is available.  
 
NOTE:   Once you verify that the command is correct, don't forget to 
        add it to your /etc/rc.d/rc.local file.  If you forget this 
        important step, your Linux machine will "forget" that your 
        netbooting computer exists!  
 
        This will cause very strange netboot behavior after the Linux 
        server has been (re)started.  Suddenly your netbooting Sun will 
        not work!  Save yourself the grief and do it now.  
 
Here's what my /etc/rc.d/rc.local looks like:
 
#
#
#
#
 
--? INSERT APPROPRIATE TEXT HERE
 
-----------------------------------------------------------------------------
Topic 28.  How do I configure RARP?
-----------------------------------------------------------------------------
 
The RARP cache has to be "primed". 
 
For sphere this is done by executing the following:
 
:/#/sbin/rarp -s sphere 8:0:20:8:FA:51
 
The RARP cache can be dumped to the screen (and verified) with the 
following command:
 
:/#/sbin/rarp -a
IP address       HW type             HW address
192.168.0.150    10Mbps Ethernet     08:00:20:08:fa:51
 
As you can see, the IP address 192.168.0.150 has been linked with the 
Ethernet address 08:00:20:08:fa:51.  The connection between the Ethernet 
address 08002008FA51, the name "sphere" and the IP address 192.168.0.150 
has been successfully established! 
 
How do I know?  The name "sphere" doesn't appear in the list that is 
produced by RARP.  While the name "sphere" is used in the "priming" step 
to help form the connection, its IP address appears in its stead when 
RARP is asked to produce its table.  This is verification that the RARP 
entry worked.  The RARP entry forms a between the Ethernet address, the 
name of the netbooting machine in the /etc/hosts file, and the IP 
address that also appears in that file.
 
NOTE:   Once you verify that the command is correct and the information in 
        the RARP cache is right, don't forget to add it to your 
        /etc/rc.d/rc.local file.  If you forget this important step, your 
        Linux machine will "forget" that your netbooting computer exists!  
 
        This will cause very strange netboot behavior after the Linux 
        server has been (re)started.  Suddenly your netbooting Sun will 
        not work!  Save yourself the grief and do it now.  
 
Here's what my /etc/rc.d/rc.local looks like:
 
# --------------------------------------------------------------------------
# Graham Leach 
# 1997-03-01    
# To enable netbooting from this machine, RARP must be enabled
# --------------------------------------------------------------------------
echo Installing RARP
insmod RARP
 
# --------------------------------------------------------------------------
# Graham Leach 
# 1997-03-01    
#
# A RARP entry is necessary for a machine to netboot.
# --------------------------------------------------------------------------
echo -n "Priming RARP cache for: "
/sbin/rarp -s sphere 08:00:20:08:FA:51
echo "sphere "
 
-----------------------------------------------------------------------------
Topic 29.  What does it look like when RARP is NOT working properly?
-----------------------------------------------------------------------------
 
RARP isn't working properly when an IP address isn't handed to a RARP 
broadcasting machine.  Here's what I see when RARP is not working right:
 
_______________________________________________________________________
FDX         8:01a    1-  1
-----------------------------------------------------------------------
EEPROM:  Using RS232 Port A as input device
Selftest Completed.
 
Sun SPARCsystem 3XX
ROM Rev 3.0.3, 32MB memory installed, Serial #15234.
Ethernet address 8:0:20:8:FA:51, Host ID 23003B82
 
Testing 1 Megabytes of Memory ... Completed.
 
Auto-boot in progress...
 
EEPROM boot device... le(0,0,0)
Requesting Internet address for 8:0:20:8:FA:51
/
_______________________________________________________________________
 
That's where the boot ends.  If the machine cannot obtain its IP address
from the RARP server, it cannot determine the name of the SSBL that it has
to load for the boot to continue on.  Full stop.
 
-----------------------------------------------------------------------------
Topic 30.  How do I know that RARP is working properly?
-----------------------------------------------------------------------------
 
RARP is working properly when your server responds to the RARP request 
and gives the client computer the IP address as specified in the 
/etc/hosts file:
 
_______________________________________________________________________
FDX         8:01a    1-  1
-----------------------------------------------------------------------
EEPROM:  Using RS232 Port A as input device
Selftest Completed.
 
Sun SPARCsystem 3XX
ROM Rev 3.0.3, 32MB memory installed, Serial #15234.
Ethernet address 8:0:20:8:FA:51, Host ID 23003B82
 
Testing 1 Megabytes of Memory ... Completed.
 
Auto-boot in progress...
 
EEPROM boot device... le(0,0,0)
Using IP Address 192.168.0.150 = C0A80096
tftp: time-out
tftp: time-out
_______________________________________________________________________
 
 
Let me explain what is going on.  sphere is:
 
 
1)  Loading the MONITOR program from EEPROM
2)  Running self-checks to guarantee machine "ready" state
3)  Executing the Primary Stage Boot Loader (PSBL) Program
4)  Asking for its IP address via a RARP request
5)  Obtaining its IP address from the Linux RARP server
6)  Timing out on a call to TFTP
 
As you can see above, everything is in place in terms of the Address 
Protocols.  The machine called sphere now knows its IP address.  The failure
at this point is with TFTP a higher level boot protocol than RARP.
 
Our discussion now moves to TFTP.  Up the networking layers we go!
        
-----------------------------------------------------------------------------
Topic 31.  What is TFTP?  What does it do?
-----------------------------------------------------------------------------
 
Trivial File Transfer Protocol is used to transmit files between 
networked computers.  It can be used to boot diskless computers.  It is 
usually automatically started when required by the inetd "SUPERSERVER" 
daemon.
 
NOTE:   One of the packages required for a successful Sun netboot is 
        Xkernel.  It contains a specially modified version of TFTP that 
        transmits files in 1k blocks.  This is the block size that Sun 
        computers require.  The Xkernel TFTP is different than the TFTP 
        which comes with Linux.  It transmits in 8k blocks.  Another 
        difference is that the Xkernel TFTP daemon looks for files in a 
        specific place in the file system.  Here is a relevant section 
        of the Xkernel documentation that describes this special tftp 
        daemon:
 
        "This package includes a specially modified tftpd server.  To 
        increase security, it prepends usr/export/tftpboot/ to the 
        pathname of all requested files.  This helps to remove a
        bug found in some Linux tftpd's that causes them to refuse
        requests for files that don't have a complete (from the root)
        path."
 
        The Xkernel package is copyright:
 
        ---> Get the Xkernel credits together here.
 
As I stated before, inetd is responsible for starting many services.  
One of these services is tftp.  To have Linux inetd start the "right" 
TFTP daemon when a TFTP request is received it must know where the tftpd  
program is.  It also must know under which uid to run the tftp program.  
All of this information is held in the inetd.conf configuration file.
 
NOTE:   TFTP is a service offered by the Unix "SUPERSERVER" - inetd.  At 
one time there was a HUGE collection of single purpose programs that answered 
requests for services in Unix.  Hundreds of services begat hundreds of little 
daemon programs.  The services were so popular and requested so frequently 
that someone decided to create a big program that held all of the most popular
 servers (daemons) within it.  The reasons behind this have to do with systems 
efficiency and architecture. Basically the superserver helps to reduce context 
switching, enables a consistent invocation medium and addresses other important 
issues inherent in a separate implementation strategy.  
 
-----------------------------------------------------------------------------
Topic 32.  How do I install TFTP on a Linux computer?
-----------------------------------------------------------------------------
 
TFTP is another "dormant" Linux feature that has to be turned on.  Fortunately,
a kernel build is NOT necessary.  All that has to be done to enable the TFTP 
server is a small adjustment to the /etc/inetd.conf file on the Linux machine.  
The /etc/inetd.conf file is quite large.  You will have to look for the 
string "tftp" to locate the appropriate section.  Here's what mine looked like 
before and after I edited it:  
 
BEFORE
------
 
# Tftp service is provided primarily for booting.  Most sites
# run this only on machines acting as "boot servers."
#
#tftp  dgram   udp     wait    root    /usr/sbin/tcpd  in.tftpd
 
 
AFTER
-----
 
# Tftp service is provided primarily for booting.  Most sites
# run this only on machines acting as "boot servers."
#
# tftp  dgram   udp     wait    root    /usr/sbin/tcpd  in.tftpd
#
#-----------------------------------------------------------------------
# Graham Leach (98.09.23)
# Following instructions in /usr/export/README:179
# I have added the following one (1) line(s).
#-----------------------------------------------------------------------
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/export/src/tftpd/tftpd
 
Here's an explanation of that line:
 
tftp                                  : This is the service name
dgram                                 : This defines the socket type
udp                                   : The User Datagram Protocol is used
wait                                  : A special condition for tftp.
nobody                         : Execute this program as user "nobody"
/usr/sbin/tcpd                 : Use this program as a "wrapper" 
/usr/export/src/tftpd/tftpd    : This is the executable to run
 
Here is some information that explains the special "wait" condition for 
tftp in inetd.conf.  This excerpt is from man(8):
 
"Tftpd(8) is an exception; it is a datagram server that establishes 
pseudo-connections.  It must be listed as ``wait'' in order to avoid a race; 
the server reads the first packet, creates a new socket, and then forks and 
exits to allow inetd to check for new service requests to spawn new servers."
 
Once the /etc/inetd.conf file has been adjusted, inetd must be told to reload 
its configuration file.  If this is not done the changes will not take effect 
until the next reboot.
 
This can be done with the following command:
 
:/#kill -HUP `ps ax | grep inetd | cut -c 1-6`
 
Now that the Linux server has been configured to respond to TFTP requests, a 
question remains to be answered. What does sphere want?  Certainly, when 
sphere issues a TFTP request it doesn't just stop at a TFTP server being 
started on the Linux machine.  sphere is asking for something via TFTP.  
What is it?
 
-----------------------------------------------------------------------------
Topic 33.  What IS this file that TFTP is being asked to provide?
-----------------------------------------------------------------------------
 
When a netbooting computer issues a TFTP request, it is looking for its 
Secondary Stage Boot Loader, or SSBL.   Usually this file resides on 
some sort of local media.  In the case of a netbooting computer, TFTP is 
taking the place of that local mass storage device and providing that 
service via a network connection. 
 
Let me explain again what a Secondary Stage Boot Loader is.  It performs 
a job very similar to the PSBL - in fact, some would say that it is 
merely an extension of the PSBL.  It certainly has a similar mode of 
operation - it too exists to load a program, then execute it.  
 
But that is where the similarity ends.  There are critical differences: 
In the case of the PSBL the program being loaded is the SSBL.  In the 
case of the SSBL the program being loaded is an Operating System kernel.   
There is another important distinction.  The SSBL is implemented in 
software and the PSBL is implemented in firmware (EEPROM).  
 
The SSBL has certain advantages over the PSBL.  The SSBL is much more 
flexible because it can be easily (re)programmed. It can be larger than 
the PSBL.  As a result, it can offer more resources; like additional 
device drivers, virtual memory and networking (NFS).
 
NOTE:   For an in-depth discussion of boot loader theory, review the LILO 
documentation.  On my machine I would execute the following 
command to review the literature:
 
:/#less /usr/doc/lilo/README
 
Now we know WHAT the SSBL is.  The next step is the find out what FORM 
the SSBL must be in and WHERE it needed to be located for TFTP to be 
able to hand it over to sphere when it is asked for. 
 
What is the FORM of the information that sphere is asking for?  Quite 
simple really.  sphere is requesting a file whose name matches the IP 
address that was given to it via the RARP response.
 
There is one complication - the filename has to be in hexadecimal 
format, not the familiar "dotted decimal" notation that we (humans) are 
more used to.  Moreover, the characters ".SUN4" be added to the end of 
the filename.  This is because sphere is a Sun 4/xxx machine.
 
As you may recall, the IP address I chose for sphere is 192.168.0.150.  
 
Using a Windows(tm) calculator (in scientific mode) I translated the IP 
address to hexadecimal.  In my case the numbers translated as follows:
 
192     decimal =       CO      hexadecimal
168     decimal =       A8      hexadecimal
0       decimal =       00      hexadecimal
150     decimal =       96      hexadecimal
 
192.168.0.150  =       C0A80096
 
Add the suffix .SUN4 and the file becomes C0A80096.SUN4
 
sphere is asking for the file C0A80096.SUN4 via TFTP.  Next question is: 
Where should C0A80096.SUN4 go so TFTP can find it?
 
-----------------------------------------------------------------------------
Topic 34.  O.K.  Now I know what TFTP is looking for.  Where do I put it?
-----------------------------------------------------------------------------
 
When this version of TFTP is called upon to provide a file, it looks in 
a specific directory.  The source to the TFTP code has been altered.  
This is is to increase security and prevent problems with incomplete 
file paths from crashing the server.  
 
The directory that TFTP looks in is /usr/export/tftpboot directory.
 
Here's the scenario:  sphere issues a TFTP request asking the Linux TFTP 
server to provide it with the file C0A80096.SUN4.  TFTP is started by 
inetd and immediately looks for C0A80096.SUN4 in the directory that has 
been compiled into it.  Logically it follows that I had to put something 
as C0A80096.SUN4 in the /usr/export/tftpboot directory for anything to 
happen.  
 
My next question was naturally about the file C0A80096.SUN4 - where 
could I get one?
 
I hit the Internet.  I knew what I was looking for.  I needed something 
akin to the boot section of the boot/root combo for Linux.
 
I hit upon a promising collection of software.  There was an ongoing 
Linux port to the Sparc platform under the name SparcLinux.  The boot 
loader for the project was called SILO.  Unfortunately, it seemed that 
my Sun hardware (VME bus)was not supported.  I bit my lip and moved on 
?  
 
Then I hit upon NetBSD.  
 
I'd heard about the FreeBSD effort of course, but I didn't really know 
very much about it other than the name.  I knew that it was another one 
of the free Unices, that was about it.
 
What I found was impressive. First of all, my 4/380 was on the Supported 
Hardware list.  Secondly there was a document that described netbooting 
Sun computers right on their website.  
 
There was not as much supporting information as I was used to with 
Linux, what was there was excellent.  It was also current.  The 
netbooting Sun document I found at that site has greatly influenced the 
format of this document (Thank You).  Here it is:
 
http://www.netbsd.org/Documentation/network/netboot/index.html
 
The above document is c 1997 The NetBSD Foundation, Inc. 
 
 
If you want to know more about the NetBSD effort, here is the resource:
 
http://www.netbsd.org 
 
By far the most useful thing I found at the NetBSD ftp/website was a 
file called boot.net. boot.net is a Secondary Stage Boot Loader (SSBL) 
for NetBSD. But you can call it (taa-daah!) C0A80096.SUN4
 
 
I found net.boot at: 
 
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.3.2/sparc/installation/netboot
 
Setting up the Linux box to hand over the NetBSD SSBL was pretty 
straightforward.  I downloaded the boot.net file via FTP straight into 
the TFTP /usr/export/tftpboot directory.  I then created a symbolic link 
that pointed to it with the name C0A80096.SUN4.
 
I did it this way:
 
:/usr/export/tftpboot#ln -s boot.net C0A80096.SUN4
 
I used a link for a few reasons: 
 
1) I wanted to retain the original filename boot.net.  Changing the 
name of the file via "mv" to COA80096.SUN4 not an available option.
2) If I ever get another Sparc that could use this particular boot.net 
file, I would be able to reference the file with another symbolic 
link instead of having to copy it.  That makes maintenance easier if 
a new, improved boot.net is ever released and I am forced to replace 
the one that is there.
3) I did it this way to "future proof" the installation.
 
The final step here is to make sure that the file permissions on 
C0A80096.SUN4 were correct so tftp could read the file.  If you 
installed the boot.net file as "root" then TFTP will not be able to open 
the file unless some permissions are adjusted.
 
NOTE:   This has to be done in such a way as to enable tftp to satisfy the 
request it receives from sphere without throwing the computer open 
to the four winds.  TFTP is a security problem due to its lack of 
demand for authentication.
 
-----------------------------------------------------------------------------
Topic 35.  TFTP Security - A Contradiction in Terms
-----------------------------------------------------------------------------
 
Setting up TFTP properly is really important.  TFTP poses a very real 
security risk because it provides unauthenticated clients access to the 
filesystem of the server upon which it resides.
 
While I am sure that you DO want your netbooting clients to be able to 
access their kernels, you DON'T want to do it in such a way that it 
leaves you open to damage from persons or processes with less benign 
intentions.  Hackers love facilities like TFTP because they give easy 
password-free access to the machine.  It's like a toehold.
 
When it came to securing the Linux system, I found that using the 
following commands really helped:
 
1) chown nobody *
2) su nobody
 
I used command (1) to change ownership of the boot files to nobody.  The 
account nobody is often used in conjuction with providing services to 
anonymous clients or running processes at a very low security 
equivalence.  That's why the account exists.  It has only the most 
minimal access rights.
 
Changing ownership of the files to nobody ensured that the Operating 
System didn't terminate the TFTP process when it tried to access files 
in trying to provide them to anonymous clients.  
 
NOTE:   Don't forget that tftpd is fired up via tcpd when inetd receives a 
        tftp request.  When TFTP is fired, it is configured to run under 
        the uid of nobody.  This becomes important when hackers try to 
        break TFTP.  If they manage somehow to get TFTP to provide them a 
        shell, that shell retains the uid of the owner process - in this 
        case "nobody".  It's a lot easier to hack a system if you can 
        obtain the uid "root" than "nobody".  To make it safer, TFTP is 
        run as "nobody".
 
---> VERIFY
 
I used command (2) when things didn't go right.  And not just for this 
step either.  Whenever files weren't being passed correctly and error 
codes were flying, or what I expected to happen didn't - I would:
 
su nobody
 
And then try to manually navigate to the files from the root directory.  
If I couldn't get to where I wanted (a la "permission denied"), I would 
either adjust ownership (or permissions) on files and directories until 
things started to work.  
 
Let me tell you, a lot of adjustments were necessary to get both the 
TFTP transfer to work correctly AND satisfy security.  I caution you to 
be patient and thorough.  It is worth it in the long run. 
 
BEFORE
------
192.168.0.1     linux     linux.network.domain
 
AFTER
-----
192.168.0.1     linux     linux.network.domain
 
-----------------------------------------------------------------------------
Topic 36.  What does it look like when TFTP is NOT working properly?
-----------------------------------------------------------------------------
 
With TFTP not working, the following appeared when I booted sphere:
_______________________________________________________________________
 
 
>b le()
Using IP Address 192.168.0.150 = C0A80096
Boot: le(0,0,0)
tftp: time-out
tftp: time-out
-
_______________________________________________________________________
 
-----------------------------------------------------------------------------
Topic 37.  How do I know that TFTP is working properly?
-----------------------------------------------------------------------------
 
 
With TFTP working, the following appeared when I booted sphere:
 
_______________________________________________________________________
 
 
>b le()
Using IP Address 192.168.0.150 = C0A80096
Boot: le(0,0,0)
Booting from tftp server at 192.168.0.1 = C0A80002
Downloaded 43784 bytes from tftp server
 
>> NetBSD/sparc Secondary Boot, Revision 1.7
>> (pk@flambard, Fri Jan  2 00:10:58 MET 1996)
Using IP address: 192.168.0.150
Boot: client IP address: 192.168.0.150
bootparamd: 'whoami' call failed
Can't open network device 'le(0,0,0)'
open: netbsd: Unknown error: code 60
device[le(0,0,0)]:
_______________________________________________________________________
 
 
This was GREAT!
 
Now the client machine (Sun) was:
 
 
1)  Loading the MONITOR program from EEPROM
2)  Running self-checks to guarantee machine "ready" state
3)  Executing the Primary Stage Boot Loader (PSBL) Program
4)  Asking for its IP address via a RARP request
5)  Obtaining its IP address from the Linux RARP server
6)  Downloading its SSBL from the Linux TFTP server (43784 bytes)
7)  Failing on a 'whoami' call to bootparamd
 
I initially guessed that "open: netbsd: Unknown error: code 60" really 
meant "No such file or directory".  My reasoning went like this: I was 
sure bootparamd was not doing its job because of the preceding line: " 
bootparamd: 'whoami' call failed".  
 
By failing to answer the 'whoami' request, bootparamd was not generating 
a means for the netbooting client to open something (probably a file) 
via the network.  In essence, the file "open" call failed and the boot 
halted.  
 
This error bubbled back up and the MONITOR program identified bootparamd 
as the source of the problem.  It seemed that it was time to get 
bootparamd working.
 
 
-----------------------------------------------------------------------------
Topic 38.  What is bootparamd?
-----------------------------------------------------------------------------
 
bootparamd is a program designed to respond to netbooting computers to 
help them load their kernels.  It works in conjunction with NFS.  It is 
also used to export file systems to netbooting machines.
 
Getting a Sun to netboot involves configuring bootparamd to respond to 
netbooting machines with their name and the location of any other 
resources they require.  It is then up to the netbooting computer to 
request those via NFS.  That is why a discussion of bootparamd MUST also 
include a discussion of NFS.  It also means that the bootparamd and the 
NFS servers do not necessarily have to reside upon the same computer, 
but for simplicity they co-exist on the Linux machine for the purpose of 
this document.
 
-----------------------------------------------------------------------------
Topic 39.  How do I get bootparamd to work on a Linux machine?
-----------------------------------------------------------------------------
 
bootparamd relies on a settings file called bootparams.  On my Linux 
machine this file is located at /usr/export/bootparams.   
 
A bootparams file contains a series of entries, or "stanzas".  A stanza 
is a collection of lines in an identifiable and logical group.  A stanza 
must exist for each netbooting computer.
 
Here's what my /usr/export/bootparams file looks like:
 
#/usr/export/bootparams
sphere     root=linux:/usr/export/sphere \
           swap=linux:/usr/export/sphere/swap \
           dump=linux:/usr/export/sphere/dump   
 
What this entry says is:
 
1) An entity named "sphere" exists as a client of bootparamd.  
2) It has a root filesystem at /usr/export/sphere.
3) Its swap area should be located at /usr/export/sphere/swap.
4) Any core dumps should be placed at /usr/export/sphere/dump.
 
NOTE:   In the Xkernel package the last two settings (swap,dump) are not 
implemented.  The swap area has to be manually implemented on the 
root file system.  Core dumps happen wherever they happen.  I 
figured that putting the settings in now (and creating the 
directory entries to match) would just "future proof" the 
installation and reduce work (and frustration) later.
 
I enabled bootparamd with the following command:
 
:/#/usr/export/src/bootparamd/rpc.bootparamd -f /usr/export/bootparams&
 
 
NOTE:   Once you verify that the command is correct and the information in 
the ARP cache is right, don't forget to add it to your 
/etc/rc.d/rc.local file.  If you forget this important step, your 
Linux machine will "forget" that your netbooting computer exists!  
 
This will cause very strange netboot behavior afterLinux server 
has been (re)started.  Suddenly your netbooting Sun will not work!  
Save yourself the grief and do it now.
 
With bootparamd enabled and running, the netbooting computer will 
receive its name:
_______________________________________________________________________
 
 
>b le()
Using IP Address 192.168.0.150 = C0A80096
Boot: le(0,0,0)
Booting from tftp server at 192.168.0.1 = C0A80002
Downloaded 43784 bytes from tftp server
 
>> NetBSD/sparc Secondary Boot, Revision 1.7
>> (pk@flambard, Fri Jan  2 00:10:58 MET 1996)
Using IP address: 192.168.0.150
Boot: client IP address: 192.168.0.150
Boot: client name: sphere
Can't open network device 'le(0,0,0)'
open: netbsd: Unknown error: code 72
device[le(0,0,0)]:
 
_______________________________________________________________________
 
Here's what is happening:
 
 
1)  Loading the MONITOR program from EEPROM
2)  Running self-checks to guarantee machine "ready" state
3)  Executing the Primary Stage Boot Loader (PSBL) Program
4)  Asking for its IP address via a RARP request
5)  Obtaining its IP address from the Linux RARP server
6)  Downloading its SSBL from the Linux TFTP server (43784 bytes)
7)  Obtaining its name from the Linux bootparamd (sphere)
8) Obtaining kernel and file system pointers from bootparamd 
9)  Failing on a call to NFS.
 
 
The next step is to configure NFS to work in harmony with bootparamd so 
that it can deliver the resources that the netbooting client requests 
from it as a result of a bootparamd response.
 
-----------------------------------------------------------------------------
Topic 40.  What is NFS?
-----------------------------------------------------------------------------
 
NFS stands for Network File System. It allows computers on a network to 
share information by extending the file system concept to network 
resources.  When Sun invented NFS they wanted to give users access to 
information on remote hosts with the same ease as they had on their 
local machines.  NFS was the answer. 
 
An NFS resource (an export) on one machine (the NFS server) can be 
"mounted" upon any point in the directory structure of another machine 
(the client) - just like a disk.  The resource can then be manipulated 
from that point on as if it were a natural part of the directory tree of 
the client(with very few exceptions).  It's beautiful. Learn about it.  
I guarantee you won't be sorry you did.
 
-----------------------------------------------------------------------------
Topic 41.  How does NFS fit together with bootparamd?
-----------------------------------------------------------------------------
 
NFS and bootparamd fit together in the sense that bootparamd only 
provides a netbooting computer pointers to information it needs. 
bootparamd  relies on NFS for actual delivery of those resources to  the 
netbooting computer.  bootparamd is pretty useless without NFS to back 
it up.
 
NOTE:   It is the software-based SSBL (boot.net) that knows how to "speak" 
to NFS, not the hardware-based PSBL that resides within EEPROM in 
the Sun.  The only "network speak" that the Sun PSBL knows is TFTP 
and RARP.  This serves as an example of how SSBL programs can be 
more powerful and flexible than SSBL programs.
 
-----------------------------------------------------------------------------
Topic 42.  What happens when bootparamd and NFS do their thing?
-----------------------------------------------------------------------------
 
As I have already explained, NFS has to work in conjunction with 
bootparamd for a successful netboot to occur.  
 
When the client issues a 'whoami' call, it's more like a "who am I and 
where am I' call.  Take this to mean that what the client wants to know 
both its identity AND the location of its kernel and file structure.  
RARP may have told the netbooting computer its IP Address, but it still 
doesn't know its name.  bootparamd provides that information.
 
The netbooting computer is also looking for software - more 
specifically, its Operating System.  bootparamd tells it where to look 
by forwarding the netbooting computer values stored in its bootparams 
file.  The client then requests these resources via NFS.  
 
For the netboot to move forward, NFS has to provide these resources 
(known as exports) to the netbooting (client) computer.  NFS must be 
able to support the directory structure as defined in the 
/usr/export/bootparams file.  The trick between bootparamd and NFS is to 
get the bootparamd settings file (bootparams) and the NFS settings file 
(exports) to match.
 
NOTE:   Here's what is happening on my Linux machine from the perspective 
of the "root" directory (/) of each machine, and where the 
directories really reside.
 
Linux                  NetBSD
NFS Server directory   NFS Client
 
usr
|__export           
|___root
        |____sphere
           |           sphere:/
           |___root            |___root
           |___swap                   |___swap
           |___usr             |___usr
           |___home            |___home
           |___var             |___var
 
 
As you can see, the physical organization of the information looks 
very different to the machine providing the information (the Linux 
NFS server) than to the machine receiving the information (the 
NetBSD NFS client).  It's the same information, but the location 
of the directories in which the information is contained is 
different.
               
Another important concept to remember is that the information 
never actually "leaves" the NFS server.  NFS allows the client to 
think that the information is mounted locally.  It is NOT being 
transmitted like an FTP session would transport information.  It 
is NOT in two places at one time.  It just looks that way.  Cut 
off the network to the NFS client and you'll see immediately just 
how "local" it is!
 
-----------------------------------------------------------------------------
Topic 43.  How do I get bootparamd and NFS to work together?
-----------------------------------------------------------------------------
 
Setting up NFS and bootparamd to work together is a straightforward 
process.  You have to alter the /etc/exports file and restart the 
rpc.nfsd and rpc.mountd daemons that compose the service.  You have to 
alter the bootparams file and restart the rpc.bootparamd daemon.  The 
values in the files must match.
 
Here we go: 
 
This is what my /etc/exports file looks like:
 
#/etc/exports:
 
/usr/export/root/sphere               sphere(rw,no_root_squash)
 
This entry tells the NFS daemon to allow connections from the machine 
known as sphere to access the "export" known as sphere.  
 
Furthermore, the files contained in the export "sphere" are located at 
/usr/export/sphere/root in the NFS server file system.  The machine 
sphere is allowed to both read and write to files in that export.
 
It also instructs the NFS daemon not to squash the root file system.  
This is referenced in the man pages for exports, located in man(5):
 
no_root_squash
 
     Turn off root squashing. This option is mainly useful for
     diskless clients.
 
 
-----------------------------------------------------------------------------
Topic 44.  How do I know that bootparamd is NOT working?
-----------------------------------------------------------------------------
 
We know it is not working for sure when it reports errors.  We've 
already seen the Code 60 error.  Let's go a little deeper into the Code 
72 error that results from a properly configured bootparamd and 
improperly configured NFS:
 
After I enabled bootparamd on the Linux server, I saw the following:
 
______________________________________________________________________
 
 
>b le()
Using IP Address 192.168.0.150 = C0A80096
Boot: le(0,0,0)
Booting from tftp server at 192.168.0.1 = C0A80002
Downloaded 43784 bytes from tftp server
 
>> NetBSD/sparc Secondary Boot, Revision 1.7
>> (pk@flambard, Fri Jan  2 00:10:58 MET 1996)
Using IP address: 192.168.0.150
Boot: client IP address: 192.168.0.150
Boot: client name: sphere
Can't open network device 'le(0,0,0)'
open: netbsd: Unknown error: code 72
device[le(0,0,0)]:
 
_______________________________________________________________________
 
 
When I first saw this error my guess was that error 72 had something to 
do with permissions.  My reasoning went like this:
 
1) Error 60 had something to do with file existence.  
2) 72 is a higher number than 60.  
3) I thought that the first thing a developer would take care of 
when building a tool was whether or not the file was 
locatable.  
4) Error 72 must concern "higher" functionality than file 
existence.
5) I was just guessing anyways ? 
 
I felt that file ownership or access permissions had to be at the root 
of this.  A "ls -l" of the directory gave the following permissions for 
tftpboot:
 
drwx------   3 nobody   root         1024 Sep 26 16:33 tftpboot/ 
 
Would you agree that directory permissions of 700 could be a problem?
 
My conclusion was that error 72 meant "Permission denied".  when TFTP 
tried to access the file to was not being allowed access to that 
directory, only "nobody" could go into that directory, according to the 
way the permissions were set.
 
I tested this theory by using an account other than "root" and "nobody".  
Sure enough, I was not allowed in.  To fix it, I had to execute the 
following command as root:
 
:/#chmod 755 tftpboot
 
This gave the following permissions to that directory:
 
drwxr-xr-x   3 nobody   root         1024 Sep 26 16:33 tftpboot/  
 
Then I rebooted the computer one more time.  But I did it differently.  
From sheer experimentation, I had discovered that all I had to do was 
press CTRL-BREAK and the Sun would drop down into its MONITOR screen and 
give me a ">" prompt.
 
-----------------------------------------------------------------------------
Topic 45.  How do I know that bootparamd is working?
-----------------------------------------------------------------------------
 
---> Place a boot with a missing kernel here.
 
-----------------------------------------------------------------------------
Topic 46.  This is all about Sun and Linux.  Where does NetBSD fit in?
-----------------------------------------------------------------------------
 
I know this question sounds a little crazy.  But with all this Linux-
specific configuration activity, the focus of this document may seem to 
be a little lost.  We ARE going to boot a Sun 4/380 on a NetBSD at the 
end of this document, I promise.  Hang in there.  We're almost done.
 
For the NFS server to have something to export, you have to obtain and 
install the NetBSD files compiled for the Sparc architecture in the 
appropriate place on the disk drive of the Linux machine.
 
To get that boot to happen, NetBSD has to be installed on the Linux 
server in directory that is NFS-exported as "sphere".  
 
-----------------------------------------------------------------------------
Topic 47.  What is NetBSD?
-----------------------------------------------------------------------------
 
NetBSD is another Unix effort in the spirit of Linux.  That means that it 
is under the care and control of its users.  The NetBSD Operating System 
is free and is open.  It comes with its own source code.  Users are 
encouraged to extend the OS as they see fit.  
 
It also comes with no warrantee, express or implied. ?
 
Here is what the NetBSD people have to say about their own product.  
This comes direct from the NetBSD homepage, http://www.netbsd.org:
 
     The NetBSD Project is a collective volunteer effort to produce a
     freely available and redistributable UNIX-like operating system. 
 
     NetBSD runs on a broad range of hardware platforms and is highly
     portable. It comes with complete source code, and is user-supported.
 
-----------------------------------------------------------------------------
Topic 48.  Where do I get NetBSD?
-----------------------------------------------------------------------------
 
The definitive source of all NetBSD information, including the location 
of kernels, utilities and applications for the Operating System is at 
http://www.netbsd.org.  
 
I found my particular distribution at:
 
ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-1.3.2/sparc/binary/sets/base.tgz
 
-----------------------------------------------------------------------------
Topic 49.  Which NetBSD is the right NetBSD?
-----------------------------------------------------------------------------
 
The version of NetBSD I chose to install was 1.3.2.  As the Operating 
System matures, I expect that the version number will increment.  My 
advice?  Just download the latest "stable" version of the OS and you'll 
be fine.  
 
I chose to download the one just before that marked as "current".  You 
may choose to live on the dangerous side and download the "current" 
version of the OS.  I must tell you that the "current" version is 
usually more on the experimental side and is as a result a little less 
reliable, but often is more fun to run, especially if you consider the 
cutting edge to be cool.
 
-----------------------------------------------------------------------------
Topic 50.  Is it Dangerous to Install Sparc Executables on an Intel box?
-----------------------------------------------------------------------------
 
Installing Sparc-executable files on your Linux system won't risk 
anything.  Even if you forget yourself and execute one of them nothing 
very exciting will happen.  You will see the following message from your 
Intel Linux box:
 
:/# 
bash: ./: cannot execute binary file
 
The binary format of Sparc-executables is totally incomprehensible to an 
Intel-based Linux machine.  The message is saying that Linux is guessing 
that it is a binary file, but cannot make any sense of what is in there.  
It definitely cannot execute it.  So the Linux kernel gives up and 
issues an error.
 
-----------------------------------------------------------------------------
Topic 51.  How do I install Sparc NetBSD on a Linux system?
-----------------------------------------------------------------------------
 
It is necessary to extract the netbsd archive base.tgz into an NFS-
exported directory on your Linux host.  Once this has been done, the 
client will be able to access and download its NetBSD kernel.  
 
The extraction will also put in place a skeleton file system structure.  
This file system can be fleshed out with other packages later.  Many 
critical utilities are installed, especially in the /bin, /sbin, 
/usr/bin directories.
 
To do this, a recent version of the program known as "tar" is needed.  
 
-----------------------------------------------------------------------------
Topic 52.  What is TAR?
-----------------------------------------------------------------------------
 
TAR is an archiving utility.  Archiving utilities are used to collect a 
bunch of files together into one file.  This makes it easier to package 
them for transport to other computer systems - you only have to keep 
track of one large file instead of hundreds of little ones.  Another 
advantage of archive utilities is that they preserve the directory 
structure.  Think of the directory structure as the relative position of 
files to one another from one absolute location.  In this case, the 
absolute location is the "root directory" or "/".
 
In the old days of Unix, when only tapes existed as the means by which 
software could be loaded onto a computer, the Utility "Tape ARchive" was 
created.  It was really useful.  It's been used ever since, even though 
the use of tapes to install software has largely become a thing of the 
past, especially with microcomputers.  The last time I really used a 
tape with a microcomputer was with an Apple II+ cassette port.  It was a 
while ago. ?
 
Now we use TAR to move information around regardless of the media it 
resides upon.  A tar archive can be transported to disk, tape, over a 
network, even converted to light and burned into a CD-ROM.  They are 
infinitely flexible and essential to the distribution of packages in the 
Unix world.
 
NOTE:   tar is useful because it preserves not only the files 
(information), but also where they are (structure).  When used in 
conjunction with a compression utility, tar can be a very, very 
powerful tool.  It is in use everywhere.
 
-----------------------------------------------------------------------------
Topic 53.  Why do I potentially need a more recent version of TAR?
-----------------------------------------------------------------------------
 
The structure of the NetBSD base.tgz file contains not just files and 
their directory structures - it also contains file ownership and 
permissions information.  It is really important to retain file 
ownership information.  This is because of something known as the suid 
bit.  When a file has the suid bit set on. It runs under the privilege 
level of the owner of the file, not the user executing it.  
 
This can lead to some really horrible security issues.  Consider this: 
The file gets put into the archive owned by the user nobody.  The file 
is extracted by and ownership is set to root.  The suid bit of that file 
happens to be "on".  
 
Now there is a file on the system that when "broken" creates a means by 
which a person could hack the computer system as root!  This is because 
"broken" suid root programs can give hackers a means of obtaining the 
privileges of root.  This situation is really to be avoided.  The new 
version of tar (1.1.2) retains file ownership information correctly. 
Older versions do not.  For this reason the new version is compulsory 
for this installation and must be obtained and installed on the Linux 
system before the contents of the base.tgz file are extracted.
 
-----------------------------------------------------------------------------
Topic 54.  Where do I get TAR 1.1.2?
-----------------------------------------------------------------------------
 
tar version 1.1.2 is available from the Free Software Foundation (FSF):
 
http://www.fsf.org
 
-----------------------------------------------------------------------------
Topic 55.  How do I install TAR 1.1.2 on my computer?
-----------------------------------------------------------------------------
 
---> Read the instructions
 
-----------------------------------------------------------------------------
Topic 56.  How do I use TAR 1.1.2 to install NetBSD on Linux?
-----------------------------------------------------------------------------
 
---> Follow the instructions that come with base.tgz
 
After you have installed the NetBSD files in the proper locations and 
checked that their permissions are legal, it's time to see if all of 
this hard work will be rewarded.  Reboot!
 
 
-----------------------------------------------------------------------------
Topic 57.  What does it look like when everything works properly?
-----------------------------------------------------------------------------
 
_______________________________________________________________________
 
 
>b le()
Using IP Address 192.168.0.150 = C0A80096
Boot: le(0,0,0)
Booting from tftp server at 192.168.0.1 = C0A80002
Downloaded 43784 bytes from tftp server
 
>> NetBSD/sparc Secondary Boot, Revision 1.7
>> (pk@flambard, Fri Jan  2 00:10:58 MET 1996)
Using IP address: 192.168.0.150
Boot: client IP address: 192.168.0.150
Boot: client name: sphere
Boot addr=192.168.0.150 path=/usr/export/sphere
Booting netbsd @ 0x4000
1376256116800+[77844+91083]
.
.
.
Enter pathname of shell or RETURN for sh:
_______________________________________________________________________r
 
Success!  sphere is:
 
1)  Loading the MONITOR program from EEPROM
2)  Running self-checks to guarantee machine "ready" state
3)  Executing the Primary Stage Boot Loader (PSBL) Program
4)  Asking for its IP address via a RARP request
5)  Obtaining its IP address from the Linux RARP server
6)  Downloading its SSBL from the Linux TFTP server (43784 bytes)
7)  Obtaining its name from the Linux bootparamd (sphere)
8)  Obtaining kernel and file system pointers from bootparamd 
9)  Using NFS to download the NetBSD kernel
10) Using NFS to mount its file system 
11) Executing the NetBSD kernel
 
The Sun has booted!  Mission accomplished.
 
I hope that this document has both entertained and helped you.  
 
It was a pleasure to write.
 
g.
 
-----------------------------------------------------------------------------
Bibliography
-----------------------------------------------------------------------------
 
Innumerable documents provided the resources necessary to enable me to create 
this text.  I am very grateful for their existence, and that is why I wrote 
this document.  Thank you.
 
-----------------------------------------------------------------------------
Revision History
-----------------------------------------------------------------------------
 
CREATED:       1997-03-01
UPDATED:       2017-03-11
 
--------------------------------------------------------------------
END:  Netbooting a Sun 4/380 on NetBSD via Linux HOWTO
--------------------------------------------------------------------
 

No comments:

Post a Comment