
   $Id: SLXT_FAQ,v 1.1 1998/01/31 10:19:13 root Exp root $


                   SLXT - SPARC-Linux Xterminal FAQs
		   =================================


Section I - General Information.
================================

Q1-01 - What is this package?

Q1-02 - Why would I want to use this package?

Q1-03 - What are the differences between this and the other Xkernel
        packages out there?


Section II - Requirements & Configuration.
==========================================

Q2-01 - What extra hardware do I need?

Q2-02 - What extra software do I need?

Q2-03 - Do I have to use a Linux machine as a server?

Q2-04 - I've heard that a Linux server can cause problems on a Sun
        network. Does this apply to an Xterminal server, too?

Q2-05 - Do I have to use your ditsy install scripts and templates?

Q2-06 - Can I use multiple frame-buffers and displays on a single client?

Q2-07 - Can I use a diskfull, Sun workstation as a test client, just to
        get the feel of the package?


Section III - Functionality.
============================

Q3-01 - How do I boot the Xterminal client system?

Q3-02 - How do I shut down the Xterminal client system?

Q3-03 - My IPC runs much faster as an Xterminal than it does as a normal
        SPARC-Linux machine.  Does this mean that the "slowdown bug" is
        fixed in the SLXT kernel?

Q3-04 - Will the audio work on the client workstation?

Q3-05 - Can I use the floppy drive as a mountable filesystem?

Q3-06 - When I log on at the client workstation, the prompt shows that I'm
        actually running a shell on the server. Can I change this?

Q3-07 - Can I run multiple Xterminal clients from the same server? 

Q3-08 - Do I need to set up the /usr/gnemul tree to be able to run
        Netscape? 

Q3-09 - <CTRL><ALT><F1> gets me back to the console from the X session, but
        this functionality stops working after I log into X for the second
        time.  When will this be fixed?

Q3-10 - What other functionality can we expect to see in the SPARC-Linux
        Xterminal package?


Section IV - Troubleshooting.
=============================

Q4-01 - My client doesn't boot. What could be wrong?

Q4-02 - The ARP/RARP entries on my server look okay... now what?

Q4-03 - Where can I find the Xterminal client log files?


--------------------------------------------------------------------------------

Section I - General Information (ANSWERS).
==========================================


Q1-01 - What is this package?

A1-01 - This is a simple, SPARC-Linux implementation of Seth Robertson's
        Xkernel package. It enables a Sun SPARCstation to be used as an
        Xterminal, running only the X server process, while all of the
        client programs are run on a separate system with the output
        displayed on the high resolution, SPARC monitor.


Q1-02 - Why would I want to use this package?

A1-02 - This package uses a Linux kernel to give full display
        functionality to the SPARCstation at speeds approaching that of
        the host server. In cases where  the SPARC is an exceptionally
        slow model, or has very little memory, this speed increase can be
        very marked.  The package also enables a SPARCstation to be used
        without an internal disk and with only 12MB of memory (an 8MB
        machine will boot, but the X server process will eat all of
        available physical memory and the system will explode in a shower
        of slimy, unsatisfied kmallocs - this is an experience on a par
        with that of a visiting Mother-in-law... rarely fatal, but not to
        be encouraged).


Q1-03 - What are the differences between this and the other Xkernel
        packages out there?

A1-03 - This package uses only the very finest, hand crafted, Linux code.
	There are no Sun binaries or libraries used at all, so this
	package is totally free from any licencing restrictions (other
	than those imposed by the GNU General Public Licence - see
	enclosed LICENCE file).  This package is intended to support
	SPARC architecture clients only. For Xterminal client support
	of i386 clients, I would recommend that you grab the DXT
	package (the "Diskless X-window Toolkit" from Roman Dolejsi -
	roman@sorry.vse.cz).  It also includes support for virtual
	consoles on the client machine.


--------------------------------------------------------------------------------

Section II - Requirements & Configuration (ANSWERS).
====================================================


Q2-01 - What extra hardware do I need?

A2-01 - None. Any SPARCstation system with a frame-buffer manufactured by
        Sun should work. Obviously, your machine must have a monitor, 
	keyboard and a mouse.


Q2-02 - What extra software do I need?

A2-02 - None for the client system; everything you need is included in
	the SLXT package. The machine you choose as a server must have a
	full X11 tree (default for most Linux installations) and
	ARP/RARP support either built into the kernel, or available as
	loadable kernel modules (again, these should be available by
	default on most, post 2.0 Linux systems).


Q2-03 - Do I have to use a Linux machine as a server?

A2-03 - You do not need to use a Linux (or an iX86 system) as your
        server. Any system capable of providing ARP/RARP, TFTP and NFS
        support will work, although the installation and add_xterm scripts
        will probably need some modification. I have already tested the
        package using a Solaris 2.5.1 server and, although the scripts did
        not work, installing and running SPARC-Linux Xterminals proved to
        be a very easy task -  no more than ten minutes work at most for
        an experienced Sun admin.


Q2-04 - I've heard that a Linux server can cause problems on a Sun
        network. Does this apply to an Xterminal server, too?

A2-04 - Yes. Please be very careful where you deploy this package. It
	will almost certainly cause problems on networks where there
	are diskless, dataless, or autoclient Sun machines, unless the
	server chosen as the Xterminal server also happens to be the
	server for the existing clients. The reason for this is that
	most Suns will assume that a server answering an RARP request
	will also provide bootparam services. This is obviously not
	going to be the case when that "server" is actually an iX86
	Linux system  providing nothing more than Xterminal support.


Q2-05 - Do I have to use your ditsy install scripts and templates?

A2-05 - No. If you have the experience to be able to install things
        manually, I would encourage you to experiment with the package
        (and to post any improvements).


Q2-06 - Can I use multiple frame-buffers and displays on a single client?

A2-06 - You tell me!  The X server process did detect the second and
	third frame buffers in my IPC, but the screen output at
	initialization was jumbled.  This could well be a problem with
	my hardware rather than the X server itself, though. I'd
	certainly like to hear from anyone else who has tried multiple
	frame-buffers in their machine.


Q2-07 - Can I use a diskfull, Sun workstation as a test client, just to
        get the feel of the package?

A2-07 - Yes. The kernel image in the package does not have any device
        drivers for disks included. It cannot overwrite existing data and
        so it is quite safe to use a diskfull system as a test client.


--------------------------------------------------------------------------------

Section III - Functionality (ANSWERS).
======================================

Q3-01 - How do I boot the Xterminal client system?

A3-01 - You need to ensure that the client boots from the network. The
	exact syntax of the boot command depends upon the revision of
	the boot PROM in your machine, but one of the following two
	examples will generally work:-

                    PROMPT             COMMAND
		    ======             =======

                       >                 ble()

                      ok                 boot net


       To make the change permanent and ensure that the machine boots
       from the network by default, save the setting to NVRAM:-

                      ok                 setenv  boot-device  net


Q3-02 - How do I shut down the Xterminal client system?

A3-02 - Simply log-out and switch off. The client doesn't have any
        filesystems to sync or check.


Q3-03 - My IPC runs much faster as an Xterminal than it does as a normal
        SPARC-Linux machine.  Does this mean that the "slowdown bug" is
        fixed in the SLXT kernel?

A3-03 - No. The SLXT package does not fix the IPC "slowdown" bug (it
	only appears to do so by moving the load from the client onto
	the server).  The SLXT kernel is a standard, 2.0.30 kernel,
	with most of the drivers for peripheral devices removed. The
	client doesn't do anything other than run the X-server process;
	there is no disk I/O and no swapping. In the same way that some
	IPC systems display the "slowdown" bug and some don't, it's
	quite possible that some SLXT clients might still suffer from
	the problem, but because there's so little running on the
	system, it is unlikely that the symptoms will be as evident as
	on a normally configured SPARC-Linux machine.


Q3-04 - Will the audio work on the client workstation?

A3-04 - No. All applications run on the server, with only the display
	output redirected to the SPARC-Linux Xterminal. Any sound
	output (other than keyboard beeps) would normally be through
	the speaker or sound card on the server, assuming that the user
	has access permission.


Q3-05 - Can I use the floppy drive as a mountable filesystem?

A3-05 - No. There are no floppy, or other disk drivers included in the
        Xterminal kernel.


Q3-06 - When I log on at the client workstation, the prompt shows that I'm
        actually running a shell on the server. Can I change this?

A3-06 - Yes. Although you cannot get a shell on the client machine
	itself (it only runs a cut-down kernel and the X-server
	process), you can change the XDM configuration to enable a
	menu-selectable choice of machines before the initial login.
	See the "CHOOSER" section of the XDM manual page for more
	details on how to configure the target servers, and the
	"X-server configuration" section at the top of the
	SLXT_root/bin/init file for client side changes.  In addition,
	the normal practice of setting the DISPLAY variable and running
	applications from remote machines will also work.


Q3-07 - Can I run multiple Xterminal clients from the same server? 

A3-07 - Yes. I have run two SPARC clients from a single, i386 Linux
	server, with surprisingly good results. The only limits to the
	number of simultaneous clients are the horsepower of your
	server and the bandwidth of your network.


Q3-08 - Do I need to set up the /usr/gnemul tree to be able to run
        Netscape? 

A3-08 - No. All applications run on the server with display
	output redirected to the SPARC client, so your server's native
	version of Netscape will work. You do not need the SunOS
	emulation tree unless your server is also a SPARC-Linux system
	(and even then, you can probably "xhost" applications like
	Netscape from some other machine on the net).


Q3-09 - <CTRL><ALT><F1> gets me back to the console from the X session, but
        this functionality stops working after I log into X for the second
        time.  When will this be fixed?

A3-09 - Actually, the initial virtual-console functionality is the bug,
        not the fact that it stops working.  Switching between X and the
	console display can really confuse the X keyboard handling and
	I don't recommend doing it unless you're trying to debug
	display problems.  As there's no shell available on the virtual
	console, there's very little point in switching to it anyway.


Q3-10 - What other functionality can we expect to see in the SPARC-Linux
        Xterminal package?

A3-10 - Extra functionality will come with the addition of
	administration scripts for OS'es other than Linux, making it
	easier to use different systems and architectures as support
	servers for SPARC-Linux Xterminal clients.  For non-SPARC
	clients I would recommend that you look at the DXT package


--------------------------------------------------------------------------------

Section IV - Troubleshooting (ANSWERS).
=======================================

Q4-01 - My client doesn't boot. What could be wrong?

A4-01 - There are many reasons for a failed boot, but the most common
	one is a missing, or bad, ARP or RARP entry on the server,
	resulting in repeated "Timeout waiting for ARP/RARP packet"
	messages scrolling down the console on the client system.  To
	check this, log into the server and do "arp -a" and "rarp -a".
	You should see the client hostname and ethernet address in both
	tables.  Double check the ethernet address against the address
	shown at the top of the client's display (all numbers in
	the ARP/RARP tables will be padded with leading zeros).  If the
	client address is missing or incorrect, you can add it manually
	using "arp -s <HOSTNAME> <ETHERNET-ADDRESS>" (the syntax is the
	same for the "rarp" command).  Remember to pad any single
	characters with a leading zero.


Q4-02 - The ARP/RARP entries on my server look okay... now what?

A4-02 - Make sure that your client and server are physically connected
	to the same sub-net.  Most routers and repeaters will not
	forward ARP/RARP packets.

	If you're still having problems, use the "tcpdump" program
	("etherfind" on SunOS, or "snoop" on Solaris) to verify that
	your client is actually sending packets out onto the network.
        The syntax is simple:-

                          tcpdump host <HOSTNAME>

	You should verify that the ethernet address which the client is
	sending out in it's initial packet is the same as the one you
	have loaded in your ARP/RARP tables on the server.

	Make sure that some other system isn't answering the initial
	ARP request.  You might have to delete client entries from the
	ARP/RARP tables on other machines to ensure that only the
	server answers the Xterminal client's requests.


Q4-03 - Where can I find the Xterminal client log files?

A4-03 - The client machines do not write to the server filesystem at
	all (in fact, the server exports the common, client filesystem
	"read-only").  This can make debugging a little difficult, but
	you can use the XDM error log to troubleshoot  most application
	problems (check the xdm-config file for the location on your
	particular machine, but generally the file is
	/var/tmp/xdm-errors).  Boot problems should be visible on the
	client console during the boot sequence.


--------------------------------------------------------------------------------

