Linux Remote-Boot mini-HOWTO: Configuring Remote-Boot Workstations with Red-Hat Linux, DOS, Windows 3.1 and Windows 95: Introduction

Rate this post

prev-1584005 next-9242827 toc-8815725

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

  • computers devoted to students
  • computers devoted to research and teaching assistants

We developped the current configuration with the following aims:

  • Every computer should be able to run under Linux, DOS, Windows 3.1 or Windows 95. One should be able to choose the desired operating system for each session.
  • All softwares, including operating systems, should reside on the server, in order to facilitate the installations and upgrades.
  • Clients computers should be able to run without any write-access on the server (for security reasons), except their home directory.
  • Client-side configuration should be reduced to its very minimum. Clients should automatically get their IP configuration parameters from the server, and this information should be located in a single file, used for all operating systems.
  • Since almost every computer now has a hard-disk, clients should be able to take profit of it for reducing network load and as temporary storage space for the user.
  • Users must have a login to be able to use any of the computers.
  • The login should be the same for all operating system and should let the user access its unique home directory, common to all operating systems.
  • Students computers should be fully cleaned up at each start. That is, the PC should always look like if it were just installed.
  • Every computer has to be protected from virus attacks.

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

2.1 The Network

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

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

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

2.2 How it Works

  1. When a client PC is turned on, it first performs the traditional system checks before the TCP/IP bootprom takes the control.
  2. The bootprom issues a BOOTP/DHCP request in order to get its IP configuration parameters.
  3. If the server knows the PC issuing the request, it will send back a BOOTP/DHCP reply with informations such as the client’s IP address, the default gateway, and which bootdisk image to use. Otherwise, the server will just discard the request.
  4. The bootprom then downloads the bootdisk image from the server using the TFTP protocol, and emulates at the BIOS level a floppy disk with this image.
  5. The PC boot on this disk image, which happens to contains a single boot program (no operating system yet).
  6. If the PC is a student computer, the program starts by downloading by TFTP a small text file containing the expected hard-disk configuration for the computer. According to this file, the partition table is rebuilt and DOS partitions are quick-formatted. When all this is done, no more than three seconds have elapsed since the computer was turned on.
  7. The program then offers to the user the choice of the operating system for the session.
  8. According to the choice of the user, a new bootdisk image is downloaded from the server, using TFTP.
  9. If the user decides to use Linux, the boot image is a a kernel loader plus a compressed kernel, with support for NFS root and caching filesystem:
    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 And if you experience problems while reproducing this configuration, have a look at these pages !

prev-1584005 next-9242827 toc-8815725

Lire aussi...  Linux Hardware Compatibility HOWTO