We have been running a thin-client setup in the office for a number of years now as we’ve found them to be easier to maintain, and it allowed everyone to login on any PC and access their work. Our thin-clients were all desktop PC-based machines with Gigabit Ethernet and no storage.

However, the machines are getting old (some were close to a decade old) and were starting to show signs of age. So, we had to get some replacements and we decided to replace them with Raspberry Pi’s. Before buying the Pis, we tested the idea out with some Raspberry Pi 1Bs and 3Bs that we had in the office.

From the software perspective, the LTSP setup on this wiki page was spot on. We were able to immediately boot up our Pi thin-clients. The 1B model is too slow to be used as a thin-client. The 3B model was pretty decent as a thin-client except when one had to play videos. In those cases, the network bandwidth was saturated at about 80Mbps.

Therefore, we ended up buying a bunch of 3B+ Pis that had a more generous network bandwidth of up to 300Mbps as our entire office network was on GigE. We had assumed that getting LTSP to boot on the 3B+ models would be just a matter of swapping the micro-SD card over from the 3B test unit. Unfortunately, this was not true.

The issue is that the 3B+ models use a different network chip and the built-in kernel provided by the LTSP setup we had, did not have the drivers for the new chip. Therefore, it was having trouble booting up from the network, which defeats the whole purpose of using the 3B+ as a thin-client.

However, instead of having to roll-out our own kernel, all we had to do was to instruct the build-process to load the necessary drivers in the initrd part of the boot process. This can be achieved by editing a single file and rebuilding the initrd image. So:

# export FLASH_KERNEL_SKIP=true
# ltsp-chroot -ma armhf
# nano /etc/initramfs-tools/modules

The correct drivers that need to be loaded are microchip and lan78xx modules. This can be done by adding the following lines to the file above.


Finally, we will rebuild the initrd and updating the copy in the tftp directory.

# update-initramfs -u
# exit
# ltsp-update-kernels armhf

The newly generated initrd.img needs to be copied to the micro-SD card, replacing the existing one already there. Then, reboot the Pi and watch it boot up as a LTSP thin-client.

However, our problems didn’t end there. There turned out to be an issue with PulseAudio as well. For some reason, our Raspberry Pi LTSP clients don’t seem to have any audio hardware even though we have enabled the necessary settings in config.txt and also verified from the command line, that the hardware actually exists.

It turns out that there is a race condition or timing issue. The audio drivers for the Pi are usually loaded by the standard module loading mechanism during init stage of the boot process. However, for some reason, PulseAudio actually gets loaded before the device has been properly initialised.

It took us a while to debug this issue but once it was discovered, it was a fairly simple thing to get the drivers to be loaded earlier, during the same initrd stage earlier. This meant adding a few more modules to the file above:


Rebuilding our initrd image and replacing the one in the micro-SD card, made it work.

Now, we have Raspberry Pi 3B+ LTSP thin-clients that are capable of watching videos (within limitations) and 3D rendering (within limitations) and working Audio as well. This was all we needed for our office use-case.


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.