First, arrange to have the following two machines within arm's reach:
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:
In the server /tftpboot
directory, put the following special
boot images (warning for hypertext readers: these are binary files)
bpclean
,
our hard-disk cleaning utilitybpmenu
, 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 diskIn 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
bpclean
will not erase the content of any partition
but rewrite the master boot record, including the partition table.
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:
.CLS 23
.ATT 23
.POS 23 4
.WRT Simple Boot Menu \
.POS 23 5
.WRT ---------------- \
.POS 23 8
.WRT 1. Boot from local hard disk \
.POS 23 10
.WRT 2. Boot DOS and Windows 3 \
.POS 23 12
.WRT 3. Boot Windows 95 \
.POS 23 14
.WRT 4. Boot RedHat Linux \
.POS 23 17
.WRT Your choice : \
.POS 37 17
.KEY 1 :bphdboot
.KEY 2 :linux.PX
.KEY 3 :win31.P
.KEY 4 :win95.P
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.
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).
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.
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
filecache
support
.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.
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.
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
:
/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
runtime/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 directories: we use links
named S35filecache
in the rc3.d
and rc5.d
directories,
and K80filecache
in the rc0.d
, rc1.d
, rc2.d
and
rc6.d
directories.
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
configuration
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 !
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.
If you want later to upgrade software, install bug fixes and security fixes, proceed as follow:
rootfs
directoryruntime
directory read-write for your clientnfsroot
directory to runtime
(in the
/etc/bootptab)
rpm
, it works perfectly
well (just be carefull when you install packages that
might alter modifications that you have made yourself).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.
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.
@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.
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.
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.
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:
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
Windows 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.
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.
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.
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 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 registery 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 automatically 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
.