Linux Remote-Boot mini-HOWTO: Configuring Remote-Boot Workstations with Red-Hat Linux, DOS, Windows 3.1 and Windows 95 <author>Marc Vuilleumier Stückelberg, Sandro Viale and David Clerc <date>v2.5, August 1997 <abstract> This document describes how to set up a very robust server-based configuration 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 materials, can be found at the address <tt><htmlurl url="http://cuiwww.unige.ch/info/pc/remote-boot/howto.html" name="http://cuiwww.unige.ch/info/pc/remote-boot/howto.html"></tt>. Linuxdoc-SGML, DVI and postscript versions are available in the same directory. </abstract> <toc> <sect>What has changed... <sect1>...since version 1.x ? A lot of things: <itemize> <item>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. <item>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). <item>We now use a DHCP server, with standard DHCP/BOOTP extensions (RFC 2132). <item>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... </itemize> <sect1>...since version 2.4 ? A new banner feature has been added to the <tt>bpunzip</tt> 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 (<htmlurl url="http://www.lancache.com" name="Shared LAN Cache">) and documentation (from J. Carlstedt, of <htmlurl url="http://www.katedral.se/system/elevsyst" name="The Cathedral School of Uppsala, Sweden">) have also been added. <sect>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: <itemize> <item>computers devoted to students <item>computers devoted to research and teaching assistants </itemize> We developped the current configuration with the following aims: <itemize> <item>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. <item>All softwares, including operating systems, should reside on the server, in order to facilitate the installations and upgrades. <item>Clients computers should be able to run without any write-access on the server (for security reasons), except their home directory. <item>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. <item>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. <item>Users <em/must/ have a login to be able to use any of the computers. <item>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. <item>Students computers should be fully cleaned up at each start. That is, the PC should always look like if it were just installed. <item>Every computer has to be protected from virus attacks. </itemize> These constraints lead us to base our configuration on the excellent <bf><htmlurl url="http://www.incom.de/bp_info.htm" name="TCP/IP Bootprom"> </bf> from <bf><htmlurl url="http://www.incom.de/bp_info.htm" name="Köppen EDV GmbH"></bf>. 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. <sect1>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. <sect1>How it Works <enum> <item>When a client PC is turned on, it first performs the traditional system checks before the TCP/IP bootprom takes the control. <item>The bootprom issues a BOOTP/DHCP request in order to get its IP configuration parameters. <item>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. <item>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. <item>The PC <em/boot/ on this disk image, which happens to contains a single boot program (no operating system yet). <item>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. <item>The program then offers to the user the choice of the operating system for the session. <item>According to the choice of the user, a new bootdisk image is downloaded from the server, using TFTP. <item>If the user decides to use <bf/Linux/, the boot image is a a kernel loader plus a compressed kernel, with support for NFS root and caching filesystem: <enum> <item>First, the IP configuration is made according to the BOOTP/DHCP reply received from the Novell server. <item>The kernel is then able to mount a read-only root filesystem, using NFS. <item>A small ramdisk is set up and mounted to the places where write access is desirable. <item>If a swap partition is found on the local hard disk, it is prepared and activated. <item>If a linux partition is found on the local hard disk, it is mounted and prepared for caching NFS partitions. <item>IP configuration is finalized, services are started, and xdm is launched. <item>The user is asked for its login. The workstation is ready. </enum> <item>If the user decides to use <bf/DOS/ or <bf/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: <enum> <item>The program download a checksum file (512 bytes) that validates the boot image of the choosen operating system <item>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. <item>The operating system image is decompressed into the first FAT16 partition, at the approximate speed of one second per used megabyte. <item>The program jump into the boot sector of the selected OS, which is now completely present on the local hard-disk. </enum> For <bf/DOS and Windows 3.1/, we use the freely available Microsoft LanManager for DOS (search the network for the mirror nearest to you; the distribution consists of three files named <tt/disk1/ to <tt/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 <tt/win/ command. Note that at this point, DOS and Windows 3.1 appear to be installed locally. For <bf/Windows 95/, we also use Microsoft SMB client (called <it/Client for the Microsoft Network/), that supports dynamic configuration using DHCP. We reduce network load using <htmlurl url="http://www.lancache.com" name="Shared LAN Cache">, a nice and powerful network-to-disk cache program. </enum> Students computers can be turned off <em/the hard way/ at any time without 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. <sect1>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 <tt/Marc.VuilleumierStuckelberg@cui.unige.ch/. And if you experience problems while reproducing this configuration, have a look at these pages ! <itemize> <item><tt><htmlurl url="http://www.katedral.se/system/elevsyst" name="http://www.katedral.se/system/elevsyst"></tt>, by Johan Carlstedt of The Cathedral School of Uppsala, Sweden. </itemize> <sect>The Configuration How-To First, arrange to have the following two machines within arm's reach: <itemize> <item>the <bf/server/, for us a Unix machine <item>the <bf/client/, a PC with a TCP/IP bootprom enabled, and nothing valuable on the hard disk. </itemize> If you want to test the configuration but you do not yet have a TCP/IP Bootprom, you can download the demo diskette from <tt><htmlurl url="http://www.incom.de" name="http://www.incom.de"></tt>. 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 <tt/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: <itemize> <item>Configure the initial hard-disk setup and cleaning <item>Configure the operating system choice menu <item>Test the boot process </itemize> Then, for each operating system, we will go through the following steps: <itemize> <item>Setup a stand-alone client <item>Save its configuration on the server <item>Test it as a remote-boot client <item>Adapt it so that it works for any similar client machine </itemize> 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. <sect1>Setting Up the Boot Process In the server <tt>/tftpboot</tt> directory, put the following special boot images (warning for hypertext readers: these are binary files) <itemize> <item><tt><htmlurl url="soft/tftpboot/bpclean" name="bpclean"></tt>, our hard-disk cleaning utility <item><tt>bpmenu</tt>, the TCP/IP Bootprom menu program (included with your bootprom utility disk) <item><tt><htmlurl url="soft/tftpboot/bpunzip" name="bpunzip"></tt>, our hard-disk restore utility <item><tt><htmlurl url="soft/tftpboot/bphdboot" name="bphdboot"></tt>, the image that redirect the boot process to the hard disk </itemize> <sect2>The Initial Hard-disk Setup and Cleaning In the same directory, create a symbolic link to (or make a copy of) <tt/bpclean/ named <tt/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 <tt/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 <tscreen><code> # 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 </code></tscreen> The precise format of the file is described later in this document. For now, all you need to know is that <itemize> <item>partition type 6 is <it/BIGDOS/, ie. DOS Fat-16 from 32Mb to 500Mb <item>partition type hex 82 is <it/Linux Swap/ <item>partition type hex 83 is <it/Linux Ext2fs/ <item>the negative size means that we partition three should occupy all available space but 50 Mb <item>partition type 0 means <it/empty/ (unused) partition entry. </itemize> For now, <tt/bpclean/ will not erase the content of any partition but rewrite the master boot record, including the partition table. <sect2>The Operating System Choice Menu Similarly, create a symbolic link to (or make a copy of) <tt/bpmenu/ named <tt/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 <tt/XXXmenu.m/ containing the boot menu for your machine. You might either create this file by hand, or use our <tt><htmlurl url="soft/dos/bin/menuedit.exe" name="menuedit.exe"></tt> full-screen menu editor. For the example, assume that you use the following file: <tscreen><code> .CLS 23 .ATT 23 .POS 23 4 .WRT Simple Boot Menu \ .POS 23 5 .WRT ---------------- \ .POS 23 8 .WRT 1. Boot from local hard disk \ .POS 23 10 .WRT 2. Boot DOS and Windows 3 \ .POS 23 12 .WRT 3. Boot Windows 95 \ .POS 23 14 .WRT 4. Boot RedHat Linux \ .POS 23 17 .WRT Your choice : \ .POS 37 17 .KEY 1 :bphdboot .KEY 2 :linux.PX .KEY 3 :win31.P .KEY 4 :win95.P </code></tscreen> <sect2>Testing the Boot Process Create an entry in the DHCP configuration file for your client. Set the boot image to <tt>/tftpboot/XXXclean</tt>. 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 <tt/bpclean/, telling you the size of the partitions created, and then the boot menu should appear on your screen. You can use the <tt/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 <tt/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 (<tt/lilo/) does that. Such changes would be destroyed by <tt/bpclean/, so you should better change the DHCP entry for your client so that the boot image is directly <tt>/tftpboot/XXXmenu</tt> (no clean). Don't forget to restart the DHCP server to take your changes into account. <sect1>Setting Up Linux Set up <htmlurl url="http://www.redhat.com" name="RedHat Linux 4.1"> on your client, with network support, kernel sources and any packages you may want. Prepare future moint points (a <tt>/mnt/tmp</tt> will be usefull), setup your X server, and so on. In the directory <tt>/usr/src/linux-2.0.27</tt>, 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). <sect2>Building the Kernel First, go to your <tt>/usr/src</tt> directory and apply the following patches, using the command <tt/patch -p0 < /<em/the-patch-file/: <itemize> <item><tt><htmlurl url="soft/linux/src/kernel/patch-2.0.28" name="patch-2.0.28"></tt>: this is the official kernel update, a big patch that you should better apply <item><tt><htmlurl url="soft/linux/src/kernel/patch-config-sound" name="patch-config-sound"></tt>: a cosmetic patch for the sound configuration, taken from Unifix Linux 2.0 <item><tt><htmlurl url="soft/linux/src/kernel/patch-PCSP" name="patch-PCSP"></tt>: a rather big patch for adding soundcard emulation using the PC speaker, taken from Unifix Linux 2.0 <item><tt><htmlurl url="soft/linux/src/kernel/patch-bootprom" name="patch-bootprom"></tt>: a small patch that will let you produce a special kernel image, usable as a boot image with the TCP/IP Bootprom <item><tt><htmlurl url="soft/linux/src/kernel/patch-filecache" name="patch-filecache"></tt>: a small patch that adds special functionalities to your kernel, so that you can use Unifix filecache. Taken from Unifix Linux 2.0 <item><tt><htmlurl url="soft/linux/src/kernel/patch-penguinlogo" name="patch-penguinlogo"></tt>: a small patch that will help your end-users to wait until your Linux system is completely loaded <item><tt><htmlurl url="soft/linux/src/kernel/patch-2.0.29" name="patch-2.0.29"></tt>: 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. <item><tt><htmlurl url="soft/linux/src/kernel/patch-2.0.30" name="patch-2.0.30"></tt>: 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 <it/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. </itemize> Then run <tt/make mrproper/ and <tt/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 <itemize> <item>networking support <item>NFS-Root support, with BOOTP support <item><tt/filecache/ support <item>support for the client computer hardware, possibly modular </itemize> You may use our <tt><htmlurl url="soft/linux/src/kernel/good.config" name=".config"></tt> 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 <tt/make clean; make dep/ and then <tt/make zImage/, <tt/make modules/ and <tt/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 <tt/depmod -a/ to compute the modules dependencies. When there are no more errors, do a <tt/make bpImage/ to build a bootimage for use with the TCP/IP Bootprom. <sect2>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 <tt/rootfs/, and create another new directory within it named <tt/runtime/. We use <tt>/export/linux/rootfs/runtime</tt>. Export it read-write, with root access (<tt/annon=0/), for your Linux client only. For instance, our NFS server is running under Solaris, and we gave the command: <tt>share -F nfs -o rw=pc7971,anon=0 /export/linux/rootfs/runtime</tt>. Mount this partition on your Linux client and copy the whole Linux system on it using GNU <tt/tar/ (the default on RedHat Linux). It is important that you use GNU <tt/tar/ because all <tt/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) <tt>/export/linux/rootfs/runtime/etc/sysconfig/network-scripts/ifcfg-eth0</tt> since the network device will be initialized by NFS-root and should not be initialized twice. Now duplicate the linux entry in your <tt>/etc/lilo.conf</tt>, using the name <tt/linux-nfs/ for instance, and add the following parameter to it: <tt>append="root=/dev/nfs nfsroot=/export/linux/rootfs/runtime nfsaddrs=</tt><em/your-ip:server-ip:gateway-ip:netmask:machine-name/<tt/"/ (where <em/your-ip/ is the decimal dotted notation for your Linux client IP address, <em/server-ip/ is the NFS server IP address, <em/gateway-ip/ is the default gateway used by the Linux machine, <em/netmask/ is the netmask and <em/machine-name/ is the hostname of the Linux machine). Run lilo again, reboot your computer (still from the hard disk), and choose <tt/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 <tt/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 <tt>/usr/src/linux/Documentation</tt> files... You might also look at the <htmlurl url="http://www.ag.or.at/~andreas/NFS-Root-Mini-Howto.html" name="NFS-Root-Mini-Howto">. You can repeat the experience with only <tt>append="root=/dev/nfs"</tt> 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: <tscreen><code> option subnet-mask 255.255.252.0; option routers 129.194.68.1; option root-path "/export/linux/rootfs"; </code></tscreen> If your Linux kernel needs additional command-line parameters, you can add them using <tt/option option-177/. The next step is to have our system work with a read-only NFS filesystem. <sect2>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 <tt>/export/linux/rootfs</tt> directory, so that the standard distribution is directly available under <tt>/runtime/</tt>. Log on your NFS server and create the following directories and links, under <tt>/export/linux/rootfs</tt>: <itemize> <item>bin -> cache/bin <item>dev -> ramdisk/dev <item>etc -> ramdisk/etc <item>lib -> cache/lib <item>root -> ramdisk/root <item>sbin -> cache/sbin <item>tmp -> ramdisk/tmp <item>usr -> cache/usr <item>var -> ramdisk/var <item>cache/<itemize> <item>bin -> /runtime/bin <item>lib -> /runtime/lib <item>sbin -> /runtime/sbin <item>usr -> /runtime/usr </itemize> <item>mnt/<itemize> <item>cdrom/ <item>floppy/ <item>tmp/ </itemize> <item>proc/ <item>ramdisk/<itemize> <item>dev -> /runtime/dev <item>etc -> /runtime/etc <item>root -> /runtime/root <item>tmp -> /runtime/tmp <item>var -> /runtime/var </itemize> </itemize> 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 <tt>/ramdisk</tt>. Similarly, a local hard disk partition will be mounted on <tt>/cache</tt> for caching NFS requests. Roughly, the principle of the filecache is that whenever a symbolic link from the <tt/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 <tt>/runtime</tt> to <tt>/export/linux/rootfs/runtime</tt> 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: <itemize> <item><tt><htmlurl url="soft/linux/etc/rc.ramdisk" name="runtime/etc/rc.d/rc.ramdisk"></tt>, which quickly setup and mount the ramdisk: <tscreen><code> #!/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 </code></tscreen> <item><tt><htmlurl url="soft/linux/etc/rc.sysdetect" name="runtime/etc/rc.d/rc.sysdetect"></tt>, 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; <item><tt><htmlurl url="soft/linux/etc/filecache.init" name="runtime/etc/rc.d/init.d/filecache.init"></tt> which starts the filecache itself: <tscreen><code> #!/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 </code></tscreen> <item><tt><htmlurl url="soft/linux/etc/filecache.conf" name="runtime/etc/filecache.conf"></tt>, the filecache configuration file <tscreen><code> Max 100 MB 50 % # Cache /runtime /cache </code></tscreen> </itemize> The first two files should be invoked at the beginning of <tt><htmlurl url="soft/linux/etc/rc.sysinit" name="runtime/etc/rc.d/rc.sysinit"></tt>, as follow: <tscreen><code> # 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 </code></tscreen> and the third one should be bound as usual to the System V init directories: we use links named <tt/S35filecache/ in the <tt/rc3.d/ and <tt/rc5.d/ directories, and <tt/K80filecache/ in the <tt/rc0.d/, <tt/rc1.d/, <tt/rc2.d/ and <tt/rc6.d/ directories. Take a look at the <tt/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 <tt>/proc/pci</tt> and modify the script according to that. There is a section of <tt/rc.sysdetect/ with customize configuration files (for instance the <tt/printcap/), according to the machine location. For this to work, you need to set each machine location using the special tag <tt/option-132/ of the server <tt/dhcpd.conf/ file. Before you continue this installation, you must at least build basic <tt><htmlurl url="soft/linux/etc/fstab.ref" name="runtime/etc/fstab.ref"></tt> and <tt><htmlurl url="soft/linux/etc/hosts.ref" name="runtime/etc/hosts.ref"></tt> files, which will be finalized by the <tt/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 <tt>/usr/X11R6/bin</tt> and <tt>/usr/X11R6/lib/X11</tt> 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 <htmlurl url="soft/linux/bin/filecache" name="filecache"> in <tt>runtime/bin</tt>, and its <htmlurl url="soft/linux/man/filecache.8" name="man page"> in <tt>runtime/usr/man/man8</tt>. Install <htmlurl url="soft/linux/bin/bootptag" name="bootptag"> in <tt>runtime/usr/local/bin</tt>, and <htmlurl url="soft/linux/src/util/bootptag.c" name="bootptag.c"> in <tt>runtime/usr/local/src</tt>: 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: <tscreen><code> 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' </code></tscreen> The name of the tags is similar to that used in the <tt/dhcpd/ configuration file. We use this program for auto-configuration in <tt/rc.sysdetect/. Finally, install the <htmlurl url="soft/linux/src/util/makeramdisk" name="makeramdisk script"> in <tt>runtime/lib</tt>. 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 <tt>/etc/fstab</tt>, <tt>/etc/hosts</tt>, <tt>/etc/sysconfig/network</tt> have been created correctly. If it is not the case, retry in single user mode, and debug the <tt>rc.sysdetect</tt> script to discover what you have done wrong. When it works, go to the <tt>/lib</tt> directory and run <tt>./makeramdisk</tt>. This will take a few seconds, and build a ramdisk image for the read-only NFS clients. Install the created ramdisk image under <tt>/lib/ramdisk.gz</tt>, and your configuration is ready ! <sect2>Booting from the Bootprom If you did not already do it, install your TCP/IP Bootprom-compliant kernel image (found in <tt>/usr/src/linux/arch/i386/boot/bpImage</tt>) as <tt>/tftpboot/linux.PX</tt> on your server. The <tt/rc.sysdetect/ script is able to initialize for you the Linux swap and a Linux data partition. In order to trigger it, edit the <tt/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 <em/partitions to prepare/. In the DHCP configuration file, set the boot file to <tt/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 <tt>runtime</tt> directory, and export read-only the <tt>/export/linux/rootfs</tt> directory. Restart the client, and this time boot using the <bf/Linux/ menu option. Your system will now remote-boot Linux. <sect2>System Maintenance and Upgrades If you want later to upgrade software, install bug fixes and security fixes, proceed as follow: <itemize> <item>Unexport the <tt/rootfs/ directory <item>Export the <tt/runtime/ directory read-write for your client <item>Set your client <tt/nfsroot/ directory to <tt/runtime/ (in the <tt>/etc/bootptab)</tt> <item>Start your Linux client, and install everything you want. Do not be afraid of using <tt>rpm</tt>, it works perfectly well (just be carefull when you install packages that might alter modifications that you have made yourself). <item>Redo the normal export when you are done </itemize> That means, you can upgrade software on your server-based configuration as if it were a local install. <sect1>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 <tt>/S</tt> option, in order to put the operating system on it. Create a <tt/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 <tt/config.sys/: <tscreen><code> device=\util\bputil.sys -r </code></tscreen> (<tt/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 <tt><htmlurl url="soft/dos/bin/nobreak.sys" name="nobreak.sys"></tt> pseudo-device driver at the beginning of your <tt/config.sys/ and put something like this in your <tt/autoexec.bat/: <tscreen><code> 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 </code></tscreen> Ensure that your client boot well by rebooting and choosing the <em/Boot from local hard-disk/ option in the boot menu. <sect2>Moving the Configuration to the Server On the server, make a share called <tt/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 <tt/admin/ a softlink to the <tt>/tftpboot</tt> subdirectory, so that you can put images in it directly from the client. Within <tt/admin/, create a <tt>/utils</tt> subdirectory and put the following utilities in it: <itemize> <item><tt><htmlurl url="soft/dos/bin/mrzip.exe" name="mrzip.exe"></tt>, a program that will create a compressed image of your hard disk. <item><tt><htmlurl url="soft/dos/bin/mrunzip.exe" name="mrunzip.exe"></tt>, a program that can restore from within DOS a compressed image of your hard disk. </itemize> 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: <tscreen><code> @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 </code></tscreen> Now go back to your client, mount the <tt/admin/ volume on drive <tt/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 :-) <tscreen><code> L:\util\mrzip L:\tftpboot\win31 </code></tscreen> One minute later, you will have two new files in your server <tt>/tftpboot</tt> subdirectory, namely <tt/win31.imz/, the compressed image of your hard disk and <tt/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) <tt/bpunzip/ named <tt/win31.P/. Your disk-based remote-boot configuration is now ready. <sect2>Testing the Remote-Boot Client Now reboot your client and choose the <it/DOS and Windows 3.1/ option of the boot menu. The <tt/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. <sect2>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 <tt><htmlurl url="soft/dos/bin/unzipreg.exe" name="unzipreg.exe"></tt> program from within the client <tt/autoexec.bat/. This program will read a special hidden file created by <tt/bpunzip/, namely <tt>BOOTP.ANS</tt>, 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 <tt/UNZIPREG:/<it/tagname/<tt/:/ 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 <tt/input.bat/ which contains: <tscreen><code> set domainname=UNZIPREG:DOMAINNAME: set printer=UNZIPREG:T180: </code></tscreen> and you execute the command <tscreen><code> unzipreg input.bat output.bat </code></tscreen> you will get a file <tt/output.bat/ containing: <tscreen><code> set domainname=unige.ch set printer=laserwriter1 </code></tscreen> assuming that your DHCP configuration file defines the domain name as <tt/unige.ch/ and the <tt/option-180/ tag as <tt/laserwriter1/. Note that it is also possible to customize the Windows desktop according to the login. We wrote a <htmlurl url="soft/dos/src/addgroup.pas" name="simple program"> to add a group to the <tt/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 <tt/mrzip/ if you want to preserve your changes. <sect1>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: <itemize> <item>It is very, very bogus <item>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). <item>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 <item>It makes software upgrades almost impossible since every client turned on will lock many DLLs on the server, and thus produce <em/sharing violations/ if you try to upgrade them. </itemize> 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 <htmlurl url="win95old/win95old.html" name="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. <sect2>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 <tt>/S</tt> 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 <tt/WINDOWS/ directory). Start Windows 95 setup, and follow all steps of a <bf/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 <em/Boot from local hard-disk/ option of your boot menu. Once you have set up all drivers you want, you shall consider running <tt/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 <tt/config.sys/: <tscreen><code> device=\util\bputil.sys -r </code></tscreen> (<tt/bputil/ is a program provided on the TCP/IP Bootprom utility disk). In opposition to DOS, you shall better avoid to use <tt/EMM386/ with Windows 95. If you want to reduce network and server load (which will improve your system performances) while keeping all softwares on the server, you should consider installing the excellent Shared LAN Cache, from Measurement Techniques, Inc (see <htmlurl url="http://www.lancache.com" name="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. <sect2>Moving the Configuration to the Server On the server, if you don't already have it, make a share called <tt/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 <tt/admin/ a softlink to the <tt>/tftpboot</tt> subdirectory, so that you can put images in it directly from the client. Within <tt/admin/, create a <tt>/utils</tt> subdirectory and put the following utilities in it: <itemize> <item><tt><htmlurl url="soft/dos/bin/mrzip.exe" name="mrzip.exe"></tt>, a program that will create a compressed image of your hard disk. <item><tt><htmlurl url="soft/dos/bin/mrunzip.exe" name="mrunzip.exe"></tt>, a program that can restore from within DOS a compressed image of your hard disk. </itemize> Open a MS-DOS window on your client, mount the <tt/admin/ volume on drive <tt/L:/ for instance and execute the following command (absolute path names are not required, but they do not hurt :-) <tscreen><code> L:\util\mrzip L:\tftpboot\win95 </code></tscreen> This will create two new files in the <tt>/tftpboot</tt> subdirectory of your server, namely <tt/win95.imz/, the compressed image of your hard disk and <tt/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) <tt/bpunzip/ named <tt/win95.P/. Your disk-based remote-boot configuration of Windows 95 is now ready. <sect2>Testing the Remote-Boot Client Now reboot your client and choose the <it/Windows 95/ option of the boot menu. The <tt/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. <sect2>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: <itemize> <item>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) <item>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) </itemize> 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 <tt/autoexec.bat/. Note that this trick is not any more needed with most PCI cards. On your client computer, edit the <tt/autoexec.bat/ and add the following lines: <tscreen><code> 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 </code></tscreen> <tt/regedit/ is a standard Windows 95 program that let you browse the registery if you start it from within Windows 95, or do simple operations on the registery if you call it from DOS. <tt><htmlurl url="soft/dos/bin/unzipreg.exe" name="unzipreg.exe"></tt> is a small home-made program that you should put somewhere in your path. It will read a special hidden file created by <tt/bpunzip/, namely <tt>BOOTP.ANS</tt>, 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 <tt/UNZIPREG:/<it/tagname/<tt/:/ by their content in the BOOTP/DHCP reply and write the result on the file given as second argument. In in the <tt/lib/ subdirectory, we have a file named <tt><htmlurl url="soft/dos/lib/smc.reg" name="smc.reg"></tt> with the following content: <tscreen><code> 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 </code></tscreen> This file was initially generated using the Windows 95 interface to <tt/regedit/. We exported the branch corresponding to our network adapter (<tt>HKEY_LOCAL_MACHINE/Enum/ISAPNP/SMC8416</tt>) and substituted the number corresponding to the adapter hardware address by the tag <tt/UNZIPREG:MACID:/. When we run <tt/unzipreg/ on this file, it will automatically substitute the tag by the number corresponding to the actual netword adapter. Note that there is one number after the MACID that was sometimes <tt/C0/, sometimes <tt/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 <tt/smc.reg/ file: <tscreen><code> [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:" </code></tscreen> 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 <tt/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 <tt><htmlurl url="http://cuiwww.unige.ch/info/pc" name="http://cuiwww.unige.ch/info/pc"></tt>. <sect>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. <sect1>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 <htmlurl url="soft/dos/src/menuedit.pas" name="here">. <sect1>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 <htmlurl url="soft/dos/src/bphdboot.zip" name="here">. <sect1>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 <tt/.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: <tscreen><code> 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 </code></tscreen> <itemize> <item>In the first form, the file give the precise geometry of the partition. <item>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. <item>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. </itemize> 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. <itemize> <item>The <bf/type/ of a partition is <tt/4/ for DOS partitions under 32Mb, and <tt/6/ for DOS partitions from 32Mb to 500Mb. Many other values can be found using Linux <tt/fdisk/ help for instance. <item>The <bf/boot?/ field should be <tt/Y/ for the boot partition and <tt/N/ for all other partitions. This flag is used by the master boot record. <item>The <bf/1st-cyl/, <bf/1st-head/ and <bf/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. <item>The <bf/last-cyl/, <bf/last-head/ and <bf/last-sect/ are the absolute coordinates of the last sector of the partition. Partition usually end on a cylinder boundary. <item>The <bf/relative-size/ of a partition takes can be expressed in the following ways: <itemize> <item><tt/+ 10 Mb/ which means that the partition should be at least 10 Mb (ie. 2048 sectors) big; <item><tt/- 100 Mb/ which means that the partition should leave at least 100 Mb (ie. 20480 sectors) free for the next partitions; <item><tt/+ 30 %/ which means that the partition should occupy at least 30 percent of the space available at this point; <item><tt/- 70 %/ which means that the partition shouls leave at least 70 percent of the space available at this point for the next partitions. </itemize> 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. </itemize> 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, <tt/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 <em/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 <htmlurl url="soft/dos/src/bpclean.zip" name="here">. <sect1>MRZIP, MRUNZIP and BPUNZIP <tt/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 <tt/.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 <tt/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. <tt/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. <tt/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 <tt/.imz/. It first read the partition table and look for <itemize> <item>the first DOS partition, where the disk image should be restored <item>the last cylinder allocated for a partition, after which the compressed hard disk images will be stored. </itemize> 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 <sf/shift/ keys are depressed (a special <it/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 <tt/bpunzip/ was loaded with a <tt/.P/ extension (for instance as <tt/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). <tt/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 <tt/bpunzip/ was loaded with a <tt/.G/ extension (for instance as <tt/win95.GP/), it will first download a GIF file with the same basename (for instance <tt/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, <tt/bpunzip/ will issue a warning telling that some space is lost. By default, <tt/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 <em/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 <htmlurl url="soft/dos/src/mrzip.zip" name="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 <htmlurl url="soft/solaris/in.tftpd" name="extended TFTP server"> (also provided for other OS on your TCP/IP Bootprom utility disk). <sect1>NOBREAK <tt/Nobreak.sys/ is a very small (about 350 bytes only) driver that you include at the beginning of your <tt/config.sys/. Its goal is to secure the boot process, until the user is logged in. DOS provides a setting for this (namely <tt/BREAK=OFF/), but it is not drastic enough, and has almost no effect in the <tt/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 <tt/config.sys/ (or using the <tt/devlod/ program from <em/Undocumented DOS/). Afterwards, break can be enabled by sending <tt/Yes/ to the <tt/NOBRK/ pseudo-device, and disabled again by sending <tt/No/ (in fact, only the first character, <tt/Y/ or <tt/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 <htmlurl url="soft/dos/src/nobreak.zip" name="here">. <sect>Discussion We here discuss some theoretical issues related to our configuration. <sect1>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: <itemize> <item>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. <item>A local harddisk make the configuration more efficient, since it can reduce the network trafic through caching, and allows for efficient swap. </itemize> <sect1>Which Bootprom ? Several bootproms are available for PCs. We had several reason for choosing the TCP/IP Bootprom from Köppen EDV GmbH: <itemize> <item>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 <em/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. <item>It is not bound to a specific operating system. <item>Technical informations and API informations are available on request. <item>Home-made boot loader can be written (as we have done) <item>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. <item>Tools are provided for building and maintaining boot menus. </itemize> </article>