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.
If you already have a Boot ROM, you need to enable it. If you are using Incom TCP/IP Bootprom, you can do that using a special program from your network card manufacturer. If you have a PXE Bootprom, you can do it simply from BIOS setup, by changing the default boot device.
For student computers, we configured the boot on network first, and disabled hard-disk and floppy-disk boot. For assistant computers, we also configured network-boot first, but we allow hard-disk and floppy-disk boot.
On the server, you will need the following services:
ndd /dev/ip ip_path_mtu_discovery to see if you have it enabled
and ndd -set /dev/ip ip_path_mtu_discovery 0 to disable it.
However, this fix only works for non-broadcast packets (ask SUN why...).
That means, it will work for TFTP but not for DHCP :-(.
The role of the DHCP server is to give to the client an IP
address and to make it load the
file named bpbatch.P from the TFTP server.
DHCP is a superprotocol over BOOTP. If you are using InCom
TCP/IP Bootprom, you may live without DHCP (using an old BOOTP server).
On Windows NT, you will probably use the native DHCP server. If you are using InCom TCP/IP Bootprom, you will have to use a special trick to specify the boot file name (get more info from InCom WWW site). If you are using a PXE Bootrom, you will need a Proxy DHCP server, but no other trick is needed as the boot file name will be provided by the Proxy DHCP server.
On Linux, the best choice is the standard DHCP server from the Internet Software Consortium. If you are using a PXE Bootrom, in addition to the usual options, you will need to add the following ones:
option dhcp-class-identifier "PXEClient"option vendor-encapsulated-options ff;On Solaris, you can either use the Internet Software Consortium DHCP server (available on the Web), or use Solaris DHCP server (available since Solaris 2.5). However, as Solaris DHCP server does not seems to be able to insert a client class identifier in its DHCP offer, you must install a Proxy DHCP server. Morever, this Proxy DHCP server must reside on another computer since Solaris DHCP server locks the DHCP port.
We suggest giving infinite lease time for remote-boot clients. 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 BOOTP/DHCP Relay agent on any computer between the two. For now, just assume that both machines are on the same subnet.
The role of the Proxy DHCP server is to overcome limitions of some DHCP servers and to provide PXE specific extensions. A proxy DHCP server only makes sense for a PXE Boot rom.
As BpBatch itself is quite powerfull, you wont need to use any PXE specific DHCP extension (menus, etc.). However, if your DHCP server is not able to show minimal PXE compliance, you will need a Proxy DHCP server or your PXE Boot ROM will not accept to go further.
On Windows NT, you can try to use Intel WfM PDK (available from their web site), but it is not very easy to use. We rather suggest having a Linux machine on the subnet and using our small Proxy DHCP. The major advantage of our Proxy DHCP Server for BpBatch is that our server will let you specify an option 155 vendor tag that will be interpreted by BpBatch as a command line.
On Linux and Solaris, you can run our Proxy DHCP program, that simply
takes as argument the TFTP server IP address, boot file name and
optional arguments, and does everything for you.
If the DHCP port on the server is already requested by another daemon,
the proxy DHCP server will run on port 4011. In this case, it is
necessary that the other daemon on DHCP port answer a DHCP offer with
client class PXEClient so that the PXE client knows that it must
try on port 4011.
If you want to understand better PXE extensions to DHCP, there is an extensive description available on Intel WWW site. However, be warned that the documents are quite confusing, as the protocol has been extended to a number of optional stages, in order to allow for a maximal flexibility. The key to understand it is that all what a PXE client needs is a complete enhanced DHCP answer. If it receives only a standard DHCP offer, it will look further until it gets
PXEClientff)
The TFTP server is a very simple file server. In its basic version, TFTP use 512 bytes data blocks, which are quite inefficients. InCom TCP/IP Bootprom and PXE Boot ROMs allow to use larger blocks (1408 bytes), which speeds up transfers a lot. However, this can only work with an enhanced TFTP server.
On Windows NT, we suggest using InCom enhanced TFTP server, available on their web site.
On Linux, you can use our enhanced TFTP server, available at
http://cuiwww.unige.ch/info/pc/remote-boot/soft/etftpd.tar.gz.
On Solaris, you should use InCom enhanced TFTP serer, available on the utility disk provided with the TCP/IP Bootprom.
If you prefer using 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 (This trick was introduced
by InCom GmbH for the TCP/IP Bootprom. We still use it as an easy way
to select the default TFTP port with PXE bootproms).
First, we will do set up the part common to all operating systems, ie. the batch-file interpreter. Then, for each operating system, we will go through the following steps:
Our examples assume that you have a hard disk of 1.4 Gb or more. If you have less, reduce the sizes of the partitions, but remember the you need to leave a few hundreds megabytes unallocated (that is, the last partition must not take up to the last cylinder) to leave free room for the special cache partition. Moreover, as the cache always starts at the cylinder following the last allocated cylinder, if you do not use the same total size for all your tests, you will have to download several times the same files (the cache will be automatically cleared).
Never despair. If you can't get it to work, first look in the
Troubleshooting section if your problem is not already solved
(get the latest version from the Web).
If it still does not work, think about monitoring network traffic
for network related problems (use tcpdump on Linux or
snoop on Solaris). If you really cannot get it to work,
you can send an E-mail to David.Clerc@cui.unige.ch or
Marc.VuilleumierStuckelberg@cui.unige.ch.
If your problem is strictly related with the remote-boot configuration
and if we are not overflowed, we will try to solve your problem.
Get the BpBatch software, either as .zip or as .tar.gz.
The executables are available at
http://cuiwww.unige.ch/info/pc/remote-boot/soft/bpb-exe.zip
http://cuiwww.unige.ch/info/pc/remote-boot/soft/bpb-exe.tar.gzIn the server /tftpboot directory, put the following three special
boot images, which together make our pre-boot batch file interpreter:
bpbatch.P, the dynamic loader (respect the uppercase !)bpbatch.ovl, the relocated interpreterbpbatch.hlp, the on-line help file"bpbatch.P". Define a vendor option tag 155
(decimal) with the value "-i"
(on the standard DHCP server, this is done by the following
command: option option-155 "-i";). It is interpreted by bpbatch
as the command line, and -i stands for "interactive".
Boot the client computer. You might shortly see
DHCP while the client waits for a DHCP replyTFTP while the client waits for the first TFTP packetLoading BpBatch while the loader download the
interpreterhelp.
Note that you can run the same interpreter within DOS and Linux by
running the MrBatch program. There are a only very few differences
(the Linux version do not have graphics support and the DOS version
can only send BOOTP and TFTP requests if the BootProm is not hidden
by the operating system).
It may be a good idea to read now the section about the
Syntax Rules of BpBatch, and in particular the paragraphs
on File References and on The Cache Filesystem.
This will help you understand the examples.
Once all operating systems will be set up, you will have to make a menu to let the user choose the one he wants. You should be able to discover by yourself how to make such a menu. All necessary commands are documented at the end of this document.
Try to type LogVars. You should get about thirty variables
listed. Roughly, the first are BpBatch settings, then come
all parameters extracted from the BOOTP/DHCP reply, and the last
variable is a list of disks sizes, in Megabytes.
Type GetPartitions part, then LogVars again. There should be
one more variable containing the list of defined partitions on your
first hard-drive. Assuming that the first partition is either
BIGDOS, FAT32 or LINUX-EXT2, try LogDir "{:1}" to get the
content of the root directory, then LogDir "{:1}/usr" if
there is an usr directory. You can even try
LogTree "{:1}/etc" to get a directory tree.
Put a GIF file (format GIF-87a, interlaced or not, but NOT GIF-89a)
on your TFTP server. We will suppose that the file is named image.gif.
You can copy it wherever you want with the following command:
Copy "image.gif" "{:1}/temp/image.gif". Or you can use it
directly from the server. Now type Logvars "V*" and look at
the value of the VESA variable. If it is On, which is most
probable, that means you have a VESA-compliant video adapter and
you will be able to display the image with the following command:
DrawGif "image.gif". The image should be on the upper
left corner of the screen. You can draw it on another place by specifying
X and Y coordinates after the image name. You can also draw text
with DrawText 200 200 "Hello world" yellow. Or draw an empty
window with DrawWindow 200 200 300 150. When you are tired
of graphic mode, simply type CloseGraph.
Now take a text editor, and create a file named test.bpb
in the tftpboot directory with the following content:
:again
DrawWindow 150 200 400 160
DrawText 155 204 "Identity check" white
TextAttr Black LightGray
At 15,20 Print "Username : "
Input username 8
At 17,20 Print "Password : "
Getpasswd userpass 8
if "$username" != "smith" goto again
if not "$userpass" match-passwd "BpR8oiIlRR9bo" goto again
#
clear
DrawWindow 200 200 150 100 green
DrawText 205 204 "Congratulations" white
DrawText 220 250 "You got it !" yellow
WaitForKey 3
CloseGraph
interact
"-i"
to "test", and reboot the client computer. The small script
should run automatically, and ask you for a username and password.
If you do not type smith and justdoit, you wont be able to
boot the computer. Later you will learn how to use a Unix, NT or Radius
server to check valid user names.
In order to set up Linux, you will need to boot the floppy disk
provided with the RedHat Linux distribution. BpBatch includes a
command that can redirect the boot to the floppy: FloppyBoot.
Unfortunately, it does not seem to work correctly with this special
boot floppy (any suggestion is welcome to fix this). Consequently, you will
probably need to boot a computer without bootprom for this first
part of Linux setup.
Set up RedHat Linux on your client, with network support, and any packages you may want. You may want to recompile the kernel to better fit your hardware, but it is not necessary.
It is probably a good idea to include BOOTP support to the kernel, so that you do not have to customize the client IP address manually.
In order to reduce network load, you might also want to setup the
filecache for caching on the hard disk files that are
loaded by NFS.
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.
The filecache has been written by Unifix GmbH, and is part of
Unifix Linux 2.0. It is freely distributable, and you can get the
necessary files from
http://cuiwww.unige.ch/info/pc/remote-boot/soft/filecache.tar.gz.
In order to use the filecache, you have to
patch-filecache),
enable filecache support through make config or whatever
you prefer, and recompile the kernel/sbin/mnt/nfs (using mkdir)filecache.conf to /etc. This file contains
the following lines:
Max 100 MB 50 % # Cache /mnt/nfs/usr /usr Cache /mnt/nfs/opt /opt
/usr and /opt to the server,
export them read-only
with anon=0 (for allowing root access) and mount them under
/mnt/nfs (add a line for that in /etc/fstab)/usr as /usr.orig/usr to /mnt/nfs/usr/opt as /opt.orig/opt to /mnt/nfs/opt/usr and /opt are not empty and contains
the correct directories/usr.orig and /opt.origfilecache.init to /etc/rc.d/init.d/etc/rc.d/rc3.d/S35filecache to /etc/rc.d/init.d/filecache.init
Copy your compressed kernel image (zImage, bzImage, vmlinuz
or whatever you call it) to the
server /tftpboot directory as linux.krn. If you had to unplug
the bootprom from the PC, you can now plug it again. When BpBatch
starts, type LinuxBoot "linux.krn" "root=/dev/hda1 BOOT_IMAGE=linux"
(assuming
that the root ext2 filesystem is on the first partition). Alternatively,
if you did setup your configuration on a computer without bootprom,
just boot let it boot using the loader you installed (lilo, ...). But
in the later case, if you want the filecache to work, you should have
explicitely installed your kernel with filecache support at the right place.
Wait until the system comes up.
If you installed the filecache, you can check that /usr has
exploded into a directory with some symlinks and some already-exploded
directories. Now start the programs that the end-users will use most of
the time, in order to load them once for all to the hard disk.
You can still make adjustements to your configuration, like on any stand-alone linux station.
When you are happy with your configuration, login as root,
go to the /tmp directory and
run our mrzip program.
MrZip is a command interpreter like BpBatch, but it can
understand more commands than BpBatch does. In particular, it
can understand the following commands:
showlog
filter -"tmp/*"
filter -"var/log/*"
fullzip "/" "/tmp/linux.imz"
/tmp/linux.imz. Move it to
the server /tftpboot directory. Then copy the following
batch file to /tftpboot/linux.bpb:
hidelog
setpartitions "linux-ext2:992 linux-swap:32"
fullunzip "linux.imz" 1
clean 2
linuxboot "linux.krn" "root=/dev/hda1 BOOT_IMAGE=linux"
The BOOT_IMAGE argument is to stay compatible with lilo for
RedHat 5.1 and later rc.sysinit.
Your remote-boot linux configuration is ready ! You can now either
set the BOOTP-option-155 to "linux", or type include "linux.bpb"
from within BpBatch to test it.
If you want later to upgrade software, install bug fixes and security fixes, proceed as follow:
On the client computer, boot on your favorite dos floppy disk (either
remove the bootprom or type FloppyBoot within BpBatch).
Format the dos partition of your hard-drive with the /S
option, in order to put the operating system on it.
The size of the partition is not important, as disk archives created
with MrZip
Create a DOS subdirectory, copy DOS in it. Install your
favorite network client (for instance Microsoft LanManager),
Windows 3.1, and so on. If you use Microsoft LanManager,
do not use DHCP for the IP configuration as it is a very poor
implementation that will almost surely fail with reasonable
network load. To do that, add the following lines in your protocol.ref
file, in the section that loads tcptsr (of course, replaces the xxx
by your true IP parameters):
IPADDRESS0 = xxx xxx xxx xxx
SUBNETMASK0 = 255 255 xxx xxx
DEFAULTGATEWAY0 = xxx xxx xxx xxx
DISABLEDHCP = 1
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. Use the NOEMS parameter.
If you want to ensure that the client machine cannot be used without
a valid login name, download our nobreak
pseudo-device driver (available at
http://cuiwww.unige.ch/info/pc/remote-boot/soft/nobreak.zip)
and run it at the beginning of your
config.sys. Then add something like this to 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 the client and evaluating the following commands
within BpBatch interactive mode:
HideBootprom
HdBoot
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 files in it:
mrbatch.exe,
the DOS version of BpBatchmrzip.exe,
the DOS version of the program for building disk imagesbpbatch.hlp,
the on-line help filezipdos.mrz
file that contains the commands needed for building a DOS image, like this
one:
showlog
filter -"lanman.dos/lmuser.ini"
filter -"temp/*"
filter -"*.swp"
fullzip "c:/" "L:/tftpboot/dos.imz"
Now go back to your client, mount the admin volume on drive
L:, go to your utils directory and type the following command:
mrzip -b zipdos
One minute later, you will have a new file in the server
/tftpboot subdirectory called dos.imz, which is a
compressed image of your hard disk. Copy the following
batch file to /tftpboot/dos.bpb:
hidelog
setpartitions "bigdos:1024"
setbootpart 1
fullunzip "dos.imz" 1
hidebootprom
hdboot :1
Your remote-boot DOS configuration is ready ! You can now either
set the BOOTP-option-155 to "dos", or type include "dos.bpb"
from within BpBatch to test it.
If you want to customize some settings according to the machine,
typically the IP settings since Micro$oft DHCP is buggy,
you can setup BpBatch to change some files before booting.
Firsti go to the lanman.dos directory and do
copy *.ini *.ref
Then edit the .ref files and replace all fixed parameters with
BOOTP variable names as in the following examples:
computername = ${BOOTP-Host-Name}
ipaddress0 = ${MS-IPAddress}
subnetmask0 = ${MS-IPSubnet}
defaultgateway = ${MS-IPRouter}
Then rebuild the disk image as previously.
Note that for IP parameters, we do not use the BOOTP variables directly
because LanManager needs then as space-separated numbers instead of
dot-separated numbers. Change dos.bpb to the following:
hidelog
setpartitions "bigdos:1024"
setbootpart 1
fullunzip "dos.imz" 1
set MS-IPAddress="$BOOTP-Your-IP"/.= /
set MS-IPSubnet="$BOOTP-Subnet-Mask"/.= /
set MS-IPRouter="$BOOTP-Routers"/.= /
patch "{:1}lanman.dos/protocol.ref" "{:1}lanman.dos/protocol.ini"
patch "{:1}lanman.dos/tcpputils.ref" "{:1}lanman.dos/tcputils.ini"
patch "{:1}lanman.dos/lanman.ref" "{:1}lanman.dos/lanman.ini"
hidebootprom
hdboot :1
.ref files in the server
/tftpboot directory instead of in the disk image.
We like to be able to easily change the computers configuration
without rebuilding the image. To do that, copy your autoexec.bat
and config.sys as autoexec.ref and config.ref to the
server /tftpboot
and add the following two lines to the batch file above:
patch "autoexec.ref" "{:1}autoexec.bat"
patch "config.ref" "{:1}config.sys"
You can then freely change the files and even customize them
with machine-dependant values obtained from BOOTP.
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.
If you want later to add new software or change anything else, proceed as follow:
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:
Setup a regular Windows 95 client, either starting from scratch as explained in the configuration of a DOS client, starting from the DOS client and installing over the network (that is what we did). You can also start with a preconfigured Windows machine, but you will probably have less knowledge of what stuff is on the hard disk.
Proceed as described above for a DOS client. It is usually NOT necessary
to use EMM386 with Windows 95.
If you are using Windows 95 OSR2 (alias MSWIN 4.1, alias Windows 95
service pack 1, alias Windows 95 with Internet Explorer), you should
add the following line in the [Options] section of
MSDOS.SYS (yes, it is a text file):
AUTOSCAN=0
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.
Your MrZip script will be named zipwin95.mrz and contain:
showlog
filter -"temp/*"
filter -"*.swp"
fullzip "c:/" "L:/tftpboot/win95.imz"
To build the image, mount the admin volume on drive
L:, go to your utils directory and type the following command:
mrzip -b zipwin95
A few minutes later, you will have a new file if the server
/tftpboot subdirectory called win95.imz, which is a
compressed image of your hard disk. If your compressed image was bigger
than 87 MB, it has probably been splitted in two or more fragments.
These fragments will automatically loaded one after the other when
needed. Note that an image bigger than 87 MB will usually take
More than one minute to uncompress and may irritate your users.
Our Windows 95 image is only 70 MB big, because most software (except
Office and Explorer) completely reside on the server. Only 45 seconds
are needed to uncompress the image and restore the full disk.
Copy the following batch file to /tftpboot/win95.bpb:
hidelog
setpartitions "bigdos:1024"
setbootpart 1
fullunzip "win95.imz" 1
hidebootprom
hdboot :1
Your remote-boot Windows 95 configuration is ready ! You can now either
set the BOOTP-option-155 to "win95", or type include "win95.bpb"
from within BpBatch to test it.
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. PCI cards usually do not mind, but ISA Plug and Play do. 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, before starting it. Note that this trick is not any more needed with most PCI cards.
Move the autoexec.bat to the server as described above for DOS.
Edit it (on the server) and add the following lines:
rem --- Patch Windows registery in order to avoid plug-and-play detection regedit /L:c:\windows\system.dat /R:c:\windows\user.dat c:\temp\patch.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.
Run regedit under Windows 95, search for your network card,
usually under
HKEY_LOCAL_MACHINE\Enum\ISAPNP
and export the branch using the File menu. This will create a text
file, that you should same as patch.ref in the server /tftpboot
diretory. Edit this file and find out where the card ethernet address
is stored (do that on two different machines and compare the files
if you can't find it by yourself). Replace it by a pettern in the
form ${MACID}.
Then add lines to the win95.bpb script like this:
set macid = "$BOOTP-Client-ID"
patch "patch.ref" "{:1}temp/patch.reg"
(do any necessary string manipulation for setting MACID if it is
not exactly the client Ethernet address).
That's all, your clients should not any more try to autodect the network
card.
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 patch.ref file:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP]
"ComputerName"="${BOOTP-Host-Name}"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
"HostName"="${BOOTP-Host-Name}"
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\ComputerName\ComputerName]
"ComputerName"="${BOOTP-Host-Name}"
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.
If you want later to upgrade software, install bug fixes and security fixes, proceed as follow:
We do not use Windows NT for remote-boot client computers but we have tested our system to ensure that it work as well. And it works.
As our utilities currently have no support for NTFS (we neither have the documentation nor the time to do that, but I would be happy to help anyone who is interested in doing it), you will have to install NT on FAT16 (simply do not convert your partitions to NTFS during the setup).
Copy your win95.bpb boot script to winnt.bpb.
Change the setpartitions line in winnt.bpb to the following:
setpartitions "BIGDOS:512 BIGDOS:512"
Then boot Windows 95 using this script, and install
your NT client on drive C. Do not worry about the second partition for now.
Do not install too much stuff, or you will
get a really large and slow-to-uncompress image.
Remove Windows 95 from the disk disk C, you do not need it
in a Windows NT image (the boot menu is handled by the bootprom,
not by NT boot loader).
Reboot your computer in without overwriting the hard disk, ie. do not
execute the winnt script but just
hidebootprom
hdboot
Your NT station should start-up correctly. Make any
necessary customization.
The trouble with Windows NT is that direct disk access is prohibed
by the kernel. That means, MrZip will not even be able to read the
boot sectors. The best way to do an image is then to boot Windows 95
and to run MrZip from a DOS window. To do that, change the
winnt.bpb script so that the Windows 95 image is not restored
on the first but on the second partition:
hidelog
setpartitions "BIGDOS:512 BIGDOS:512"
setbootpart 2
fullunzip "win95.imz" 2
hidebootprom
hdboot :2
"{:1}" to
"{:2}"). Boot with this script; you should have Windows
95 running, but a new drive D: should be available, with
Windows NT inside.
Make your disk image as usual (but on D:, of course), and
save it as winnt.imz on the server /tftpboot directory.
Edit one last time the winnt.bpb script like this:
hidelog
setpartitions "BIGDOS:512 BIGDOS:512"
setbootpart 1
fullunzip "winnt.imz" 1
clean 2
#fullunzip "win95.imz" 2
hidebootprom
hdboot :1
If you want later to upgrade software, install bug fixes and security fixes, proceed as follow:
winnt.bpb: comment the clean and winnt fullunzip,
uncomment win95 fullunzip
This section lists most frequently encountered problems.
You are probably using a standard TFTP server, and it cannot handle more than 65535 packets of 512 bytes (or even 32767 packets for the Solaris server). That is, your image must be fragmented in pieces of no more than 30 MB (or 15 MB for Solaris). See under CopyArchive for instructions on fragmenting an existing image. But you should seriously thing about using InCom's extended TFTP server, as it is much more efficient (it uses packets of 1408 bytes instead of 512 bytes).
There are two possibilities. Either the image is really corrupted on the
server (try use MrZip to see if it is the case), or the file transfer
has failed because of TFTP timeout. TFTP timeout occurs when the network
is too heavily loaded (for instance if you try to download a huge image
with more than four clients at a time). In this case, BpBatch
does not retry indefinitely because it would not help. Shut down
a few computers and retry with no more than four computers (or maybe
even three).
If you often need to download images for a lot of computers, you can
try our special Broadcast TFTP server (see the section dedicated to it).
May be your computer has a bad VESA support. Try giving the -v
command-line argument or setting the VESA variable to "OFF".
We use a VESA 1.1 function for scrolling. If your video adapter does not support VESA 1.1, forget it. If the scrolling works for one page, but then produces a strange strippled pattern, do not worry. This is a known bug, I will fix it as soon as I have time for it (VESA scrolling is not really essential...)
When a file in the cache is corrupted by an external program,
it is automatically removed from the cache. When a file in the cache
is not fully written (because the computer is turned off during the
file transfer), it is also automatically removed. But if the server
transmits a corrupted file or if the transfer aborts from the server
side, it is possible that this file stays in the cache. You can clean-up
the cache simply by holding both shift down while BpBatch access
it for the first time. Alternatively, you can evaluate clean -1
in interactive mode.
This is not a bug. Exit is not a command. There is no exit or quit command because it does not make any sense to exit from a boot script without booting. And MrBatch is really the same program as BpBatch. What you can do instead is calling HdBoot. This makes sense, and the DOS version will cleanly exit instead of rebooting. Note that you can exit from the DOS version at any time by pressing Ctrl-Break. This will restore all hooked interrupts before leaving.
If you try to print something and immediately enter interactive mode,
you may not see your text. This is because your text was written
on the runtime screen and the Interact command has
switched the display to the Log screen. Just put a GetKey
after the print commands and you will see the text output.
Malloc failedMrZip needs a lot of conventional memory to run.
If you encounter this problem, first ensure that you have unloaded
the bootprom either using HideBootprom or using InCom's bputil.
If you run MrZip from
bare MS-DOS (not within Windows 95 DOS box), you should use EMM386
to load the network drivers high in order to get as much conventional
memory as possible. From a Windows 95 DOS box, there is usually no
problem (as long as you have not left your old 16-bit stuff in
your autoexec.bat when you installed Windows 95).
This bug has already been fixed once. Get the latest release of
MrZip. If the problem persists,
try to build your image with Trace set to "ON" (and usually
PauseLog set to "OFF"); this will let you discover which
file causes the problem. Send a detailled bug report.
MrZip is probably trying to read a locked, open or special file,
such as Windows swap
file. Such files should usually not be included in
the image and should be filtered out (using the filter command).
It is also possible that the operating system is playing you a trick.
If MrZip does not tell you what file causes the problem,
try to build your image with Trace set to "ON" (and usually
PauseLog set to "OFF").
You can also try to use direct
disk access (that is, do not refer the source partition as
"C:" or "/" but as "{:1}" or
whatever partition it is). Using
direct disk access is usually slower because we have less buffers than
the operating system, but it may be sometimes more reliable.
Disk images are stored in the special cache area and should not be reloaded if they have not changed on the server. However, as the cache area always starts after the last used partition, changing the total size of partitions will move the location of the cache and thus destroy its content. Another possible reason for a file disappearing from the cache is that the previous file has grown more than one-and-an-half times its initial size. The file would then have been overwritten and need to be downloaded once again. This should almost never occurs. A third possible reason is a too small cache area. If the free space left outside the partitions is less than one-and-an-half times the sum of all compressed image sizes, only the most recently used images will be present in the cache and the other will have to be reloaded on demand.
This distribution assumes Linux was booted using lilo and checks
for the BOOT_IMAGE command line argument (in
/etc/rc.d/rc.sysinit). Simply add it in the linuxboot
call, or change your rc.sysinit.
Linux dhcp client is a program that dynamically changes the IP address of the client according to DHCP offers. If the address is offered forever (infinite lease time), the DHCP client just set the address and returns (this is what we expect). However, if the lease time is limited, the DHCP client must remain loaded and ask for new addresses every few minutes. And if the DHCP client does not return, MrBatch will never be loaded... The solution is to give an infinite lease time (sometimes encoded as -1).
This problem occured on an AMI BIOS dated 94/07/25. We investigated a little bit, and found no solution. It seems that this problem is due to a bug in this BIOS (some register or memory location must be destroyed).
This problem was introduced with PXE compatibility, but has now been fixed. Please get the latest version.
This problem is due to libc6, which is not fully downward compatible with libc5. Linux version was linked with libc5. With the growing number of complaints, we decided to move the distribution to libc6. If you encounter this problem, simply get the latest version.
This problem is the reverse of the previous one. Now that the distribution is libc6 ready, it cannot be used any more with libc5. If you encounter this problem, simply upgrade your Linux box (Well, if we hear too much complaints, we might try to keep two distributions...).