WARNING: This page is out of date
DIET-PC is a kitset, not a plug-and-play distribution, and can be implemented in a number of ways using a number of different protocol implementations running on various platforms. It is therefore difficult to describe the setup procedure except in very general terms, so this document is necessarily a little vague.
In order to build a working DIET-PC thin client, you will need:
This need not be connected to a network (unless you also intend to use it as your DIET-PC boot server). Any recent release of the popular Linux distributions ought to suffice; I use Red Hat 9. A default install should be adequate if you intend to use a pre-built DIET-PC kernel. You will need to install development tools (gcc compiler, header files, libraries) if you wish to compile a kernel.
At present there is no escaping this requirement. You can't use Cygwin under Windows because it lacks the ability to mount ramdisks or files via loopback. However, it ought to be possible to use a "virtual Linux box" running under Windows et al using products such as VMware and CoLinux.
It is generally a good idea to set up your development box with hardware similar to that which you intend to use in your thin client PCs - particularly the same Network Interface Card (NIC).
This box may be almost anything that runs an operating system that supports the TCP/IP network protocol in general, and the DHCP and TFTP protocols in particular. Any modern operating system should be capable of this. It is possible to use your Linux development box as your DIET-PC server also. This is probably a sensible thing to do in the first instance, until you are ready to move DIET-PC onto production servers.
It is possible to set up DIET-PC to self-boot from local storage either without networking or with fixed network parameters, in which case you don't need a boot server.
The whole point of thin clients is to run applications which require permanent storage on a central server. For this to be a worthwhile exercise, you will almost certainly want this server to support two or more user sessions concurrently. Any UNIX-based O/S can do this, but in the MS Windows universe only Windows 2003 Server, Windows 2000 Server and Windows NT4 Terminal Server Edition provide this capability. It is nevertheless possible to connect a DIET-PC to a single-user O/S via the RFB (VNC) protocol, and also via RDP in the case of Windows XP.
The application server must make its service available via TCP/IP, and the DIET-PC client must have appropriate client software embedded in its boot image. DIET-PC packages are available for the ICA, RDP, RFB and X11/XDMCP protocol sets (each with limited support for SSH encapsulation), but the DIET-PC solution is by no means limited to these protocols; you may add support for others as required.
The DIET-PC application server may be the same box as the DIET-PC boot server and/or development platform.
DIET-PCs may also be used as standalone appliances, but applications that are useful in a standalone environment tend to be too large and too complex to embed. The primary focus of the DIET-PC distribution remains thin client usage. For standalone appliances, distributions based on permanent mass storage such as Knoppix may be more useful.
In practical terms, this really needs to be a Pentium (586) or later model PC with at least 32 megabytes of RAM.
It is possible - although rather inconvenient - to use your Linux development box as a test DIET-PC thin client also, provided that it is not also your DIET-PC boot server or application server (unless you are doing something really funky with VMware).
Unless you intend to boot clients from permanent storage, each client PC must be fitted with a network boot ROM of some description. Modern NICs and mainboards often come with preprogrammed PXE boot ROMs, which is an ideal solution. Older hardware can often accomodate a plug-in boot ROM, which can be programmed with Etherboot images (available from Rom-O-Matic) using an EPROM burner. For testing purposes, an Etherboot image on a bootable floppy disk that emulates a boot ROM (also obtainable from Rom-O-Matic) is an adequate substitute.
While it is possible to install DIET-PC client software on existing hard disks in old PCs that you want to "recycle", you will miss out on many of the benefits of the true thin client if you do so. If you can, I believe it is worth the extra effort to remove the hard disks, CDROMs and floppy drives, and upgrade to new 100 Mbit/s PXE-bootable NICs.
The DIET-PC kitset consists of an infrastructure package (skeleton) and a number of function packages which can be "stacked" to build a progressively more capable system. In order to build a minimal working system, you will at the very least need the skeleton and shell packages and a kernel package (either one you build yourself or a generic_kernel_586+ package). You will almost certainly want the xcommon package and an X11 driver package also (if you don't know which you'll need, try x440-vesa first), as these are needed to support any of the Graphical User Interface (GUI) options.
Impatient people with broadband may obtain all available packages all in one hit by downloading and extracting a diet-pc_comprehensive bundle. These are released semi-regularly, and contain a snapshot of all of the most recent stable packages at the time of release.
To extract the packages, start a Linux shell and change directory to the location of your choice. Extract the skeleton package (or the diet-pc_comprehensive bundle) first, then change directory into the diet-pc directory and extract the other packages:
tar xjf dietpc_skeleton-version.tar.bz2
cd diet-pc tar xjf dietpc_packagename-version.tar.bz2
This will extract all DIET-PC components into a self-contained directory tree named diet-pc. Packages don't contain clashing filenames, so extracting packages in this way will not cause anything to be overwritten.
If you don't do this now, you're going to have to do it later after everything goes wrong, so curb your impatience. Start with the README in the diet-pc directory itself, then proceed to the READMEs in each subdirectory.
If you have elected to build your own kernel (probably not necessary if you just want to evaluate DIET-PC, but strongly urged if you intend to install DIET-PC software on a production system), you must do so now. A DIET-PC kernel can be compiled from any 2.4.x Linux kernel sources - you don't have to apply any special patches. I recommend that you use standard kernel.org source rather than vendor-provided sources, as this is easier to patch against, but this isn't strictly necessary.
The README in the kernel directory contains information on what kernel features DIET-PC needs. For your first DIET-PC kernel attempt, it is probably a good idea to use the kernel config file provided in a generic_kernel-586+ package as a starting point for your new kernel. The build steps required are something like this:
cd /usr/src/linux make mrproper cp
path-to-diet-pc-directory/generic_kernel-586+/config .config make menuconfig make dep make bzImage ROOT_DEV=/dev/ram0 cp arch/i386/boot/bzImage
path-to-diet-pc-directory/kernel make modules make modules_install
INSTALL_MOD_PATH=path-to-diet-pc-directory/kernel/files vi
path-to-diet-pc-directory/kernel/files/etc/modules.conf
"cd diet-pc" if you have not already done so, and edit files as required. If this is your first build, you can probably skip most of the package-specific fine-tuning for now - the important thing is that you have acquired the appropriate packages for your hardware and functional requirements and listed them in the desired order in the COMPONENTS definition in the Makefile. It is also important that /etc/modules.conf (usually in your kernel package) is appropriately configured, particularly any required ISA NIC settings etc.
When ready, run make. If you don't specify a target, make will generate a compressed ramdisk image (initrd.img); you can further encapsulate this into an Etherboot ELF image, Etherboot Network Bootable Image (NBI) or ISO9660 CD image using "make elf", "make nbi" or "make iso" respectively.
If the initial make fails to create an initrd.img file, the build process may have attempted to run a command that doesn't exist on, or isn't supported by your, Linux O/S. If this is the case you'll need to seek assistance. build_initrdimg uses one of two methods - ramdisk mount and loopback device mount, attempted in that order - to create the ramdisk image. Hopefully your O/S will support at least one of these methods.
Installing a bootable image typically involves positioning onto the boot medium the bzImage file from the kernel package that you are using, the initrd.img file that you just created, the boot loader binary (either directly or by using an installation tool), and a boot-loader specific configuration file.
The skeleton package comes with binaries and example configuration files for the Etherboot, Syslinux, ISOlinux, PXELinux, LILO and GRUB boot loaders. The Makefile contains code to assist with installing and configuring the boot loader of your choice on the local machine (ie. the Linux development box which you used to create the DIET-PC ramdisk image just now). Until you become familiar with boot loaders, I recommend that you use this capability to set up your Linux development box as an initial DIET-PC boot server - you can copy the setup to a production boot server later on.
Makefile install targets are as follows:
| Makefile Target | Filesystem or ROM Type | Boot Loader |
|---|---|---|
| Disk Boot Loaders | ||
| install-fat | FAT16 | SysLinux |
| install-ext2 | Ext2 | LILO |
| install-fatgrub | FAT16/FAT32 | GRUB |
| install-ext2grub | Ext2 | GRUB |
| install-iso | ISO9660 | ISOLinux |
| Network Boot Loaders | ||
| install-elf | Etherboot (ELF) | Etherboot |
| install-nbi | Etherboot (NBI) | Etherboot |
| install-pxe | PXE | PXELinux |
| install-grub | PXE | GRUB |
However, using a Makefile targets presupposes that the installation medium (disk device or TFTP root directory) is locally accessable to your Linux development platform, which is not necessarily the case, and provides no flexibility in boot loader configuration.
If you do elect to use a Makefile install target, you should first read comments in the Makefile and appropriately set the variables that identify the location and properties of the installation medium. You should then do a dummy run using the -n option, eg. "make -n install-fat". This will report the actions that make would have performed, without actually doing them. Once you understand the consequences of each line reported and are satisified that the actions are correct, you can run make again without the -n.
Now let's look at each boot loader in more detail.
Your choice of disk boot loader depends largely upon target filesystem format. DIET-PC anticipates use of one of three common formats: FAT16/32 (Windows-formatted disk), EXT2 (Linux-formatted disk) and ISO9660 (CDROM). Other formats are certainly possible, but procedures for these will not be documented here.
Use FAT16/32 format if you want interoperability with Windows systems, or to make use of preformatted media. FAT is more limited than EXT2 but generally easier to deal with. FAT32 is typically used for large hard disks by Windows 98SE and later; support for it in freeware tools is still rather limited. FAT16 is generally used for small (< 1 Gb) disks, including magnetic media larger than a floppy disk (Zip, Jazz etc) and solid-state disks (Compact Flash, DiskOnChip, etc). FAT12 (used on floppy disks) is also theoretically supportable, but this is a moot point since DIET-PC will not fit on floppies.
Don't confuse FAT12/16/32 with VFAT. FAT12/16/32 describes the underlying storage format, whereas VFAT is just a filename semantics extension that may be present (and either used or ignored, depending on the O/S) on any FAT filesystem.
FAT loaders include SysLinux and GRUB, although SysLinux doesn't support FAT32 (yet). LILO can actually be used to boot FAT filesystems as well, although it doesn't have any internal understanding of FAT formats.
EXT2 is a better choice for advanced uses of DIET-PC, as it is better optimised for Linux, and supports the special files (character and block special, symbolic and hard links, sockets) that Linux and other UNIX derivatives require. EXT2 is a good choice if you wish to install Linux applications on your disk media outside of DIET-PC's initial ramdisk image (i.e. enhance DIET-PC with non-embedded apps). EXT3 could be used instead, provided that your DIET-PC had kernel support for it, but this confers no real benefit for read-only filesystems, and precludes use of e2compr.
EXT2 loaders include LILO and GRUB. Both have similar capabilities, but DIET-PC favours GRUB for advanced uses (such as interactive menus) because less site-specific configuration is embedded into boot blocks, so it is a little easier and safer to modify.
ISO9660 is the usual format of CDROMs. Through use of Joilet and Rock Ridge extensions, it caters equally well to Windows and UNIX systems. ISO9660 is intended as a read-only format; read-write CD/DVD media usually use UDF format (not supported, or at least not directly, by DIET-PC) instead. However, it is perfectly possible to repeatedly overwrite ISO9660 filesystems to CD-RW instead of CD-R, and thereby avoid disc wastage while fine-tuning DIET-PC.
ISOLinux (part of the SysLinux distribution) is a non-emulating ISO9660 boot loader. It is possible to boot ISO9660 CDs via floppy- or hard-disk emulation, and thereby use alternate boot loaders suitable for those media, but this introduces additional sizing and compatibility complications.
If you have a never-before-used disk (other than a CD) or want to reinitialise a disk from scratch, it may be necessary to partition it and create a filesystem before it is DIET-PC-ready. Disk media other than conventional hard disks (eg. flash disks, Zip disks) often come preformatted with a FAT filesystem, and in some cases lack a partition table also. You can nevertheless add a partition table and/or change the filesystem type (eg. to Ext2) if you wish.
Various disk partitioning tools exist for Linux, with varying degrees of functionality and user-friendliness. The most basic utility is fdisk, present in almost all Linux distributions. Enhanced tools include cfdisk, GNU parted, and Disk Druid. If you don't know Linux well, use parted, if available.
If no operating system has ever been installed on the disk before, you must either install the DIET-PC boot loader into the Master Boot Record (MBR) area of the disk (see comments in the Makefile), or write a general purpose MBR by some other means (eg. "fdisk /mbr" in DOS). If you install a DOS MBR, or if one is already installed, you must mark the partition in which you intend to install DIET-PC as active/bootable (actually, that's not strictly necessary if you have a multi-purpose secondary boot loader such as NTLDR in an active non-DIET-PC partition, but I don't want to further confuse matters by attempting to explain that here).
Generally speaking, if your disk has ever had or is ever likely to have Windows on it, you should partition it using DOS/Windows tools, leave the MBR alone, and use Linux partitioning tools only to set a partition type to Ext2 and to activate an Ext2 partition. Windows is very fussy about partition tables, and you don't want to aggravate it.
Filesystems can be created in Linux using "mkfs -t type block-device", where type is vfat or ext2 and block-device is the Linux hardware address of the relevant disk or disk partition, eg. /dev/hda1. Needless to say, this will destroy all existing data on the named disk/partition.
CDs are conceptually similar except that, because of the way the hardware operates, the MBR, partition table, and filesystem all have to be prepared off-disc in advance, and then written to the disc in a single pass. mkisofs takes care of all of this, so don't worry about it.
Copy kernel/vmlinuz and initrd.img to the root directory of the FAT filesystem. To do this you can either mount the filesystem, use cp, and then unmount it again, or you can use mtools. Example:
mount -t vfat /dev/hda1 /mnt cp kernel/vmlinuz initrd.img /mnt umount /mnt
label linux kernel bzImage append root=/dev/rd/0 rw initrd=initrd.img console=tty1
Network boot loaders can be broadly categorised as "PXE" and "Other". PXE (Pre-eXecution boot Environment) is rapidly becoming the de-facto network booting standard, and is supported by most modern network interface hardware. For older hardware, a plug-in hardware and/or software solution is required in order to achieve network booting. There are various alternatives to PXE - the "Other" method of choice for DIET-PC is the Network Bootable Image (NBI) standard.
PXE boot loaders include PXELinux (part of the SysLinux distribution), GRUB, BpBatch, and Etherboot. PXELinux is the simplest to use; GRUB and BpBatch are much more versatile, but GRUB supports a limited range of hardware and BpBatch is not included with DIET-PC as it is not Open Source. Etherboot can support PXE ROMs by using a PXE-encapulated intermediary to load an NBI or ELF image, but this method is complicated and undesirable, and is only useful if you have legacy Etherboot ROMs also and want to use a common image for both (actually GRUB might cater better to this situation, if you can manage it).
If you don't have a PXE ROM and would prefer to use a PXE boot loader (which is strongly recommended), you can use ROMs - either real, or emulated on floppy disk - generated by Rom-O-Matic using the latest version of Etherboot (5.3.x).
NBI boot loaders include GRUB, Netboot and Etherboot. The Network Boot Image format requires special handling by DIET-PC's assembly tools, and has largely been rendered obsolete by PXE in any case, so you should avoid using it if you have the option. GRUB is able to sidestep the need for combined kernel-plus-initrd NBI image by using an NBI-encapsulated intermediary (nbgrub) instead, which in my opinion is preferable.
If you are using a network boot loader, you must install and activate a TFTP service on your designated DIET-PC boot server. Most operating systems come with a TFTP server package, but it is usually not installed by default.
In the case of Windows 2000 Server or Windows 2003 Server, the TFTP server is an integral part of the Remote Installation Services (RIS) package, and is difficult to use in isolation (see the Windows 2000 Etherboot HowTo for details). Morgan Simonsen has constructed a standalone TFTP server package based on the native W2K/W2K3 server, which is a much simpler alternative to installing RIS. Earlier versions of Windows lack a TFTP server; in such cases a third-party product such as tftpd32 is needed.
If you intend to use PXELinux, you must use a TFTP server that supports the tsize option. For any PXE boot method, a TFTP server that supports the blksize option is highly desirable, as PXE boot loaders can make use of larger blocksizes for faster booting. I recommend using either the native Windows 2000/2003 TFTP server or tftpd32 on Windows, and tftp-hpa (usually the default TFTP server in recent Linux distributions) on UNIX platforms.
To activate the TFTP server in Linux, you would typically install the TFTP server package (RPM, DEB, etc), set "disable=no" and "server_args=-s /tftpboot" in /etc/xinetd.d/tftp and restart xinetd using "sh /etc/init.d/xinetd restart" or similar.
Set "umask 022" to ensure world-readability, "mkdir -p /tftpboot/diet-pc", and then proceed as follows:
Thanks to Darryl Bond for the recipe which follows.
Copy kernel/bzImage, initrd.img, and bpbatch.P and bpbatch.ovl (from the BpBatch distribution) to /tftpboot/diet-pc.
Rename /tftpboot/diet-pc/bpbatch.P to /tftpboot/diet-pc/bpbatch, or to /tftpboot/diet-pc/bpbatch.B if you are using a TFTP server that supports the blksize option.
Create a file named bpbatch.bpb in /tftpboot/diet-pc with contents as follows:
set CacheNever="ON" set len=@"$Basename" set len=($len - 9) set mybase="$Basename"[0-$len] LinuxBoot "$mybase/bzImage" "rw root=/dev/rd/0 console=tty1 ip=$BOOTP-Your-IP:$BOOTP-Server-IP:$BOOTP-Gateway-IP:$BOOTP-Subnet-Mask:$BOOTP-Host-Name" "$mybase/initrd.gz"
"make elf" if you have not already done so, and then copy diet-pc.elf to /tftpboot/diet-pc.
"make nbi" if you have not already done so, and then copy diet-pc.nbi to /tftpboot/diet-pc.
Copy kernel/bzImage and initrd.img to /tftpboot/diet-pc.
Create a /tftpboot/diet-pc/grub directory.
Copy the relevant nbgrub (if you are using an Etherboot boot ROM) or pxegrub (if you are using a PXE boot ROM) file from templates/netgrub/diet-pc/grub to /tftpboot/diet-pc/grub. The README file in the former directory will help you determine which is the correct file for your NIC.
If you want to use a version of GRUB other than that provided with DIET-PC, you will most likely need compile it yourself, as network-bootable GRUB files are seldom provided with GRUB builds in popular Linux distributions. You should also note that the GRUB files provided with DIET-PC have been compiled with a built-in menu for important security reasons (see templates/netgrub/diet-pc/grub/README).
Copy templates/netgrub/diet-pc/grub/grub.conf to /tftpboot/diet-pc/grub/grub.conf (recommended), or create this file with contents minimally as follows:
title diet-pc kernel /diet-pc/bzImage rw root=/dev/rd/0 console=tty1 initrd /diet-pc/initrd.img
Copy kernel/bzImage, initrd.img and templates/pxelinux/diet-pc/pxelinux.0 to /tftpboot/diet-pc.
pxelinux.0 is from the SysLinux distribution.
Create a /tftpboot/diet-pc/pxelinux.cfg directory.
Copy templates/pxelinux/diet-pc/pxelinux.cfg/default to /tftpboot/diet-pc/pxelinux.cfg/default, or create this file with contents minimally as follows:
label linux kernel bzImage append root=/dev/rd/0 rw initrd=initrd.img console=tty1 ipappend 1
Configurations of DHCP or BOOTP servers will differ greatly depending upon the server software and boot loader used, so the best that I can offer here are examples of some common configurations.
You do not need to use fixed MAC address to IP address assignments. However, if you use dynamic address allocation you will need to assign permanent leases, since DIET-PCs cannot properly reconfigure themselves to new IP addresses at run time (this is very difficult to do on a thin client without major service disruptions, because of the large number of network connections that are always open).
Nor do you need to provide client hostnames in the DHCP response. A DIET-PC thin client will use this information if present; if not, it will attempt a reverse DNS lookup on the IP address it was allocated and use this name instead. If this also fails, it will fall back to using its MAC address (ie. a string of twelve upper case hexidecimal digits) as its hostname.
It is possible to load an Etherboot NBI via PXE by means of an intermediary PXE-encapsulated Etherboot ROM image (see Set Up Etherboot section below). This is a bit less efficient (requiring two DHCP requests), but also a bit more tamper-proof, than PXELinux. However, this method requires a smart DHCP server which can make run-time decisions based on the Vendor Class Identifer presented by the client. The only DHCP server that I know can do this is ISC DHCP Server 3.0. I am told that Weird Solutions DHCP Turbo can do this in a Windows server environment, but have not verified this claim.
Although the BpBatch documentation insists that you must use a DHCP or BOOTP server that is capable of setting the vendor-class-identifier (60) and vendor-encapsulated-options (43) attributes required by the PXE protocol, it appears that few PXE boot ROMs actually require such strict protocol compliance.
This of course depends entirely upon which application you are serving to your DIET-PCs. The simplest thing to do for testing is probably to set up your Linux development box as an XDMCP and XFS server. Assuming this situation, you will probably need to edit certain config files to enable network listeners, as most Linux distributions have fairly paranoid default settings. In Red Hat Linux, you need to make the following changes (and then reboot the computer or restart the relevant services):
You may also need to modify firewall settings (ie. IP filters) if you have configured your Linux distro with additional network security.
Your thin client hardware will require some configuration. If you have a mainboard network adaptor with PXE support, this may be as simple as activating the boot ROM option in the BIOS. Newer PCI network cards typically have BIOS extensions that you can modify at boot-time using a special key sequence (eg. <Ctrl>S). For older PCI or ISA network cards, you will probably have to boot to DOS and run a DOS setup utility to enable the boot ROM (whether plug-in ((E)PROM), or on-card flash memory (EEPROM)). If you are particularly unlucky, you may have to use a Windows driver to configure the NIC. If you don't already have a boot ROM, you will need to get one.
NIC setup utilities are often hard to locate; typically they are part of a larger self-extracting Windows driver bundle, and either barely- or un-documented. The setup utility usually caters to a range of chipsets rather than vendor make and model numbers, so the association may not be obvious (eg. RSET8029.EXE for NE2000 PCI clones). If you don't have the original Windows drivers, try an Internet search - you may be able to download a utility from somewhere.
If you don't have a boot ROM, check to see if you have a ROM socket. Older NICs will typically have a rectangular 28-pin or 32-pin socket for an EPROM, and newer ones will either have soldered-on EEPROM or a small square plug-in EEPROM socket. If you have a soldered-on EEPROM but no PXE boot ROM, its possible - but unlikely - that you may be able to find a utility that can program an abritrary ROM image onto it. If you don't know what sort of EPROM the NIC will accept, it's highly likely that a 27C512 (28-pin socket) or 27C010 (32-pin socket) will work. But before you rush out and buy an EPROM burner, get your ROM working on floppy disk first (see below).
The one-stop-shop for all your DIY boot ROM needs is Rom-O-Matic, an ingeniously designed site that dynamically compiles Etherboot ROM images to your specification and then uploads them to you, in a few easy steps. The only pitfall is that it isn't always obvious from the description which Etherboot image you need. Each image is keyed to a unique PCI bus identifier, and will only work if your NIC uses exactly that identifier. If you are using the same type of NIC in your Linux development box, you can discover the PCI ID of your NIC by comparing the output of "lspci" and "lspci -n". Otherwise, see the online help provided by Rom-o-matic.
For a production rollout of DIET-PC, you would obtain an Etherboot ROM image (.lzrom extension) and "burn" this onto (E)EPROMs using an EPROM burner, then fit the EPROM to the NIC's ROM socket. However, for development and testing purposes you should obtain a floppy-disk-bootable image (.lzdsk extension) instead. To use this image, write it to a blank (or expendable) floppy disk using "dd if=name-of-rom-o-matic-file of=/dev/fd0" on your Linux box, then insert the disk into your thin client PC and boot it.
If all goes well, you should now be able to boot your DIET-PCs. However, there's no guarantee that, once booted, the X server will start and that the DIET-PC will connect to your application server properly. Even if it does, you will probably want to optimise your solution further. Fortunately DIET-PC allows on-the-fly debugging.
If your X server is not starting properly, the screen will flicker madly for a few seconds while init tries to restart X several times in rapid succession before giving up and disabling that service for five minutes, at which point you will be dumped back at the boot menu (or login prompt if you opted for this instead).
If your X server started but there was a problem with an embedded GUI application, you'll probably be looking at an empty grey screen with an X-shaped cursor in the middle. In this case, you are on Virtual Terminal #3 (VT3) and you need to switch back to the boot menu on Virtual Terminal #2 (VT2). To do this, hold down the <Ctrl> and <Alt> keys and press <F2>.
You should now be able to log into the DIET-PC as the privileged user (root). If you haven't changed it, the root password will be "foobar" (a word traditionally used by UNIX hackers as a placeholder in cited examples, derived from the military acronym FUBAR ("Fouled" Up Beyond All Recognition), which is probably quite appropriate in this case! By way of additional trivia, in the UNIX vernacular users don't log "on", they log "in").
Once logged in, you can search logs for explanations as to what has gone wrong. For X server problems, look in /var/log/XFree86.0.log (eg. "more /var/log/XFree86.0.log"). For embedded application failures, use <Ctrl><Alt><F1> to switch to the console ("console" is a rather vague term in UNIX, in this context I mean "the pseudoterminal where stderr from the kernel and processes that don't explicitly redirect it elsewhere ends up") and take a look at the last few messages reported. Use <Ctrl><Alt><F2> to switch back to your login shell.
Another common failure is inability to initialise the network, or inability to resolve hostnames into meaningful IP addresses for some other reason (eg. missing DNS options in the DHCP response). Use "ifconfig eth0" to check whether your default Ethernet interface is set up correctly. If you are trying to refer to an application server by name rather than IP address, check to see if "nslookup hostname" succeeds.
Another useful source of information is syslog. If you have defined a log server in your server-side DHCP configuration, then syslog data from your thin client can be found on that server. Otherwise, the information is being recorded in a memory buffer which can be played back using the "logread" command.
To reattempt a failed service, either use "kill -1 1" to signal the init process to try again, or use "init 1" to change the runlevel to shell-only, followed by "init n" (where n is 2 for XDM, 3 for RDP, 4 for ICA, 5 for RFB (VNC), 7 for HTTP, 8 for local media player). You can also change runlevels (and reassign server roles) using the boot menu.
You can make simple run-time corrections to configuration files (eg. the X server configuration file, /etc/X11/XF86Config-4) using "vi". Vi is arcane, but omnipresent in UNIX distributions. If you're not familiar with it, you'll need to read up on it first (try "man vi" on your Linux development box).
If you find that your thin client is missing a vital file, you can copy the missing files to /tftpboot on your boot server and use the Busybox tftp applet on the DIET-PC to download it (eg. "tftp -g -r filename bootserver"). DIET-PC also supports tar, gunzip and bunzip2, so you can use "tarballs" to transfer directory trees via TFTP. Conversely, if you have corrected a file and want to upload it to your server to avoid duplicating your corrections there manually, you can use "touch /tftpboot/filename; chmod 666 /tftpboot/filename" on your server followed by "tftp -p -l filename bootserver" on the DIET-PC.
You will probably have to rebuild and retest your DIET-PC boot image several times in order to resolve all the issues. Before finalising your production boot image, make sure that you have changed all passwords to something other than the default (see the READMEs in the relevant packages).