Chip 1998 September

home *** CD-ROM | disk | FTP | other *** search

/ Chip 1998 September / CHIP Eylül 1998.iso / Slackwar / docs / mini / Remote-Boot < prev next >

Wrap

Text File | 1997-08-11 | 66.7 KB | 1,527 lines

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