Introduction

Local devices in LTSP5 under Ubuntu gutsy should work out of the box. However, in the event that they don't, here are some procedures to go through to try and get them working.

Step 1: Is the device partitioned?

Because of the way localdevices work under gutsy LTSP5, unpartitioned memory sticks don't work. Try plugging the memory stick into a regular workstation, and looking at the system mounts with the "mount" command. If the stick is mounted as /dev/sda or /dev/sdb only, and not /dev/sda1 or /dev/sdb1, then the stick is unpartitioned. Backup any data off the stick, then use fdisk and mkdosfs to recreate a partitioned memory stick.

Note: By default, memory sticks (either USB or an actual card such as CF or SD) will be partitioned into a single FAT32 partition.

Note2: If the device is formatted with FAT will not work.

Step 2: Is ltspfs installed on the server?

You need the ltspfs package on the server, and _not_ the ltspfsd package. Check this with the following step:

sbalneav@edubuntu:~$ dpkg -l ltspfs | grep ^ii
ii  ltspfs         0.5-0ubuntu2  Fuse based remote filesystem for LTSP thin clients

If you do not get the above returned, then install the ltspfs package using your favorite package management tool, such as Synaptic.

Step 3: Is fuse loaded on the server?

Check and see that the fuse module is loaded:

root@edubuntu:~# lsmod | grep fuse
fuse                   47124  3 

If you don't see the above, then fuse isn't loading. Make sure the packages libfuse2 and fuse-utils are installed.

Also that the /dev/fuse device exists:

root@edubuntu:~# ls -la /dev/fuse
crw-rw---- 1 root fuse 10, 229 2007-08-13 08:48 /dev/fuse

Note that the owner of /dev/fuse is root, and the group is fuse. If they are set otherwise, then try rebooting your machine.

Step 4: Is the user a member of the fuse group?

As a user who you want localdevs to work for:

sbalneav@edubuntu:~$ id
uid=1000(sbalneav) gid=1000(sbalneav) groups=4(adm),...,115(fuse),...,1000(sbalneav)

Note that they have fuse listed in their groups.

Debugging the chroot

The LTSP chroot, is the CHange ROOT environment, so named after the key command that allows us to set it up in the first place, and maintain it afterwards. This directory on your hard drive is what gets mounted as the root drive on the thin client over the network. By default, the only user in the chroot is the root user, because the thin client runs all it's programs on the server, and not on the thin client itself. However, all thin clients are Linux boxes in their own right, and as such, you can use the Control-Alt-F1 key combination to switch to a character console. If you could log in, then you'd actually be executing command on the thin client itself, as opposed to the server. However, we first need to allow a user to log in. We'll do that by setting a root password in the chroot.

Step 1: Setting a root password in the LTSP chroot

Normally, you can't log in on any of the text consoles on a thin client, however, for debugging purposes, you may have to log in. The only user that exists in the chroot is root, so we'll set a root password with:

$ sudo chroot /opt/ltsp/i386
# passwd
<enter password twice>
# exit
$ sudo ltsp-update-image

And set a root password. Then, you should be able to reboot the terminal, and log in on the text console of the terminal.

Step 2: Does the client recognize the plug event

Log in on the text console by pressing Control-Alt-F1, and logging in as root, with the password you just set. Then, plug in a usb device. Run the dmesg command, and you should see something like:

[ 9599.460000] usb 2-1: new full speed USB device using uhci_hcd and address 2
[ 9599.648000] usb 2-1: configuration #1 chosen from 1 choice
[ 9599.884000] usbcore: registered new interface driver libusual
[ 9599.936000] Initializing USB Mass Storage driver...
[ 9599.944000] scsi0 : SCSI emulation for USB Mass Storage devices
[ 9599.960000] usb-storage: device found at 2
[ 9599.960000] usb-storage: waiting for device to settle before scanning
[ 9599.960000] usbcore: registered new interface driver usb-storage
[ 9599.960000] USB Mass Storage support registered.
[ 9604.960000] usb-storage: device scan complete
[ 9604.968000] scsi 0:0:0:0: Direct-Access     USB      Flash Drive      1.12 PQ: 0 ANSI: 0 CCS
[ 9605.076000] sd 0:0:0:0: [sda] 2031613 512-byte hardware sectors (1040 MB)
[ 9605.084000] sd 0:0:0:0: [sda] Write Protect is off
[ 9605.084000] sd 0:0:0:0: [sda] Mode Sense: 37 00 00 00
[ 9605.084000] sd 0:0:0:0: [sda] Assuming drive cache: write through

If so, then the workstation saw the usb device get plugged in. If not, then the kernel on the thin client either doesn't see your usb port, or doesn't like your usb device.

Step 3: Did the ltsp udev rules fire?

If the udev rules are firing, then you should see an entry for the usb device in /var/run/ltspfs_fstab on the thin client:

/dev/sda1 /var/run/drives/usbdisk-sda1 vfat defaults 0 0

If not, then the device wasn't picked up by the LTSP udev rules. Is the device partitioned? See the first step in the document.

If the filesystem is shown as ntfs, then its possible that the stick is formatted with FAT (not FAT32) and will not work:

/dev/sda1 /var/run/drives/scsidisk-sda1 ntfs defaults 0 0

Step 4: Can you manually issue a mount command?

Try the following on the thin client:

ssh -X -S /var/run/ldm_socket_vt7_192.168.0.254 192.168.0.254 "/usr/sbin/ltspfsmounter /tmp add"

Substitute in the name of the ldm socket, and the server ip address. The ldm socket's name is "ldm_socket_<vt number ldm is running on>_<ip address of server>

If this works, then you should have an icon on your Gnome desktop that corresponds to the /tmp directory on the thin client. If it gives an error, then write the error down, and report it EXACTLY to the usual bug reporting channels. Most LTSP developers, and Edubuntu developers (there's a lot of overlap between the two!) hang out in #ltsp or #edubuntu on irc.freenode.net.