Archive for September, 2010

Ubuntu Diskless Workstation and X-Terminal Howto – Part 1 – Preparing the Server

by on Sep.25, 2010, under Desktop Productivity, Hardware/Disk Management, Networking

Why a diskless workstation? In today’s day and age, this is a good question. My take on it is that I have a multiuser operating system (Linux) running on a large machine (Dual Xeon 5160 with 12 GB RAM) that could be used from several locations in the house by deploying X-Terminals. Rather than spending money on X-Terminals, why not use an old laptop or desktop machine to access the servers gui, applications and resources? That is my reasoning, and I also add some local application support for things not suitable for the X protocol over the network, such as Video, so while the machine is diskless, it isn’t just a dumb display device.

Preparing the Server

Lets get started with preparing the server side of the diskless environment.  For our purposes we will be using a traditional NFS based environment for running the diskless workstation.  This process should work on Ubuntu Lucid or Karmic Server or Desktop Installations.

Several things need to be installed on the server:

  • tftp server
  • dhcp server
  • nfs server
  • pxelinux.0 and startup files

Install the tftp sever, dhcp server and nfs server with the following command:

sudo apt-get install atftpd && sudo apt-get install dhcp3-server && sudo apt-get install nfs-kernel-server

You will also need to download the pxelinux.0 file.  You can get that file here:

For our example, we will need to create a directory to house our diskless file systems, and pxelinux startup files.  We will use /srv/netboot.  Create this directory on your server with the following command:

sudo mkdir /srv/netboot

In this directory, lets create the following subdirectories:

sudo mkdir /srv/netboot/diskless1

“diskless1” is where the root filesystem of our diskless machine will live.

sudo mkdir /srv/netboot/startup_files

“startup_files” is where kernel images, pxe and initrd images will reside for booting diskless workstations – this is similar to the /boot directory on a linux system. The workstation will access these files via tftp.

Lets share the needed directories via NFS.  To do this, we need to edit the exports file on the server and add the following line:

/srv/netboot/diskless1    *(rw,sync,no_root_squash,no_subtree_check)

Then, tell the nfs server to refresh its export list with exportfs command:

sudo exportfs -avr

Next we will configure the tftp server, atftpd. The configuration file for atftpd is /etc/default/atftpd. We will customize ours to look like this:

#OPTIONS="--tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr --mcast-ttl 1 --maxthread 100 --verbose=5 /var/lib/tftpboot"
OPTIONS="--daemon --port 69 --tftpd-timeout 300 --retry-timeout 5     --mcast-port 1758 --mcast-addr --mcast-ttl 1 --maxthread 100 --verbose=5  /srv/netboot/startup_files"

The first two lines of the file are the default entries – we are going to comment them out and add the second two lines as shown above. After editing the file, restart the tftpd service with the command:

/etc/init.d/atftp restart

Next, we need to configure the DHCP server. Some custom options are required for the DHCP server to tell the diskless workstation how to retrieve its boot files. In our example, we will use a network, so the DHCP server configuration will look something like this (this also assumes that this is the only DHCP server for the network having more than one is bad news unless configured properly) assuming your DNS servers are and and your default router (route to the internet) is

# The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-update-style none;

# option definitions common to all supported networks...
option domain-name "";
option domain-name-servers,;
option ntp-servers;

default-lease-time 172800;
max-lease-time 259200;

# If this DHCP server is the official DHCP server for the local
# network, the authoritative directive should be uncommented.

# This is a very basic subnet declaration.
subnet netmask {
  option routers;

host diskless1  {
      hardware ethernet     00:04:76:3F:A6:36;
      next-server ;
      option root-path      "/srv/netboot/diskless1";
      filename              "/pxelinux.0";

In the example above I created a reservation for the diskless workstation. DHCP reservations are based on mac addresses. The hardware ethernet parameter above should be editted to reflect the diskless workstation’s ethernet card mac address. The fixed-address specifies the IP address that will be assigned to the diskless workstation. The last 3 parameters, called DHCP options, give booting information to the diskless workstation. These should be updated to reflect the appropriate server IP (next-server) and path (option root-path). Substitute your server’s IP address and path for your installation. The DHCP server that ships with Ubuntu linux is the only one that I am aware of that supports per reservation DHCP options such as these. Be sure to also change the DNS server settings the in the dhcp.conf file to the servers for your site/network.

The last part of preparing the server is the configuration of pxelinux and the diskless boot files.

Configuring PXE

The first thing we need to do is take the pxelinux.0 file you downloaded above and copy it to the /srv/netboot/startup_files directory we created above.  Then, in the /srv/netboot/startup_files directory, make the following directory (as root or using sudo):

mkdir pxelinux.cfg

The pxelinux.cfg directory will contain the pxelinux boot configuration file for each diskless workstation.  We will configure these files after we build our diskless workstation image.

This should about wrap it up for the server configuration piece of the diskless workstation setup.  The next part will cover the building of a diskless workstation image from a standard ubuntu-desktop installation.

Stay tuned!

7 Comments :, , , , , , , , more...

NVIDIA 256.53 Drivers and older Games

by on Sep.21, 2010, under Games

Its time for a quick howto – for some time I have been sticking with older NVIDIA driver releases on my Ubuntu machines do to a buffer overrun error on some older games when using driver sets newer than 185.18.36. The interesting thing is that equivalent Windows drivers exhibited the same problem, except that eventually the issue was fixed on Windows. After doing some searching I came across the answer to fix this issue – thanks to Conky on

The problem stems from the newer drivers reporting a GL Extension Version String that is too long for some older programs to process, thus resulting in the buffer overrun. To fix this, NVIDIA included an environment variable that can be set to report older (and thus shorter) version strings.

The game I was having the most trouble with was Call of Duty 1. I know, why would I want to play such an old version? I am a COD addict and still play COD1 all the way up to the current COD:MW2. Under linux, COD1 must be run using Wine. Normally cd’ing to the Call of Duty Directory and running the following command will start the game:

wine CoDSP.exe

However, using NVIDIA 256.53 (or anything beyond the 185.18.36 driver version) will result in the buffer overrun error. To fix this issue, change your startup command to the following:

__GL_ExtensionStringVersion=17700 wine CoDSP.exe

The __GL_ExtensionStringVersion is an environment variable that in this case is set to 17700. What this is doing it telling the NVIDIA driver to report the GL_ExtensionString as if the driver was from the 177.00 series. This effectively eliminates the overrun error and allows the game to start.

This issue, is mentioned in the NVIDIA driver readme file (here is the snippet), as was kindly pointed out by Conky over at

Some applications, such as Quake 3, crash after querying the OpenGL extension string

Some applications have bugs that are triggered when the extension string is longer than a certain size. As more features are added to the driver, the length of this string increases and can trigger these sorts of bugs.

You can limit the extensions listed in the OpenGL extension string to the ones that appeared in a particular version of the driver by setting the __GL_ExtensionStringVersion environment variable to a particular version number. For example,

__GL_ExtensionStringVersion=17700 quake3

will run Quake 3 with the extension string that appeared in the 177.* driver series. Limiting the size of the extension string can work around this sort of application bug.
—End Quote—

So, there you have it. I learned that you’re never “too good” read the readme files.

3 Comments :, , , , , more...

New Content Coming Soon!

by on Sep.14, 2010, under General

Hi – I have been gone for awhile, working on my real job and other responsibilities, but I have several new articles in the works – The last part of the Ubuntu LAMP Server Quick Howto, Ubuntu Diskless Workstation series, and an Ubuntu Firewall article. Keep checking the site these should start showing up in the coming weeks.

Leave a Comment more...

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!


A few highly recommended websites...