Trouble Shooting LTSP

There are several steps to booting an LTSP workstation. When troubleshooting, the first thing to do is figure out where in the boot process the problem is happening.

Slow Applications on Client

• Slow Java Applications

Booting the kernel

• Terminal won't download kernel & boot
• Upgraded DHCP Terminal won't find a boot server due to ISC's DHCP change to how the next-server parameter is defaulted, if not explicitly set in dhcpd.conf.

Mounting the root filesystem via NFS

• NFS hangs on mount or behaves erratically
• NFS Server not responding

Launching X to give a graphical session

• X server doesn't start on client / shows a text console after netbooting
• Widescreen and other Displays show up with wrong resolution
• Gray Screen with X
• Mysterious vtconsole argument screwing X
• If your (k)dm resets immediately after login in, check the permission on /tmp they should be 1777 . Use something like chmod 1777 /tmp -- ChristophSchneeberger - 19 May 2006
• If your (k)dm resets immediately after login in on SUSE, ln -s /etc/X11/xdm/Xsession /etc/X11/Xsession
• If you are using KDE instead of GNOME and you cant seem to log in (every time you log in you get dumped back to login screen), add LDM_REMOTECMD=/usr/bin/startkde to lts.conf and that should fix everything.
• If you are using Gnome and your clients' gdm resets immediately after login, you may have Sabayon installed; remove it, and the issue is resolved (issue discovered with Edubuntu 7.04/LTSP 5.0).
• Be sure that the ssh server is running on your server. Run ltsp-update-sshkeys to be sure the correct keys are generated. If it still doesn't work try "sudo chroot /opt/ltsp/i386" then run passwd and set a root password which will allow logins to the client. Then boot the client and control-alt-F1 to get a terminal. Then ssh to the server using the servers ip address. If you get in this will prove ssh is working correctly.

Problems with the mouse

• Mouse Jittery^?
• Mouse Wheel Not Working
• USB Mouse too fast

Problems with the keyboard

Normally "setxkbmap -layout map" should allow you to change your keyboard configuration without any problem, this either by entering a direct command from xterm "ex: setxkbmap -layout ch -variant fr" or by having it done directly from your KDE/Gnome control center. Unfortunately on OpenSuSE^? and most probably on many other distributions "setxkbmap" will fail to load your map when running it from an LTSP client. This error is comming from an incompatibility of the "/etc/X11/xkb" on your server and on your LTSP client. In order to solve this just replace the LTSP /opt/ltsp/i386/etc/X11/xkb with the one from your server. You may also need a writable directory for compiled keymaps.

 setxkbmap -layout ch -variant fr     ;# not working, hoops !!!
 cd /opt/ltsp                         ;# where ever you installed LTSP
 mv ./etc/X11/xkb ./etc/X11/xkb.ori   ;# backup before any change is alway good
 cp -r /etc/X11/xkb ./etc/X11         ;# replace LTSP map with the one from your server
                                      ;# for OpenSuse 10.2 see following note and insert additional command
 ln -s /tmp ./etc/X11/xkb/compiled    ;# link to writable dir (on client) for compiled keymaps
 setxkbmap -layout ch -variant fr     ;# now it works.

Note for OpenSuse^? 10.2: The above mentioned replacement of xkb didn't work for me. I additionaly had to replace the xkbcomp command. I had to use the ltsp-version of xkbcomp so I had to insert:

 cp ./etc/X11/xkb.ori/xkbcomp ./etc/X11/xkb  ;# worked for me with OpenSuse 10.2

-- VolkerPaul - 30 May 2007

Now that is works dynamically, you can update your lts.conf. Note that on LTSP/4.2 the only variable used is "XkbLayout" and this what ever say lts.conf.readme. Check on your light terminal your X11 config in /tmp/XF86Config.1 to understand how your lts.conf configuration is used to build Xorg config file from i386//etc/build_x4_cfg script.

[10.10.11.105]                 # my terminal IP addr
   LIKE       = tecra-fr       # my generic config
   XkbLayout  = ch(fr)         # my specific keyboard

• Brazil Keyboard has some non-functional keys
• Croatian/Serbian/... Keyboards have a non/functional minus/underscore key
• Swiss German keyboard configuration
• Czech keyboard configuration
• Bulgarian keyboard configuration

Another issue that is common with old motherboards (specially PCCHIPS) is a very high repeat rate (IE you press any key and it gets typed like 30 million times), this seems to be some kind of issue with ACPI, so you just add either to your DHCPD.conf (if using etherboot)

option option-128 e4:45:74:68:00:00; 
option option-129 "acpi=off";

If your dhcpd.conf file already has an option-129 active, just append the acpi=off to it. If instead you have PXE (like the latest versions of rom-o-matic), you just add the acpi=off to the "default" file in the pxelinux.cfg dir (in my system FC4 its at /tftpboot/lts/2.6.16.1-ltsp-2/pxelinux.cfg/default) [thanks to kaminski-ltsp-br in #ltsp for this tip]

Terminal freezes after "pivot_root"

• NFS uses UDP for its communication. UDP does not have handshaking, so in case of lost packets it does not work.
• This problem occures when using cheap 10/100M network switches and 10M network interfaces on terminals. Some switches do not implement queuing correctly or have too short queues and just drop some packets to fit to 10Mbit bandwidth (for example, a Trendnet TE100-S16e does not work correctly). When connecting 10M clients and 100M server to such switches, problems start occuring. At the same time, 100Mbit clients work as intended and when connected through another working 10/100 switch, also 10M clients work.
• Sometimes you may deinstall the kernel nfs-daemon and install e.g. nfs-utils for a nfs server daemon in user space. -- SvenRoth - 18 Oct 2005

Terminal freezes intermittently in X sessions

• This is most noticed when working over a remote X session and most commonly seen when browsing the web on pages that contain large images or detailed images.
• It is caused because the local X session reaches and out of memory segfault. Most likely because there is not swap file.
• Correction of this problem is often as easy as enabling local or network swap files, or if already enabled, to increase the size of the swap file.
• See, Swap, SwapHardDisk, SwapNbd -- KarlBowden - 23 Mar 2006

Terminal freezes consistently in X sessions

• If you get crashes (the console shows but everything is frozen) visiting Flash-heavy sites such as nadaguides.com or hertz.com with i810 video drivers even though your terminal has plenty of RAM, increase video memory with X_VIDEORAM =8192. See VideoCards.

syslogd: cannot write to remote file handle on 192.168.0.254:514

Once the kernel is loaded, and the system is nearly ready to let you log in, it will attempt to establish a connection with the server, to send logging messages to the servers syslog daemon. BUT, most distros are shipped with remote logging disabled. This can easily be fixed by configuring your syslogd on your server to allow remove logging requests.

If you are using the original syslogd, it's usually just a matter of adding the '-r' flag to the syslogd command line. How you do that varies, depending on your distribution of Linux.

Here's some examples of how to configure it on various distros:

Ubuntu

You have to edit the /etc/init.d/sysklogd script and around line 15, you should see a line that says SYSLOGD="-u syslog" You'll need to add a '-r', so it looks like this: SYSLOGD="-r -u syslog"

Debian Etch

You have to edit the /etc/default/syslogd script, you should see a line that says SYSLOGD="" You'll need to add a '-r', so it looks like this: SYSLOGD="-r". If there are additional options between the quotation marks, then tag the '-r' as per the Ubuntu example above.

Redhat RHEL3

There should be a file called /etc/sysconfig/syslog. You need to edit that file, and look for the line that says SYSLOGD_OPTIONS="-m 0", and add the '-r', so it looks like this: SYSLOGD_OPTIONS="-m 0 -r"

SuSE^? 10.0

Uncomment /etc/syslog-ng/syslog-ng.conf.in ll42. Optionally modify the ("0.0.0.0") parameter to your subnet value.

If you have a distro that isn't listed above, then you might have to dig around to see how to change it. Once you get it figured out, please come back and update this wiki entry, so others can benefit from the knowledge.

Boot floppies don't get loaded by the client machines

• Maybe there is some kind of incompability between some floppy drivers. Using an old notebook as a client machine [Texas Instruments, Extensa 510] it was not possible to load a boot ltsp-wireless image from any of the 20 floppies tested generated from a recent machine with a recent floppy driver, either using grub, syslinux (yeah, the '-s' flag was tested too) and directly write at sector 0 (in this case, trying to load directly a kernel image). The solution found was to write the ltsp-wireless image using the own floppy driver of the notebook, transfered to it by network using a poor OS already installed before.

-- RodrigoBaroni - 27 Jul 2005

Another problem on the same topic: some machines have integrated to bios kind of boot sector virus protection. Usually it can be turned off, but on one specific motherboard, the bios crashed when a floppy with a LTSP boot was in drive just after the ram parity check. Upgrading to a newer bios solved the problem.

Miscellaneous tips - What I needed to do to get Edubuntu working on Netier boxes

I'm trying to setup a edubuntu system for a group of homeschoolers at my church. It is turning into an adventure, and I thought I would document some of the problems and workarounds so others can find their way through. Sorry it is not in the proper format, but it is too technical for the "success stories" page, and I can't really separate out the tips or workarounds easily, so I'll leave it as is. Maybe there will be a war-story page added.

Basics: Installed a clean and full edubuntu distribution, upgraded any packages contained, separately upgraded LTSP to the latest 4.1.

For some reason, the nfs mounting section of the initrd wouldn't accept the DHCP supplied NFSROOT environment variable, so it couldn't mount and do the pivot root - it would just drop into a shell. The commands worked manually and the values were set correctly, which I could verify with the shell, and manually mount it using what should have been the correct string (which worked - but the shell script didn't as best I could duplicate). Note - I think the problem is with parsing the environment variables, so that there is additional junk appended to the option root-path string when the mount command occurs, or nfsmount fails in some other obscure way. Since there is no easy provision for editing or rebuilding the initrd, I couldn't modify the nfs mount scripts to find out the exact reason the nfsmount command failed when called from the script.

I got around this problem by specifying the nfsroot in the vmlinuz command line, i.e. in /var/lib/tftpboot/ltsp/pxelinux.cfg, I have it as:

DEFAULT vmlinuz ro initrd=initrd.img nfsroot=10.0.1.7:/opt/ltsp/i386/

10.0.1.7 is my temporary server I'm using to set this up - the value is the same as from the DHCP line.

The X Server didn't come up. I determined it had an S3 Virge card, so S3V might work, but ended up using XF86_SVGA for now. The S3 server didn't work at all, and the S3V managed to create a screen where the mouse would only move on the left half of the screen (but the startup X cursor was in red, so it was using something different). The XF86config parameters probably need some tweaking which I haven't spent much time on since the SVGA server, though slower, works correctly. I would recommend trying the SVGA server before any accellerated servers.

The first problem was that it said it could not find any mouse. I managed to get a USB mouse working, but I had a PS/2 mouse attached.

To Debug I added a /bin/sh line in the sections of startx both where the server would succeed and fail. That way I would have the environment variables and everything else so I could do probes, redirect error messages, and massage the system, environment, and command line until I could get something working. I could have done a SCREEN_02 with a shell (I wish I read that first, but it was easier to hack), but that would not show me the state which caused the failure or what was detected that succeeded. I haven't added a consolechars line to make it 80x50 so I could see more context, but that would be another thing that would help.

I found the hardware probe would not properly detect the PS/2 mouse (Why doesn't LTSP have an override) so I had to edit screen.d/startx to manually modprobe and create the mouse device. There are probably better places to put it, but others I've tried either didn't work or might create more problems (how much do I want to change rc.sysinit).

One problem with these changes is that an update is likely to wipe them out, so I have separate files that I can reinsert if I need them. I also keep backups of the originals.

I also enabled the Netier's disk-on-chip and mounted it (it was a Citrix minimal NT install) since I was doing modprobes and such anyway.

The following section now appears near the top of startx:

=#load mouse modprobe psmouse mknod /dev/psaux c 10 1 #load diskonchip and mount modprobe diskonchip modprobe nftl modprobe ntfs mknod /dev/nftl b 93 0 mknod /dev/nftl1 b 93 1 mkdir /tmp/chipdisk mount /dev/nftl1 /tmp/chipdisk=

With the mouse and SVGA, it came up. But no GDM. Apparently Edubuntu forgot to enable the XDMCP section in the /etc/gdm/gdm.conf file. Change the line Enable=false to Enable=true. You may also want to change the "RemoteGreeter" line (uncomment it) and various other settings, but this will get the greeting screen on the workstation. You may wish to allow more than two logins with "DisplaysPerHost".

At that point I was able to login and get a desktop. Note that I could only get full capability where I logged in first. Gnome seemed to lock some things when I was on the server console, so the icons appeared plain on the workstation - until I exited the server session.

I might try try to install linux directly on the disk-on-chip, this web page has info: http://tlug.up.ac.za/wiki/index.php/Installing_Linux_on_DiskOnChip_Devices

Software that is not friendly for a LTSP environment

For a specific list of bugs in software that makes the software not work well in a LTSP environment, see the page NotLTSPFriendlySoftware.

Troubleshooting Local Device Access

Troubleshooting Local Device Access in LTSP 4.2

Where to go for more help

If you still need help solving your problem, we have a Support page so you can get help from others.

Troubleshooting information for LTSP on openSUSE