Previous Next Contents

2. Introduction

The configuration described here was developped since Summer 1996 at the CUI, University of Geneva. The Computer Science Department uses several servers (both Unix and Novell), and a number of PCs, which fall into two classes:

We developped the current configuration with the following aims: These constraints lead us to base our configuration on the excellent TCP/IP Bootprom from Köppen EDV GmbH. This bootprom is especially interesting because it is not devoted to any specific operating system; it just emulates a floppy disk, and can easily be used for booting Linux as well as DOS or Windows 95. Moreover, the bootdisk image can be replaced by a home-made program, that let us perform several initializations before the operating system itself starts.

2.1 The Network

The University of Geneva owns a class B domain, subdivided into several subnets. The CUI uses four subnets, among them one is dedicated to students.

Originally, our PCs were concerned about two network protocols: IPX and IP. On the IPX side, we used a single Novell Netware 3 server for sharing software and users files for DOS and Windows. On the IP side, we used a SUN server for sharing software and users partitions for Linux, with NFS.

In our latest configuration, we do not any more use IPX. There is a single Unix server (which could be Linux as well as a SUN), sharing software and user files using NFS for Linux clients and using SMB (NetBIOS) over TCP/IP for Dos and Windows clients.

2.2 How it Works

  1. When a client PC is turned on, it first performs the traditional system checks before the TCP/IP bootprom takes the control.
  2. The bootprom issues a BOOTP/DHCP request in order to get its IP configuration parameters.
  3. If the server knows the PC issuing the request, it will send back a BOOTP/DHCP reply with informations such as the client's IP address, the default gateway, and which bootdisk image to use. Otherwise, the server will just discard the request.
  4. The bootprom then downloads the bootdisk image from the server using the TFTP protocol, and emulates at the BIOS level a floppy disk with this image.
  5. The PC boot on this disk image, which happens to contains a single boot program (no operating system yet).
  6. If the PC is a student computer, the program starts by downloading by TFTP a small text file containing the expected hard-disk configuration for the computer. According to this file, the partition table is rebuilt and DOS partitions are quick-formatted. When all this is done, no more than three seconds have elapsed since the computer was turned on.
  7. The program then offers to the user the choice of the operating system for the session.
  8. According to the choice of the user, a new bootdisk image is downloaded from the server, using TFTP.
  9. If the user decides to use Linux, the boot image is a a kernel loader plus a compressed kernel, with support for NFS root and caching filesystem:
    1. First, the IP configuration is made according to the BOOTP/DHCP reply received from the Novell server.
    2. The kernel is then able to mount a read-only root filesystem, using NFS.
    3. A small ramdisk is set up and mounted to the places where write access is desirable.
    4. If a swap partition is found on the local hard disk, it is prepared and activated.
    5. If a linux partition is found on the local hard disk, it is mounted and prepared for caching NFS partitions.
    6. IP configuration is finalized, services are started, and xdm is launched.
    7. The user is asked for its login. The workstation is ready.
  10. If the user decides to use DOS or Windows, the boot image is a program that handle compressed images of FAT16 partitions. Images are downloaded using TFTP, and stored for further use at the very end of the hard-disk, above any used partition. More precisely, the program works in the following way:
    1. The program download a checksum file (512 bytes) that validates the boot image of the choosen operating system
    2. 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.
    3. The operating system image is decompressed into the first FAT16 partition, at the approximate speed of one second per used megabyte.
    4. The program jump into the boot sector of the selected OS, which is now completely present on the local hard-disk.
    For DOS and Windows 3.1, we use the freely available Microsoft LanManager for DOS (search the network for the mirror nearest to you; the distribution consists of three files named disk1 to disk4) as SMB client. Microsoft LanManager supports dynamic configuration using DHCP. After logging in, the user is faced to DOS, and can start Windows 3.1 by typing the traditional win command. Note that at this point, DOS and Windows 3.1 appear to be installed locally. For Windows 95, we also use Microsoft SMB client (called Client for the Microsoft Network), that supports dynamic configuration using DHCP. We reduce network load using Shared LAN Cache, a nice and powerful network-to-disk cache program.
Students computers can be turned off the hard way at any time 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.

2.3 Related non-commercial documentations

This configuration has been successfully reproduced at several places around the world. A few people have written some hints and tricks that complement this How-To. If you did so and that your page is not already referenced in this documentation, please send an e-mail to Marc.VuilleumierStuckelberg@cui.unige.ch. And if you experience problems while reproducing this configuration, have a look at these pages !


Previous Next Contents