Diskless Linux X Terminals

How to network-boot a Linux box that has no persistent storage and use it as a diskless X terminal.
PXELINUX

PXELINUX knows where the PXE boot ROMs stashed the network parameters from the DHCP server's response in memory, and it can use these to start another TFTP session to download its configuration file from the server. With the TFTP server configured as described above, the bootloader running on the client first tries to find its configuration file in /tftpboot/pxelinux.cfg/ethermac, where ethermac represents the client's Ethernet hardware address in lowercase hexadecimal, with octets separated by hyphens, for example, fe-ed-de-ad-be-ef. Failing that, the bootloader tries /tftpboot/pxelinux.cfg/iphex, where iphex is the client's IP address in uppercase hexadecimal. For example, if the client has the IP address 192.168.0.12, PXELINUX would try to download the file /tftpboot/pxelinux.cfg/C0A8000C. If that file doesn't exist, the least significant nibble is dropped from the name and the process repeats. Therefore, in the example above, after C0A8000C is not found, PXELINUX tries C0A8000, then C0A800 and so on. This makes it possible to have a single configuration file for an entire subnet, provided that the subnet boundary is nibble-aligned.

Listing 2 shows the contents of a PXELINUX configuration file. The first line gives the name of a file containing a compressed kernel image to be downloaded—all paths are relative to /tftpboot on the server. The second line lists parameters that should be passed to the kernel specifying that the root filesystem be a 64MB RAM disk that should be mounted read/write. The last line causes PXELINUX to generate an additional kernel parameter containing ip=client-ip:server-ip:gateway-ip:netmask and using the values obtained by the PXE boot ROMs from the DHCP server's response. This is useful if the kernel was built with kernel-level autoconfiguration of IP networking enabled. If so, when the kernel boots it uses these parameters to configure the network interface, making it unnecessary to do so using ifconfig or ifup in a startup script.

Building the Kernel

In order to use kernel-level autoconfiguration of IP parameters, the network device driver must be available early in the boot, even before the root filesystem is mounted. Therefore, it cannot be a loadable module. Because the kernels that come with most distributions use loadable modules extensively, in practice this means it is necessary to build a custom kernel for the X terminal. In addition, the custom kernel should support RAM disks and initial RAM disks. Kernel-level autoconfiguration of IP networking is also convenient. It is not necessary to include any of the dynamic methods of obtaining IP addresses (DHCP, BOOTP and RARP can be selected), however, as the IPAPPEND line included in the PXELINUX configuration file ensures that the kernel receives the correct IP parameters. Finally, device filesystem support with devfs mounted automatically on boot greatly simplifies the /dev directory in the RAM disk root filesystem.

RAM Disk Root Filesystem

Building and populating the root filesystem would be the most complicated part of setting up a diskless Linux box if it weren't for the advent of Richard Gooch's device filesystem and Erik Anderson's BusyBox combined binary. The device filesystem automatically manages the /dev directory, creating device entry points as needed for the devices loaded in the kernel. This means two things: the directory has no unnecessary entries, and builders of RAM disk root filesystems don't have to spend hours with mknod trying to create all the needed device entry points. The BusyBox combined binary is an executable that changes its personality depending on how it is invoked. The usual methodology is to create symlinks to /bin/busybox from /bin/ls, /bin/cat, /bin/ps, /sbin/mount and so on, to create a minimalist UNIX system. No additional libraries or binaries are needed; the BusyBox rolls them into one.

One way to think of this setup is that the device filesystem takes care of /dev; the BusyBox takes care of /bin and /sbin; the kernel takes care of /proc; a read-only NFS mount takes care of /usr; and /tmp can be empty. So, all you need to worry about is /etc. In fact, /etc can be starkly minimalist, containing only /etc/fstab, /etc/inittab and /etc/init.d/rcS, the latter being the single startup script used by BusyBox when running as init.

BusyBox was written for the world of embedded Linux and normally would be built as a static executable. However, the XFree86 server itself depends on a number of shared libraries normally found in /lib. We are going to NFS-mount /usr, so we don't have to worry about shared libraries found in /usr/lib, but we do have to provide the ones XFree86 expects to find in /lib. Therefore, we might as well take advantage of the space savings made possible by configuring BusyBox as a dynamic executable. The minimum libraries required in /lib to run XFree86 can be discovered by running ldd /usr/X11R6/bin/XFree86. They are glibc (libc.so and libm.so), PAM (libpam.so and libpam_misc.so) and the dynamic loader itself (libdl.so and ld-linux.so).

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Symbio Technologies' LTSP based diskless thin client solution

Diane Romm's picture

Readers who are interested in Linux-based diskless thin client technology should find the products of our company, Symbio Technologies, very compelling.

We offer a complete solution, based on LTSP, that can replace the PC on the desktop with low powered network terminals. We call the solution The Symbiont Solution. It includes:

1. The Symbiont Management Suite: Server based software that makes it easy to setup, configure, manage, and control a network comprised of diskless network terminals.

2. The Symbiont Boot Appliance: A device that boots the network terminals, directs them to the appropriate application server(s), and offers Internet-based access to setup, configure, manage and control the network. The SBA takes the place of a boot server and enables the efficient consolidation, management, and control of application servers.

3. Network terminals: These energy efficient units have no moving parts including no hard drives, no floppy drives, and no fans. They are guaranteed to work perfectly with our management suite and boot appliance.

Diskless Linux X Terminals and LTSP

stern's picture

Thanks Chip for a great article. It motivated me to do something usefull. I'm setting up a diskless machine for a friend which will boot off her partner's linux pc. She doesn't have enough disk to
setup a stand alone machine. I may not use pxe but expect to use etherboot via a floppy.

I think it a real shame that the "Diskless Linux X Terminal" article made no mention of the Linux Terminal Server Project! I followed the article and links and found it frustrating. (using SuSE 9.2) I downloaded the latest LTSP (www.ltsp.org) and had it all working in an
hour. The hardest part being getting the xdmcp to work. I would have found something explaining the differences between bootp, etherboot, and pxe really helpfull. Again the LTSP is very good at explaining this.

In the end I feel that as good as it was, the article had the
potential to be much better.

John Stern
Linux Specialist
RHCE

NVRAM? (I actually do need it....)

mhoskins's picture

I liked your article, however, I am one of the few, the proud, who need NVRAM information:

The essential characteristic of any thin client is that it should have little or no persistent storage. Typically, a purpose-built X terminal has a small quantity of NVRAM used to store configuration options and nothing else. In practice, it usually is possible to put even these options in a configuration file stored on the server and downloaded by the terminal on boot. This article takes the purist view that an X terminal should have no persistent storage whatsoever.

I need to save some bootup settings there, such as monitor settings, kernel params, etc., in a situation that I do *not* have a managed thin-client situation.

I have a customer who does *not* want this saved on a server, but who wants to boot through CD's -- no hard disk drives, no flash, no boot ROMs or PXES, no floppies, etc.! Only whatever-else-is-part-of-a-bare-machine and CD-R's are allowed, here....

I also have a great deal of hardware configs, from P-90's to P4-2.5GHz machines, and a wide range of video cards and monitors....

Unfortunately, I have found virtually no information for /dev/nvram. I have done several Google searches, but perhaps I'm not using the correct search criteria.

Can anybody help, here?

You really want to check out

Alex S.'s picture

You really want to check out the "A Temporary Internet Lounge" article in the same issue - build your Knoppix disk to contain the stuff you want and not the stuff you don't.

Re: NVRAM? (I actually do need it....)

mhoskins (cannot login)'s picture

I have built several custom Knoppix and Morphix (and BeatrIX) CD's over the last year and a half, or so. This is precisely why I need to save my settings somewhere. (I read the "Internet Lounge" article ahwile ago, as well.)

All I have in my customer's machines is CD-R media and I just need a place to hold a few bytes for settings. This is a unique situation where I have no hard disk, no USB device, and I can't save to/load from a server.

Saving it in NVRAM would be ideal. I need maybe 20-30 bytes, or so, but I've heard that NVRAM can do 64-128 bytes, perhaps higher.

Can anybody help?

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix