1437 lines
73 KiB
Plaintext
1437 lines
73 KiB
Plaintext
|
Network Boot and Exotic Root HOWTO
|
|||
|
|
|||
|
Brieuc Jeunhomme
|
|||
|
|
|||
|
frtest
|
|||
|
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>bbp@via.ecp.fr
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
|
|||
|
Logilab S.A.
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|
|||
|
This document explains how to quickly setup a linux server to provide what
|
|||
|
diskless linux clients require to get up and running, using an IP network. It
|
|||
|
includes data and partly rewritten text from the Diskless-HOWTO, the
|
|||
|
Diskless-root-NFS-HOWTO, the linux kernel documentation, the etherboot
|
|||
|
project's documentation, the linux terminal server project's homepage, and
|
|||
|
the author's personal experience, acquired when working for Logilab.
|
|||
|
Eventually this document may end up deprecating the Diskless-HOWTO and
|
|||
|
Diskless-root-NFS-HOWTO. Please note that you'll also find useful information
|
|||
|
in the From-PowerUp-to-bash-prompt-HOWTO and the Thin-Client-HOWTO, and the
|
|||
|
Claus-Justus Heine's page about NFS swapping.
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
Table of Contents
|
|||
|
1. Introduction
|
|||
|
1.1. What is this all about?
|
|||
|
1.2. Thanks
|
|||
|
1.3. Diskless booting advocacy
|
|||
|
1.4. Requirements
|
|||
|
1.5. Acknowledgements and related documentation
|
|||
|
1.6. Feedback
|
|||
|
1.7. Copyright Information
|
|||
|
|
|||
|
|
|||
|
2. Diskless booting operation overview
|
|||
|
2.1. Obtaining IP parameters
|
|||
|
2.2. Loading the kernel
|
|||
|
2.3. Mounting the root filesystem
|
|||
|
2.4. Terminating the boot process
|
|||
|
|
|||
|
|
|||
|
3. Building the kernel
|
|||
|
3.1. When the root filesystem is on a ramdisk
|
|||
|
|
|||
|
|
|||
|
4. Daemons setup
|
|||
|
4.1. NFS daemon
|
|||
|
4.2. BOOTP daemon
|
|||
|
4.3. TFTP
|
|||
|
|
|||
|
|
|||
|
5. Clients setup, creation of the root filesystem
|
|||
|
5.1. Creating the first files and directories
|
|||
|
5.2. The /var and /etc directories
|
|||
|
5.3. Last details
|
|||
|
5.4. Trial...
|
|||
|
5.5. And Error!
|
|||
|
|
|||
|
|
|||
|
6. Several ways of obtaining the kernel
|
|||
|
6.1. BOOTP or DHCP capable NICs
|
|||
|
6.2. Kernel on a local floppy or hard drive
|
|||
|
6.3. Bootloader without kernel on a local floppy or hard drive
|
|||
|
6.4. Creating ROMs for the clients
|
|||
|
6.5. Local CDROM
|
|||
|
|
|||
|
|
|||
|
7. How to create diskless MS-Windows stations?
|
|||
|
8. Troubleshooting, tips, tricks, and useful links
|
|||
|
8.1. Transparently handling workstations'specific files
|
|||
|
8.2. Reducing diskless workstations'memory usage
|
|||
|
8.3. Swapping over NFS
|
|||
|
8.4. Swapping over network block devices
|
|||
|
8.5. Getting rid of error messages about /etc/mtab or unmounted
|
|||
|
directories on shutdown
|
|||
|
8.6. Installing new packages on workstations
|
|||
|
|
|||
|
|
|||
|
A. Non-Volatile Memory chips
|
|||
|
B. Determining the size and speed of EPROMs to plug in a NIC
|
|||
|
C. Companies selling diskless computers
|
|||
|
References
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
1.1. What is this all about?
|
|||
|
|
|||
|
Recent linux kernels offer the possibility to boot a linux box entirely from
|
|||
|
network, by loading its kernel and root filesystem from a server. In that
|
|||
|
case, the client may use several ways to get the first instructions it has to
|
|||
|
execute when booting: home made eproms, special network cards implementing
|
|||
|
the RARP, BOOTP or DHCP protocols, cdroms, or bootloaders loaded from a boot
|
|||
|
floppy or a local hard drive.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
1.2. Thanks
|
|||
|
|
|||
|
Logilab sponsored this HOWTO. Check their [http://www.logilab.org] 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<EFBFBD>, Kyle Bateman, Peter T. Breuer, Charles Howes, and Thomas Marteau for
|
|||
|
their comments and contributions.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
1.3. Diskless booting advocacy
|
|||
|
|
|||
|
1.3.1. Buying is cheaper than building
|
|||
|
|
|||
|
Sometimes, buying a diskless linux computer will be cheaper than building!
|
|||
|
Checkout the list of commercial sites given in appendix, which are selling
|
|||
|
diskless linux network cards and diskless computers. These companies do mass
|
|||
|
production of linux diskless computers selling millions of units and thereby
|
|||
|
reducing the cost per unit.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
1.3.2. Advantages of diskless computers
|
|||
|
|
|||
|
Diskless computers will become more and more popular in the next years. They
|
|||
|
will be very successful because of the availability of very high-speed
|
|||
|
network cards at very low prices. Today 100 Megabit per second (12.5<EFBFBD>MB per
|
|||
|
sec transfer rate) network cards are common and in about 1 to 2 years
|
|||
|
1000<EFBFBD>MBit (125<32>MB per sec transfer rate) network cards will become very cheap
|
|||
|
and will be the standard.
|
|||
|
|
|||
|
In near future, monitor manufacturers will place the CPU, NIC, RAM right
|
|||
|
inside the monitor to form a diskless computer. This eliminates the diskless
|
|||
|
computer box and saves space. The monitor will have outlet for mouse,
|
|||
|
keyboard, network RJ45 and power supply.
|
|||
|
|
|||
|
The following are benefits of using diskless computers:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Total cost of ownership is very low in case of diskless computers. Total
|
|||
|
cost of ownership is cost of initial purchasing<6E>+ cost of maintenance.
|
|||
|
The cost of maintenance is usually 3 to 5 times the cost of initial
|
|||
|
computer purchase and this cost is recurring year after year. In case of
|
|||
|
diskless computers, the cost of maintenance is completely eliminated.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>All the backups are centralized at one single main server.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>No need of UPS battery, air-conditioning, dust proof environment for
|
|||
|
diskless clients, only server needs UPS battery, A/C and dust proof
|
|||
|
environment.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>A better protection from virus attack<63>- Some computer virus cannot attack
|
|||
|
diskless computers as they do not have any hard disk. This kind of virus
|
|||
|
cannot do any damage to diskless computers. Only one single server box
|
|||
|
needs to be protected against virus attack. This saves millions of
|
|||
|
dollars for the company by avoiding installation of vaccines and cleaning
|
|||
|
the hard disks.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Servers can have large powerful/high performance hard disks, can optimize
|
|||
|
the usage of disk space via sharing by many diskless computer users.
|
|||
|
Fault tolerance of hard disk failure is possible by using RAID on main
|
|||
|
server.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>On some installations: sharing of central server RAM memory by many
|
|||
|
diskless computer users. For example, if many users are running a web
|
|||
|
browser remotely on a server, then there will be only one copy of this
|
|||
|
web browser in its RAM.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Very few system administrators required to maintain central server.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Zero administration at diskless client side. Diskless computers are
|
|||
|
absolutely maintenance free and troublefree.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Long life of diskless clients.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Eliminates install/upgrade of hardware, software on diskless client side.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Eliminates cost of cdrom, floppy, tape drive, modem, UPS battery, printer
|
|||
|
parallel ports, serial ports etc...
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Can operate in places like factory floor where a hard disk might be too
|
|||
|
fragile.
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
1.4. Requirements
|
|||
|
|
|||
|
1.4.1. Hardware requirements
|
|||
|
|
|||
|
The most important thing in order to boot from network is to have an
|
|||
|
equipment which enables the stations to execute a bootloader, which will get
|
|||
|
the kernel on the server and launch it. Another solution is to use a device
|
|||
|
which will load a local kernel, which will mount the root filesystem on the
|
|||
|
server. There are several solutions: home made eproms containing the first
|
|||
|
instructions to execute when booting the station, boot with BOOTP/DHCP
|
|||
|
capable network adapters, or a local floppy, a tiny hard drive, or a cdrom to
|
|||
|
load the kernel. Note that some vendors also sell network booting capable
|
|||
|
stations: for instance, some Sun stations implement the BOOTP protocol.
|
|||
|
|
|||
|
Other hardware requirements depend on the configuration you plan to use: on
|
|||
|
some sites, every application run by the stations is executed remotely on the
|
|||
|
server, this implies that a very high-performance server is required, but
|
|||
|
only light stations are required: depending on what they will have to do,
|
|||
|
80486 CPUs with 16<31>MB of RAM may be enough. On the other side, if application
|
|||
|
programs are really executed locally on the stations, the requirements for
|
|||
|
the stations depend completely on these applications. In that case, only a
|
|||
|
small server is required. A 80486 CPU with 32<33>MB of RAM will be sufficient
|
|||
|
for a small number of stations, but more memory will be necessary in very
|
|||
|
large installations with hundreds or thousands of machines. Note the server's
|
|||
|
CPU does not really matter for such an installation.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
1.4.2. Software requirements
|
|||
|
|
|||
|
Linux kernel version 2.0 or above sources are required. All tools required to
|
|||
|
build a linux kernel are also necessary (see the linux kernel documentation
|
|||
|
for more information on this).
|
|||
|
|
|||
|
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 [http://etherboot.sourceforge.net] 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/] http://www.ltsp.org/contrib/.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
1.5. Acknowledgements and related documentation
|
|||
|
|
|||
|
This documentation has been written for experimented system administrators,
|
|||
|
who are already aware of linux fundamentals, like the use of grep, sed, and
|
|||
|
awk, basic shell programming, the init process and the boot scripts, kernel
|
|||
|
compilation, and NFS server configuration. Experience of kernel arguments
|
|||
|
passing should also help. Information on these subjects can be found
|
|||
|
respectively in the grep, sed, awk, and bash man/info pages, in the
|
|||
|
Bootdisk-HOWTO, the From-PowerUp-To-Bash-Prompt-HOWTO, the Kernel-HOWTO, the
|
|||
|
BootPrompt-HOWTO, the bootparam man page, the rdev man page, the NFS-HOWTO,
|
|||
|
and the exports manual page.
|
|||
|
|
|||
|
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 [http://www.ltsp.org]
|
|||
|
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
|
|||
|
[http://etherboot.sourceforge.net] 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.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
1.6. Feedback
|
|||
|
|
|||
|
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>.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
1.7. Copyright Information
|
|||
|
|
|||
|
This document is copyrighted (c) 2001 and is distributed under the terms of
|
|||
|
the GNU Free Documentation License. You should have received a copy along
|
|||
|
with it. If not, it is available from [http://www.fsf.org/licenses/fdl.html]
|
|||
|
http://www.fsf.org/licenses/fdl.html.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
2. Diskless booting operation overview
|
|||
|
|
|||
|
Hey, you think it's time to start with the real stuff, right? Here we go.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
2.1. Obtaining IP parameters
|
|||
|
|
|||
|
One could wonder how a station may boot over an IP network if it doesn't even
|
|||
|
know its own IP address. In fact, three protocols enable the client to obtain
|
|||
|
this information and some additional configuration parameters:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>RARP: this is the simplest of these protocols. However I guess it does
|
|||
|
not enable the server to specify how the client should download the
|
|||
|
kernel, so we won't use it (In fact, there is a convention that uses the
|
|||
|
IP address of the workstation as filename, e.g. a client getting the
|
|||
|
address 192.168.42.12 by RARP might ask for /tftpboot/192.168.42.12 by
|
|||
|
TFTP, as the linux kernel does. The filename might also be the hex form
|
|||
|
of the IP address, this is implementation dependant, and is not
|
|||
|
mandatory.).
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>BOOTP: this protocol allows a server to provide the client (identified by
|
|||
|
its hardware MAC address) with much information, in particular its IP
|
|||
|
address, subnet mask, broadcast address, network address, gateway
|
|||
|
address, host name, and kernel loading path. This is the one we will use.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>DHCP: this is an extension of BOOTP.
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
2.2. Loading the kernel
|
|||
|
|
|||
|
When the client has got its IP parameters, if the kernel is not on a local
|
|||
|
support (like a floppy, a cdrom, or a hard drive), the client will start to
|
|||
|
download it via TFTP. Its location is given by the BOOTP/DHCP server. A
|
|||
|
server (not necessarily the BOOTP/DHCP server) will also have to run a TFTP
|
|||
|
daemon for non local kernels. The kernel one obtains after compilation can
|
|||
|
not be used "as is" for BOOTP/DHCP operation, its binary image has to be
|
|||
|
modified with the mknbi utility (and then modified again with the imggen
|
|||
|
utility if you use LanWorks EPROMs). The mknbi utility should also be used to
|
|||
|
modify kernels that will be written in a ROM.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
2.3. Mounting the root filesystem
|
|||
|
|
|||
|
After the kernel has started, it will try to mount its root filesystem. The
|
|||
|
location of this filesystem is also obtained through BOOTP/DHCP, and it is
|
|||
|
mounted via NFS. It means a client may use BOOTP twice for booting: the first
|
|||
|
time to get its kernel, and the second time to learn the location of the root
|
|||
|
filesystem (which may be on a third server).
|
|||
|
|
|||
|
Another solution is to use a ramdisk as root filesystem. In this case, the
|
|||
|
ramdisk image is obtained with the kernel via TFTP.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
2.4. Terminating the boot process
|
|||
|
|
|||
|
When the root filesystem is mounted, you can start breathing: you can at
|
|||
|
least use your swiss army knife with its sh, sed, and awk blades. In fact,
|
|||
|
you will have to customize the initialization scripts of the client's
|
|||
|
filesystem: for instance, you will have to remove all hard drive, floppy or
|
|||
|
cdrom related stuff from /etc/fstab (when your stations are not equipped with
|
|||
|
these devices), you may also have to inhibit swap partitions activation (note
|
|||
|
there is a way to swap over NFS or network block devices). You also will have
|
|||
|
to automagically generate all network configuration files at boot time if
|
|||
|
several clients use the same remote root filesystem.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
3. Building the kernel
|
|||
|
|
|||
|
First of all, build a kernel for the clients. I suggest you build it on the
|
|||
|
server, this will be useful later for modules installation. Use a zImage to
|
|||
|
reduce its size. Include everything you need, but try to use as many modules
|
|||
|
as possible, because many BOOTP client implementations are unable to load
|
|||
|
very large kernels (at least on intel x86 architectures). Also include
|
|||
|
iramdisk support, NFS protocol support, root filesystem on NFS support,
|
|||
|
support for your NIC, kernel level IP autoconfiguration via BOOTP; do not use
|
|||
|
modules for these! Then, if you plan to use the same remote root filesystem
|
|||
|
for several clients, add support for ext2fs or some other filesystem and
|
|||
|
ramdisks (16 Megabytes ramdisks will do fine on most systems). You can then
|
|||
|
modify the kernel arguments as usual (see the BootPrompt-HOWTO for
|
|||
|
information on this topic), but you will have another opportunity to modify
|
|||
|
kernel arguments later.
|
|||
|
|
|||
|
Then, if you plan to use BOOTP, copy the kernel zImage on the server. We will
|
|||
|
assume it resides in /tftpboot, its name is zImage, the name of the image you
|
|||
|
want to create from this zImage for BOOTP operation is kernel, and the nfs
|
|||
|
root filesystem will reside in /nfsroot.
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
Your kernel is ready for BOOTP/DHCP/ROM operation. You of course don't need
|
|||
|
to do this if you plan to use a local drive.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
3.1. When the root filesystem is on a ramdisk
|
|||
|
|
|||
|
It is possible to use a ramdisk for the root filesystem. In this case, the
|
|||
|
command used to modify the kernel's binary image is slightly different. If
|
|||
|
you choose to do so, you have to enable support for initial ramdisk (initrd),
|
|||
|
and you probably don't need NFS support, or you probably can compile it as a
|
|||
|
module.
|
|||
|
|
|||
|
Its time to give an overview of what happens when you use initrd. The full
|
|||
|
documentation for this is in your kernel source tree, in the Documentation/
|
|||
|
initrd.txt file. I have to warn you I did never try this<69>:).
|
|||
|
|
|||
|
When initrd is enabled, the boot loader first loads the kernel and the inital
|
|||
|
ramdisk into memory. Then, the ramdisk is mounted read-write as root
|
|||
|
filesystem. The kernel looks for a /linuxrc file (a binary executable or a
|
|||
|
script beginning with #!). When /linuxrc terminates, the traditionnal root
|
|||
|
filesystem is mounted as /, and the usual boot sequence is performed. So, if
|
|||
|
you want to run your box entirely from ramdisk, you just have to create a
|
|||
|
link from /linuxrc to /sbin/init, or to write there a shell script to perform
|
|||
|
any action you like, and then shutdown the computer.
|
|||
|
|
|||
|
After the kernel has been compiled, you have to build a root filesystem for
|
|||
|
your installation. This is explained in the "Clients setup, creation of the
|
|||
|
root filesystem" section. I will assume here that this is already done and
|
|||
|
that the root filesystem for your clients temporarily resides in /tmp/rootfs.
|
|||
|
You now have to create a ramdisk image. A simple way to do so is the
|
|||
|
following:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Make sure the computer you are working on has support for ramdisks and
|
|||
|
has such a device (/dev/ram0).
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Create an empty filesystem with the appropriate size on this ramdisk:
|
|||
|
# mke2fs -m0 /dev/ram0 300
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Mount it somewhere:
|
|||
|
# mount -t ext2 /dev/ram0 /mnt
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Copy what you need for your new root filesystem, and create your future /
|
|||
|
linuxrc if you did not create it in /tmp/rootfs/linuxrc:
|
|||
|
# cp -a /tmp/rootfs/* /mnt
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Unmount the ramdisk:
|
|||
|
# umount /mnt
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Save the ramdisk image to some file and free it:
|
|||
|
# dd if=/dev/ram0 of=initrd bs=1024 count=300
|
|||
|
# freeramdisk /dev/ram0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
What was toled above about LanWorks PROMs is also true if you use initrd.
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
4. Daemons setup
|
|||
|
|
|||
|
4.1. NFS daemon
|
|||
|
|
|||
|
Just export the directory in which the client's root filesystem will reside
|
|||
|
(see the exports manpage for more information about this topic). The simplest
|
|||
|
is to export it no_root_squash and rw, but a perfect setup would export most
|
|||
|
of the root filesystem root_squash and ro, and have separate lines in the /
|
|||
|
etc/exports for directories which really require no_root_squash and/or rw.
|
|||
|
Just start with everything rw and no_root_squash, the fine tuning will be
|
|||
|
done later.
|
|||
|
|
|||
|
Of course, you don't need any NFS server at all if you plan to run your
|
|||
|
clients entirely from ramdisk.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
4.2. BOOTP daemon
|
|||
|
|
|||
|
I assume you have installed the bootpd package. The default configuration
|
|||
|
file is /etc/bootptab, and its syntax is detailed in the bootptab manpage.
|
|||
|
Let's create it.
|
|||
|
|
|||
|
First, open as root your favourite text editor. It is vim. Yes, it is. If it
|
|||
|
is not, it has to become. Now, enter the following lines (they are the
|
|||
|
default attributes). All the attributes you give here and do not override in
|
|||
|
a machine's specific attributes list will be given to clients):
|
|||
|
.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
|
|||
|
|
|||
|
Of course, not all these parameters are required, this depends on your
|
|||
|
network configuration and BOOTP implementations, but these will work in most
|
|||
|
cases.
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
The MAC address above is the hexadecimal hardware address of the client
|
|||
|
without the ':' characters.
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
|
|||
|
Then, run the bootpd daemon with the bootpd<70>-s command (it is also a good
|
|||
|
idea to add it to your startup scripts), or add the following line to your /
|
|||
|
etc/inetd.conf:
|
|||
|
bootps dgram udp wait root /usr/sbin/tcpd<70>bootpd -i -t 120
|
|||
|
|
|||
|
|
|||
|
If you want to test the BOOTP server, add an entry to your /etc/bootptab and
|
|||
|
use the bootptest program.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
4.3. TFTP
|
|||
|
|
|||
|
Setting up the TFTP daemon is not the hard part: just install the tftpd
|
|||
|
package if you have one, and add the following line to your /etc/inetd.conf
|
|||
|
(again, I assume /tftpboot is the directory where the kernel image resides):
|
|||
|
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd /tftpboot
|
|||
|
|
|||
|
Don't forget to chmod<6F>555 the /tftpboot directory, as most TFTP servers won't
|
|||
|
send the files if they are not world readable.
|
|||
|
|
|||
|
You should be aware of the limitations implied by running the TFTP daemon
|
|||
|
from the inetd. Most inetd's will shutdown a service if it is spawned to
|
|||
|
frequently. So if you have many clients, you should look for another inetd
|
|||
|
like xinetd, or run a standalone TFTP daemon.
|
|||
|
|
|||
|
Now you have properly setup all daemons, you can restart the inetd and take a
|
|||
|
coffee. Don't forget to tell everyone the server setup is over, so you think
|
|||
|
you're a hero before you start building the root filesystem for the clients.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
5. Clients setup, creation of the root filesystem
|
|||
|
|
|||
|
Tired? No you're not. Remember you're a hero. Here comes the tricky part. We
|
|||
|
will (err... you will) build the client's root filesystem. This shouldn't be
|
|||
|
very hard, but you probably will have to use trial and error.
|
|||
|
|
|||
|
The simplest way to create a root filesystem is to use an already working
|
|||
|
filesystem and customize it for the needs of diskless operation. Of course,
|
|||
|
you can also build one by hand (like in the good old times) if you like:=),
|
|||
|
but I won't explain this here.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
5.1. Creating the first files and directories
|
|||
|
|
|||
|
First, cd to your future station's root directory. You can safely create the
|
|||
|
future /home directory with the mkdir command, or by copying it from anywhere
|
|||
|
you want (you can use cp<63>-a to do a recursive copy preserving owners, groups,
|
|||
|
symlinks, and permissions). Same thing for the future /mnt, /root, /tmp
|
|||
|
(don't forget to chmod<6F>0 it, this is only a mount point for the actual /tmp
|
|||
|
we will use, because each workstation needs to have its own /tmp). Then, copy
|
|||
|
some existing /bin, /sbin, /boot, and /usr into this future root directory
|
|||
|
(use cp<63>-a). You can create the /proc directory with mkdir, and chmod<6F>0 it.
|
|||
|
Note some applications need write access to their user's home directory.
|
|||
|
|
|||
|
The /lib directory can be safely copied from somewhere else, but you will
|
|||
|
have to put the proper modules in it. To do so, use the following commands
|
|||
|
(assuming you have compiled the kernel for your clients on the server in /usr
|
|||
|
/src/linux, and the root filesystem will reside in /nfsroot):
|
|||
|
# cd /usr/src/linux
|
|||
|
# make modules_install INSTALL_MOD_PATH=/nfsroot
|
|||
|
|
|||
|
|
|||
|
Don't forget to put the System.map file in /nfsroot/boot. A first problem we
|
|||
|
will have to fix is that, depending on your configuration, your system may
|
|||
|
try to run fsck on the root filesystem at boot time. It shouldn't if there is
|
|||
|
no hard drive in the box. Most distributions will also skip this fsck if they
|
|||
|
find a fastboot file in the root directory. So, issue the following commands
|
|||
|
if you do not plan to mount any hard drive:
|
|||
|
# cd /nfsroot
|
|||
|
# touch fastboot
|
|||
|
# chmod 0 fastboot
|
|||
|
|
|||
|
Another method is tell fsck that checking a NFS filesystem always succeeds:
|
|||
|
# cd /nfsroot/sbin
|
|||
|
# ln -s ../bin/true fsck.nfs
|
|||
|
|
|||
|
|
|||
|
The /dev directory can also be safely copied from another place into /
|
|||
|
nfsroot. But permissions and symlinks have to be preserved, so use cp<63>-a.
|
|||
|
Another solution is to use kernel 2.2.x devfs feature, which will reduce
|
|||
|
memory consumption and improve performance, but the drawback of this method
|
|||
|
is that all symlinks created in /dev will be lost. The point to remember is
|
|||
|
that each workstation needs to have its own /dev, so you will have to copy it
|
|||
|
on a ramdisk if you plan to use several clients and not to use devfs.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
5.2. The /var and /etc directories
|
|||
|
|
|||
|
We will use ramdisks for these directories, because each client needs to have
|
|||
|
its own one. But we still need them at the beginning to create their standard
|
|||
|
structure. Note you are not required to do so if you use a single client. So
|
|||
|
copy these directories (cp -a) from another place into /nfsroot. Then you can
|
|||
|
make some cleanup in /var: you can remove everything in /nfsroot/var/log and
|
|||
|
/nfsroot/var/run. You also probably can remove everything in /nfsroot/var/
|
|||
|
spool/mail, if you plan to export it via NFS. You also will have to remove
|
|||
|
the files containing host specific information in /nfsroot/etc to build them
|
|||
|
on the fly during the boot process.
|
|||
|
|
|||
|
The startup scripts will have to be customized in order to mount some parts
|
|||
|
of the filesystem: the /dev directory, if you don't use devfs, the /tmp, the
|
|||
|
/var, and the /etc directories. Here is some code which will achieve this:
|
|||
|
# 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 ';'
|
|||
|
|
|||
|
|
|||
|
If you plan to use more than a single client, you will also have to change
|
|||
|
files dynamically at boot time in /etc: the files which contain the IP and
|
|||
|
hostname of the client. These files depend on your distribution, but you will
|
|||
|
easily find them with a few greps. Just remove client-specific information
|
|||
|
from them, and add code into your startup files to generate this information
|
|||
|
again at boot time but only once the new /etc has been mounted on the
|
|||
|
ramdisk! A way to obtain your IP address and hostname at bootup is the
|
|||
|
following (if you have the bootpc package installed on the
|
|||
|
workstations'filesystem):
|
|||
|
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)
|
|||
|
}')"
|
|||
|
|
|||
|
This is a complicated solution, but I guess it should work on most sites. The
|
|||
|
IP address can alternatively be obtained with the output of ifconfig and the
|
|||
|
hostname can be obtained from the output of the host command, but this is not
|
|||
|
portable, because these outputs differ from system to system depending on the
|
|||
|
distribution you are using, and the locales settings.
|
|||
|
|
|||
|
Then, the hostname should be set with the hostname<6D>$HOSTNAME command. When
|
|||
|
this is done, it is time to generate on the fly the configuration files which
|
|||
|
contain the IP address or the hostname of the client.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
5.3. Last details
|
|||
|
|
|||
|
Now, it's time to do the fine tuning of the client. As /var will be mounted
|
|||
|
on a ramdisk (unless you have a single client), you will have to send the
|
|||
|
logs to a logs server if you want to keep them. One way to do that is to
|
|||
|
delete the /nfsroot/etc/syslog.conf file and replacing it by the following
|
|||
|
file (see man syslog.conf for details):
|
|||
|
*.* /dev/tty12
|
|||
|
*.* @dns or IP of the logs server
|
|||
|
|
|||
|
If you do so, the logs server will have to run syslogd with the -r option
|
|||
|
(see the syslogd manual page).
|
|||
|
|
|||
|
If you use logrotate and you have done the preceding operation, you should
|
|||
|
replace the logrotate configuration file (/etc/logrotate.conf on most boxes)
|
|||
|
by an empty file:
|
|||
|
# rm -f /etc/logrotate.conf
|
|||
|
# touch /etc/logrotate.conf
|
|||
|
|
|||
|
If you don't use it, just remove the logs rotation scripts from the crontab,
|
|||
|
and as you no longer have log files in /var/log, put an exit<69>0 at the
|
|||
|
beginning of your logs rotation scripts.
|
|||
|
|
|||
|
In the /nfsroot/etc/fstab file, remove anything related to the hard drive,
|
|||
|
floppy disk reader, or cdrom if you don't have such devices on your
|
|||
|
workstations. Add an entry for the /var/spool/mail directory, which should be
|
|||
|
exported by the server through NFS or any other network filesystem. You
|
|||
|
probably also want to put an entry for the /home directory in this file.
|
|||
|
|
|||
|
You can also comment the lines running newaliases, activating swap, and
|
|||
|
running depmod<6F>-a and remove the /nfsroot/etc/mtab file. Comment out the line
|
|||
|
(s) removing /fastboot, /fsckoptions, and /forcefsck in your startup scripts.
|
|||
|
Also remove or comment any line in the startup scripts that would try to
|
|||
|
write on the root filesystem except for really necessary writes, which should
|
|||
|
all be redirected to some ramdisk location if you use several clients.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
5.4. Trial...
|
|||
|
|
|||
|
Time has come for a small trial. MAKE A BACKUP OF YOUR NEWLY CREATED /
|
|||
|
nfsroot. tar<61>-cvvIf should do fine. Take a minute to verify we didn't forget
|
|||
|
anything. Try to boot a client.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
5.5. And Error!
|
|||
|
|
|||
|
Look carefully at the client's screen during the boot process. Oh, I didn't
|
|||
|
tell you to connect a screen... Run, forest! Run an get one. You will
|
|||
|
probably see some error messages. Fix the problems, and make frequent backups
|
|||
|
of your /nfsroot. One day, the client will boot properly. This day, you will
|
|||
|
have to fix errors occurring during shutdown;=P.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6. Several ways of obtaining the kernel
|
|||
|
|
|||
|
We have spoken so far about the client and server's configuration for
|
|||
|
operation after the BOOTP request has been issued by the client, but the
|
|||
|
first problem is that most computers are not able to behave as BOOTP clients
|
|||
|
by default. We will see in this section how to fix this.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6.1. BOOTP or DHCP capable NICs
|
|||
|
|
|||
|
This is the most simple case: some network cards provide a supplement to the
|
|||
|
BIOS, containing a BOOTP or DHCP client, so just setup them for BOOTP or DHCP
|
|||
|
operation in the BIOS, and you're done.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6.2. Kernel on a local floppy or hard drive
|
|||
|
|
|||
|
These cases are also quite simple: the kernel is loaded from a local drive,
|
|||
|
and all the kernel has to do is to obtain its network parameters from BOOTP,
|
|||
|
and mount its root filesystem over NFS; this should not cause any problem. By
|
|||
|
the way, a local hard drive is a good place to leave a /var, /tmp, and a /
|
|||
|
dev...
|
|||
|
|
|||
|
If you have a local hard drive, all you have to do is to use lilo or your
|
|||
|
favourite boot loader as usual. If you use a floppy, you can use a bootloader
|
|||
|
or simply write the kernel on the floppy: a kernel is directly bootable.This
|
|||
|
enables you to use a command like the following:
|
|||
|
# 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 [http://www.tldp.org/HOWTO/Bootdisk-HOWTO/
|
|||
|
index.html] boot-disk-HOWTO for this topic.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6.3. Bootloader without kernel on a local floppy or hard drive
|
|||
|
|
|||
|
Certain bootloaders are network aware, you may thus use them to download the
|
|||
|
kernel image from the network. Some of them are listed below:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>[http://netboot.sourceforge.net] netboot, a bootloader dedicated to
|
|||
|
network boot.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>[http://www.gnu.org/software/grub/] GRUB, the GNU project's GRand Unified
|
|||
|
Bootloader, which is a very general purpose bootloader.
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
6.4. Creating ROMs for the clients
|
|||
|
|
|||
|
Many network cards include a slot in which one can insert an EPROM with
|
|||
|
additional BIOS code. This enables one to add, for instance, BOOTP
|
|||
|
capabilities to the BI0S. To do so, you will first have to find how to enable
|
|||
|
the EPROM socket. You may need a jumper or a special software to do so. Some
|
|||
|
cards like the 3Com 905B have slots for EEPROMs which enable one to change
|
|||
|
the software in the EEPROM in place. In appendix, you'll find the information
|
|||
|
about EPROM and various types of memory chips.
|
|||
|
|
|||
|
For a list of EPROM burner manufacturers visit the Yahoo site and go to
|
|||
|
[http://dir.yahoo.com/Business_and_Economy/Companies/Computers/Hardware/
|
|||
|
Peripherals/Device_Programmers/] 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.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6.4.1. LanWorks BootWare PROMs
|
|||
|
|
|||
|
This information may save you time. In order to make LanWorks BootWare(tm)
|
|||
|
PROMs to correctly start up a linux kernel image, the "bootsector" part of
|
|||
|
the image must be modified so as to enable the boot prom to jump right into
|
|||
|
the image start address. The net-bootable image format created by netboot/
|
|||
|
etherboot's `mknbi-linux' tool differs and will not run if used with BootWare
|
|||
|
PROMs.
|
|||
|
|
|||
|
A modified bootsector together with a Makefile to create a BootWare-bootable
|
|||
|
image after kernel compilation can be found at:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Bwimage package: [ftp://ftp.ipp.mpg.de/pub/ipp/wls/linux/bwimage-0.1.tgz]
|
|||
|
ftp://ftp.ipp.mpg.de/pub/ipp/wls/linux/bwimage-0.1.tgz
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>See also [http://www.patoche.org/LTT/net/00000096.html] http://
|
|||
|
www.patoche.org/LTT/net/00000096.html
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>LanWorks BootWare Boot ROMs: [http://www.3com.com/lanworks] 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.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6.5. Local CDROM
|
|||
|
|
|||
|
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.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6.5.1. Creating a test setup
|
|||
|
|
|||
|
Now that we know what we want to do and how, it's time to create a test
|
|||
|
setup:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>For starters just take one of the machines which you want to use and put
|
|||
|
in a big disk and a cd burner.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Install your linux of choice on this machine, and leave a 650<35>MB
|
|||
|
partition free for the test setup. This install will be used to make the
|
|||
|
iso image and to burn the cd's from, so install the necessary tools. It
|
|||
|
will also be used to restore any booboo's which leave the test setup
|
|||
|
unbootable.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>On the 650 mb partition install your linux of choice with the setup you
|
|||
|
want to have on the cd, this will be the test setup.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Boot the test setup.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Compile a kernel with isofs and cdrom support compiled in.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Configure the test setup as described above with the root filesystem
|
|||
|
mounted read only.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Verify that the test setup automagically boots and everything works.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Boot the main install and mount the 650<35>MB partition on /test of the main
|
|||
|
install.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Put the following in a file called /test/etc/rc.d/rc.iso, this file will
|
|||
|
be sourced at the beginning of rc.sysinit to create /var:
|
|||
|
#/var
|
|||
|
echo Creating /var ...
|
|||
|
mke2fs -q -i 1024 /dev/ram1 16384
|
|||
|
mount /dev/ram1 /var -o defaults,rw
|
|||
|
cp -a /lib/var /
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Edit /test/etc/rc.sysinit, comment the lines where the root is remounted
|
|||
|
rw, and add the following 2 lines directly after setting the PATH:
|
|||
|
#to boot from cdrom
|
|||
|
. /etc/rc.d/rc.iso
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Copy the following to a script and execute it to make a template for /var
|
|||
|
and create /tmp and /etc/mtab links.
|
|||
|
#!/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`
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Remove the creation of /etc/issue* from /test/etc/rc.local: it will only
|
|||
|
fail.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Now boot the test partition again, it will be read only just like a
|
|||
|
cdrom. If something doesn't work reboot to the working partition fix it,
|
|||
|
try again etc. Or you could remount / rw, fix it, then reboot straight
|
|||
|
into to test partition again. To remount / rw type:
|
|||
|
# mount -o remount,rw /
|
|||
|
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
6.5.2. Creating the CD
|
|||
|
|
|||
|
If you need more information than you can find below, please refer to the
|
|||
|
CD-Writing-HOWTO.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6.5.2.1. Creating a boot image
|
|||
|
|
|||
|
First of all, boot into the working partition. To create a bootable cd we'll
|
|||
|
need an image of a bootable floppy. Just dd-ing a zImage doesn't work since
|
|||
|
the loader at the beginning of the zimage doesn't seem to like the fake
|
|||
|
floppydrive a bootable cd creates. So we'll use syslinux instead.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Get boot.img from a redhat cd.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Mount boot.img somewhere through loopback by typing:
|
|||
|
# mount boot.img somewhere -o loop -t vfat
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Remove everything from boot.img except for ldlinux.sys and syslinux.cfg.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Cp the kernel-image from the test partition to boot.img.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Edit syslinux.cfg so that it contains the following, of course replace
|
|||
|
zImage by the appropriate image name:
|
|||
|
default linux
|
|||
|
|
|||
|
label linux
|
|||
|
kernel zImage
|
|||
|
append root=/dev/<insert your cdrom device here>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Umount boot.img:
|
|||
|
# umount somewhere
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>If your /etc/mtab is a link to /proc/mounts, umount won't automagically
|
|||
|
free /dev/loop0 so free it by typing:
|
|||
|
# losetup -d /dev/loop0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
6.5.2.2. Creating the iso image
|
|||
|
|
|||
|
Now that we have the boot image and an install that can boot from a readonly
|
|||
|
mount it's time to create an iso image of the cd:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Copy boot.img to /test
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Cd to the directory where you want to store the image and make sure it's
|
|||
|
on a partition with enough free space.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Now generate the image by typing:
|
|||
|
# mkisofs -R -b boot.img -c boot.catalog -o boot.iso /test
|
|||
|
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
6.5.2.3. Verifying the iso image
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Mounting the image through the loopbackdevice by typing:
|
|||
|
# mount boot.iso somewhere -o loop -t iso9660
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Umount boot.iso:
|
|||
|
# umount somewhere
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>If your /etc/mtab is a link to /proc/mounts umount won't automagically
|
|||
|
free /dev/loop0 so free it by typing:
|
|||
|
# losetup -d /dev/loop0
|
|||
|
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
6.5.2.4. Writing the actual CD
|
|||
|
|
|||
|
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
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
6.5.3. Boot the cd and test it
|
|||
|
|
|||
|
Well the title of this paragraph says it all;)
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
7. How to create diskless MS-Windows stations?
|
|||
|
|
|||
|
Since MS-Windows does not support diskless booting, a simple workaround is
|
|||
|
presented here: the solution is to use software like [http://www.vmware.com]
|
|||
|
VMWare or its free alternative, [http://www.plex86.org] 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.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8. Troubleshooting, tips, tricks, and useful links
|
|||
|
|
|||
|
8.1. Transparently handling workstations'specific files
|
|||
|
|
|||
|
The previous sections discussed a simple way to handle
|
|||
|
workstations'specific files and directories like /var. Most of them are
|
|||
|
simply build on the fly and put on ramdisks, you may however prefer to deal
|
|||
|
with this problem on the NFS server. The clusternfs project provides a
|
|||
|
network filesystem server that can serve different files based on several
|
|||
|
criteria including the client's IP address or host name. The basic idea is
|
|||
|
that if the client whose IP address is 10.2.12.42 requests a file named, for
|
|||
|
instance, myfile, the server will look for a file named myfile$$IP=
|
|||
|
10.2.12.42$$ and serve this file instead of myfile if it is available.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8.2. Reducing diskless workstations'memory usage
|
|||
|
|
|||
|
One simple way to reduce memory consumption is to put several dynamically
|
|||
|
created directories on the same ramdisk. For instance, let's say the first
|
|||
|
ramdisk will contain the /tmp directory. Then, one may move the /var/tmp
|
|||
|
directory on that ramdisk with the following commands issued on the server:
|
|||
|
# mkdir /nfsroot/tmp/var
|
|||
|
# chmod 0 /nfsroot/tmp/var
|
|||
|
# ln -s /tmp/var /nfsroot/var/tmp
|
|||
|
|
|||
|
|
|||
|
Another good way to reduce memory consumption if you don't have local hard
|
|||
|
drives and do not swap over a network block device is to disable the Swapping
|
|||
|
to block devices option during kernel compilation.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8.3. Swapping over NFS
|
|||
|
|
|||
|
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/] 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, compile your kernel normally and enable the Swapping via network
|
|||
|
sockets (EXPERIMENTAL) and Swapping via NFS (EXPERIMENTAL) options.
|
|||
|
|
|||
|
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<32>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
|
|||
|
|
|||
|
Of course, this was just for an example, because if you have several
|
|||
|
workstations, you will have to change the swap file name or directory, or all
|
|||
|
your workstations will use the same swap file for their swap...
|
|||
|
|
|||
|
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.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8.4. Swapping over network block devices
|
|||
|
|
|||
|
Although I have never tried it personally, I got report that the trick
|
|||
|
described below works, at least with recent kernels.
|
|||
|
|
|||
|
The general principle for swapping over network block devices is the same
|
|||
|
than to swap over NFS. The good point is you won't have to patch the kernel.
|
|||
|
But most of the same drawbacks also apply to the NBD method.
|
|||
|
|
|||
|
To create a 20<32>MB swap file, you will have to first create it on the server,
|
|||
|
export it to the client, and do an mkswap on the file. Note that the mkswap
|
|||
|
must be done on the server, because mkswap uses system calls which are not
|
|||
|
handled by NBD. Moreover, this command must be issued after the server starts
|
|||
|
exporting the file, because the data on the file may be destroyed when the
|
|||
|
server starts exporting it. If we assume the server's name is NBDserver, the
|
|||
|
client's name is NBDclient, and the TCP port used for the export is 1024, the
|
|||
|
commands to issue on the server are the following:
|
|||
|
# dd if=/dev/zero of=/swap/swapfile bs=1k count=20480
|
|||
|
# nbd-server NBDclient 1024 /swap/swapfile
|
|||
|
# mkswap /swap/swapfile
|
|||
|
|
|||
|
Now, the client should use the following command:
|
|||
|
# swapon /dev/nd0
|
|||
|
|
|||
|
|
|||
|
Again, this was just to show the general principle. The files'names should
|
|||
|
also be dependant on the workstations'names or IPs.
|
|||
|
|
|||
|
Another solution to swap over a network block device is to create an ext2
|
|||
|
filesystem on the NBD, then create a regular file on this filesystem, and at
|
|||
|
last, use mkswap and swapon to start swapping on this file. This second
|
|||
|
method method is closer to the swap over NFS method than the first solution.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8.5. Getting rid of error messages about /etc/mtab or unmounted directories
|
|||
|
on shutdown
|
|||
|
|
|||
|
The following commands, issued on the server may solve the problem:
|
|||
|
# ln -s /proc/mounts /nfsroot/etc/mtab
|
|||
|
# touch /nfsroot/proc/mounts
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
8.6. Installing new packages on workstations
|
|||
|
|
|||
|
A simple way to do so is to use, on the server, a chroot and then execute
|
|||
|
your favourite installation commands normally. To chroot to the appropriate
|
|||
|
place, use the following command:
|
|||
|
# chroot /nfsroot
|
|||
|
|
|||
|
|
|||
|
Debian users will be particularly interested in the --root option of dpkg,
|
|||
|
which simply tells dpkg where the root of the target system is.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
A. Non-Volatile Memory chips
|
|||
|
|
|||
|
Here is a brief descriptions of memory chips and their types:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>PROM: Pronounced prom, an acronym for programmable read-only memory. A
|
|||
|
PROM is a memory chip on which data can be written only once. Once a
|
|||
|
program has been written onto a PROM, it remains there forever. Unlike
|
|||
|
RAM, PROMs retain their contents when the computer is turned off. The
|
|||
|
difference between a PROM and a ROM (read-only memory) is that a PROM is
|
|||
|
manufactured as blank memory, whereas a ROM is programmed during the
|
|||
|
manufacturing process. To write data onto a PROM chip, you need a special
|
|||
|
device called a PROM programmer or PROM burner. The process of
|
|||
|
programming a PROM is sometimes called burning the PROM. An EPROM
|
|||
|
(erasable programmable read-only memory) is a special type of PROM that
|
|||
|
can be erased by exposing it to ultraviolet light. Once it is erased, it
|
|||
|
can be reprogrammed. An EEPROM is similar to a PROM, but requires only
|
|||
|
electricity to be erased.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>EPROM: Acronym for erasable programmable read-only memory, and pronounced
|
|||
|
e-prom, EPROM is a special type of memory that retains its contents until
|
|||
|
it is exposed to ultraviolet light. The ultraviolet light clears its
|
|||
|
contents, making it possible to reprogram the memory. To write to and
|
|||
|
erase an EPROM, you need a special device called a PROM programmer or
|
|||
|
PROM burner. An EPROM differs from a PROM in that a PROM can be written
|
|||
|
to only once and cannot be erased. EPROMs are used widely in personal
|
|||
|
computers because they enable the manufacturer to change the contents of
|
|||
|
the PROM before the computer is actually shipped. This means that bugs
|
|||
|
can be removed and new versions installed shortly before delivery. A note
|
|||
|
on EPROM technology: The bits of an EPROM are programmed by injecting
|
|||
|
electrons with an elevated voltage into the floating gate of a
|
|||
|
field-effect transistor where a 0 bit is desired. The electrons trapped
|
|||
|
there cause that transistor to conduct, reading as 0. To erase the EPROM,
|
|||
|
the trapped electrons are given enough energy to escape the floating gate
|
|||
|
by bombarding the chip with ultraviolet radiation through the quartz
|
|||
|
window. To prevent slow erasure over a period of years from sunlight and
|
|||
|
fluorescent lights, this quartz window is covered with an opaque label in
|
|||
|
normal use.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>EEPROM: Acronym for electrically erasable programmable read-only memory.
|
|||
|
Pronounced double-e-prom or e-e-prom, an EEPROM is a special type of PROM
|
|||
|
that can be erased by exposing it to an electrical charge. Like other
|
|||
|
types of PROM, EEPROM retains its contents even when the power is turned
|
|||
|
off. Also like other types of ROM, EEPROM is not as fast as RAM. EEPROM
|
|||
|
is similar to flash memory (sometimes called flash EEPROM). The principal
|
|||
|
difference is that EEPROM requires data to be written or erased one byte
|
|||
|
at a time whereas flash memory allows data to be written or erased in
|
|||
|
blocks. This makes flash memory faster.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>FRAM: Short for Ferroelectric Random Access Memory, a type of
|
|||
|
non-volatile memory developed by Ramtron International Corporation. FRAM
|
|||
|
combines the access speed of DRAM and SRAM with the non-volatility of
|
|||
|
ROM. Because of its high speed, it is replacing EEPROM in many devices.
|
|||
|
The term FRAM itself is a trademark of Ramtron.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>NVRAM: Abbreviation of Non-Volatile Random Access Memory, a type of
|
|||
|
memory that retains its contents when power is turned off. One type of
|
|||
|
NVRAM is SRAM that is made non-volatile by connecting it to a constant
|
|||
|
power source such as a battery. Another type of NVRAM uses EEPROM chips
|
|||
|
to save its contents when power is turned off. In this case, NVRAM is
|
|||
|
composed of a combination of SRAM and EEPROM chips.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Bubble Memory: A type of non-volatile memory composed of a thin layer of
|
|||
|
material that can be easily magnetized in only one direction. When a
|
|||
|
magnetic field is applied to circular area of this substance that is not
|
|||
|
magnetized in the same direction, the area is reduced to a smaller
|
|||
|
circle, or bubble. It was once widely believed that bubble memory would
|
|||
|
become one of the leading memory technologies, but these promises have
|
|||
|
not been fulfilled. Other non-volatile memory types, such as EEPROM, are
|
|||
|
both faster and less expensive than bubble memory.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Flash Memory: A special type of EEPROM that can be erased and
|
|||
|
reprogrammed in blocks instead of one byte at a time. Many modern PCs
|
|||
|
have their BIOS stored on a flash memory chip so that it can easily be
|
|||
|
updated if necessary. Such a BIOS is sometimes called a flash BIOS. Flash
|
|||
|
memory is also popular in modems because it enables the modem
|
|||
|
manufacturer to support new protocols as they become standardized.
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
B. Determining the size and speed of EPROMs to plug in a NIC
|
|||
|
|
|||
|
This section comes from the etherboot project's documentation version 5.0. It
|
|||
|
provides tips to determine the size and speed of EPROMs to use with a
|
|||
|
particular NIC
|
|||
|
|
|||
|
The smallest EPROM that is accepted by network cards is an 8k<38>EPROM (2764).
|
|||
|
16<EFBFBD>kB (27128) or 32<33>kB (27256) are the norm. Some cards will even go up to
|
|||
|
64<EFBFBD>kB EPROMs (27512). (You will often see a C after the 27, e.g. 27C256. This
|
|||
|
indicates a CMOS EPROM, which is equivalent to the non-C version and is a
|
|||
|
good thing because of lower power consumption.) You want to use the smallest
|
|||
|
EPROM you can so that you don't take up more of the upper memory area than
|
|||
|
needed as other extensions BIOSes may need the space. However you also want
|
|||
|
to get a good price for the EPROM. Currently the 32<33>kB and 64<36>kB EPROMs
|
|||
|
(27256 and 27512) seem to be the cheapest per unit. Smaller EPROMs appear to
|
|||
|
be more expensive because they are out of mainstream production.
|
|||
|
|
|||
|
If you cannot find out from the documentation what capacity of EPROM your
|
|||
|
card takes, for ISA NICs only, you could do it by trial and error. (PCI NICs
|
|||
|
do not enable the EPROM until the BIOS tells the NIC to.) Take a ROM with
|
|||
|
some data on it (say a character generator ROM) and plug it into the socket.
|
|||
|
Be careful not to use an extension BIOS for this test because it may be
|
|||
|
detected and activated and prevent you from booting your computer. Using the
|
|||
|
debug program under DOS, dump various regions of the memory space. Say you
|
|||
|
discover that you can see the data in a memory window from CC00:0 to CC00:
|
|||
|
3FFF (=<3D>4000 hex<65>=<3D>16384 decimal locations). This indicates that a 16<31>kB
|
|||
|
EPROM is needed. However if you see an alias in parts of the memory space,
|
|||
|
say the region from CC00:0 to CC00:1FFF is duplicated in CC00:2000 to CC00:
|
|||
|
3FFF, then you have put an 8<>kB EPROM into a 16<31>kB slot and you need to try a
|
|||
|
larger EPROM.
|
|||
|
|
|||
|
Note that because pinouts for 28 pin EPROMs are upward compatible after a
|
|||
|
fashion, you can probably use a larger capacity EPROM in a slot intended for
|
|||
|
a smaller one. The higher address lines will probably be held high so you
|
|||
|
will need to program the image in the upper half or upper quarter of the
|
|||
|
larger EPROM, as the case may be. However you should double check the
|
|||
|
voltages on the pins armed with data sheet and a meter because CMOS EPROMs
|
|||
|
don't like floating pins.
|
|||
|
|
|||
|
If the ROM is larger than the size of the image, for example, a 32<33>kB ROM
|
|||
|
containing a 16<31>kB image, then you can put the image in either half of the
|
|||
|
ROM. You will sometimes see advice to put two copies of the image in the ROM.
|
|||
|
This will work but is not recommended because the ROM will be activated twice
|
|||
|
if it's a legacy ROM and may not work at all if it's a PCI/PnP ROM. It is
|
|||
|
tolerated by Etherboot because the code checks to see if it's been activated
|
|||
|
already and the second activation will do nothing. The recommended method is
|
|||
|
to fill the unused half with blank data. All ones data is recommended because
|
|||
|
it is the natural state of the EPROM and involves less work for the PROM
|
|||
|
programmer. Here is a Unix command line that will generate 16384 bytes of
|
|||
|
0xFF and combine it with a 16<31>kB ROM into a 32<33>kB image for your PROM
|
|||
|
programmer.
|
|||
|
# (perl -e 'print "\xFF" x 16384'; cat bin32/3c509.lzrom) > 32kbimage
|
|||
|
|
|||
|
|
|||
|
The speed of the EPROM needed depends on how it is connected to the computer
|
|||
|
bus. If the EPROM is directly connected to the computer bus, as in the case
|
|||
|
of many cheap NE2000 clones, then you will probably have to get an EPROM that
|
|||
|
is at least as fast as the ROMs used for the main BIOS. This is typically
|
|||
|
120-150 ns. Some network cards mediate access to the EPROM via circuitry and
|
|||
|
this may insert wait states so that slower EPROMs can be used. Incidentally
|
|||
|
the slowness of the EPROM doesn't affect Etherboot execution speed much
|
|||
|
because Etherboot copies itself to RAM before executing. I'm told Netboot
|
|||
|
does the same thing.
|
|||
|
|
|||
|
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] 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] 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.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
C. Companies selling diskless computers
|
|||
|
|
|||
|
The original Diskless-HOWTO mentions the names of the following vendors of
|
|||
|
diskless computers:
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Linux Systems Labs Inc., USA [http://www.lsl.com] 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.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Diskless Workstations Corporation, USA [http://
|
|||
|
www.disklessworkstations.com] http://www.disklessworkstations.com.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A>Unique Systems of Holland Inc., Ohio, USA [http://www.uniqsys.com] http:/
|
|||
|
/www.uniqsys.com
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
References
|
|||
|
|
|||
|
[Diskless-HOWTO]<5D>Diskless-HOWTO.
|
|||
|
|
|||
|
http://www.linuxdoc.org/HOWTO/Diskless-HOWTO.html
|
|||
|
|
|||
|
|
|||
|
[Diskless-root-NFS-HOWTO]<5D>Diskless-root-NFS-HOWTO.
|
|||
|
|
|||
|
http://www.linuxdoc.org/HOWTO/Diskless-root-NFS-HOWTO.html
|
|||
|
|
|||
|
|
|||
|
[Bootdisk-HOWTO]<5D>Boot-disk-HOWTO.
|
|||
|
|
|||
|
http://www.tldp.org/HOWTO/Bootdisk-HOWTO/index.html
|
|||
|
|
|||
|
|
|||
|
[ltsp]<5D>linux terminal server project.
|
|||
|
|
|||
|
A set of utilities and documentation for diskless stations, based on the red
|
|||
|
hat distribution.
|
|||
|
|
|||
|
http://www.ltsp.org
|
|||
|
|
|||
|
|
|||
|
[plume]<5D>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
|
|||
|
|
|||
|
|
|||
|
[logilab]<5D>Logilab.org web site.
|
|||
|
|
|||
|
http://www.logilab.org
|
|||
|
|
|||
|
|
|||
|
[PowerUp2Bash]<5D>From-PowerUp-to-bash-prompt-HOWTO.
|
|||
|
|
|||
|
http://www.linuxdoc.org/HOWTO/From-PowerUp-to-bash-prompt-HOWTO.html
|
|||
|
|
|||
|
|
|||
|
[ThinClient]<5D>Thin-Client-HOWTO.
|
|||
|
|
|||
|
http://www.linuxdoc.org/HOWTO/Thin-Client-HOWTO.html
|
|||
|
|
|||
|
|
|||
|
[cdwriting]<5D>CD-Writing-HOWTO.
|
|||
|
|
|||
|
http://www.linuxdoc.org/HOWTO/CD-Writing-HOWTO.html
|
|||
|
|
|||
|
|
|||
|
[etb]<5D>etherboot project.
|
|||
|
|
|||
|
http://etherboot.sourceforge.net
|
|||
|
|
|||
|
|
|||
|
[VMWare]<5D>VMWare.
|
|||
|
|
|||
|
A non free virtual machine software.
|
|||
|
|
|||
|
http://www.vmware.com
|
|||
|
|
|||
|
|
|||
|
[plex86]<5D>plex86.
|
|||
|
|
|||
|
A free virtual machine software.
|
|||
|
|
|||
|
http://www.plex86.org
|