1.1. What and Why

This document describes how to boot the Dachstein LRP distribution over a network using Etherboot to perform the boot loading.

The benefits of this method include....

• The reliance on floppy media is removed.

• The speed of reboots - ~3 seconds to transfer the image. (For LRP developers - this speed and ease of booting could assist development)

• A possible reduction in hardware.

• With a serial console it becomes a compact setup.

• Once the boot code is on the NIC, it can be used to boot anything suitable.

Admittedly, the thought of your secure firewall being dependent on a tftp server may seem contradictory but the *stein distributions close all external connections during the bootup sequence. This should be no worse than any of the internal services running already and assumes that you can trust your internal network but, as always, be aware of the risks

The reasons for this approach are many, for me it was the extension of a motherboard resuscitation project ( in other words I had the eprom burner already ) but other uses for netbooting come to mind, such as Ken Yaps rundown on booting Tomsrtbt CD Section 6.1 testing your machines memory, also Section 6.2 or the LTSP Project for a terminal project.

The Dachstein distribution also comes in a CD version so perhaps with a bit of tweaking this could be configured to allow netbooting.

I have used the 1.680 meg floppy image for this exercise.

1.2. Copyright Information

This document is copyrighted (c) 2000 Glenn McKechnie and is distributed under the terms of the Linux Documentation Project (LDP) license, stated below.

Unless otherwise stated, Linux HOWTO documents are copyrighted by their respective authors. Linux HOWTO documents may be reproduced and distributed in whole or in part, in any medium physical or electronic, as long as this copyright notice is retained on all copies. Commercial redistribution is allowed and encouraged; however, the author would like to be notified of any such distributions.

All translations, derivative works, or aggregate works incorporating any Linux HOWTO documents must be covered under this copyright notice. That is, you may not produce a derivative work from a HOWTO and impose additional restrictions on its distribution. Exceptions to these rules may be granted under certain conditions; please contact the Linux HOWTO coordinator at the address given below.

In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, and would like to be notified of any plans to redistribute the HOWTOs.

If you have any questions, please contact <linux-howto@metalab.unc.edu>

2.1. Set up the Cards

Having selected the cards to use, check for a valid driver in the Etherboot or Rom-o-matic databases.

If you're lucky the driver will be obvious and you can either fetch and compile the source or use Rom-o-matic which will save you getting into compilation issues if using RedHat.

If the card driver is not obvious then do some further research as the driver could well be there but disguised as something else. See Section 7.1 for an example

Having selected the driver, the option to download the rom as a floppy image is the best way to start as the process can be debugged first.

2.2. Boot from the internal network

Obvious .. yes .. Simple .. No.. Well .. In truth it is simple but it sure had me confused for a bit, but it was late and the coffee was weak ;-)

I initially used two 3com 3c509s, I set them up correctly with the DOS configuration program and inserted the eprom into the configured card.

On start up the machine was assigned an address via the DHCPD (Section 3.1) server and then magically booted from the tftp (Section 3.2) server, but all from the "wrong" interface.   It turns out that I had put the Eprom in eth1 ( the last card to boot up ) but all communication is via eth0 and no matter where the rom is, it will work. While the hardware adjusted for my error, my reasoning lagged a bit, so make good use of those post-it notes, in other words - label them.

It is probably mentioned in the documentation somewhere and someday I will read it all properly :-) but if you want to avoid confusing yourself then be aware of that trap.

2.3. Repeat - that's the first card

Knowing that bootup is via eth0 ( the first configured card in the boot up sequence ) we need to confirm which one it is. You can just note the MAC address from Etherboots start up display (eth0) or install Dachstein by the floppy method

If you choose to install Dachstein at this point, after configuring the all cards use dmesg or grep the appropriate log file ( /var/log/messages ).  Then make sure that you know eth0 from eth1.   With this information an important change will also need to be made to the network.conf file. If the extracdach.pl script is used then this will be done for you.

Dachstein is configured to assign eth0 to the external network and eth1 for the internal. From the above notes we realize that for etherboot this needs reversing. The extractdach.pl script will reverse these fields within the /etc/network.conf file.   If for some reason the conversion script breaks, or it all works until you attach to the modem, then check and make sure the above changes have been done correctly.    We want to be listening on the correct interface otherwise we will never find our internal DHCPD nor TFTP server.

3.1. Setup a working DHCP server

For this information the Etherboot Userman Setting up a DHCP daemon should be your first read.

At the very least you need to set up DHCPD to give an IP address to the machines card.

If no filename is given the current Etherboot 5.0.5 defaults to /tftpboot/kernel -- a file called kernel.     However it is safer to give a specific filename in /etc/dhcpd.conf so that "kernel" can be reserved for a fall-back netboot using something like tomsrtbt, as described in Section 6.1.

Under the chroot environment (-s switch), that path will actually be /tftpboot/tftpboot/kernel. This allows the first /tftpboot to be stripped off under the chroot environment, which then allows etherboot to "find" the file.

For the Dachstein/Etherboot setup, this netboot file will be lrp.nb so filename "firewall/lrp.nb"; would be the string to use within the /etc/dhcpd.conf file

If you need more info regarding DHCP then the following links should be enough to overwhelm you.  If you are using a new distribution such as RedHat 7.2 then be aware that any references to building the package from a tarball should not need to be pursued.  The rpms on the distributions installation disk should be easier to set up and will also include the necessary xinetd and init.d scripts.

The DHCP Links were found using this google search ... an unsubtle hint ... :-)

• DHCP mini-HOWTO

• Linux Networking HOWTO

• Network Nirvana:

If it helps, here is an extract from my dhcpd.conf that is specific to netbooting...

/etc/dhcpd.conf

   
    group   {
    use-host-decl-names       on;
    option log-servers        192.168.22.20;
host lance-test{
        hardware ethernet 00:80:4b:0a:05:14; # lance
        fixed-address 192.168.22.48;
        option host-name "lance-test";
        filename "firewall/lrp.nb";
        }
}
    

3.2. Setup the tftp server

For RedHat 7.2, one trap is to be aware of the xinetd file for the tftp daemon, this config file will install with the rpm for tftp however a few changes may be necessary. Besides enabling it you may want to turn on logging with "l" and become familiar with how the -s flag works.    Other distributions may well be different in their initial setup, so become familiar with them.

/etc/xinetd.d/tftp

# default: off
     # description: The tftp server serves files using the trivial file transfer \
     # protocol.  The tftp protocol is often used to boot diskless \
     # workstations, download configuration files to network-aware printers, \
     # and to start the installation process for some operating systems.
     service tftp
     {
            socket_type         = dgram
            protocol              = udp
            wait                    = yes
            user                    = root
            server                 = /usr/sbin/in.tftpd
            server_args         = -sl /tftpboot
      #    disable                = yes
     }

If the server args are as above (-s = chroot) then make sure the filename argument in /etc/dhcpd.conf is used without including the /tftpboot/ path.

In other words -- filename "firewall/lrp.nb" instead of filename "/tftpboot/firewall/lrp.nb". As usual, man tftp for the good oil on why and man chroot if the reasons are still vague.

I have changed the permissions by putting /tftpboot in the group nobody and making it searchable only, the same for the directories within. The files ( specifically, lrp.nb ) need to be readable by others for etherboot to load and run.

These alterations will be done by the extractdach.pl script and may seriously mess with an existing /tftpboot directories permissions. If you do have an existing setup then you may need to edit the script (if necessary) to suit that, then be prepared for more configuration changes.

4.1. Extract the LRP image

The following is a modified version of a file included with the Etherboot distribution, the original file can be found in the contrib/mklrpnb directory.    The new file is extractdach.pl and can be viewed here or as the workable perl script in Section 4.2 . There are some variables that need setting up first, so read the source.

On the first pass it will extract the lrp files to a base directory ( this is currently /usr/src/LRP/lrp-firewall ), within this newly created directory will be the expanded Dachstein distribution. It is now our working directory and will form the basis of the new distribution.

Additionally on the first pass the script will modify /linuxrc so that it does not try to mount and read the non-existent *.lrp files ( these are now transferred over the network in the lrp.nb file).   It also creates a /var/lib/lrpkg/package file which is built when using the floppy method.   This file allows the configuration files for the packages to be viewed using lrcfg on the netbooted machine.

Finally the script changes a boot error message to reflect the fact that this modified distribution cannot do backups, not entirely necessary but ...

With this netboot method, all mods are done to the expanded distribution in $dachnew.    When the changes are ready to be tested then the extractdach.pl script is run a second ( third, fourth... whatever ) time to build the netbootable images.    These images will be in /tftpboot/firewall/ as required by the /etc/dhcpd.conf and /etc/xinetd.d/tftp config files and is set by the extractdach.pl variable $tftpboot

The LRP source image can be read by extractdach.pl at any stage, it does not have to be the original version but instead can be a backup copy of an existing (working) install.  You will need to transfer this image onto the hard-drive with...

 dd < fd0u1680 > same_string_as_$image_in_extractdach.pl
  

for the 1.680meg image.    If the path and filename are not the same as the $image location then copy it over so that the script can do the rest of the work.  If you want to be sure you got something from the disk then use the following command to view it under /mnt/floppy...

mount -t msdos -o ro,loop same_string_as_$image_in_extractdach.pl /mnt/floppy
 

4.2. The extarctdach.pl script

#!/usr/bin/perl -w
#
# A program to make a netbootable image from a LRP firewall floppy
#
# Tested on a Dachstein Linux floppy image available from
# http://lrp1.steinkuehler.net/ or via http://leaf.sourceforge.net/

# The most recent version of this script and a companion HowTo is available at
# http://members.optushome.com.au/graybeard/linux/netboot.html
#
# Modified from the mklrpnb file found in the contrib/mklrpnb directory of the
# Etherboot source at http://etherboot.sourceforge.net/
#
# Modifications by Glenn McK <graybeard(at)users.sourceforge.net>
# $Id: netboot.html,v 1.19 2003/01/09 10:40:24 graybeard Exp $
##################################### 

# this entry will need changing
#$image = "/home/graybeard/etherboot/dachstein-v1.0.2-1680.bin";
$image = "/home/graybeard/etherboot/optustein/dachstein-v1.0.2-1680.bin";

#$image = "/home/graybeard/etherboot/bootdisk.bin";

# these can remain, but change them if desired
#
# the next argument defaults to firewall if no other name is passed via the
# command line, this will be the directory where distribution will be expanded
# under $base and also the directory in /tftpboot for lrp.nb

my $uniqdir = shift || 'firewall';

$mntdir   = "/mnt/floppy";          # where the above image file can be mounted
$tftpbase = "/tftpboot";
$tftpboot = "$tftpbase/$uniqdir";   # where the netboot images will be available
$base     = "/usr/src/LRP";
$dachorg = "$base/dach-org-$uniqdir"; # a copy required to make the distribution
$dachnew = "$base/lrp-$uniqdir";      # the base files for the new distribution
$packages = "$dachnew/var/lib/lrpkg"; # list to allow lrcfg to display Packages

# everything below should be okay
######################################

if ( !-e $image ) {
    print
"\n\tA valid LRP file and directory are required\n\tdownload one then edit $0\n\n";
    exit 1;
}
if ( !-d $base ) {
    mkdir( $base, 0700 );
}

if ( !-d $dachorg ) {
    mkdir( $dachorg, 0700 );
}

if ( !-d $dachnew ) {
    mkdir( $dachnew, 0700 );
    `umount $mntdir`;
    `mount -t msdos -o ro,loop $image $mntdir`;

    `cp -vr $mntdir/* $dachorg/`;

    @cfg = `cat $mntdir/syslinux.cfg`;

    unless ( defined(@cfg) ) {
        print "Cannot find syslinux.cfg on $mntdir\n";
        exit 1;
    }
    print "cfg = @cfg\n";
    ($append) = grep( /append/, @cfg );    # find the append= line
    print "append = \n$append\n";
    chomp($append);                        # remove trailing newline
    $append =~ s/append=//;                # remove the append= at beginning
    print "strip append = \n$append\n\n";
    @args = split ( / /, $append );        # split into arguments at whitespace
    ($root) = grep( /^initrd=/, @args );   # find the initrd= argument
    $root =~ s/^initrd=//;                 # remove the initrd= at beginning
    $root =~ s/\.lrp$//;                   # cleanup for paclages list
    print "strip initrd = \n$root\n\n";
    ($lrp) = grep( /^LRP=/, @args );       # find the LRP= argument
    $lrp =~ s/^LRP=//;                     # remove the LRP= at beginning
    print "strip LRP =\n$lrp\n\n";
    @lrp = split ( /,/, $lrp );            # split into filenames at ,
    unshift ( @lrp, $root );               # prepend the root LRP filename
    @pack = @lrp;
    print "LRP =\n@lrp\n\n";
    $append = '';

    foreach $i (@args) {                   # rebuild the append string
        next if ( $i =~ /^initrd=/ );      # minus the unneeded parameters
        next if ( $i =~ /^LRP=/ );
        next if ( $i =~ /^boot=/ );
        next if ( $i =~ /^PKGPATH=/ );
        print "$i = i\n";
        $append .= "$i ";
    }

    print "final append = \n$append\n";

    chdir($dachnew) or die "$dachnew: $!\n";
    foreach $i (@lrp) {
        $i .= '.lrp' if $i !~ /\.lrp$/;
        print "\n\n\nUnpacking $i\n";
        system("ln -svf $dachorg/$i ${dachorg}/${i}.tar.gz");
        chmod 0600, "$dachorg/$i";
        system("cat $mntdir/$i | tar zxvf -");
    }

    # create file for lrcfg to display packages
    open( PACKAGES, ">$packages/packages" )
      || print "unable to modify $packages:$!\n";
    foreach $line (@pack) {
        print PACKAGES "$line\n";
    }
    close PACKAGES;

    # prevent previous file from being overwritten during installation
    # and also mess with some values in /linuxrc to hide non errors
    open( LINUXRC, "$packages/root.linuxrc" );
    @text = <LINUXRC>;
    close LINUXRC;
    open( LINUXRC, ">$packages/root.linuxrc" );
    foreach $line (@text) {
        $line =~ s/PFX\/packages/PFX\/packages-old \
\t\t\t\t# packages changed to packages-old for netboot setup/;
        $line =~
s/^rc=1/# rc=1 changed to rc=0 to suppress error messages for netboot setup \
rc=0/;
        $line =~
s/echo -n \" \(nf\!\)\"/#echo -n \" \(nf\!\)\" changed to reflect ToDo list \
\t\t\techo -n \" netboot setup - No backups possible from this machine - ToFix ?"/;
        print LINUXRC $line;
    }
    close LINUXRC;

    # swap interfaces around in network config file
    # eth1 is the new external eth0 is OUR internal server access
    open( NETWORK, "$dachnew/etc/network.conf" )
      || print "Unable to modify NETWORK:$!\n";
    @text = <NETWORK>;
    close NETWORK;
    open( NETWORK, ">$dachnew/etc/network.conf" )
      || print "Unable to modify NETWORK:$!\n";
    foreach $line (@text) {
        $line =~ s/eth0/eth00/;
        $line =~ s/eth1/eth0/;
        $line =~ s/eth00/eth1/;
        print NETWORK $line;
    }
    close NETWORK;

    `echo $append > $dachorg/appendstr`;

    `umount /mnt/floppy`;
    print "\nThe files have been extracted to $dachnew\n";
    system("ls -al $dachnew");
}
else {
    print "\n\n\t$image \n \thas already been extracted to $dachnew \
\tNow skipping to the next step where the netboot file\
\twill be created.\n";

    $append = `cat $dachorg/appendstr`;
    print "\nThe new append string will be...\n$append\n";

    chdir($dachnew);
    if ( !-d $tftpbase ) {
        mkdir( $tftpbase, 0710 );
        system("chgrp nobody $tftpbase");
    }

    unlink($tftpboot);

    # these permissions really need changing to something secure
    mkdir( $tftpboot, 0710 );
    system("chgrp nobody $tftpboot");
    print "\tRepacking to $tftpboot/lrp.lrp\n";
    system("tar zcf $tftpboot/lrp.lrp *");
    print "\tExtracting kernel image from $dachorg\n";
    system("cat $dachorg/linux > $tftpboot/lrp.ker");
    print "\tCreating netboot image $tftpboot/lrp.nb\n";
    system(
"mknbi-linux --append='$append' --output=$tftpboot/lrp.nb $tftpboot/lrp.ker $tftpboot/lrp.lrp"
    );
    chmod 0604, "$tftpboot/lrp.nb", "$tftpboot/lrp.ker", "$tftpboot/lrp.lrp";
    print "\nThese netboot files are in $tftpboot\n";
    system("ls -al $tftpboot");
    print "\n   The owner and permissions for $tftpboot \
 and files should be checked for security. The above\
permissions assume that tftp is running chroot (nobody)
      drwx--r---   root:nobody   /tftpboot\n\n";
}

exit 0;

4.3. How to add extra lrp Modules

The LRP files have the extension .lrp which are tar.gz files in disguise; so to add a module to your new distribution you need to download the appropriate *.lrp file and rename it to have the extension .tar.gz.     Once that's done then extract the enclosed files to the /usr/src/LRP/lrp-firewall directory and update /var/lib/lrpkg/packages as this file contains the names of any modules installed.  If you fail to add the entry to packages it will not display in lrcfg.    We cannot use the script directly for backup to the tftp server, however it is still useful and the absence of those entries could cause confusion later.

   weblet.lrp becomes
    weblet.tar.gz
    lastly the
    /usr/src/LRP/lrp-firewall/var/packages file is updated with the name weblet

4.4. Run lrcfg and modify the scripts

Time to move on to the second part of the project, or was it the first?

On the router - firewall if you accept the default name - you will need to configure the machine to get an assigned IP from your ISP, as well as setting up routing and configuring the firewall.

The usual deal when running an LRP machine from floppy, hard drive or whatever, is to execute lrcfg and follow the menus till all the configurations are done. In our case lrcfg will not be quite as useful, there are no backups available from this menu for starters; but it can serve as a useful prompt to work out which files to modify back on the tftp server.

If you install the ssh.lrp module this will make available the scp command for the transfer of files between machines. This will assist in keeping the two versions (client and server) synced

The firewall script was not my friend but we get along Okay now :-) Back when I was running Eigerstein I wimped it and just ran my own script after the machine booted up, bypassing all that scripting work the LRP team have done.    Eventually though I decided to use it, in truth the dynamic IPs we now get with Optus forced the rethink.   It was worth the effort to understand it

To assist with configuring Dachstein, the README network.txt is invaluable and has a useful section labeled "IP FILTER SETUP"

I'll add to this section as needed and may even upload an image suitable for the Optus network, but later........Perhaps the scripts are needed first but this HowTo is primarily about Netbooting the Dachstein/Eigerstein distributions. and if I don't get this page uploaded now it will take another six months to do.

4.5. Serial Console

We've now got the start of a compact setup. To run headless should be the next step to save space and also for convenience.

We are also able to get most of our boot messages with a serial console. To do this we set up minicom to run on the internal machine, with a null modem cable between the serial ports; that's between the router and minicom --- not between the.... Ah forget it..;-)

The Eigerstein HowTos have a quick rundown on enabling the serial port.    You need to replace the kernel that came with the 1.68 meg floppy with one that supports a serial console during boot up, if you want all the console output.

Basically.... Rename linux-2.2.19-3-LEAF-normal.zImage.upx to linux and replace the file in $dachorg.    Add the serial module to /etc/modules then edit /etc/inittab by adding the appropriate strings to $dachorg/appendstr ( view the extractdach.pl script to find it )

For example purposes only, this is the $dachorg/appendstr that I use ....

load_ramdisk=1 initrd_archive=minix ramdisk_size=6144
root=/dev/ram0 console=ttyS1,115200n8

along with this in /etc/inittab

T1:23:respawn:/sbin/getty -L ttyS1 115200 vt102

additionally you may need to comment out the terminals otherwise you will get the infamous INIT: Id "1" respawning too: fast disabled for 5 minutes message if you elected to remove the video card from the machine.

# Format:
#  <id><runlevels><action><process>
#1:2345:respawn:/sbin/getty 38400 tty1
#2:23:respawn:/sbin/getty 38400 tty2

finally /etc/securetty needs an entry to enable root access to /dev/ttyS1

ttyS1

This will give a serial console on ttyS01 ( com b or async 2 .)     When the serial connection is fully enabled everything will be displayed from the moment the bootrom takes control to when shutdown displays "Power down".     The only thing missing is the ability to configure the BIOS, a small loss considering the gain.

Catching the boot process at the bootrom start-up also allows the menu feature to be used. If you have configured this menu then the netboot can be bypassed and a local drive mounted instead.

If you opt for the full serial setup ( replacing the kernel as outlined above ) then you will also need to set the Etherboot options appropriately when configuring it.     Using rom-o-matic the following options will need due attention.

CONSOLE_SERIAL 
    set for serial console. 
 CONSOLE_DUAL   
    set for CRT and serial console, see comment at -DANSIESC and -DGFX  
    COMCONSOLE:   
    set port, e.g. 0x3F8  
    CONSPEED:   
    set speed, e.g. 57600  
    COMPARM:   
    set Line Control Register value for data bits, stop bits and parity.
    

There will be NO other console with the above configuration, if you want a keyboard and monitor for the initial setup process then the serial HowTo is your friend.    Briefly :- insert console=tty0 into the $dachorg/appendstr string, like so (all on one line though)....

load_ramdisk=1 initrd_archive=minix ramdisk_size=6144
root=/dev/ram0 console=tty0 console=ttyS1,115200n8

and leave those terminal entries uncommented within the inittab file.

If you can score yourself a 16550A uart chip for the serial port then do so. These seem to be rather scarce but are a slightly quicker on throughput as the Serial HowTo explains.    However the common 16450 is quite usable considering what we are expecting from it.

cat /var/log/messages | grep ttyS

ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A

The serial cable (null modem) I use is a DTE<=>DTE using 7 wires, but a better description lies at the nullmodem site in the form of the first image, or the one labeled "Common Null-Modem Connection"

There are a few terminal clients around, I have used minicom and it's almost satisfactory ;-)

One BIG advantage of a serial connection is that when you run something such as tcpdump over the remote link, there is no need to hit yourself with the cluestick afterwards.    You did install ssh as well?

4.6. Ditch unneeded cards and check

Depending on the motherboard you may be able to ditch the video card, the floppy and hard drive can go along with the i/o card - unless the serial port is soldered to it. Try it and see!    If the only complaint from the BIOS is a series of annoying beeps just disconnect the speaker lead.

Removing unnecessary cards will reduce power consumption along with the amount of heat produced.

  READ and take HEED of the warning on the power supply BEFORE OPENING it 
                 and modding the internals.
  The voltages ARE LETHAL and you DO need to KNOW what you are doing.
   

Braver people than I have disconnected the fan from the computers power-supply unit    :-)    I was able to get a power supply that used a thermistor circuit in the fans power lead and have used this instead.    It works well and the fan operates at a reduced speed, if the box ever gets hot the sensor should detect it and increase the speed (cooling) accordingly.

I have back traced the circuit in my supply and it can be found at Section 7.2, but visit the following links to get a better background and also other, perhaps more appropriate, designs.

• Keeping the Fans Quiet - Power Control Methods Has a wealth of information and good links

• One of the above links is unfortunately broken but it still lives here

• This circuit is very close to the money and gives a good description as well.

• Under the heading "Optional very dangerous" (at the bottom of that page) is an interesting idea.    I would not do it myself, however the addition of some extra (small) holes in the top cover could be a suitable compromise.

Obviously the thermistor has to be placed in a position that allows it to perform some speed regulation for the required temperatures, placing it directly on the heatsink or in the bottom corner of the power supply box would be two useless extremes.

 DO NOT work on the Power Supply with the box OPEN AND switched ON.
  Even if recently turned off the capacitors may
   still HOLD enough CHARGE to supply 240 volts

5.1. How do you make an eprom for the NIC?

The following almost deserves a page of its own but...

If you can afford or are able to use the new type of PCI NIC with a flashable rom then you can skip this section and just do the deed.    If you are stuck with an ISA or non-flashable type then you will need to continue on.

    Words from the wise.... Before the eprom is burnt, make sure it has all been tested with a
   a floppy rom image. Even if burning eproms is trivial erasing them is not.
  
 

5.2. Where to get an eprom OR what are they?

It depends on the type or size of eprom needed but with that old 386(486) board, the one you saved because you knew it would come in handy one day - in spite of the leaking battery, the chances are good that you'll find one.    Check that beneath the sticker on the BIOS chip there is a glass like window, if so then carefully pop the chip (28 pin dip) and you will have an eprom of hopefully the correct size (27c256 seems to be the most common.)

Video cards can also be a good supply for eproms (especially the older ones).    You will need to pay attention to the existence or otherwise of that "glass window". When the manufacturer settled on their code or perhaps when volumes made it worthwhile, they would change over to PROMs which means no reprogramming allowed.

Now that you know what they look like, you'll find them "everywhere" ;-)

Or you can buy one (two?) ;-)

5.3. Burning an image

An Eprom burner? well this might be slightly harder to find. Ask amongst your Electronics friends, build one or if your local then, mail me and we'll work something out.

If you want to follow up on my eprom burning offer, I live in Australia.   I'll do it for nix - you supply the eprom and postage & handling costs, test your image out first using the methods described on the Etherboot page and remember; all care but no warranty :)

There is also a design within the Diskless-HOWTO. That one runs on linux, unlike the others

I have not built the Eprom Burners linked to above, so I'm only assuming they will deliver the goods, however I have built this one linked to from here.   There is also a forum accessible from that last link.     This is a more detailed version that will burn a range of flash Roms as well. I needed that one originally so it was worth my effort. YMMV.

5.4. Erasing the eproms

If you build the eprom burner then it is not much good without an U.V. eraser. You can source a commercial unit or you can wait a fortnight or two for sunlight or fluorescent tubes to work their magic - but then that's not really an option.

If you want something in the middle then Mikes site gives the run down on converting one particular brand of torch to use as an eraser.    This style of torch is available in Australia at the discount stores, but the globes are not.     As luck would have it though there is also a torch sold here that takes tubes that are next size up and these UV tubes are available, so it is a possibility. You could be lucky in your locality!

Another option is the barbers fluorescent sterilizing cabinet.    The short length UV also goes under the name of Germicidal thus the sterilizing cabinet will work.    I should add that it works VERY well; it's what I use, I've never run it at full capacity though (~150 eproms) - for some reason!?

Once you have a burner, remember that the Etherboot project is not only about netbooting your firewall, X terminals can consume the rest of your spare time.

5.5. Safety

The UV source required to erase the eproms is at the short end of the spectrum, which is potentially dangerous to our health. That link is quite informative and not just from a safety aspect so I'd encourage you to read it, other informative links can be found with this or a similar search

6.1. To boot Tomsrtbt via boot-rom

While we are at it, why not?

If nothing else it is a neat trick and it can be used to prove the netboot process quickly. Having this well recognized recovery "disk" easily accessible will increase its usefulness.

Subject: [Etherboot-users] netbooting tomsrtbt
From: ken_yap.users.sourceforge.net
Date: Sat, 29 Dec 2001 19:53:38 +1100
To: Etherboot users list <etherboot-users.lists.sourceforge.net>
From etherboot-users-admin.lists.sourceforge.net Sat Dec 29 20:05:37 2001
Reply-To: Etherboot users list <etherboot-users.lists.sourceforge.net>


I struggled for a while to make the floppy version netbootable then
remembered there is a CD version of tomsrtbt. This one turned out to be
a cinch to netboot. So here are the notes.

Notes on turning tomsrtbt El Torito into a Etherboot image:

0. Tomsrtbt (http://www.toms.net/) is an all-purpose rescue and utility
1-floppy Linux system. You can read all about it at the web site. These
notes explain how to turn the El Torito version of it into a netbootable
image for Etherboot.  Note that the .img file is not an ISO image, it is
a 2.88M floppy emulation image for writing onto a CD-R(W) with mkisofs.
It's actually a minix filesystem.  Inside it is the kernel zImage and
initrd.gz.

1. First uncompress the .img:

        bunzip2 tomsrtbt-1.7.361.ElTorito.288.img.bz2

2. Mount the image using loopback. You probably need to be root to do
this:

        mount -o ro,loop tomsrtbt-1.7.361.ElTorito.288.img /media/floppy

I've specified /media/floppy which is the floppy mount point for my
system, but any convenient directory will do.

3. Copy the kernel image and initrd off it:

        cp -p /media/floppy/zImage /media/floppy/initrd.gz .

4. Use mknbi-linux (or mkelf-linux) to make a netbootable image:

mknbi-linux --append='root=100' zImage initrd.gz > tomsrtbt.nb

root=100 means use /dev/ram0 (device 1,0) as the root device.

5. That's it. Clean up by unmounting the .img:

        umount /media/cdrom

tomsrtbt.nb can now be loaded with Etherboot. Have fun.

_______________________________________________
Etherboot-users mailing list
Etherboot-users.lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/etherboot-users

6.2. Another useful tool is Memtest86

Considering we use RAM for our filesystem, we should be confident of its health.

Memtest86 provides that solution.

Using etherboot to load memtest takes about a second - trying to measure it is pointless, it's running before you know it.  This quick startup makes it ideal for testing bad, or a lot of memory as there is no time involved (comparatively) in restarting it.  If you are unlucky enough to have to cycle through this process when eliminating chips you may appreciate having one less obstacle in your path.

I was using version 2.8 (Section 6.2.1) however Eric W. Biederman has improved the 2.9 version and it is usable for these small memory machines. I recommend that one (Section 6.2.2) for our 486, or low memory machines. The serial options for our serial setup are described below.

To get the serial console to work in the first place then read the README packaged with the source, the config.h file also holds the secret to faster baud rates.    After initially thinking they would not work I have since found I can run mine at 115200, which suits my existing minicom setup.    After you have built it with make, the file memtest needs to be moved to your /tftpboot directory and some means of loading it enabled.

Incidentally, I do not have a selection menu on the firewall so if I want to load this I either symlink it or edit /etc/dhcpd.conf and restart the dhcpd daemon.  You now get to choose your own method :-)

#define serial_echo_outb(v,a) outb((v),(a)+0x3f8)
#define serial_echo_inb(a)    inb((a)+0x3f8)

#define serial_echo_outb(v,a) outb((v),(a)+0x2f8)
#define serial_echo_inb(a)    inb((a)+0x2f8)

#define serial_echo_outb(v,a) outb((v),(a)+0x3f8)
#define serial_echo_inb(a)    inb((a)+0x3f8)

#define serial_echo_outb(v,a) outb((v),(a)+0xf8)
#define serial_echo_inb(a)    inb((a)+0x3f8)

/*v->firmware = FIRMWARE_UNKNOWN;*/

7.1. An example, if the card driver cannot be found....

I have used an Eagle systems Intl ISA card which uses the lance driver under Linux quite happily. The Etherboot Drivers list does not ( Okay that's a didn't because it does now ;-) ) list it under the AMD section and the Etherboot driver for lance is for a PCI card.

The main chip on the network card is identified as an AM79C960KC  243GB5M  © 1992 AMD.  Using this we grep the source tree (after compiling the drivers) for the string "79C960" with the following result ...

09:34pm $grep -r src -e 79C960
      src/depca.c:   
         4) "Am79C960 PCnet-ISA(tm), Single-Chip Ethernet Controller for ISA",
      Binary file src/bin32/ni6510.img matches
      Binary file src/bin32/ni6510.rom matches
      Binary file src/bin32/ni6510.tmp matches
      Binary file src/bin32/lance.o matches
      Binary file src/bin32/ni6510.o matches
      Binary file src/bin32/pcnetfastiii.rom matches
      Binary file src/bin32/amdhomepna.rom matches
      Binary file src/bin32/ne2100.o matches
      Binary file src/bin32/ne2100.img matches
      Binary file src/bin32/ne2100.rom matches
      Binary file src/bin32/ne2100.tmp matches
      Binary file src/bin32/lance.img matches
      Binary file src/bin32/lance.tmp matches
      Binary file src/bin32/lancepci.rom matches
      src/lance.c:  {0x0003, "PCnet/ISA 79C960",        /* 79C960 PCnet/ISA.  */
      src/lance.c:      /* This is 79C960 specific; Turn on auto-select of media

So the 79C960 is there and as an ISA driver as well.

Investigating the associated .lzrom files we can dismiss the lance as it only comes as a PCI driver, Working down the list we eventually try the ne2100 and bingo we have a winner.   Of course if you had the manual it would tell you that the Novell ne2100 driver would have worked, but then manuals do not always come with second-hand cards.

The NIC page at the Rom-o-matic site or in the distributions src tree    etherboot-5.0.5/src/NIC    gives confirmation that the above files are indeed lance drivers but do not mention the 79C960 specifically.

7.2. Fan power regulator

This circuit needs to be read along with Section 4.6 and the warnings displayed there.     It is my representation of an existing circuit found with a power supply I had.   It is provided as a curiosity and I would expect only the adventurous or knowledgeable would want to pursue it, all the information I can help with is provided with it.

In that context, let me know if you get it working :-)

Depending on your browser, this fine example of ASCII art may appear to be garbled, to decrypt it you will need to use special tools.

In this case vi and only vi.

Okay -- the power lies with fixed fonts, so it needs to be viewed with anything that displays in fixed, cutting and pasting into vi will work a treat, as should other plain text editors.

.                ______________________________________o + input
                |   555d IC   |             __      |
 output   + o---|    o  o  o  o 1           /       | TTC 10k ohm
                |____   |  `------------\/\/\/--|   |  thermistor
                     |  |                 /     |   |
                     |  `--+------+--+----------'   |
 output   - o---|    |     |      |  |              |
                |    o  o  o  o   |  |              |
      |-----o e |       |     |   |  |   30k        |
      |         |       |     |   |  `--\/\/\/------'
      |   c o---'       |     | __|__
      |                 |     | _____
      |   b o---\/\/\/--'     |   |  104 poly cap
      |           1k          |   |
      |_______________________|___|____________________o - input

         9013 switching transistor NPN