Theory of operation

Booting a thin client involves several steps. Understanding what is happening along the way will make it much easier to solve problems, should they arise.

There are four basic services required to boot an LTSP thin client. They are:

The LTSP chroot environment

In order to turn a computer into a thin client, we need to run a mini version of GNU/Linux on the workstation. It needs to boot this mini version of GNU/Linux over the network, since it probably won't have a hard drive on it's own. This mini GNU/Linux installation needs to live somewhere, and the best place for it is on the server.

This scaled-down GNU/Linux installation, customized so that it's efficient to boot over the network, is called a chroot environment. You can have several of them, based upon several different CPU architectures. They'll normally live under /opt/ltsp on the server, with subdirectories for each of the architectures. For instance, if you have a lab full of old Power PC Macs, and older PC's, you'll have an /opt/ltsp/ppc and an /opt/ltsp/i386 directory on the server.

The reason why it is called a chroot environment is that to install it, the GNU/Linux command chroot is called to actually set the installation root to /opt/ltsp/arch. From there, a scaled-down version of the distribution is installed. What this means is that for you to manage the chroot, performing such things as updates, all you need to do is use the chroot command to change the root of your installation. Then you can use all your tools like you normally would.

The boot process of a thin client

  1. Load the Linux kernel into the memory of the thin client. This can be done several different ways, including:

    1. Bootrom (Etherboot,PXE)

    2. Floppy

    3. Harddisk

    4. CD-ROM

    5. USB Memory Device

    Each of the above booting methods will be explained later in this chapter.

  2. Once the kernel has been loaded into memory, it will begin executing.

  3. The kernel will initialize the entire system and all of the peripherals that it recognizes.

  4. This is where the fun really begins. During the kernel loading process, an initramfs image will also be loaded into memory.

  5. Normally, when the kernel is finished booting, it will launch the new task launcher upstart, which will handle starting up a server or workstation. But, in this case, we've instructed the kernel to load a small shell script instead. This shell script is called /init, and lives in the root of the initramfs.

  6. The /init script begins by mounting /proc and /sys, starts udev to discover and initialize hardware, especially the network card, which is needed for every aspect of the boot from here on. As well, it creates a small ram disk, where any local storage that is needed (to configure the xorg.conf file, for instance) can be written to.

  7. The loopback network interface is configured. This is the networking interface that has 127.0.0.1 as its IP address.

  8. A small DHCP client called ipconfig will then be run, to make another query from the DHCP server. This separate user-space query gets information supplied in the dhcpd.conf file, like the nfs root server, default gateway, and other important parameters.

  9. When ipconfig gets a reply from the server, the information it receives is used to configure the ethernet interface, and determine the server to mount the root from.

  10. Up to this point, the root filesystem has been a ram disk. Now, the /init script will mount a new root filesystem via either NBD or NFS. In the case of NBD, the image that is normally loaded is /opt/ltsp/images/i386.img. If the root is mounted via NFS, then the directory that is exported from the server is typically /opt/ltsp/i386. It can't just mount the new filesystem as /. It must first mount it to a separate directory. Then, it will do a run-init, which will swap the current root filesystem for a new filesystem. When it completes, the filesystem will be mounted on /. At this point, any directories that need to be writable for regular startup to occur, like /tmp, or /var, are mounted at this time.

  11. Once the mounting of the new root filesystem is complete, we are done with the /init shell script and we need to invoke the real /sbin/init program.

  12. The init program will read the /etc/event.d directory and begin setting up the thin client environment. From there, upstart will begin reading the startup commands in /etc/rcS.d.

  13. It will execute the S32ltsp-client-setup command which will configure many aspects of the thin client environment, such as checking if local devices need starting, loading any specified modules, etc.

  14. Next, the init program will begin to execute commands in the /etc/rc2.d directory

  15. One of the items in the /etc/rc2.d directory is the S20ltsp-client-corecommand that will be run while the thin client is booting.

  16. The lts.conf file will be parsed, and all of the parameters in that file that pertain to this thin client will be set as environment variables for the S20ltsp-client-core script to use.

  17. If Sound is configured at this point, the pulseaudio daemon is started, to allow remote audio connections from the server to connect and play on the thin client.

  18. If the thin client has local device support enabled, the ltspfsd program is started to allow the server to read from devices such as memory sticks or CD-Roms attached to the thin client.

  19. At this point, any of the screen sessions you've defined in your lts.conf will be executed.

    Screen sessions are what you want to launch on all of the virtual screens on your terminal. These are the standard virtual screens that all GNU/Linux distros have, i.e. alt-F1, through alt-F10.

    By default, a standard character based getty will be run on screen 1 (SCREEN_01 in the lts.conf file).

    As well, if nothing else is specified in the lts.conf file, an ldm screen script is run on SCREEN_07. The LTSP Display Manager (ldm) is the default login manager for LTSP.

  20. If SCREEN_07 is set to a value of ldm, or startx, then the X Windows System will be launched, giving you a graphical user interface.

    By default, the Xorg server will auto-probe the card, create a default /etc/X11/xorg.conf file on the ramdisk in the terminal, and start up xorg with that custom config.

  21. The X server will either start an encrypted ssh tunnel to the server, in the case of ldm, or an an XDMCP query to the LTSP server, in the case of startx. Either way, a login box will appear on the terminal.

  22. At this point, the user can log in. They'll get a session on the server.

    This confuses a lot of people at first. They are sitting at a thin client, but they are running a session on the server. All commands they run will be run on the server, but the output will be displayed on the thin client.

Network booting the thin client

Getting the thin client to boot over the network can be accomplished in a variety of ways:

  • Boot ROM

  • Local media

Boot ROM

Depending on your network card, it may already contain a boot ROM, or you may be able to use an EPROM programmer to create your own. Check the hardware documentation for the network card in your thin client for details.

Etherboot

Etherboot is a very popular open-source bootrom project. It contains drivers for many common network cards, and works very well with LTSP.

ROM images suitable for booting from floppy, CD-ROM, etc., can be obtained from http://www.rom-o-matic.org

Linux kernels must be tagged with the mknbi-linux, which will prepare the kernel for network booting, by prefixing the kernel with some additional code, and appending the initrd to the end of the kernel.

The kernels that are supplied with Edubuntu/LTSP are already tagged, and ready to boot with Etherboot.

PXE

Part of the 'Wired for Management' specification from the late 1990's included a specification for a bootrom technology known as the Pre-boot Execution Environment commonly abbreviated as PXE.

A PXE bootrom can load at most a 32 kilo-byte file. A Linux kernel is quite a bit larger than that. Therefore, we setup PXE to load a 2nd stage boot loader called pxelinux, which is small enough to be loaded. It knows how to load much larger files, such as a Linux kernel.

Local media

If your network card in the thin client doesn't have a boot ROM built in, and you don't have access to an EPROM burner, have no fear! Chances are, that old machine has a floppy drive, or CD-ROM in it. If so, then you can use local media to boot the thin client.

Floppy disk

Booting Etheboot from a floppy is an excellent way of booting an LTSP thin client that doesn't have a boot ROM. Etherboot is loaded in the boot sector of the floppy. Then, it will act just like a bootrom. The boot code will be executed, the network card will be initialized, and the kernel will be loaded from the network server.

Hard disk

The hard disk can be used with LILO or GRUB, to load the Linux kernel and initrd. You can also load the Etherboot bootrom image from the hard disk, and it will act like a bootrom.

CD-ROM

A bootable CD-ROM can be loaded either with a Linux kernel, or an Etherboot image.

USB Memory device

Just like a CD-ROM, Floppy disk and Hard disk, you can use a USB Memory device to boot an Etherboot module.

Prev  Up  Next
Hardware Requirements  Home  Customizing thin client behaviour