Linux Remote-Boot mini-HOWTO: Configuring Remote-Boot Workstations with Red-Hat Linux, DOS, Windows 3.1 and Windows 95: The Configuration How-To

prev-8059744 next-8399512 toc-5278121

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

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.

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:


.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

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).

READ  Linux Gazette Table of Contents LG #48

Building the Kernel

First, go to your /usr/src directory and apply the following patches, using the command

patch -p0 /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 runtime/etc/rc.d/rc.sysinit, as follow:

    
    # Setup ramdisk if necessary (for read-only root NFS)
    if [ -e /ramdisk -a -r /etc/rc.d/rc.ramdisk ]; then
            /etc/rc.d/rc.ramdisk
    fi
    
    # Setup hardware dependent parameters (for any root NFS)
    if [ -r /etc/rc.d/rc.sysdetect ]; then
            /etc/rc.d/rc.sysdetect
    fi
    

    and the third one should be bound as usual to the System V init directories: we use links named S35filecache in the rc3.d and rc5.d directories, and K80filecache in the rc0.d, rc1.d, rc2.d and rc6.d directories.

    Take a look at the rc.sysdetect file, and adapt it to your hardware. In particular, if you do not use the same video adapters and screen as we do (which is very likely :-), see how they report to /proc/pci and modify the script according to that. There is a section of rc.sysdetect with customize configuration files (for instance the printcap), according to the machine location. For this to work, you need to set each machine location using the special tag option-132 of the server dhcpd.conf file. Before you continue this installation, you must at least build basic runtime/etc/fstab.ref and runtime/etc/hosts.ref files, which will be finalized by the rc.sysdetect script on boot time, according to the detected configuration. For dynamically configuring the X server, there is one thing you have to change from the RedHat distribution: in the /usr/X11R6/bin and /usr/X11R6/lib/X11 directories, there are a few relative links to configuration files and directories that should be changed to absolute links. Don’t forget to do that again if you reinstall later an upgrade of the X server.

    Install the filecache in runtime/bin, and its man page in runtime/usr/man/man8. Install bootptag in runtime/usr/local/bin, and bootptag.c in runtime/usr/local/src: it is a simple program that issues a BOOTP request and answer its content on the standard output, in a shell-compatible format, as in the following example:

    
    bootp_your_ip='129.194.71.32'
    bootp_server_ip='129.194.77.31'
    bootp_filename='XXXclean'
    bootp_subnet_mask='255.255.252.0'
    bootp_routers='129.194.68.1'
    bootp_domain_name_servers='129.194.69.200 129.194.8.7 129.194.4.32'
    bootp_host_name='pc7132'
    bootp_domain_name='unige.ch'
    bootp_root_path='/export/linux/rootfs'
    bootp_broadcast_address='129.194.71.255'
    bootp_nis_domain='cuisunnet.unige.ch'
    bootp_nis_servers='129.194.69.200'
    bootp_option_132='dufour'
    

    The name of the tags is similar to that used in the dhcpd configuration file. We use this program for auto-configuration in rc.sysdetect. Finally, install the makeramdisk script in runtime/lib. We will use it to build automatically the ramdisk image. All these software are available in the hypertext version of this document.

    Now try to boot your read-write NFS client (still boot from the hard disk). It should detect your local configuration, and generate the appropriate files. Check that /etc/fstab, /etc/hosts, /etc/sysconfig/network have been created correctly. If it is not the case, retry in single user mode, and debug the rc.sysdetect script to discover what you have done wrong.

    When it works, go to the /lib directory and run ./makeramdisk. This will take a few seconds, and build a ramdisk image for the read-only NFS clients. Install the created ramdisk image under /lib/ramdisk.gz, and your configuration is ready !

    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.

    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.

    READ  Downloading LinuxToday links and Linux Gazette's TOC with Python (and Perl) LG #63

    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.

    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.

    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.

    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 Windows 95.

    If you want to reduce network and server load (which will improve your system performances) while keeping all softwares on the server, you should consider installing the excellent Shared LAN Cache, from Measurement Techniques, Inc (see http://www.lancache.com). This software runs on each client computer, and caches to the local hard disk every data obtained from the network. Even MS-Office starts much faster the second time you run it… You need one license per client computer, but it is not very expensive, and the firm make special prices for universities and colleges. The best thing to do is to go to their Web site and download the free evaluation copy.

    READ  Linux Ethernet-Howto: Miscellaneous.

    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.

    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.

    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 registery if you start it from within Windows 95, or do simple operations on the registery if you call it from DOS. unzipreg.exe is a small home-made program that you should put somewhere in your path. It will read a special hidden file created by bpunzip, namely BOOTP.ANS, that contains the original BOOTP/DHCP reply sent by the server. Then, it will read the file given as first argument, substitute all strings of the form UNZIPREG:tagname: by their content in the BOOTP/DHCP reply and write the result on the file given as second argument.

    In in the lib subdirectory, we have a file named smc.reg with the following content:

    
    REGEDIT4
    
    [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C0]
    "HardwareID"="*SMC8416,ISAPNP\SMC8416"
    "HWRevision"="1.0.10"
    "DeviceDesc"="SMC EtherEZ (8416)"
    "Class"="Net"
    "Driver"="Net\\0001"
    "CompatibleIDs"="*SMC8416"
    "Mfg"="SMC"
    "ConfigFlags"=hex:10,00,00,00
    
    [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C0\Bindings]
    "MSTCP\\0001"=""
    
    [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C0\LogConfig]
    "0000"=hex:00,04,00,00,00,20,00,00,10,00,00,00,04,00,00,00,00,00,00,00,a8,0e,\
      00,00,20,00,00,00,02,00,00,00,01,00,0c,00,00,00,00,00,00,00,00,00,e0,ff,20,\
      00,40,02,ff,03,00,00,04,03,2c,00,00,00,01,00,00,00,01,00,14,00,00,00,00,00,\
      00,00,00,00,00,00,00,00,00,e0,ff,ff,00,20,00,00,00,00,0c,00,ff,ff,0f,00,00,\
      00,00,00,2c,00,00,00,01,80,00,00,01,00,14,00,00,00,00,00,00,00,00,00,00,00,\
      00,00,00,e0,ff,ff,00,80,00,00,00,00,0c,00,ff,5f,10,00,00,00,00,00,00,00,00,\
      00
    
    [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C1]
    "HardwareID"="*SMC8416,ISAPNP\SMC8416"
    "HWRevision"="1.0.10"
    "DeviceDesc"="SMC EtherEZ (8416)"
    "Class"="Net"
    "Driver"="Net\\0001"
    "CompatibleIDs"="*SMC8416"
    "Mfg"="SMC"
    "ConfigFlags"=hex:10,00,00,00
    
    [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C1\Bindings]
    "MSTCP\\0001"=""
    
    [HKEY_LOCAL_MACHINE\Enum\ISAPNP\SMC8416\UNZIPREG:MACID:C1\LogConfig]
    "0000"=hex:00,04,00,00,00,20,00,00,10,00,00,00,04,00,00,00,00,00,00,00,a8,0e,\
      00,00,20,00,00,00,02,00,00,00,01,00,0c,00,00,00,00,00,00,00,00,00,e0,ff,20,\
      00,40,02,ff,03,00,00,04,03,2c,00,00,00,01,00,00,00,01,00,14,00,00,00,00,00,\
      00,00,00,00,00,00,00,00,00,e0,ff,ff,00,20,00,00,00,00,0c,00,ff,ff,0f,00,00,\
      00,00,00,2c,00,00,00,01,80,00,00,01,00,14,00,00,00,00,00,00,00,00,00,00,00,\
      00,00,00,e0,ff,ff,00,80,00,00,00,00,0c,00,ff,5f,10,00,00,00,00,00,00,00,00,\
      00
    

    This file was initially generated using the Windows 95 interface to regedit. We exported the branch corresponding to our network adapter (HKEY_LOCAL_MACHINE/Enum/ISAPNP/SMC8416) and substituted the number corresponding to the adapter hardware address by the tag UNZIPREG:MACID:. When we run unzipreg on this file, it will automatically substitute the tag by the number corresponding to the actual netword adapter. Note that there is one number after the MACID that was sometimes C0, sometimes C1. Since it does not hurt to put a non-existant adapter in the registery, we add entries for both.

    Once again, this whole trick is not necessary when using PCI network adapters. Incidentally, we can use the same mechanism for automatically configuring the hostname, which Windows 95 does not seem to take into account when configuring through DHCP. We just add the following line to our smc.reg file:

    
    [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\VNETSUP]
    "ComputerName"="UNZIPREG:HOSTNAME:"
    
    [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
    "HostName"="UNZIPREG:HOSTNAME:"
    
    [HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\ComputerName\ComputerName]
    "ComputerName"="UNZIPREG:HOSTNAME:"
    

    You can also use the same mechanism to customize other settings according to the machine type or to its location. For examples of that, see also the corresponding paragraph of the DOS/Windows 3.1 configuration description.

    After making any change to the client machine configuration, do not forget to rebuild the disk image using mrzip, or all your changes will be lost.

    Using this small registery trick, your configuration should normally be portable for all machines with similar configurations. If you cannot avoid that Windows detect some hardware as new on one machine, try to rebuild the disk image from this machine. This will include the registery configuration specific to this machine into the image, and hopefully supress the problem.

    As the disk image decompression may take some time (typically 20-30 sec.), you may want to give to the user informations or just a nice picture to look at. This can be done very easily (see the documentation on BPUNZIP below).

    If you are interested in getting more informations and tools for configuring Samba with remote boot computers, we have written another document. Have a look at http://cuiwww.unige.ch/info/pc.

    prev-8059744 next-8399512 toc-5278121