Diskless booting can be a handy and wonderful thing.
Getting it to work involves tinkering with a variety of
things that are not often tinkered with, and this is a
short guide as to what these might be on a linux server.
lets you use a network card to do the diskless boot.
With older cards you will be most happy if you have a ROM burner
and some blank roms laying around. If you have a newer card, you
may be able to flash etherboot into the card (a bit risky and I
never have), or to set things up so that the on-card network
booting code (probably PXE) can pull in etherboot and go from
there. This "bounce boot" scheme is very nice and works great
for the Intel ether pro 100 and I am sure other cards.
In either case, you can download etherboot
and build rom images from the source, but you will probably find it
more convienent to pick up images from
You will need to setup a /etc/dhcpd.conf file.
Since I have done this once, I almost always have one laying
around to copy into place as use asa starting point.
Then you need to start the dhcp server (and make sure
it always gets started when the system reboots) via:
service dhcpd restart
chkconfig dhcpd on
If you hack on the config file, you must restart the server
before your changes will have any effect.
Very likely you will also need to open up port 67 on your firewall
for this to work.
The directory /tftpboot hold things that tftpd can dole
out, and usually tftpd is restricted to only serve files from
this directory for security reasons. You will have to turn on
the tftp server (it should never be on by default), but editing
the file /etc/xinetd.d/tftp and changing the disable line
from no to yes, then:
service xinetd restart
One particular diskless client (vxWorks) uses the remote shell
protocol to transfer file. This operates on port 514 (another
hole to punch in the firewall). It is good to write an
iptables rule that only opens this port up to the local net,
or better yet only to specific machines that need it.
The rsh service must be activated in the same was as TFTP
is, by editing /etc/xinetd.d/rsh and changing the
disable line from no to yes, then:
service xinetd restart
Security (such as it is with this protocol) is also controlled
by the .rhosts file in the home directory of the user
being used for file transfer, and is quite fussy about permissions
and ownership of this file.
iptables (the firewall)
I used to run the monmotha firewall script, but more recently
I decided to just monkey with the iptables scripts that come as
part of fedora. It turns out the key file to dork with here is
/etc/sysconfig/iptables. After fiddling with this to
open up UDP port 67 (for DHCP/BOOTP) and UDP port 68 (for TFTP),
you must as usual do:
service iptables restart
When things go wrong
Even after doing the usual jive described above, things still
were not working when I set up a new machine with Fedora Core 5.
One thing that seems to be relevant is that the DHCPD server
moved from ISC 3.0.2 to ISC 3.0.3 and the etherboot FAQ suggests
that the following line is now needed with the 3.0.3 server:
This tells etherboot what the IP number of the TFTP server is.
In general this is the same IP as the DHCP server (and this
used to be the default).
The ethereal (aka wireshark) packet sniffer is sometimes a handy
tool in these grim situations.
It is instructive to run the dhcp server in a console window when
sorting out problems. To do this:
service dhcpd stop
/usr/sbin/dhcpd -f -d
After doing this, I discover that some other machine on our subnet
is sending DHCPINFORM messages telling my server that he is authoritative
on my subnet and I am not. Apparently an authoritative server
may send DHCPNAK messages to veto address assignments from non
authoritative servers. Things work without my claiming to be
authoritative (which could be done with a single line in the
dhcpd.conf file), but it works just to ignore all the chatter from
this self-important windows box.
Drop me a line!
Uncle Tom's Computer Info / firstname.lastname@example.org