linux server做为pxe server起NT 98/200无盘站的方法
The Configuration How-To
First, arrange to have the following two machines within arms reach:
* the server, usually a Unix or Windows NT machine.
* the client, a PC with a bootprom enabled, and nothing valuable on the hard disk.
If you want to test the configuration but you do not yet have a bootprom, you can download the TCP/IP BootProm demo diskette from Bootix at http://www.bootix.com. 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 Bootix 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.
4.1 Server-side configuration
On the server, you will need the following services:
1. A BOOTP/DHCP server.
2. Maybe a Proxy DHCP server.
3. A TFTP server.
Note for PXE Boot ROM users: make sure you have the latest PXE version. At the time of this writing, the latest version is PXE 2.0. PXE 0.99x bootroms are also supported, but some DHCP options may not be sent by the DHCP server. In particular, you should upgrade to PXE 2.0 if option 135 has no effect on BpBatch (BpBatch displays "Cannot load file" on startup). If your network card belongs to one of the Intel EPRO100 series of adapters, you can get the latest evaluation release in the Intel PXE Product Development Kit (PDK), which also includes the necessary flash utility to program the boot rom. The PDK is available at http://developer.intel.com/ial/wfm/tools/pxepdk20/index.htm.
Setting up DHCP
The role of the DHCP server is to give 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 Bootix 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 Bootix TCP/IP Bootprom, you will have to use a special trick to specify the boot file name (get more info from Bootix WWW site). If you are using a PXE Bootrom, you will need to define the boot filename using the DHCP option 67. You will also have to set the VendorClass (opt 60) to "PXEClient" and the VendorOptions (opt 43) to 01,04,00,00,00,00,ff (see below).
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 01:04:00:00:00:00:ff;.
If you are using ISC DHCP 3.0, the syntax is slightly different. Here is an example of a DHCP 3.0-compatible configuration :
# DHCP configuration file for DHCP ISC 3.0 & BpBatch
#
# Global options
option subnet-mask 255.255.255.0;
default-lease-time -1;
# Definition of PXE-specific options
# Code 1: Multicast IP address of bootfile
# Code 2: UDP port that client should monitor for MTFTP responses
# Code 3: UDP port that MTFTP servers are using to listen for MTFTP requests
# Code 4: Number of seconds a client must listen for activity before trying
# to start a new MTFTP transfer
# Code 5: Number of seconds a client must listen before trying to restart
# a MTFTP transfer
option space PXE;
option PXE.mtftp-ip code 1 = ip-address;
option PXE.mtftp-cport code 2 = unsigned integer 16;
option PXE.mtftp-sport code 3 = unsigned integer 16;
option PXE.mtftp-tmout code 4 = unsigned integer 8;
option PXE.mtftp-delay code 5 = unsigned integer 8;
# Subnet-specific options
subnet 192.168.1.0 netmask 255.255.255.0 {
option routers 192.168.1.1;
# Host specific options
host pctest {
hardware ethernet 00:01:02:03:04:05;
filename "bpbatch.P";
next-server 192.168.1.2;
fixed-address 192.168.1.100;
# BpBatch command-line argument : -i == interactive
# You can also specify a script name (do not include the
# trailing .bpb extension)
option option-135 "-i";
# PXE specific options
class "pxeclients"
{
match if substring (option vendor-class-identifier, 0, 9) =
"PXEClient";
option vendor-class-identifier "PXEClient";
# At least one of the vendor-specific option must be set. We set
# the MCAST IP address to 0.0.0.0 to tell the bootrom to still use
# TFTP (address 0.0.0.0 is considered as "no address")
option PXE.mtftp-ip 0.0.0.0;
vendor-option-space PXE;
}
}
}
On Solaris, you can either use the Internet Software Consortium DHCP server (available on the Web), or use the Solaris DHCP server (available since Solaris 2.5). However, as the Solaris DHCP server does not seem 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 the Solaris DHCP server locks the DHCP port.
We suggest giving infinite lease time for remote-boot clients. Don 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.
If you are using a PXE 2.0 bootrom, you can only uses site-specific options numbered from 128 to 135 for passing information to BpBatch. Options with a number greater than 135 are ignored by PXE 2.0 bootroms. Option-135 is used by BpBatch for command-line arguments. You have 6 options left for your specific needs.
Setting up a Proxy DHCP
The role of the Proxy DHCP server is to overcome limitations of some DHCP servers and to provide PXE specific extensions. A proxy DHCP server only makes sense for a PXE Boot rom. However, the Proxy DHCP server is not mandatory. If your DHCP server sends all the requested options, the PXE bootrom will not search for a Proxy DHCP (aka BINL). By "all the requested options", we mean basic IP options (IP address, gateway, subnet, hostname, ...) and PXE vendor-specific options (vendor-class -- opt 60 -- set to "PXEClient" and vendor-encapsulated-options set to something meaningful for a PXE bootrom. You can use 01:04:00:00:00:00:ff if you don know what is meaningful for a PXE bootrom). A more complete description is shown below.
As BpBatch itself is quite powerful, you won 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. By minimal PXE compliance, we mean setting the VendorClass and VendorOptions (options 60 and 43 resp.).
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 the DHCP port answers 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 the 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
1. a client class (T60) set to PXEClient.
2. vendor encapsulated options (T43). (Cannot be empty. But you can specify hex 01:04:00:00:00:00, it will be interpreted properly by the PXE bootrom).
3. a non-empty boot filename.
4. a valid hostname.
The PXE specific negotiation ends as soon as all this info is received, but can lead to a very complex process (install server discovery, etc.) if some information is missing.
Setting up TFTP
The TFTP server is a very simple file server. In its basic version, TFTP uses 512 bytes data blocks, which are quite inefficient. Bootix 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 the Intel TFTP server, available from the Intel PXE Product Development Kit for Windows. You can find the PDK at http://developer.intel.com/ial/wfm/tools/pxepdk20/index.htm. Important note: if you plan to use the Intel TFTP server on Windows NT, do not forget to rename your BpBatch loader from bpbatch.P to bpbatch.B. This will tell BpBatch to use Intel-compatible TFTP options.
The Intel PXE PDK also includes evaluation PXE boot rom code for the Intel EPRO100 series of network adapters, along with the necessary flash utility to program the boot rom with the latest PXE release.
On Linux, you can use the tftp daemon included in most distributions, but you will have no support for the enhanced TFTP mode (1408 bytes packets). We suggest to get the Bootix enhanced TFTP server, available on our distribution directory ( http://cuiwww.unige.ch/info/pc/remote-boot/soft/), the filename is incomtftpdlx.tar.gz.
On Solaris, you should use Bootix enhanced TFTP serer, also available in our distribution directory (filename is incomtftpdsun.tar.gz). Another possible choice: John Martin ([email protected]) has ported Linux tftpd for Solaris. You can get it from http://www.csd.abdn.ac.uk/~jmartin/tftpd.tar.gz.
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 Bootix for the TCP/IP Bootprom. We still use it as an easy way to select the default TFTP port with PXE bootproms.)
In summary, if you plan to use a standard TFTP server, remove the extension from BpBatchs loader filename (i.e bpbatch). If you plan to use the Bootix TFTP server with support for 1408 bytes packets on port 59, your loaders filename must have the .P extension. Finally, if you plan to use the Intel TFTP server (or the one from Bootware), rename your loader to bpbatch.B.
4.2 Client-side configuration
First, we will set up the part common to all operating systems, i.e. the batch-file interpreter. Then, for each operating system, we will go through the following steps:
1. Set up a stand-alone client.
2. Save its configuration on the server.
3. Test it as a remote-boot client.
4. 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 Boot ROM in it (or buying a Wired for Management ready computer...) and adding one line in the DHCP configuration file.
Our examples assume that you have a hard disk of 1.4 Gb or more. If you have less, reduce the size of the partitions, but remember that you need to leave a few hundreds megabytes unallocated (that is, the last partition must not take up to the last cylinder) to leave room for the special cache partition. Moreover, the cache always starts at the cylinder following the last allocated cylinder, so 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 get it to work, first look in the Troubleshooting section if your problem is not already solved (get the latest version from the Web). Then, take a look in the BpBatch forum. Perhaps someone else had the same troubles, and the answer can be found in the forum. Forums URL : http://cuiwww.unige.ch/info/pc/remote-boot/forum/. 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 [email protected]. If your problem is strictly related with the remote-boot configuration, we will try to solve your problem.
4.3 Setting Up the Boot Process
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.gz.
In the server /tftpboot directory, put the following three special boot images, which together make our pre-boot batch file interpreter (in the following lines, we use bpbatch.P as the loaders name. If you are not using the Bootix TFTP server, rename the loader to either bpbatch (standard TFTP) or bpbatch.B (Intel/Bootware TFTP server):
* bpbatch.P, the dynamic loader (respect the uppercase and read the section about TFTP servers for selecting the proper extension).
* bpbatch.ovl, the relocated interpreter
* bpbatch.hlp, the on-line help file
Then add an entry in the DHCP configuration file for your client, with the boot file set to "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
* The Boot ROM copyright.
* The string DHCP while the client waits for a DHCP reply.
* The string TFTP while the client waits for the first TFTP packet.
* The string Loading BpBatch while the loader downloads the interpreter.
* And finaly our banner, followed by a nice greater-than prompt.
Congratulations ! You have started the batch interpreter... If you are curious about what you can do with it, continue reading the next section. If you are in a hurry, skip it and directly go install the operating system of your choice. If you have any doubt about a command within the interpreter, type help.
Note that you can run the same interpreter within DOS and Linux by running the MrBatch program. There are only very few differences (the Linux versions 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 yourself how to make such a menu. All necessary commands are documented at the end of this document.
Discovering BpBatch
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. You can list the available video modes using Echo "$VESA-Modes". To display your image try 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. To insert a title when you create a new window, try DrawWindow 200 200 300 150 "My Window". When you are tired of graphic mode, simply type CloseGraph.
Note on graphics : by default, all graphical routines work in the 800x600 VESA mode (with 256 colors), which is the first field of the VESA-Modes variable. If you want to use a different video mode, change the variable in order to have the requested video mode as the first field of the list.
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 "Identity check"
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 blue "Congratulations"
DrawText 220 250 "You got it !" yellow
WaitForKey 3
CloseGraph
interact
In your BOOTP/DHCP configuration, change the option-155 from "-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.
4.4 Setting Up Linux
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.
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.
Configuring the Client
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 file cache for caching on the hard disk files that are loaded by NFS. Roughly, the principle of the file cache 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 file cache 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 file cache, you have to
* apply a patch to the kernel (file patch-filecache), enable file cache support through make config or whatever you prefer, and recompile the kernel.
* copy the file cache binary file to /sbin.
* create a mount point called /mnt/nfs (using mkdir).
* copy filecache.conf to /etc. This file contains the following lines:
Max 100 MB 50 % #
Cache /mnt/nfs/usr /usr
Cache /mnt/nfs/opt /opt
* copy the content of /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)
* rename /usr as /usr.orig
* link /usr to /mnt/nfs/usr
* rename /opt as /opt.orig
* link /opt to /mnt/nfs/opt
* ensure that /usr and /opt are not empty and contain the correct directories.
* recursively remove /usr.orig and /opt.orig.
* copy filecache.init to /etc/rc.d/init.d.
* And finally link /etc/rc.d/rc3.d/S35filecache to /etc/rc.d/init.d/filecache.init.
If you successfully followed each of these steps, you should have the file cache working next time you boot, as long as you do not forget to use your patched kernel.
Testing the Configuration
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 let it boot using the loader you installed (lilo, ...). But in the latter case, if you want the file cache to work, you should have explicitly installed your kernel with file cache support at the right place.
Wait until the system comes up. If you installed the file cache, 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 and for all to the hard disk.
You can still make adjustements to your configuration, like on any stand-alone linux station.
Building the Disk Image
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"
This will create a disk image in /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.
System Maintenance and Upgrades
If you want later to upgrade software, install bug fixes and security fixes, proceed as follow:
* Remote-boot a client computer to get a fresh linux install.
* Make your changes.
* Redo the disk image.
* Copy the new image in place of the old one on the server.
That means, you can upgrade software on your server-based configuration as if it were a purely local install.
4.5 Setting up DOS 6 and Windows 3.1
On the client computer, boot from 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 are file-based and therefore partition-size independant.
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 boots well by rebooting the client and evaluating the following commands within BpBatch interactive mode:
HideBootprom
HdBoot
The PC should boot on the hard disk as if BpBatch were never seen.
Building the Disk Image
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 BpBatch.
* mrzip.exe, the DOS version of the program for building disk images.
* bpbatch.hlp, the on-line help file.
You might also like to put in the same directory a simple MrZip script file named zipdos.mrz 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.
Adapting the configuration for other machines
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. First 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
If you prefer, you can also put the .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-dependent values obtained from BOOTP.
After making any changes to the client machine configuration, do not forget to rebuild the disk image using mrzip if you want to preserve your changes.
System Maintenance and Upgrades
If you later want to add new software or change anything else, proceed as follows:
* Remote-boot a client computer to get a fresh install.
* Make your changes.
* Redo the disk image.
* Copy the new image in place of the old one on the server.
That means, you can upgrade software on your server-based configuration as if it were a purely local install.
4.6 Setting up Windows 95/98
In previous versions of this document, we used the Microsoft server-based installation of Windows 95/98, 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, Novells 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/98. 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 removed from this document all the information and bug-workarounds 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/98 is now almost as easy the configuration for DOS.
Setting up a Stand-Alone Client
Set up a regular Windows 95/98 client, either starting from scratch as explained in the configuration of a DOS client, or 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/98. If you are using Windows 98 or 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
This will let Windows know that you do not want ScanDisk to be run automatically at boot time.
If you want to reduce network and server load (which will improve your system performance) 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.
Building the Disk Image
At this point, if you are using a Samba server, you might have to disable password encryption to be able to mount the admin volume later on. You can do that by adding a registry key EnablePlainTextPassword with a DWORD value of 1 in the section
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP]
Your MrZip script will be named zipwin.mrz and contain:
showlog
filter -"windows/schedlog.txt"
filter -"windows/msimgsiz.dat"
filter -"*/index.dat"
filter -"*.swp"
filter -"*.tmp"
filter -"temp/*"
fullzip "c:/" "L:/tftpboot/win.imz"
To build the image, mount the admin volume on drive L:, go to your utils directory and type the following command:
mrzip -b zipwin
A few minutes later, you will have a new file in the server /tftpboot subdirectory called win.imz, which is a compressed image of your hard disk. If your compressed image was bigger than 87 MB, it has probably been split in two or more fragments. These fragments will automatically be 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/98 image is only 70 MB big, because most softwares are installed on the server and are loaded on demand only. There are only few software that you really have to install locally. If you take care of this issue as we did, you should be able to uncompress the image and restore the full disk in less than one minute.
Copy the following batch file to /tftpboot/win.bpb:
hidelog
setpartitions "bigdos:1024"
setbootpart 1
fullunzip "win.imz" 1
hidebootprom
hdboot :1
Your remote-boot Windows 95/98 configuration is ready! You can now either set the BOOTP-option-155 to "win", or type include "win.bpb" from within BpBatch to test it.
Adapting the configuration for other Machines
The big difference between Windows 3.1 and Windows 95/98 is that the latter includes code for Plug-and-play , i.e. 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 Windows 95/98 their personal serial number (for instance, every Windows 95/98 differentiates every network card on the basis of its world-wide unique ethernet address).
The fact that Windows 95/98 discovers that the hardware has changed may not be a problem if the plug-and-play works as it should, but it becomes 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 results in no mouse at all. To solve such kind of problems, arrange to have all computers as similar as possible, or make different images for different hardware. Later, you will discover that you can simply use the same image and just have several copies of the registry, that you can copy after having restored the disk image but before booting.
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/98 believe that it already knows 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 the Windows 95/98 registry, 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 registry 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/98 program that let you browse the registry if you start it from within Windows, or do simple operations on the registry if you call it from DOS. Run regedit under Windows, 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 directory. Edit this file and find out where the cards ethernet address is stored (do that on two different machines and compare the files if you can find it by yourself). Replace it by a pattern in the form ${MACID}. Then add lines to the win.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). Thats 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 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 registry trick, your configuration should normally be portable to all machines with similar configurations. If you cannot avoid that Windows detects some hardware as new on one machine, try to rebuild the disk image from this machine. This will include the registry configuration specific to this machine into the image, and hopefully suppress the problem.
System Maintenance and Upgrades
If you want later to upgrade software, install bug fixes and security fixes, proceed as follows:
* Remote-boot a client computer to get a fresh install.
* Make your changes.
* Redo the disk image.
* Copy the new image in place of the old one on the server.
That means, you can upgrade software on your server-based configuration as if it were a purely local install.
4.7 Setting up Windows NT
We do not use Windows NT for remote-boot client computers but we have tested our system to ensure that it works as well. And it does.
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 win.bpb boot script to winnt.bpb. Change the setpartitions line in winnt.bpb to the following:
setpartitions "BIGDOS:512 BIGDOS:512"
Then boot Windows 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 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 the NT boot loader).
Reboot your computer without overwriting the hard disk, i.e. do not execute the winnt script but just
hidebootprom
hdboot
Your NT station should start-up correctly. Make any necessary customization.
Building the Disk Image
The trouble with Windows NT is that direct disk access is prohibited 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/98 and to run MrZip from a DOS window. To do that, change the winnt.bpb script so that the Windows image is not restored on the first but on the second partition:
hidelog
setpartitions "BIGDOS:512 BIGDOS:512"
setbootpart 2
fullunzip "win.imz" 2
hidebootprom
hdboot :2
(if you have any supplementary patch, change the "{:1}" to "{:2}"). Boot with this script; you should have Windows 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 "win.imz" 2
hidebootprom
hdboot :1
Your Windows NT remote-boot configuration is ready. Of course, if you do not like to have two partitions, you can setup a single partition instead. But when you have to rebuild the image, you will have to setup the second partition again for booting Windows 95.
System Maintenance and Upgrades
If you want later to upgrade software, install bug fixes and security fixes, proceed as follows:
* Remote-boot a client computer to get a fresh install.
* Make your changes.
* Edit winnt.bpb: comment the clean and winnt fullunzip, uncomment win95 fullunzip.
* Redo the disk image.
* Copy the new image in place of the old one on the server.
Thats all, folks!
4.8 Troubleshooting (FAQ)
This section lists the most frequently encountered problems.
The image download never ends
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. If your are using a standard TFTP server, you should consider installing the Bootix or Intel TFTP server. See next question for issues about these servers.
BpBatch display a "Fragment is not complete" error message
This a TFTP issue. Your loaders filename extension must be adequately set (read the section about TFTP servers). If you are using the Bootix TFTP server with the -s 1408 59 option, your loader should be named bpbatch.P. If you are using the Intel or Bootware TFTP server with blksize TFTP option support, rename your loader to bpbatch.B. Finally, if you are using a standard TFTP server, rename your loader to bpbatch (no extension). In this last case BpBatch will use 512-bytes packets instead of 1408-bytes. This will limit the size of the fragments to 32Mb (internal TFTP limitation) instead of 87Mb. See above question for issues about 512-bytes packets.
The archive decompression fails immediately
There are three 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 a TFTP timeout, or because of an incompatible protocol.
A 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).
An incompatible protocol error is caused by using a standard TFTP server (typically the one built-in in your UNIX server) while asking BpBatch to work with enhanced TFTP. If you use a standard TFTP server, you should remove the .P extension (see the explanation in the next question).
The computer hangs instead of downloading/unzipping (1)
If you are using Bootixs TFTP server, try to add -s 1408 59 to the command line. If you are not using an enhanced TFTP server, remove the .P extension from BpBatch filename on the server and in bootptab.
Detailed explanation : this problem occurs if you did not setup an extended TFTP server but you used bpbatch.P as the boot filename DHCP/BOOTP tag. BpBatch will indeed try to connect to an Bootix TFTP server when the boot filename ends with a .P extension. To solve this problem, you can either remove the .P extension at the end of the boot filename (it will tell BpBatch to use standard TFTP) or install an extended TFTP server. Alternatively, you can install the Intel TFTP server and rename the loader to bpbatch.B. Note: for Bootixs TFTP server to properly work with the extended TFTP feature, you must add -s 1408 59 to the command line.
The computer hangs instead of downloading/unzipping (2)
May be your computer has a bad VESA support. Try giving the -v command-line argument or setting the VESA variable to "OFF".
VESA scrolling is broken
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...).
There is a corrupted file in the cache
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 keys down while BpBatch accesses it for the first time. Alternatively, you can evaluate clean -1 in interactive mode.
The EXIT command does not work in a batch file
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.
The Print command does not print
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.
MrZip says Malloc failed
MrZip 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 Bootixs bputil. If you run MrZip from bare MS-DOS (not within Windows 95/98 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 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).
MrZip aborts while reading directories
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 detailed bug report.
MrZip cannot access some file
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 to 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 always reloaded from the server
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.
Red Hat Linux 5.1 does not boot properly
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.
The broadcast TFTP ramdisk hangs (Got in bound state)
The Linux DHCP client is a program that dynamically changes the IP address of the client according to the DHCP offers. If the address is offered forever (infinite lease time), the DHCP client just sets 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).
File access hangs under BpBatch, but not under MrBatch
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).
Unzip of a fragmented archive fails (Malloc failed)
This problem was introduced with PXE compatibility, but has now been fixed. Please get the latest version.
MrBatch and MrZip complain about the terminal under RedHat 5.x
This problem has been fixed in the 9th of August version of MrBatch/MrZip. There was a problem with a new version of ncurses which has been released with RedHat 5.1.
"libncurses.so.3.0: cannot open shared object file" under Linux
MrZip has been linked to the version 3.0 of libncurses. You can use other versions of libncurses only if they are newer than version 3.0. To use a newer libncurses, all you have to do is to create a soft link from libncurses.so.3.0 to your libncurses.so.xx file. With RedHat 5.1, you can use the following command : cd /usr/lib ; ln -s libncurses.4.2 libncurses.3.0 You can also download a version recent version of mrzip/mrbatch. Starting from the 10/25/98 release, MrBatch is now compiled under RedHat 5.1.
MrBatch and MrZip do not start under Linux (file not found)
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...).
I can not access other mode than the default 800x600 VESA mode
You should first display the contents of the VESA-Modes variable, to see if your hardware supports the mode you would like to use. Then, try one of the two ways to select a special VESA mode :
* InitGraph "mode": Try InitGraph "1024x768", and then run the graphical primitive you are interested in (e.g DrawGif).
* VESA-Modes: The first field of the VESA-Modes variable is the name of the default mode. If you change the VESA-Modes variable, all graphical primitives will use the mode you specified.
BpBatch prints a "Malloc failed" message when restoring multiple fragments images
We corrected a bug in the memory allocation functions of BpBatch. You should make sure that you have a version of BpBatch which has been released after september the 22nd 1998.
Fullunzip using the Linux version of MrBatch always fails
We corrected this problem in the 09/22/1998 release.
Scandisk says my disk is corrupted
The 10/25/98 release did correct a problem with large images. Try to download a recent version of BpBatch.
My RedHat boot floppydisk does not work with FloppyBoot
This bug has been corrected in the 10/25/98 release.
My FAT32 disk image does not boot properly
This bug has been corrected in the 02/09/99 release.
You always get "Cannot load file" when you start BpBatch
Your DHCP server does not send a valid option-135 to the client. BpBatch uses option 135 as its command-line arguments. You can specify "-i" if you want to go interactive, or you can specify a script name if you want BpBatch to start the selected script (do not include the trailing .bpb extension). If you are using a PXE bootrom, make sure that you are using option-135 for command-line arguments. Option-155 is not more supported by PXE 2.0 bootroms.发布人:pxe2 来自: