| Revision History | ||
|---|---|---|
| Revision 0.3 | 2002-04-28 | Revised by: bej |
| Many feedback inclusions, added links to several projects | ||
| Revision 0.2.2 | 2001-12-08 | Revised by: dcm |
| Licensed GFDL | ||
| Revision 0.2.1 | 2001-05-21 | Revised by: logilab |
| Fixed bibliography and artheader | ||
| Revision 0.2 | 2001-05-19 | Revised by: bej |
| Many improvements and included Ken Yap's feedback. | ||
| Revision 0.1.1 | 2001-04-09 | Revised by: logilab |
| First public draft. | ||
| Revision 0.1 | 2000-12-09 | Revised by: bej |
| Initial draft. | ||
Logilab sponsored this HOWTO. Check their website for new versions of this document. I also thank the etherboot, netboot, plume and linux terminal server project developers and webmasters, who made it really possible to boot a Linux worstation over a network.
Very special thanks go to Ken Yap, member of the etherboot project, whose comments greatly helped to improve the quality of this document.
I also thank Jerome Warnier, main developer of the plume project, Pierre Mondié, Kyle Bateman, Peter T. Breuer, Charles Howes, and Thomas Marteau for their comments and contributions.
A BOOTP daemon (a DHCP daemon may also do fine, but I won't explain how to configure this), a NFS daemon (if you want to mount the root filesystem on a remote server), are also required. We will also need a TFTP daemon if you plan to load the kernel remotely. At last, the mknbi utility provided with the etherboot distribution, and, if you use LanWorks EPROMs, like those included in the 3c905 3com ethernet adapter, you will also need the imggen utility, available at http://www.ltsp.org/contrib/.
There are many sources of information on network booting, but, and this is why I wrote this HOWTO, none describes all the existing ways of booting over a network, and much of them are specific to a way of operating. The most useful to me has been the documentation provided by the linux terminal server project, although I did not use the packages they recommend, and I have chosen to describe here how to proceed without these packages, because they configure things so that every application program is executed remotely on a server. Useful information can also be found on the etherboot project's homepage.
At last, you can also find useful but succinct information in the kernel's source tree, in /usr/src/linux/Documentation, assuming your kernel source tree resides in /usr/src/linux.
I will highly appreciate any feedback about this document. Please feel free to mail me at <bbp@via.ecp.fr> if you have any comment, correction, or suggestion. You may also use <contact@logilab.fr>.
Hey, you think it's time to start with the real stuff, right? Here we go.
Issue the following commands on the server (the mknbi package should be installed):
# cd /tftpboot
# chmod 0555 zImage
# chown root:root zImage
# mknbi-linux zImage --output=kernel --rootdir=/nfsroot
|
If you are using LanWorks EPROMs, also issue the following commands (you need the imggen utility):
# mv -f kernel tmpkernel
# imggen -a tmpkernel kernel
# rm -f tmpkernel
|
Create an empty filesystem with the appropriate size on this ramdisk:
# mke2fs -m0 /dev/ram0 300 |
# mount -t ext2 /dev/ram0 /mnt |
# cp -a /tmp/rootfs/* /mnt |
# umount /mnt |
Save the ramdisk image to some file and free it:
# dd if=/dev/ram0 of=initrd bs=1024 count=300 # freeramdisk /dev/ram0 |
Then, you have to modify the kernel image, as was told above, with the mknbi-linux utility. Its invocation will slightly differ from the above, though (I will assume your just compiled zImage resides in /tftpboot/zImage and your initial ramdisk image resides in /tmp/initrd):
# cd /tftpboot
# chmod 0555 zImage
# chown root:root zImage
# rdev zImage /dev/ram0
# mknbi-linux zImage --output=kernel --rootdir=/dev/ram0 /tmp/initrd
|
.default\
:sm=your subnet mask\
:ds=the IP address of your DNS server\
:ht=ethernet\
:dn=your domain name\
:gw=the IP address of your gateway\
:sa=the IP address of the TFTP server\
:bf=path to find the kernel image\
:rp=path of the root filesystem\
:hn
|
Then, add an entry per client in your network. An entry should look like this:
dns of the client\
:ha=MAC address of the client\
:ip=IP address of the client
|
Here is a sample /etc/bootptab file:
.default\
:sm=255.255.0.0\
:ds=192.168.0.2\
:ht=ethernet\
:dn=frtest.org\
:gw=192.168.0.1\
:sa=192.168.0.2\
:bf=/tftpboot/kernel\
:rp=/nfsroot\
:hn
foo\
:ha=001122334455\
:ip=192.168.2.12
bar\
:ha=00FFEEDDCCBB\
:ip=192.168.12.42\
:ds=192.168.2.42
|
bootps dgram udp wait root /usr/sbin/tcpd bootpd -i -t 120
|
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot
|
# cd /usr/src/linux
# make modules_install INSTALL_MOD_PATH=/nfsroot
|
# cd /nfsroot
# touch fastboot
# chmod 0 fastboot
|
# cd /nfsroot/sbin
# ln -s ../bin/true fsck.nfs
|
# this part only if you don't use devfs
mke2fs -q -i 1024 /dev/ram0 16384
mount -n -t ext2 -o rw,suid,dev,exec, \
async,nocheck /dev/ram0 /dev
# this part for everyone
mke2fs -q -i 1024 /dev/ram1 16384
mount -n -t ext2 -o rw,suid,dev,exec, \
async,nocheck /dev/ram1 /tmp
chmod 1777 /tmp
cp -a /etc /tmp
mke2fs -q -i 1024 /dev/ram2 16384
mount -n -t ext2 -o rw,suid,dev,exec, \
async,nocheck /dev/ram2 /etc
find /tmp/etc -maxdepth 1 -exec cp -a '{}' /etc ';'
mount -f -t ext2 -o rw,suid,dev,exec, \
async,nocheck,remount /dev/ram2 /etc
mount -f -o remount /
cp -a /var /tmp
mke2fs -q -i 1024 /dev/ram3 16384
mount -t ext2 -o rw,suid,dev,exec, \
async,nocheck /dev/ram3 /var
find /tmp/var -maxdepth 1 -exec cp -a '{}' /var ';'
|
IPADDR="$(bootpc | awk '/IPADDR/ \
{
match($0,"[A-Za-z]+")
s=substr($0,RSTART+RLENGTH)
match(s,"[0-9.]+")
print substr(s,RSTART,RLENGTH)
}
')"
HOST="$(bootpc | awk '/HOSTNAME/ \
{
match($0,"[A-Za-z]+")
s=substr($0,RSTART+RLENGTH)
match(s,"[A-Za-z0-9-]+")
print substr(s,RSTART,RLENGTH)
}')"
DOMAIN="$(bootpc | awk '/DOMAIN/ \
{
match($0,"[A-Za-z]+")
s=substr($0,RSTART+RLENGTH)
match(s,"[A-Za-z0-9-.]+")
print substr(s,RSTART,RLENGTH)
}')"
|
*.* /dev/tty12
*.* @dns or IP of the logs server
|
# rm -f /etc/logrotate.conf
# touch /etc/logrotate.conf
|
# dd if=zImage of=/dev/fd0 bs=8192
|
However, Alan Cox told in a linux-kernel thread that this feature of the linux kernel will be removed sooner or later, you thus will have to use a bootloader even on floppies some day. I know this still works with 2.4.11 kernels, but support seems to have been removed in the 2.4.13 version. See the sixth chapter of the boot-disk-HOWTO for this topic.
For a list of EPROM burner manufacturers visit the Yahoo site and go to economy->company->Hardware->Peripherals->Device programmers or check out the old Diskless-HOWTO List of EPROM burner manufacturers section.
If you choose to create your own ROMS, you will have to load a BOOTP or DHCP capable software in the ROM, and then, you will be in the case of BOOTP or DHCP capable NICs described above.
You will also need to find the proper EPROM size and speed for your NIC. Some methods to do so are provided in appendix, because the NICs manufacturers often do not provide this information.
Bwimage package: ftp://ftp.ipp.mpg.de/pub/ipp/wls/linux/bwimage-0.1.tgz
LanWorks BootWare Boot ROMs: http://www.3com.com/lanworks
Refer to the README file for installation details. Currently, only "zImage"-type kernels are supported. Unfortunately, kernel parameters are ignored.
This section was initially written by Jochen Kmietsch for the Diskless-HOWTO, email to: <jochen.kmietsch@tu-clausthal.de> for any questions.
This section was originally written by Hans de Goede <j.w.r.degoede@et.tudelft.nl> for the Diskless-root-NFS-HOWTO. I modified it slightly in order to reflect some differences between this document and the Diskless-root-NFS-HOWTO.
Much of the above also goes for booting from cdrom. Why would one want to boot a machine from cdrom? Booting from cdrom is interesting everywhere one wants to run a very specific application, like a kiosk, a library database program or an internet cafe, and one doesn't have a network or a server to use a root over nfs setup.
Now that we know what we want to do and how, it's time to create a test setup:
Configure the test setup as described above with the root filesystem mounted read only.
Verify that the test setup automagically boots and everything works.
Boot the main install and mount the 650 MB partition on /test of the main install.
#/var
echo Creating /var ...
mke2fs -q -i 1024 /dev/ram1 16384
mount /dev/ram1 /var -o defaults,rw
cp -a /lib/var /
|
#to boot from cdrom
. /etc/rc.d/rc.iso
|
#!/bin/sh
echo tmp
rm -fR /test/tmp
ln -s var/tmp /test/tmp
###
echo mtab
touch /test/proc/mounts
rm /test/etc/mtab
ln -s /proc/mounts /test/etc/mtab
###
echo var
mv /test/var/lib /test/lib/var-lib
mv /test/var /test/lib
mkdir /test/var
ln -s /lib/var-lib /test/lib/var/lib
rm -fR /test/lib/var/catman
rm -fR /test/lib/var/log/httpd
rm -f /test/lib/var/log/samba/*
for i in `find /test/lib/var/log -type f`; do
cat /dev/null > $i;
done
rm `find /test/lib/var/lock -type f`
rm `find /test/lib/var/run -type f`
|
Remove the creation of /etc/issue* from /test/etc/rc.local: it will only fail.
# mount -o remount,rw /
|
If you need more information than you can find below, please refer to the CD-Writing-HOWTO.
Mount boot.img somewhere through loopback by typing:
# mount boot.img somewhere -o loop -t vfat
|
Remove everything from boot.img except for ldlinux.sys and syslinux.cfg.
default linux
label linux
kernel zImage
append root=/dev/<insert your cdrom device here>
|
# umount somewhere
|
# losetup -d /dev/loop0
|
Now generate the image by typing:
# mkisofs -R -b boot.img -c boot.catalog -o boot.iso /test
|
Mounting the image through the loopbackdevice by typing:
# mount boot.iso somewhere -o loop -t iso9660
|
# umount somewhere
|
# losetup -d /dev/loop0
|
Assuming that you've got cdrecord installed and configured for your cd-writer type:
# cdrecord -v speed=<desired writing speed> dev=<path to your writers generic scsi device> boot.iso
|
Since MS-Windows does not support diskless booting, a simple workaround is presented here: the solution is to use software like VMWare or its free alternative, plex86. Although the plex86 seems to have been abandonned, one can still boot certain versions of MS-Windows using this software. These enable MS-Windows to be executed transparently on the linux box.
# mkdir /nfsroot/tmp/var
# chmod 0 /nfsroot/tmp/var
# ln -s /tmp/var /nfsroot/var/tmp
|
If your stations do not have enough memory and do not have local drives, you may want to swap over NFS. You have to be warned the cod eto do so is still under development and this method is generally quite slow. The full documentation for this can be found at http://www.instmath.rwth-aachen.de/~heine/nfs-swap/.
The first thing to do if you want to apply this solution is to patch your kernel (you need a kernel version 2.2 or above). First download the patch at the above url, and cd to /usr/src/linux. I assume the patch is in /usr/src/patch. Then issue the following command:
# cat ../patch | patch -p1 -l -s
|
Then export a directory read-write and no_root_squash from the NFS server. Setup the clients so that they will mount it somewhere (say on /mnt/swap). It should be mounted with a rsize and wsize smaller than the page size used by the kernel (ie. 4 kilobytes on Intel architectures), otherwise your machine may run out of memory due to memory fragmentation; see the nfs manual page for details about rsize and wsize. Now, to create a 20 MB swap file, issue the following commands (which should be placed in the clients'initialization scripts):
# dd if=/dev/zero of=/mnt/swap/swapfile bs=1k count=20480
# mkswap /mnt/swap/swapfile
# swapon /mnt/swap/swapfile
|
Let's say a word about the drawbacks of NFS swapping: the first drawback is that it is generally slow, except you have specially fast network cards. Then, this possibility has not been very well tested yet. At last, this is not secure at all: anyone on the network is able to read the swapped data.
# dd if=/dev/zero of=/swap/swapfile bs=1k count=20480
# nbd-server NBDclient 1024 /swap/swapfile
# mkswap /swap/swapfile
|
# swapon /dev/nd0
|
The following commands, issued on the server may solve the problem:
# ln -s /proc/mounts /nfsroot/etc/mtab
# touch /nfsroot/proc/mounts
|
# (perl -e 'print "\xFF" x 16384'; cat bin32/3c509.lzrom) > 32kbimage
|
If you have your own EPROM programming hardware, there is a nice collection of EPROM file format conversion utilities at http://www.canb.auug.org.au/~millerp/srecord.html. The files produced by the Etherboot build process are plain binary. A simple binary to Intel hex format converter can be found at the Etherboot web site at http://etherboot.sourceforge.net/bin2intelhex.c. You may alternatively use the objcopy utility, included in the binutils package:
# objcopy --input-target binary --output-target ihex binary.file intelhex.file
# objcopy --input-target ihex --output-target binary intelhex.file binary.file
|
Etherboot is believed to make PnP compliant ROMs for PCI NICs. A long-standing bug in the headers has been tracked down. However some faulty old BIOSes are out there so I have written a Perl script swapdevids.pl to switch the header around if necessary. You'll have to experiment with it both ways to find out which works. Or you could dump a ROM image that works (e.g. RPL, PXE ROM) using the Perl script disrom.pl. The fields to look at are Device (base, sub, interface) Type. It should be 02 00 00, but some BIOSes want 00 00 02 due to ambiguity in the original specification.
The original Diskless-HOWTO mentions the names of the following vendors of diskless computers:
Linux Systems Labs Inc., USA http://www.lsl.com. Click on "Shop On-line" and then click on "HardWare" where all the diskless computers will be listed. Phone 1-888-LINUX-88.
Diskless Workstations Corporation, USA http://www.disklessworkstations.com.
Unique Systems of Holland Inc., Ohio, USA http://www.uniqsys.com
[Diskless-root-NFS-HOWTO] Diskless-root-NFS-HOWTO.
http://www.linuxdoc.org/HOWTO/Diskless-root-NFS-HOWTO.html
[ltsp] linux terminal server project.
A set of utilities and documentation for diskless stations, based on the red hat distribution.
http://www.ltsp.org
[plume] plume.
A beginning project whose goal is to provide a set of utilities for diskless stations and associated servers, based on the debian distribution.
http://plume.sourceforge.net