Linux Remote-Boot mini-HOWTO: Configuring Remote-Boot Worksta�
tions with Red-Hat Linux, DOS, Windows 3.1 and Windows 95
Marc Vuilleumier St�ckelberg, Sandro Viale and David Clerc
v2.5, August 1997
This document describes how to set up a very robust server-based con�
figuration for a cluster of PCs, allowing each client to choose at
boot-time which operating system to run. The key of this configuration
is the TCP/IP bootprom, which let the user choose at boot time one of
several boot images. The most up-to-date version of this document,
with hypertext links to downloadable software and other related mate�
rials, can be found at the address
http://cuiwww.unige.ch/info/pc/remote-boot/howto.html. Linuxdoc-SGML,
DVI and postscript versions are available in the same directory.
1. What has changed...
1.1.
A lot of things:
� The Linux server-based configuration and documentation have been
completely redesigned. It is now based on RedHat Linux 4.1, updated
to the 2.0.30 kernel. Linux system setup and maintenance has been
much simplified.
� The Dos and Windows configurations have been completely redesigned,
using a "hard-disk based" approach. This makes the configuration
MUCH easier, fasten the boot process, reduces the network load, and
even allows for a server-based setup of Windows NT station
(although this is not described in this document).
� We now use a DHCP server, with standard DHCP/BOOTP extensions (RFC
2132).
� This configuration now works also with Samba, the free SMB server,
instead of a Novell server. In fact, we are now on the point of
throwing away of our Novell server...
1.2.
A new banner feature has been added to the bpunzip utility. A bug in
MRZIP, which caused "Bad compressed data" errors during disk image
decompression, has been found and fixed.
Several precisions were added to the documentation. Links to related
software (Shared LAN Cache) and documentation (from J. Carlstedt, of
The Cathedral School of Uppsala, Sweden) have also been added.
2. Introduction
The configuration described here was developped since Summer 1996 at
the CUI, University of Geneva. The Computer Science Department uses
several servers (both Unix and Novell), and a number of PCs, which
fall into two classes:
� computers devoted to students
� computers devoted to research and teaching assistants
We developped the current configuration with the following aims:
� Every computer should be able to run under Linux, DOS, Windows 3.1
or Windows 95. One should be able to choose the desired operating
system for each session.
� All softwares, including operating systems, should reside on the
server, in order to facilitate the installations and upgrades.
� Clients computers should be able to run without any write-access on
the server (for security reasons), except their home directory.
� Client-side configuration should be reduced to its very minimum.
Clients should automatically get their IP configuration parameters
from the server, and this information should be located in a single
file, used for all operating systems.
� Since almost every computer now has a hard-disk, clients should be
able to take profit of it for reducing network load and as
temporary storage space for the user.
� Users must have a login to be able to use any of the computers.
� The login should be the same for all operating system and should
let the user access its unique home directory, common to all
operating systems.
� Students computers should be fully cleaned up at each start. That
is, the PC should always look like if it were just installed.
� Every computer has to be protected from virus attacks.
These constraints lead us to base our configuration on the
excellent TCP/IP Bootprom from K�ppen EDV GmbH. This bootprom is
especially interesting because it is not devoted to any specific
operating system; it just emulates a floppy disk, and can easily be
used for booting Linux as well as DOS or Windows 95. Moreover, the
bootdisk image can be replaced by a home-made program, that let us
perform several initializations before the operating system itself
starts.
2.1. The Network
The University of Geneva owns a class B domain, subdivided into
several subnets. The CUI uses four subnets, among them one is
dedicated to students.
Originally, our PCs were concerned about two network protocols: IPX
and IP. On the IPX side, we used a single Novell Netware 3 server for
sharing software and users files for DOS and Windows. On the IP side,
we used a SUN server for sharing software and users partitions for
Linux, with NFS.
In our latest configuration, we do not any more use IPX. There is a
single Unix server (which could be Linux as well as a SUN), sharing
software and user files using NFS for Linux clients and using SMB
(NetBIOS) over TCP/IP for Dos and Windows clients.
2.2. How it Works
1. When a client PC is turned on, it first performs the traditional
system checks before the TCP/IP bootprom takes the control.
2. The bootprom issues a BOOTP/DHCP request in order to get its IP
configuration parameters.
3. If the server knows the PC issuing the request, it will send back a
BOOTP/DHCP reply with informations such as the client's IP address,
the default gateway, and which bootdisk image to use. Otherwise,
the server will just discard the request.
4. The bootprom then downloads the bootdisk image from the server
using the TFTP protocol, and emulates at the BIOS level a floppy
disk with this image.
5. The PC boot on this disk image, which happens to contains a single
boot program (no operating system yet).
6. If the PC is a student computer, the program starts by downloading
by TFTP a small text file containing the expected hard-disk
configuration for the computer. According to this file, the
partition table is rebuilt and DOS partitions are quick-formatted.
When all this is done, no more than three seconds have elapsed
since the computer was turned on.
7. The program then offers to the user the choice of the operating
system for the session.
8. According to the choice of the user, a new bootdisk image is
downloaded from the server, using TFTP.
9. If the user decides to use Linux, the boot image is a a kernel
loader plus a compressed kernel, with support for NFS root and
caching filesystem:
a. First, the IP configuration is made according to the BOOTP/DHCP
reply received from the Novell server.
b. The kernel is then able to mount a read-only root filesystem,
using NFS.
c. A small ramdisk is set up and mounted to the places where write
access is desirable.
d. If a swap partition is found on the local hard disk, it is
prepared and activated.
e. If a linux partition is found on the local hard disk, it is
mounted and prepared for caching NFS partitions.
f. IP configuration is finalized, services are started, and xdm is
launched.
g. The user is asked for its login. The workstation is ready.
10.
If the user decides to use DOS or Windows, the boot image is a
program that handle compressed images of FAT16 partitions. Images
are downloaded using TFTP, and stored for further use at the very
end of the hard-disk, above any used partition. More precisely,
the program works in the following way:
a. The program download a checksum file (512 bytes) that validates
the boot image of the choosen operating system
b. If the wanted image is not present at the end of the disk, or if
the checksum does not match (because the image has been
corrupted or because a new release has been installed on the
server), the full image is transferred using TFTP.
c. The operating system image is decompressed into the first FAT16
partition, at the approximate speed of one second per used
megabyte.
d. The program jump into the boot sector of the selected OS, which
is now completely present on the local hard-disk.
For DOS and Windows 3.1, we use the freely available Microsoft Lan�
Manager for DOS (search the network for the mirror nearest to you;
the distribution consists of three files named disk1 to disk4) as
SMB client. Microsoft LanManager supports dynamic configuration
using DHCP. After logging in, the user is faced to DOS, and can
start Windows 3.1 by typing the traditional win command. Note that
at this point, DOS and Windows 3.1 appear to be installed locally.
For Windows 95, we also use Microsoft SMB client (called Client for
the Microsoft Network), that supports dynamic configuration using
DHCP. We reduce network load using Shared LAN Cache, a nice and
powerful network-to-disk cache program.
Students computers can be turned off the hard way at any time with�
out risks, since the hard disk is reinitialized at each start.
For "safe" computers (ie. for assistants computers), once the computer
has been booted once using the above described system, the boot image
can be changed to a simple program that redirect the boot to the local
hard-disk, without cleaning it again. This allow users to leave data
on their local hard disk. But whenever the configuration gets
corrupted, it is sufficient to change the boot image for one start in
order to get a fresh installation.
2.3. Related non-commercial documentations
This configuration has been successfully reproduced at several places
around the world. A few people have written some hints and tricks that
complement this How-To. If you did so and that your page is not
already referenced in this documentation, please send an e-mail to
Marc.VuilleumierStuckelberg@cui.unige.ch. And if you experience
problems while reproducing this configuration, have a look at these
pages !
� http://www.katedral.se/system/elevsyst, by Johan Carlstedt of The
Cathedral School of Uppsala, Sweden.
3. The Configuration How-To
First, arrange to have the following two machines within arm's reach:
� the server, for us a Unix machine
� the client, a PC with a TCP/IP bootprom enabled, and nothing
valuable on the hard disk.
If you want to test the configuration but you do not yet have a
TCP/IP Bootprom, you can download the demo diskette from
http://www.incom.de. This diskette will make your computer behave
like if it had a TCP/IP Bootprom plugged in.
For student computers, we configured our Bootprom for boot on network
first, and disabled hard-disk and floppy-disk boot. For assistant
computers, we also configured our Bootprom for network-boot, but we
allow hard-disk and floppy-disk boot; use this kind of Bootprom in
your setup client.
On the server, setup a DHCP daemon (we use the official version from
the Internet Software Consortium, release 970329). You also need to
enable a TFTP daemon. This document assume that you use the extended
TFTP daemon provided on your TCP/IP Bootprom Utility disk. If you
prefer to use a standard TFTP daemon, remove the P in all boot image
name extensions, in order to tell the Bootprom to use only the
standard TFTP port (see the TCP/IP Bootprom documentation).
Don't forget that BOOTP/DHCP requests are bounded by subnets. If the
client and the server do not reside on the same subnet, you should
install a gateway on any computer between the two. For now, just
assume that both machines are on the same subnet.
First, we will do everything common to all operating systems, ie:
� Configure the initial hard-disk setup and cleaning
� Configure the operating system choice menu
� Test the boot process
Then, for each operating system, we will go through the following
steps:
� Setup a stand-alone client
� Save its configuration on the server
� Test it as a remote-boot client
� Adapt it so that it works for any similar client machine
Once this is done, you will be able to setup any supplemental
client just by plugging a BootPROM in it and adding a few lines in
the DHCP configuration file.
3.1. Setting Up the Boot Process
In the server /tftpboot directory, put the following special boot
images (warning for hypertext readers: these are binary files)
� bpclean, our hard-disk cleaning utility
� bpmenu, the TCP/IP Bootprom menu program (included with your
bootprom utility disk)
� bpunzip, our hard-disk restore utility
� bphdboot, the image that redirect the boot process to the hard disk
3.1.1. The Initial Hard-disk Setup and Cleaning
In the same directory, create a symbolic link to (or make a copy of)
bpclean named XXXclean (or whatever you want that that can help you
remember that it is a clean-up image for your client machine) and
create a text file named XXXclean.tab describing what partition table
you want for your client, and what boot image you want to chain. For
instance, for a 2 Gb hard-disk, we use
______________________________________________________________________
# Comments are allowed, but file should not exceed 512 bytes
# Hex numbers should be prefixed by $
# Part | | Part
# type | Boot? | Size
6 Y +500 Mb
$82 N +31 Mb
$83 N -50 Mb
0
# Bootimage to chain
/tftpboot/XXXmenu
______________________________________________________________________
The precise format of the file is described later in this document.
For now, all you need to know is that
� partition type 6 is BIGDOS, ie. DOS Fat-16 from 32Mb to 500Mb
� partition type hex 82 is Linux Swap
� partition type hex 83 is Linux Ext2fs
� the negative size means that we partition three should occupy all
available space but 50 Mb
� partition type 0 means empty (unused) partition entry.
For now, bpclean will not erase the content of any partition but
rewrite the master boot record, including the partition table.
3.1.2. The Operating System Choice Menu
Similarly, create a symbolic link to (or make a copy of) bpmenu named
XXXmenu (or whatever you want that that can help you remember that it
is a boot menu image for your client machine) and create a text file
named XXXmenu.m containing the boot menu for your machine. You might
either create this file by hand, or use our menuedit.exe full-screen
menu editor. For the example, assume that you use the following file:
______________________________________________________________________
______________________________________________________________________
3.1.3. Testing the Boot Process
Create an entry in the DHCP configuration file for your client. Set
the boot image to /tftpboot/XXXclean. You will probably need to
restart the DHCP server to take your changes into account.
Now, start your client. You should quickly see messages from bpclean,
telling you the size of the partitions created, and then the boot menu
should appear on your screen. You can use the pause key on the
keyboard just before the menu is loaded in order to be able to read
the messages, but it will probably time-out the TFTP connection.
If you press the key 1, you should get a message saying that the boot
partition contains not valid boot sector. This is normal since the
boot partition has not been formatted. Any other keys should fail
since we did not make any boot image for now...
We will now install the various operating systems. You can do that in
what order you want. For each OS, you will initially need to start it
from a boot floppy. In order to do that, just press the space bar at
the very beginning of the boot process, just after the TCP/IP Bootprom
banner.
Some operating system might change the master boot record. In
particular, the Linux kernel loader (lilo) does that. Such changes
would be destroyed by bpclean, so you should better change the DHCP
entry for your client so that the boot image is directly
/tftpboot/XXXmenu (no clean). Don't forget to restart the DHCP server
to take your changes into account.
3.2. Setting Up Linux
Set up RedHat Linux 4.1 on your client, with network support, kernel
sources and any packages you may want. Prepare future moint points (a
/mnt/tmp will be usefull), setup your X server, and so on. In the
directory /usr/src/linux-2.0.27, you should have the source code for
the kernel 2.0.27.
We will now apply some patches, in order to upgrade to 2.0.30, and to
support the TCP/IP Bootprom and the filecache. The filecache is the
mechanism by which you can reduce network loading by saving "on-the-
fly" NFS files on your local hard disk. TCP/IP Bootprom support has
been written by Marc Vuilleumier Stuckelberg, and ported to kernel 2.0
by David Clerc. The filecache has been written by Unifix GmbH, and is
part of Unifix Linux 2.0. Both TCP/IP Bootprom support and the
filecache have been made freely distributable by their authors.
Note that Linux NFS-Root support is still based on BOOTP, not DHCP.
But since DHCP is just an extension of BOOTP, Linux will work as well
with a DHCP server (if you did not configure your DHCP server to deny
BOOTP requests).
3.2.1. Building the Kernel
First, go to your /usr/src directory and apply the following patches,
using the command
patch -p0 < the-patch-file:
� patch-2.0.28: this is the official kernel update, a big patch that
you should better apply
� patch-config-sound: a cosmetic patch for the sound configuration,
taken from Unifix Linux 2.0
� patch-PCSP: a rather big patch for adding soundcard emulation using
the PC speaker, taken from Unifix Linux 2.0
� patch-bootprom: a small patch that will let you produce a special
kernel image, usable as a boot image with the TCP/IP Bootprom
� patch-filecache: a small patch that adds special functionalities to
your kernel, so that you can use Unifix filecache. Taken from
Unifix Linux 2.0
� patch-penguinlogo: a small patch that will help your end-users to
wait until your Linux system is completely loaded
� patch-2.0.29: another official kernel update patch, much smaller.
You do not need to apply this patch if you don't want to have the
latest kernel release.
� patch-2.0.30: yet another official kernel update patch, quite big.
Again, you do not need to apply this patch (but it improves
TCP/IP). If you do not have sources for the alpha on your machine
(which is most probable), this patch will complain twice about an
include file that does not exist. Do not worry, just answer that
you want to skip the missing file and everything will be okay.
Then run make mrproper and make xconfig, to customize the contents
of your kernel. Remember that this will be the only software the
client computer will be given for starting Linux, so it must
contains everything necessary to launch the whole operating system.
Modules should be used, but not for networking support since the
network is needed to load the kernel modules. In brief, your kernel
should contains at least
� networking support
� NFS-Root support, with BOOTP support
� filecache support
� support for the client computer hardware, possibly modular
You may use our .config as a starting point. Ensure that you have
included support for your hard disk directly in the kernel if you
want to be able to test it without the bootprom.
When you are done with your choices, type the usual make clean; make
dep and then make zImage, make modules and make modules_install. This
will take a while... You are now ready to test your new kernel, first
using lilo. Install your kernel (see lilo documentation), and reboot
your computer (from the local hard disk). If there are any errors,
fix them and try again. Run depmod -a to compute the modules
dependencies. When there are no more errors, do a make bpImage to
build a bootimage for use with the TCP/IP Bootprom.
3.2.2. Moving the Root Filesystem to NFS
Have enough place on your server to hold the whole content of your
Linux filesystem (some hundred Megabytes). Create a new directory for
NFS export, named rootfs, and create another new directory within it
named runtime. We use /export/linux/rootfs/runtime. Export it read-
write, with root access (annon=0), for your Linux client only. For
instance, our NFS server is running under Solaris, and we gave the
command:
share -F nfs -o rw=pc7971,anon=0 /export/linux/rootfs/runtime.
Mount this partition on your Linux client and copy the whole Linux
system on it using GNU tar (the default on RedHat Linux). It is
important that you use GNU tar because all tar might not be able to
handle correctly special nodes such as block devices. Then edit the
/export/linux/rootfs/runtime/etc/fstab file and change the entry for
the root directory so that it corresponds to an nfs mount instead of a
local hard disk. You also need to remove (or at least rename)
/export/linux/rootfs/runtime/etc/sysconfig/network-scripts/ifcfg-eth0
since the network device will be initialized by NFS-root and should
not be initialized twice.
Now duplicate the linux entry in your /etc/lilo.conf, using the name
linux-nfs for instance, and add the following parameter to it:
append="root=/dev/nfs nfsroot=/export/linux/rootfs/runtime
nfsaddrs=your-ip:server-ip:gateway-ip:netmask:machine-name"
(where your-ip is the decimal dotted notation for your Linux client IP
address, server-ip is the NFS server IP address, gateway-ip is the
default gateway used by the Linux machine, netmask is the netmask and
machine-name is the hostname of the Linux machine). Run lilo again,
reboot your computer (still from the hard disk), and choose linux-nfs
boot settings. Your computer should behave almost as before, although
probably slower. If something doesn't work at this point, you can
simply reboot with your local linux boot configuration and try to fix
it. Most probably, you made the NFS root settings wrong. If there is
something you don't understand, have a look at the
/usr/src/linux/Documentation files... You might also look at the NFS-
Root-Mini-Howto.
You can repeat the experience with only append="root=/dev/nfs" to
ensure that the Linux kernel is able to get your IP parameters using a
DHCP/BOOTP request. For this to work, you should have the following
options in your DHCP configuration file (set with your own values, of
course), in addition to your machine hardware and IP addresses:
______________________________________________________________________
option subnet-mask 255.255.252.0;
option routers 129.194.68.1;
option root-path "/export/linux/rootfs";
______________________________________________________________________
If your Linux kernel needs additional command-line parameters, you can
add them using option option-177.
The next step is to have our system work with a read-only NFS
filesystem.
3.2.3. Building the Read-only NFS Root Filesystem
Since we want our root filesystem to be mounted read-only by regular
linux clients, we have to make a slightly different filesystem, so
that we can put a ramdisk or a filecache on places where write access
is desirable. We will build this filesystem in the
/export/linux/rootfs directory, so that the standard distribution is
directly available under /runtime/. Log on your NFS server and create
the following directories and links, under /export/linux/rootfs:
� bin -> cache/bin
� dev -> ramdisk/dev
� etc -> ramdisk/etc
� lib -> cache/lib
� root -> ramdisk/root
� sbin -> cache/sbin
� tmp -> ramdisk/tmp
� usr -> cache/usr
� var -> ramdisk/var
� cache/
� bin -> /runtime/bin
� lib -> /runtime/lib
� sbin -> /runtime/sbin
� usr -> /runtime/usr
� mnt/
� cdrom/
� floppy/
� tmp/
� proc/
� ramdisk/
� dev -> /runtime/dev
� etc -> /runtime/etc
� root -> /runtime/root
� tmp -> /runtime/tmp
� var -> /runtime/var
As you can see, it looks like a regular root filesystem, except
that some entries are redirected to a ramdisk, while some other are
redirected to the cache directory. When booting on a read-only NFS
filesystem, we will mount an initialized ramdisk on /ramdisk.
Similarly, a local hard disk partition will be mounted on /cache
for caching NFS requests. Roughly, the principle of the filecache
is that whenever a symbolic link from the cache subdirectory is
followed, it is replaced by its target. If the target is itself a
subdirectory, each entry of the subdirectory becomes a symbolic
link to the original entry of the foreign filesystem. Note that it
is necessary for the filecache to use absolute symbolic links, even
if they are meaningless on the NFS server. If you don't like that,
create a symbolic link from /runtime to
/export/linux/rootfs/runtime on your NFS server.
It is then necessary to add some setup stuff to the read-only client,
in order to mount the ramdisk, to setup the filecache and to detect
hardware in order to customize the configuration files. This is done
by three scripts and one configuration file, that you should copy to
your NFS server:
� runtime/etc/rc.d/rc.ramdisk, which quickly setup and mount the
ramdisk:
______________________________________________________________________
#!/bin/sh
#
# Setup a ramdisk because root was mounted read-only by NFS
#
modprobe rd
gzip -c -d /runtime/lib/ramdisk.gz | dd of=/dev/ram bs=1k > /dev/null 2>&1
mount -n -t ext2 /dev/ram /ramdisk
______________________________________________________________________
� runtime/etc/rc.d/rc.sysdetect, which does all machine-dependant
configuration, including detecting and preparing local hard disk
partitions for the filecache. It is not included in the printed
version of this document for space reasons, but can be found in the
hypertext version;
� runtime/etc/rc.d/init.d/filecache.init which starts the filecache
itself:
______________________________________________________________________
#!/bin/sh
#
# filecache: Starts the filecache (for NFS root)
#
# Source function library.
\&. /etc/rc.d/init.d/functions
# See how we were called.
case "$1" in
start)
if [ -e /cache -a -r /etc/filecache.conf ]; then
echo -n "Starting NFS filecache: "
# move var and tmp to the local hard drive
rm -rf /cache/var /cache/tmp
(cd /ramdisk; tar cf - var tmp) | (cd /cache; tar xf -)
(cd /ramdisk; rm -rf var tmp;ln -s /cache/var;ln -s /cache/tmp
)
chmod 777 /cache/tmp
# start cache
daemon filecache -d on
echo ""
touch /var/lock/subsys/filecache
fi
;;
stop)
filecache off
rm -f /var/lock/subsys/filecache
;;
*)
echo "*** Usage: filecache.init {start|stop}"
exit 1
esac
exit 0
______________________________________________________________________
� runtime/etc/filecache.conf, the filecache configuration file
______________________________________________________________________
Max 100 MB 50 % #
Cache /runtime /cache
______________________________________________________________________
The first two files should be invoked at the beginning of run�
time/etc/rc.d/rc.sysinit, as follow:
______________________________________________________________________
# Setup ramdisk if necessary (for read-only root NFS)
if [ -e /ramdisk -a -r /etc/rc.d/rc.ramdisk ]; then
/etc/rc.d/rc.ramdisk
fi
# Setup hardware dependent parameters (for any root NFS)
if [ -r /etc/rc.d/rc.sysdetect ]; then
/etc/rc.d/rc.sysdetect
fi
______________________________________________________________________
and the third one should be bound as usual to the System V init direc�
tories: we use links named S35filecache in the rc3.d and rc5.d direc�
tories, and K80filecache in the rc0.d, rc1.d, rc2.d and rc6.d directo�
ries.
Take a look at the rc.sysdetect file, and adapt it to your hardware.
In particular, if you do not use the same video adapters and screen as
we do (which is very likely :-), see how they report to /proc/pci and
modify the script according to that. There is a section of
rc.sysdetect with customize configuration files (for instance the
printcap), according to the machine location. For this to work, you
need to set each machine location using the special tag option-132 of
the server dhcpd.conf file. Before you continue this installation,
you must at least build basic runtime/etc/fstab.ref and
runtime/etc/hosts.ref files, which will be finalized by the
rc.sysdetect script on boot time, according to the detected
configuration. For dynamically configuring the X server, there is one
thing you have to change from the RedHat distribution: in the
/usr/X11R6/bin and /usr/X11R6/lib/X11 directories, there are a few
relative links to configuration files and directories that should be
changed to absolute links. Don't forget to do that again if you
reinstall later an upgrade of the X server.
Install the filecache in runtime/bin, and its man page in
runtime/usr/man/man8. Install bootptag in runtime/usr/local/bin, and
bootptag.c in runtime/usr/local/src: it is a simple program that
issues a BOOTP request and answer its content on the standard output,
in a shell-compatible format, as in the following example:
______________________________________________________________________
bootp_your_ip='129.194.71.32'
bootp_server_ip='129.194.77.31'
bootp_filename='XXXclean'
bootp_subnet_mask='255.255.252.0'
bootp_routers='129.194.68.1'
bootp_domain_name_servers='129.194.69.200 129.194.8.7 129.194.4.32'
bootp_host_name='pc7132'
bootp_domain_name='unige.ch'
bootp_root_path='/export/linux/rootfs'
bootp_broadcast_address='129.194.71.255'
bootp_nis_domain='cuisunnet.unige.ch'
bootp_nis_servers='129.194.69.200'
bootp_option_132='dufour'
______________________________________________________________________
The name of the tags is similar to that used in the dhcpd configura�
tion file. We use this program for auto-configuration in rc.sysdetect.
Finally, install the makeramdisk script in runtime/lib. We will use it
to build automatically the ramdisk image. All these software are
available in the hypertext version of this document.
Now try to boot your read-write NFS client (still boot from the hard
disk). It should detect your local configuration, and generate the
appropriate files. Check that /etc/fstab, /etc/hosts,
/etc/sysconfig/network have been created correctly. If it is not the
case, retry in single user mode, and debug the rc.sysdetect script to
discover what you have done wrong.
When it works, go to the /lib directory and run ./makeramdisk. This
will take a few seconds, and build a ramdisk image for the read-only
NFS clients. Install the created ramdisk image under /lib/ramdisk.gz,
and your configuration is ready !
3.2.4. Booting from the Bootprom
If you did not already do it, install your TCP/IP Bootprom-compliant
kernel image (found in /usr/src/linux/arch/i386/boot/bpImage) as
/tftpboot/linux.PX on your server. The rc.sysdetect script is able to
initialize for you the Linux swap and a Linux data partition. In order
to trigger it, edit the XXXclean.tab file on the server and change the
partitions types from hex 82 to hex 28, and from hex 83 to hex 38.
This is not a known partition type, but it will be recognized by the
setup script as partitions to prepare. In the DHCP configuration
file, set the boot file to XXXclean again, in order to rebuild the
partition table. Do not forget to restart the DHCP daemon after you
changed the configuration file.
Finally, unexport the read-write runtime directory, and export read-
only the /export/linux/rootfs directory. Restart the client, and this
time boot using the Linux menu option. Your system will now remote-
boot Linux.
3.2.5. System Maintenance and Upgrades
If you want later to upgrade software, install bug fixes and security
fixes, proceed as follow:
� Unexport the rootfs directory
� Export the runtime directory read-write for your client
� Set your client nfsroot directory to runtime (in the /etc/bootptab)
� Start your Linux client, and install everything you want. Do not
be afraid of using rpm, it works perfectly well (just be carefull
when you install packages that might alter modifications that you
have made yourself).
� Redo the normal export when you are done
That means, you can upgrade software on your server-based
configuration as if it were a local install.
3.3. Setting up DOS 6 and Windows 3.1
On the client computer, boot on your favorite dos floppy disk
(remember, abort the BootPROM by pressing space during boot). Format
the dos partition of your hard-drive with the /S option, in order to
put the operating system on it. Create a DOS subdirectory, copy DOS
in it. Install your favorite network client (for instance Microsoft
LanManager), Windows 3.1, and so on. Use DHCP for the IP
configuration.
You should recover the memory used by the BootPROM (since it is not
any more needed when the DOS starts) by inserting the following line
at the beginning of your config.sys:
______________________________________________________________________
device=\util\bputil.sys -r
______________________________________________________________________
(bputil is a program provided on the TCP/IP Bootprom utility disk).
Do not be afraid to use EMM386 to optimize the memory usage, and even
to include the area where you put your network adapter ROM, since it
is not used anymore at this time. But carefully exclude the network
adapter RAM, or you will not be able to connect to your server.
If you want to ensure that the client machine cannot be used without a
valid login name, include our nobreak.sys pseudo-device driver at the
beginning of your config.sys and put something like this in your
autoexec.bat:
______________________________________________________________________
rem -- we use the dummy file c:\logged as a flag
del c:\logged >nul
:loginneeded
cls
echo Please type in your login name and password
echo.
net logon *
rem -- the login script should have created c:\logged
if not exist c:\logged goto loginneeded
del c:\logged
rem -- now enable break again
echo Yes >NOBRK
______________________________________________________________________
Ensure that your client boot well by rebooting and choosing the Boot
from local hard-disk option in the boot menu.
3.3.1. Moving the Configuration to the Server
On the server, make a share called admin for instance, on which you
will put some stuff for the system administrator. If the server is a
Unix machine, it is a good opportunity to put in admin a softlink to
the /tftpboot subdirectory, so that you can put images in it directly
from the client. Within admin, create a /utils subdirectory and put
the following utilities in it:
� mrzip.exe, a program that will create a compressed image of your
hard disk.
� mrunzip.exe, a program that can restore from within DOS a
compressed image of your hard disk.
You might also like to put in the same directory a simple batch
file that does some clean-up and then create the compressed image,
like this one:
______________________________________________________________________
@echo off
if "%1"=="" goto error
echo >c:\lanman.dos\lmuser.ini
l:\utils\mrzip l:\tftpboot\%1
goto end
:error
echo Usage: MAKEIMG {image-name-without-extension}
:end
______________________________________________________________________
Now go back to your client, mount the admin volume on drive L: for
instance and execute either your batch file if you have created one,
or the following command (absolute path names are not required, but
they do not hurt :-)
______________________________________________________________________
L:\util\mrzip L:\tftpboot\win31
______________________________________________________________________
One minute later, you will have two new files in your server /tftpboot
subdirectory, namely win31.imz, the compressed image of your hard disk
and win31.chk, the associated checksum file (which is in fact a
slightly modified copy of the partition boot record). In this very
directory, just create a symbolic link to (or a copy of) bpunzip named
win31.P.
Your disk-based remote-boot configuration is now ready.
3.3.2. Testing the Remote-Boot Client
Now reboot your client and choose the DOS and Windows 3.1 option of
the boot menu. The bpunzip program shall give you some message about
his creating an image table, and then download the whole boot image
from the network (since it is the first time that it sees this boot
image). This will take about one minute. Then it will uncompress the
image to the DOS partition, and boot it. Here you are, your remote-
boot client is ready ! Next time you reboot it, it will only
uncompress the image, probably in less than 30 seconds.
3.3.3. Adapting the configuration for other Machines
If you want to customize some settings according to the machine, to
its location (such as the default printer), or if you need to make
some changes in your network configuration files that cannot be
handled through DHCP, you can use the unzipreg.exe program from within
the client autoexec.bat. This program will read a special hidden file
created by bpunzip, namely BOOTP.ANS, that contains the original
BOOTP/DHCP reply sent by the server. Then, it will read the file given
as first argument, substitute all strings of the form
UNZIPREG:tagname: by their content in the BOOTP/DHCP reply and write
the result on the file given as second argument. For instance, if you
have a file named input.bat which contains:
______________________________________________________________________
set domainname=UNZIPREG:DOMAINNAME:
set printer=UNZIPREG:T180:
______________________________________________________________________
and you execute the command
______________________________________________________________________
unzipreg input.bat output.bat
______________________________________________________________________
you will get a file output.bat containing:
______________________________________________________________________
set domainname=unige.ch
set printer=laserwriter1
______________________________________________________________________
assuming that your DHCP configuration file defines the domain name as
unige.ch and the option-180 tag as laserwriter1.
Note that it is also possible to customize the Windows desktop
according to the login. We wrote a simple program to add a group to
the PROGMAN.INI file, allowing to customize the desktop for each group
of users.
After making any change to the client machine configuration, do not
forget to rebuild the disk image using mrzip if you want to preserve
your changes.
3.4. Setting up Windows 95
In previous versions of this document, we used the Microsoft server-
based installation of Windows 95, but it was really too much pain and
not much worth:
� It is very, very bogus
� Many software package do not support it and their install will
fail. Among them, Microsoft Internet Explorer, OnNet 32, Novell's
Protected-mode client (which is MUCH more secure than Microsoft
Client for Netware).
� It cannot be used with the Microsoft Network client over TCP/IP,
since Microsoft provides no real-mode driver for TCP/IP compatibe
with Windows 95. That means, it cannot be used with Samba
� It makes software upgrades almost impossible since every client
turned on will lock many DLLs on the server, and thus produce
sharing violations if you try to upgrade them.
Consequently, we throwed away of this document all the informations
and bug-workaround collected during months (you can still find them
as a HTML document at http://cuiwww.unige.ch/info/pc/remote-
boot/win95old/win95old.html) and turned to our new disk-based
remote-boot concept. Basically, the configuration for Windows 95
is now almost as easy the configuration for DOS.
3.4.1. Setting up a Stand-Alone Client
Boot the client computer in DOS, either using the Boot menu if you
have already setup the DOS/Windows 3.1 configuration, or using a
floppy disk (aborting the BootPROM by pressing space). The advantage
of the first solution is that you will then have a running network
client, and that you probably already have somewhere on your server
the distribution disks for Windows 95.
If you boot from a floppy disk, you will probably first need to format
the dos partition of your hard-drive with the /S option, in order to
put the operating system on it. If you boot using a DOS/Windows 3.1
configuration start by removing files that you don't need for Windows
95 setup and that you do not want to be in your final boot image (for
instance, the WINDOWS directory).
Start Windows 95 setup, and follow all steps of a local install. At
the end of the install, setup will reboot your computer, make some
settings and reboot again. For all these reboot, choose the Boot from
local hard-disk option of your boot menu. Once you have set up all
drivers you want, you shall consider running defrag and doing a full
defragmentation (including defragmenting free space).
You should also consider recovering the memory used by the BootPROM by
inserting the following line at the beginning of your config.sys:
______________________________________________________________________
device=\util\bputil.sys -r
______________________________________________________________________
(bputil is a program provided on the TCP/IP Bootprom utility disk).
In opposition to DOS, you shall better avoid to use EMM386 with Win�
dows 95.
If you want to reduce network and server load (which will improve your
system performances) while keeping all softwares on the server, you
should consider installing the excellent Shared LAN Cache, from
Measurement Techniques, Inc (see http://www.lancache.com). This
software runs on each client computer, and caches to the local hard
disk every data obtained from the network. Even MS-Office starts much
faster the second time you run it... You need one license per client
computer, but it is not very expensive, and the firm make special
prices for universities and colleges. The best thing to do is to go to
their Web site and download the free evaluation copy.
3.4.2. Moving the Configuration to the Server
On the server, if you don't already have it, make a share called admin
for instance, on which you will put some stuff for the system
administrator. If the server is a Unix machine, it is a good
opportunity to put in admin a softlink to the /tftpboot subdirectory,
so that you can put images in it directly from the client. Within
admin, create a /utils subdirectory and put the following utilities in
it:
� mrzip.exe, a program that will create a compressed image of your
hard disk.
� mrunzip.exe, a program that can restore from within DOS a
compressed image of your hard disk.
Open a MS-DOS window on your client, mount the admin volume on drive
L: for instance and execute the following command (absolute path names
are not required, but they do not hurt :-)
______________________________________________________________________
L:\util\mrzip L:\tftpboot\win95
______________________________________________________________________
This will create two new files in the /tftpboot subdirectory of your
server, namely win95.imz, the compressed image of your hard disk and
win95.chk, the associated checksum file (which is in fact a slightly
modified copy of the partition boot record). In this very directory,
just create a symbolic link to (or a copy of) bpunzip named win95.P.
Your disk-based remote-boot configuration of Windows 95 is now ready.
3.4.3. Testing the Remote-Boot Client
Now reboot your client and choose the Windows 95 option of the boot
menu. The bpunzip program shall give you some message about his
updating the image table, and then download the whole boot image from
the network (since it is the first time that it sees this boot image).
This will take about two minutes. Then it will uncompress the image
to the DOS partition, and boot it. Here you are, your remote-boot
client is ready ! Next time you reboot it, it will only uncompress
the image, probably in about 40 seconds.
3.4.4. Adapting the configuration for other Machines
The big difference between Windows 3.1 and Windows 95 is that the
later includes code for Plug-and-play , ie. automatic detection of
your hardware. This not a bad thing in itself, but the trouble is that
it is often too sensible, and that it sometimes fails.
If you try to start another client with exactly the same boot image,
you will probably get several messages during startup telling that
Windows has detected new hardware: a new sound card, a new hard-disk,
a new network card, and even a new mouse... There can be two reasons
for that:
� the devices may not use the same ressources (for instance the mouse
is not connected on the same port, or the sound card is not
connected in the same slot - yes, that is detected)
� the devices may tell to Windows 95 their personal serial number
(for instance, every Windows 95 differenciate every network card on
the basis of its world-wide unique ethernet address)
The fact that Windows 95 discover that the hardware has changed may
not be a problem if the plug-and-play works as-is, but it become a
problem when the plug-and-play does not work. For instance, Windows
95 plug-and-play for our Logitech PS2/aux mouse does not work, and
result in no mouse at all. To solve such kind of problems, arrange
to have all computers as similar as possible.
The thing you cannot avoid to differ between computers is the network
card. Bad luck for us, the plug-and-play code for our SMC EtherEZ card
hangs the computer. The only solution is to let Windows 95 believe
that it already know the network card, and that it is not necessary to
trigger plug-and-play. The trick for doing that is to automatically
insert an entry for the network card in Windows 95 registery, from the
autoexec.bat. Note that this trick is not any more needed with most
PCI cards.
On your client computer, edit the autoexec.bat and add the following
lines:
______________________________________________________________________
rem --- Patch Windows registery in order to avoid plug-and-play detection
cls
unzipreg c:\lib\smc.reg c:\temp\smc.reg
regedit /L:c:\win95\system.dat /R:c:\win95\user.dat c:\temp\smc.reg
echo.
del c:\temp\smc.reg
______________________________________________________________________
regedit is a standard Windows 95 program that let you browse the reg�
istery if you start it from within Windows 95, or do simple operations
on the registery if you call it from DOS. unzipreg.exe is a small
home-made program that you should put somewhere in your path. It will
read a special hidden file created by bpunzip, namely BOOTP.ANS, that
contains the original BOOTP/DHCP reply sent by the server. Then, it
will read the file given as first argument, substitute all strings of
the form UNZIPREG:tagname: by their content in the BOOTP/DHCP reply
and write the result on the file given as second argument.
In in the lib subdirectory, we have a file named smc.reg with the
following content:
______________________________________________________________________
REGEDIT4
[HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C0]
"HardwareID"="*SMC8416,ISAPNP\SMC8416"
"HWRevision"="1.0.10"
"DeviceDesc"="SMC EtherEZ (8416)"
"Class"="Net"
"Driver"="Net\\0001"
"CompatibleIDs"="*SMC8416"
"Mfg"="SMC"
"ConfigFlags"=hex:10,00,00,00
[HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C0\Bindings]
"MSTCP\\0001"=""
[HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C0\LogConfig]
"0000"=hex:00,04,00,00,00,20,00,00,10,00,00,00,04,00,00,00,00,00,00,00,a8,0e,\
00,00,20,00,00,00,02,00,00,00,01,00,0c,00,00,00,00,00,00,00,00,00,e0,ff,20,\
00,40,02,ff,03,00,00,04,03,2c,00,00,00,01,00,00,00,01,00,14,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,e0,ff,ff,00,20,00,00,00,00,0c,00,ff,ff,0f,00,00,\
00,00,00,2c,00,00,00,01,80,00,00,01,00,14,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,e0,ff,ff,00,80,00,00,00,00,0c,00,ff,5f,10,00,00,00,00,00,00,00,00,\
00
[HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C1]
"HardwareID"="*SMC8416,ISAPNP\SMC8416"
"HWRevision"="1.0.10"
"DeviceDesc"="SMC EtherEZ (8416)"
"Class"="Net"
"Driver"="Net\\0001"
"CompatibleIDs"="*SMC8416"
"Mfg"="SMC"
"ConfigFlags"=hex:10,00,00,00
[HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C1\Bindings]
"MSTCP\\0001"=""
[HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C1\LogConfig]
"0000"=hex:00,04,00,00,00,20,00,00,10,00,00,00,04,00,00,00,00,00,00,00,a8,0e,\
00,00,20,00,00,00,02,00,00,00,01,00,0c,00,00,00,00,00,00,00,00,00,e0,ff,20,\
00,40,02,ff,03,00,00,04,03,2c,00,00,00,01,00,00,00,01,00,14,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,e0,ff,ff,00,20,00,00,00,00,0c,00,ff,ff,0f,00,00,\
00,00,00,2c,00,00,00,01,80,00,00,01,00,14,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,e0,ff,ff,00,80,00,00,00,00,0c,00,ff,5f,10,00,00,00,00,00,00,00,00,\
00
______________________________________________________________________
This file was initially generated using the Windows 95 interface to
regedit. We exported the branch corresponding to our network adapter
(HKEY_LOCAL_MACHINE/Enum/ISAPNP/SMC8416) and substituted the number
corresponding to the adapter hardware address by the tag
UNZIPREG:MACID:. When we run unzipreg on this file, it will automati�
cally substitute the tag by the number corresponding to the actual
netword adapter. Note that there is one number after the MACID that
was sometimes C0, sometimes C1. Since it does not hurt to put a non-
existant adapter in the registery, we add entries for both.
Once again, this whole trick is not necessary when using PCI network
adapters. Incidentally, we can use the same mechanism for
automatically configuring the hostname, which Windows 95 does not seem
to take into account when configuring through DHCP. We just add the
following line to our smc.reg file:
______________________________________________________________________
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP]
"ComputerName"="UNZIPREG:HOSTNAME:"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"HostName"="UNZIPREG:HOSTNAME:"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\ComputerName\ComputerName]
"ComputerName"="UNZIPREG:HOSTNAME:"
______________________________________________________________________
You can also use the same mechanism to customize other settings
according to the machine type or to its location. For examples of
that, see also the corresponding paragraph of the DOS/Windows 3.1
configuration description.
After making any change to the client machine configuration, do not
forget to rebuild the disk image using mrzip, or all your changes will
be lost.
Using this small registery trick, your configuration should normally
be portable for all machines with similar configurations. If you
cannot avoid that Windows detect some hardware as new on one machine,
try to rebuild the disk image from this machine. This will include the
registery configuration specific to this machine into the image, and
hopefully supress the problem.
As the disk image decompression may take some time (typically 20-30
sec.), you may want to give to the user informations or just a nice
picture to look at. This can be done very easily (see the
documentation on BPUNZIP below).
If you are interested in getting more informations and tools for
configuring Samba with remote boot computers, we have written another
document. Have a look at http://cuiwww.unige.ch/info/pc.
4. TCP/IP Bootprom Related Utilities
This section gives some informations on the use of the utilities we
wrote for use with the TCP/IP Bootprom.
4.1. MENUEDIT
This is a program running under DOS, for editing menu scripts usable
with the TCP/IP Bootprom. It is very basic, but is still much more
comfortable to use than the menu scripts themselves. You can get
online-help by depressing the F1 key. If you want to enhance it (for
instancing adding cut-and-paste), I would be happy to publish your new
version.
Pascal source code is available here.
4.2. BPHDBOOT
This boot image will load the hard-disk master boot record and jump
into it.
This boot image is particularly convenient to use when configuring an
operating system that wants you to reboot before it finalizes its
configuration. It can also be used on computers for which you do not
want to impose a hard-disk cleanup at any time but you still want to
be able to do it whenever needed.
Assembler source code is available here.
4.3. BPCLEAN
This boot image rewrite the hard-disk master boot record, including
the hard-disk partition table. Moreover, it can quick-format a DOS
(FAT16) data partition (but cannot make it bootable). For copyright
reasons, we had to program our own master boot record and FAT16 boot
sector. They should behave more or less like the standard
implementation, except that some messages have been adapted for the
context of remote-boot computers. In order to have this program work,
you might need to disable the BIOS master boot record protection
(which is anyway not any more necessary since it will be refreshed at
each boot).
This program downloads the partition table description file with the
same basename as itself and the .tab extension. This file can contains
empty lines, comments beginning with a sharp but should never exceed
512 characters.
The first four non-blank non-commented lines should contain the
discription for the four hard disk partitions. The fifth non-blank
non-commented line should contain the name of the next boot image to
load.
Partition description lines are made of several space- or tab-
separated fields, and must be in one of the following three forms:
______________________________________________________________________
type boot? 1st-cyl 1st-head 1st-sect last-cyl last-head last-sect
type boot? 1st-cyl 1st-head 1st-sect relative-size
type boot? relative-size
______________________________________________________________________
� In the first form, the file give the precise geometry of the
partition.
� In the second form, the first sector position is given but the end
of the partition is automatically calculated on the basis of the
requested partition size.
� In the third form, the first sector is automatically deduced from
the end of the previous partition and the end of the partition is
automatically calculated on the basis of the requested partition
size. This form is totally independant of the hard-disk geometry.
Every number is assumed to be in decimal form, except when prefixed
with a dollard, in which case it is assumed to be an hexadecimal
number.
� The type of a partition is 4 for DOS partitions under 32Mb, and 6
for DOS partitions from 32Mb to 500Mb. Many other values can be
found using Linux fdisk help for instance.
� The boot? field should be Y for the boot partition and N for all
other partitions. This flag is used by the master boot record.
� The 1st-cyl, 1st-head and 1st-sect are the absolute coordinates of
the first sector of the partition. Do not forget that while
cylinders and heads are numbered starting from 0, sectors are
numbered starting from 1.
� The last-cyl, last-head and last-sect are the absolute coordinates
of the last sector of the partition. Partition usually end on a
cylinder boundary.
� The relative-size of a partition takes can be expressed in the
following ways:
� + 10 Mb which means that the partition should be at least 10 Mb
(ie. 2048 sectors) big;
� - 100 Mb which means that the partition should leave at least 100
Mb (ie. 20480 sectors) free for the next partitions;
� + 30 % which means that the partition should occupy at least 30
percent of the space available at this point;
� - 70 % which means that the partition shouls leave at least 70
percent of the space available at this point for the next
partitions.
Partitions defined by their relative size always end on a cylinder
boundary, and unless the first sector position is precised, start
after a head boundary. To our knowledge, this is conform to the
standard usage.
Whenever a label is appended at the end of a partition description
line, the corresponding partition is formatted as a DOS FAT16
partition, whatever its type. This is compatible both with partition
types 4 and 6, and is particularely usefull for cleaning a DOS
partition on a student computer for instance. Such quick-format only
takes some tenths of a second.
By default, bpclean is compiled with support for LBA (no more than
1024 cylinders, and up to 256 heads). Some strange BIOSes and some
strange OSes prefer the so-called NORMAL mode (up to 4096 cylinders,
but no more than 64 heads); if you need it, comment the LBA definition
in the source code and recompile it.
Assembler source code is available here.
4.4. MRZIP, MRUNZIP and BPUNZIP
MrZip is a DOS program that can build a compressed raw image of a DOS
FAT16 partition. It first analyses the disk usage in order to process
only used data bytes, and then uses a very fast (but not very
efficient) statistical compression algorithm to compress the data.
Windows 95 long filenames are supported, and files with the .SWP
extension are not saved. Several magic numbers are included between
the various parts of the archive, and a checksum is computed on the
original data. The checksum is stored as the low-order word of the
volume serial number in the archive, while the high-order word is
simply incremented. If you zero the serial number of your hard-disk
before building the compressed image, you can then use this number to
track the number of updates to your image.
Since MrZip uses direct disk access, it recommended that you flush any
disk write cache before you run it. Windows 95 seems to handle direct
disk access consistently.
MrUnzip is a DOS program that can expand a compressed disk image to
the hard-disk, using direct disk access. Do not use it in conjunction
with any cache program, as it is already sufficiently afflicting for
the DOS itself... Anyway, it can be very helpfull if you you want to
fix a boot image that cannot boot anymore for instance.
BpUnzip is a boot image that manage compressed hard disk images.
Roughly, it will boot from the hard disk image with the same base
name, with the extension .imz.
It first read the partition table and look for
� the first DOS partition, where the disk image should be restored
� the last cylinder allocated for a partition, after which the
compressed hard disk images will be stored.
It then read the first sector of the first unused cylinder and see
if there is already an image table. If it is not the case, or if
the image table contains some inconsistency, or if both shift keys
are depressed (a special general-cleaning signal), the image table
is cleared.
If the image table does not already contains the requested image, it
is loaded using TFTP and added to the image table. If there is not
enough space after previously loaded images for the new one, old
images are discarded. If the image was already present in the image
table, the most recent image boot sector (including the checksum) is
loaded by TFTP and compared against the available image. If they are
not exactly the same, the compressed image is reloaded.
The image is then uncompressed, all magic numbers are verified, and
the checksum is computed on the decompressed data. If the
decompression fails, or if the checksum does not match the value
included in the most recent boot sector, the image is assumed to be
corrupted and is reloaded. Otherwise, the program gives the control to
the boot sector, and the operating system is started.
If bpunzip was loaded with a .P extension (for instance as win95.P),
it is assumed that the TFTP server has an extended interface on port
59 (in addition to the regular interface on port 69). BpUnzip will
then use it for loading the image using bigger packets, typically 1408
bytes instead of 512 bytes per packet (this convention for using
triggering the use of big packets is very similar to that used by the
TCP/IP Bootprom).
Similarly, if bpunzip was loaded with a .G extension (for instance as
win95.GP), it will first download a GIF file with the same basename
(for instance win95.gif) and display it on the screen during the whole
operation. The program works only in 800x600, 256 color mode (although
the GIF file can be smaller and use less colors). If your video
adapter is not VESA compatible, this feature is not available to you.
Note than the last 16 colors of the palette are used to display the
progress bar banner. Either do not use them, or expect them to be
incorrect. By the way, if you don't like our progress bar banner, feel
free to change it (in GIFDATA.ASM), but please leave our names visible
somewhere.
The target partition does not have to be exactly of the same size as
the original one; it just have to be big enough to hold the clusters
from the beginning of the partition to the last used cluster. If the
destination partition is smaller than the original partition, the FAT
will be shrinked accordingly (but not the cluster size). If the the
destination partition is bigger than the original partition, the FAT
will be expanded as much as possible. However, if the destination
partition is much bigger than the original, it is likely that 65518
clusters will not be enough to cover all space (since the cluster size
cannot be adapted). In this case, bpunzip will issue a warning telling
that some space is lost.
By default, bpunzip is compiled with support for LBA (no more than
1024 cylinders, and up to 256 heads). Some strange BIOSes and some
strange OSes prefer the so-called NORMAL mode (up to 4096 cylinders,
but no more than 64 heads); if you need it, comment the LBA definition
in the source code and recompile it.
Assembler source code is available here.
You might encounter problems with Solaris 2.5 TFTP server when dealing
with images bigger than 16 Megabytes. This is because it cannot handle
more than 32768 packets per file. This is a known bug, for which SUN
currently provides no fix. We suggest using the more efficient
extended TFTP server (also provided for other OS on your TCP/IP
Bootprom utility disk).
4.5. NOBREAK
Nobreak.sys is a very small (about 350 bytes only) driver that you
include at the beginning of your config.sys. Its goal is to secure the
boot process, until the user is logged in. DOS provides a setting for
this (namely BREAK=OFF), but it is not drastic enough, and has almost
no effect in the autoexec.bat. Our driver works by modifying the
scan-code of the key pressed when a break is requested, directly at
the BIOS level. This way, no program at all can receive a break until
break is enabled again.
The driver must be loaded from the config.sys (or using the devlod
program from Undocumented DOS). Afterwards, break can be enabled by
sending Yes to the NOBRK pseudo-device, and disabled again by sending
No (in fact, only the first character, Y or N is significant).
As this driver relies on the BIOS, it does only work for DOS and
Windows 3.1. Windows 95 has its own low-level keyboard handling
routines.
Assembler source code is available here.
5. Discussion
We here discuss some theoretical issues related to our configuration.
5.1. Bootproms and Hard Disks
Bootproms exist for quite a long time, but they are usually used for
diskless computers only. In our opinion, bootproms are even more
interesting for computers which have a local harddisk, since they
allow to take profit of both sides:
� A bootprom make the configurations more robust, since it ensure
that the computer will always boot the same way, no matter any
virus or partition table crash. It can be used, as we did, to
cleanup the harddisk even before the operating system is loaded.
� A local harddisk make the configuration more efficient, since it
can reduce the network trafic through caching, and allows for
efficient swap.
5.2. Which Bootprom ?
Several bootproms are available for PCs. We had several reason for
choosing the TCP/IP Bootprom from K�ppen EDV GmbH:
� It is based on the BOOTP/DHCP protocol, which is publicly defined
by RFCs. The definition states that when a BOOTP/DHCP server
receives a request from a client that he doesn't know, the server
will not answer. This avoids interferences between multiple
servers, as you might sadly experience with the MSD boot server.
Moreover, since IP broadcasts are confined to the local subnet,
they produce less noise than their IPX counterpart.
� It is not bound to a specific operating system.
� Technical informations and API informations are available on
request.
� Home-made boot loader can be written (as we have done)
� The boot process can be parametrized on many ways. Specifically, it
allowed us to forestall floppy boot on old-fashioned AST computers,
which BIOS did not include this feature.
� Tools are provided for building and maintaining boot menus.