The SPARC-Linux Xterminal Package

NOTE

The Linux Terminal Server Project (http://www.ltsp.org) includes support for SPARC architecture machines. If you're looking for an alternative to SLXT, I recommend that you check it out.

"There hasn't been any activity on the SLXT pages recently, is it worth trying this old package?"
Yes, it's certainly worth trying. The self-contained nature of the package means that it should always work, no matter what revision your kernel or OS is (and as long as you are running X, of course). That's the reason these pages (and the packages) are still here. Read on...

• What is the SLXT package?
• What isn't the SLXT package?
• Requirements
• Late news
• Download
  • Current
  • Development Tarball
• Keyboard Mapping
• Coming attractions
• The SLXT FAQ
• Removing SLXT from your system

	The SPARC-Linux Xterminal package allows a diskless, low-memory, SPARC workstation to be used as an xterminal. The concept is basically that of Seth Robertson's "Xkernel", in that the workstation runs a cut-down Unix kernel and an X-server process, but very little else. This configuration enables low-end, limited-memory machines to run X-based applications at a speed approaching that of the server (the kernel and X-server are running on the SPARC client, while the application itself is running on the server. This can be a little confusing at first).
	It's all Linux! There are no Sun binaries or libraries involved at all. The kernel and libraries are derived from Red Hat and SuSE SPARC releases and are redistributed here under the terms of the GNU General Public Licence (please see the file COPYING for details).
	These are all pretty much Beta releases and anyone using the package should probably consider themselves a tester, rather than an end-user. Bug reports and, more importantly, fixes, are welcome, as are reports of other systems and releases on which this package has been discovered to work.
"LinuxMan" created and drawn by Taro Peter Little.	The package should install as-is on most Red Hat, SuSE and Mandrake versions and, I think, Slackware. It should work with most versions of Linux, but there may be some manual tweaking required to have everything install in the correct place. Hopefully the error reporting from the install script is verbose enough to give strong hints as to what needs to be done.

The SLXT package is not intended to be a replacement for Sun's own XTerminal offerings. I don't have access to any Sun systems equipped with their XTerminal boot PROM, so I have no idea what a genuine Sun XTerminal is looking for at boot time. However, Murray Keys (mkeys AT peterboro.net) has done some testing with his SPARC Classic-X and confirms that an attempted boot from an SLXT server fails with the message:-

Error while getting software from Boot Host

Jason Wohlgemuth sent me a link to some information taken from the Sun NVRAM/HostID FAQ which explains how to update the NVRAM settings on the Classic-X to have it transmogrify itself back into a Classic (which can run under SLXT). The changes are reversible, so you get two machines for the price of one.
Interestingly enough, the original source of this mini how-to was my old friend Gary Cook. Thanks to Gary and to Jason (and to Mark Henderson, author of the FAQ) for making this information available.

• You must have your machine connected to a network on which there is at least one other machine. This second, "boot server" machine must have a minimum of 7MB of free space available for the SPARC-Linux Xterminal package, and should have a complete X11 tree. It can be anything from a standalone i386 Linux system upwards (although it obviously makes sense to use a server which is more powerful than the clients, especially where multiple clients will be operating simultaneously).

• Your SPARCstation must have at least 12MB of main memory (it will boot with 8MB, but will crash with "out of memory" errors as soon as you start using applications). In the same vein, because the client machine only runs a Linux kernel and the X-server process, any more than about 24MB of memory is a complete waste. The SPARC client cannot "page" or "swap" (see below).

• Your SPARCstation does NOT need a disk. There are no disk drivers included in the kernel, so even if the machine has a hard disk installed, it can not be accessed (this also means that it is quite safe to use a diskfull system for testing).

• Your SPARCstation client must have a frame-buffer, monitor and keyboard.

For more information, pick up the SLXT-FAQ file, the CHANGES file and the slxt.lsm package info file.

If you're planning to install onto a network with existing Sun diskless, dataless or AutoClient systems, you should be aware of the potential problems before you start.

• FreeBSD Support In Latest TarBall

  The latest tarball, SLXT_0.7g, includes basic support for SPARC-Linux Xterminals booting from FreeBSD servers. There are still some (very!) rough edges, but the basic framework is there. It should work with FreeBSD releases 4.4 and 4.5 and upwards.

• Red Hat 7.2 Issues

  Almost everything in the 7.1 section (below) is also true for 7.2. The biggest "show stopper" for 7.2 though, was the fact that the filesystem is now ext3 by default. A fix for this is included in all SLXT versions from 0.7f onwards (thanks to Paul H. Alfille for his fixes for this problem and to Chris Benson for the pointer to the "df" which I'd missed when implementing Paul's fix).

• Red Hat 7.1 Issues

  Maarten van Leunen (maartenl@charm.il.fontys.nl) put in a lot of work troubleshooting his RH-7.1 SLXT install and reported the following issues.

  • The RARP daemon.

    (See Andy Howell's info below)

  • xinetd

    Red Hat 7.1 uses xinetd by default. The tftp daemon is included in the release (on the second CDROM), but you may have to install it (using "rpm") depending upon which machine type you chose during your initial installation of the OS (workstation, server, etc).

    Maarten's suggested config file for the tftp daemon is:-

    		# default: off
    		# description: The tftp server serves files using the trivial file transfer\
    		#       protocol.  The tftp protocol is often used to boot diskless \
    		#       workstations, download configuration files to network-aware printers, \
    		#       and to start the installation process for some operating systems.
    		service tftp
    		{
    			socket_type             = dgram
    			protocol                = udp
    			wait                    = yes
    			user                    = root
    			server                  = /usr/sbin/in.tftpd
    			server_args             = -s /tftpboot
    			disable                 = no
    		}
    		

  • The font server process (again).

    See the RH-6.0 section, below.

    Maarten decided that in his situation he would disable the font server completely and he elected to copy the complete font directory into the SLXT client root tree:-

    		So. I was a little impatient and copied all my fonts from the linux server in
    		/usr/X11R6/lib/X11/fonts/ over to
    		/tftpboot/SLXT_root/usr/X11R6/lib/X11/fonts.
    		 
    		Then changed the 'init' script and removed the font parameter from the X
    		call.
    		  
    		from:
    		XSRVCMD="${XSERV_BIN} -fbinfo -pn -fp ${FS_LOC} ${XDMCMD}";
    		to:
    		XSRVCMD="${XSERV_BIN} -fbinfo -pn ${XDMCMD}";
    		   
    		This is also an interesting way to get rid of the font server ;-)
    		

    Because the clients share the root tree, this is a perfectly acceptable solution to the problem, providing you have enough space in the root tree partition for all of those font files.

  • xdm/prefdm/gdm changes

    Maarten notes that changing the entry in /etc/sysconfig/desktop will give the option of using Gnome, KDE or XDM as the desktop manager via /etc/X11/prefdm.

    He also mentions that it might be necessary to change the "xdmcp Enable" entry to "1" in /etc/X11/gdm/gdm.conf to have this work.

• Red Hat 6.0 Issues

  Reports are coming in of problems with SLXT and Red Hat release 6.0. It seems that not only does SLXT not work properly under this release, but the install changes can also adversely affect X11 on the server itself.

  I suspect that this is because RH6.0 starts an X font-server process by default, whereas none of the previous releases did (try killing off the xfs process started by SLXT if you're having problems, and let me know if it helps), but until I get a chance to trouble-shoot this issue, I'd advise you not to install SLXT on a server running Red Hat 6.0.

  The fixes will appear here as soon as I've had a chance to investigate the reported problems, but in the meantime, here are some initial findings which relate specifically to the X font-server problem.

• 2.3 (and greater) Kernels

  Andy Howell (andy@tibcofinance.com) reports that on newer 2.3 kernels, RARP is no longer integral to the kernel itself. This means that to boot SLXT clients with 2.3 kernels you will need to download and install a separate RARP daemon package. This is available from:-

  ftp://ftp.dementia.org/pub/net-tools/rarpd-1.1.tar.gz

• Network Traffic Problem

  Todd Whittaker (whittake@cis.ohio-state.edu) noticed that the SLXT program slowed his network considerably, with tcpdump showing a constant flow of traffic between his server and the client.

  This turns out to be caused by the xbanner program, the process running on the server which paints the nice little "SPARCterminal" logo in the top, right-hand corner of the xdm login screen. It seems that older versions (pre-1.31) send a steady stream of updates to the remote Xterminal screen.

  Upgrading to the very latest version of XBanner fixes the problem and both Red Hat and Debian packages are available for XBanner v1.31.

  If for some reason you are not able to upgrade, a simple temporary solution is to just kill the xbanner process on your server.

  You can also have the process killed automatically by adding these lines to the very top of your Xsession file (usually /etc/X11/xdm/Xsession on Linux systems):-

  #
  # Reap "XBanner" children, otherwise they hang around and cause
  # network traffic, trying to update the background on each display.
  #
  KILL_XBANNER=/usr/bin/X11/freetemp;
  if [ -x ${KILL_XBANNER} ];      then
          ${KILL_XBANNER} 2>&1 >/dev/console;
  fi
  

  Or, and this is preferable if you have lots of clients and/or a busy network, remove the "xbanner;" line from the ~xdm/Xsetup-<HOST>_0 file for each client to disable xbanner completely.

The main changes are:-

• Support for FreeBSD servers
• 2.2.14 Kernel
• 3.3.6 XFree86
• loadkeys utility and Sun keymaps lib
• routed (daemon)
• route (utility)
• ramdisk

There are only very minimal changes to the documentation with this tarball, so you will find inconsistencies between the instructions and what is available in the package.

This version (0.7g) also has much of the xinetd code included, so it should work with Red Hat 7.1/7.2 and with other distributions which use xinetd by default. It now also recognizes non-ext2 filesystems.

0.7g also adds support for FreeBSD servers. This means that your SPARC-Linux Xterminals are now able to boot from i386 FreeBSD servers. For this single act I have probably earned the undying enmity of at least four separate groups...

• The Linux camp for consorting with FreeBSDers.
• The FreeBSD camp for introducing the "L" thing onto their pristine system.
• The NetBSD people because everyone knows that SPARC works just fine under their OS, so why would anyone want an Xterminal?
• The OpenBSD people for the same reason, plus Theo.

The previous version, SLXT_0.5c.tar.gz is approximately 2.5MB and will take up slightly more than 6MB when installed. SLXT_0.5a.tar.gz is also still available for reference.

There's not too much development in this tarball, I'm afraid. The updates are restricted mainly to manual pages and the FAQ. This version may not build on your system and may actually break any good, existing SLXT installation. Unless you have a desperate craving for manual pages, leave well alone.

• SLXT_0.7h Development Tarball

Keyboard Mapping

• Solaris

  When I originally released the SLXT package I made a conscious decision not to include SunOS or Solaris support, even though much of the initial development and debugging was carried out on a Solaris server. The reason for this decision was the problem of having a package which was easily installable by non-technical users, but which could cause massive disruption on existing networks.

  While adding hooks for other operating systems, I decided that Solaris should be included too, this time round. The Solaris version will do some extra work on checking the environment it is being installed into and will probably be a lot noisier in announcing itself to the world in general.

  Look for a Solaris version soon. SunOS will not be supported.

• FreeBSD

  Work on the FreeBSD version is further advanced than the Solaris version. The next major release will include support for FreeBSD. Versions as of 0.7g will boot SPARC-Linux Xterminals from FreeBSD servers.

• Red Hat/Mandrake compatibility

  The latest OS releases from the Linux heavies have so many major changes (xfs, xinetd, etc) that it really is necessary to get a point release out to deal with those updates. Work on the FreeBSD changes is so far advanced that these changes will be rolled into that version.

• Others

  OpenBSD, NetBSD, HPUX?? What do you need?