Well, the Little Woman’s PC really became flaky and we looked around for alternatives:
“This Tutorial describes the downgrade process you need to run to get back stable after sid upgrade.”
- a new PC
- fixing the old one
- a thin client which I have in a pile…
If she uses a thin client for a while she might like it and we can fix her old one at our leisure. Her flaky PC has a decent CPU but is low on RAM, which was expensive back when it was built. It might take only a new PSU and a couple of sticks of RAM to fix that baby up for a few more years of use. It has a beautiful case and a decent dual-core 64-bit CPU. Taking it off-line will also allow us to switch it to 64-bit software. She had 32-bit because OpenOffice.org wasn’t 64-bit back in the day.
So, I did the LTSP-thing in Debian Jessie and an old thin client worked beautifully, except when it didn’t. It took a while to get rid of an annoying GREEN screen (changed from via to vesa driver). Then it took forever to get X to load (fixed that by switching to openchrome… Choice is good. X now starts in a couple of seconds.). Unfortunately that still crashed occasionally. I was surprised that sound worked immediately. Systemd and pulseaudio did their thing on the thin client and mplayer on Beast spoke “pulse” just fine. But, it seemed that after any interruption, mplayer was denied further connection. It went from perfection to “connection denied”. So, at least two bugs plagued us with Jessie on the thin client and we decided rather than fighting bugs on what is supposed to be a production machine, we would “downgrade” to Wheezy. We know that works… Downgrade sounds so much like that other OS, eh? We are going from beta software to known good software. It works for me.
The downgrade was rather simple as TFA suggests. A few packages were broken. I anticipated that Systemd would break because it is so complex so I removed it before the downgrade. There was also trouble with ACPID, but I managed to fix that with aptitude. apt-get would not do the job. This was done on a chroot in Beast which gets fed to the thin client via PXE-booting with TFTP and NFS for the root file-system. I also downgraded the kernel from 3.16 to 3.2 in case the instability was with the newer kernel. I also obtained the code from Via for their driver just in case we needed to build our own for some reason. They also have archived binaries which match archived Linux kernels…
ls RedHat/7.3/c3It’s all good.
libddmpeg.so via_dri.so via_drv.o via.o via_v4l_drv.o videodev.o
RedHat/7.3/c3/libddmpeg.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
RedHat/7.3/c3/via_dri.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
RedHat/7.3/c3/via_drv.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
RedHat/7.3/c3/via.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
RedHat/7.3/c3/via_v4l_drv.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped
RedHat/7.3/c3/videodev.o: ELF 32-bit LSB relocatable, Intel 8
One thing I noticed while testing this thin client was that loading applications onto the screen was snappy, like 2s, but changing tabs in the browser was very slow like 5s. I’m not sure what that’s about. Beast was not swapping at all. I reduced the screen resolution which made an improvement but it’s still poor. I’ll bet the instability and the slow performance are connected. The thin client was actually running out of memory even though it has 256MB and ordinarily only needed 64MB. It could be something silly like logging to RAM. I’ll figure that out. The audio was beautiful, unlike her previous PC, which had really poor sound. So, she should have 6 year-old performance from Beast on an 8 year-old small cheap computer in place of her 10 year-old PC. Good fun.
The downgraded thin client booted immediately and performed well except now pulseaudio doesn’t run. I get, after configuration tweaks to eliminate other messages,
“root@ltsp194:~# pulseaudio –system
N: [pulseaudio] main.c: Running in system mode, forcibly disabling exit idle time!
E: [pulseaudio] main.c: Daemon startup failed.”
I had a hard time to get it to run with
--system, so I ran it per-user as root and allowing anonymous authentication…
“root@ltsp194:~# pulseaudio –start
W: [pulseaudio] main.c: This program is not intended to be run as root (unless –system is specified).
I: [pulseaudio] main.c: Daemon startup successful.”
Now, it complains and won’t start that way, but this configuration runs, exhibits all normal behaviour but emits no sound…
/usr/bin/pulseaudio --system --exit-idle-time=-1 --disable-shm --no-cpu-limit --resample-method=trivial --high-priority --log-target=syslog -L module-udev-detect -L module-native-protocol-tcp auth-anonymous=1 -L module-stream-restore -L module-rescue-streams -L module-native-protocol-unix auth-anonymous=1 -n
I was doing all this tweaking from Beast. When I went to her office, she was already there using it and she said it’s better than the old machine because the display fits better… ;-). She has a rather wide monitor. I eventually got pulseaudio to run with –system but it never made any sound from the speakers with the downgrade to Wheezy. I’ll give up on that.
Not bad for so little RAM:
root@ltsp194:~# free -m
The thin client and Beast are having a love-in. No crashes, glitches or flawed screen for days now. I just have to fix the configuration of pulseaudio and we’ll be good. It’s refusing connections and squawking about X… It’s just like Lennart to tie X and audio together… He doesn’t get the UNIX philosophy. I could tunnel the audio over SSH but it’s probably just as easy to fix the X-authentication. He was probably thinking there were multiple users and wanted X-authentication to sort them out. Sigh…
Got the X-authentication working but still no sound with Wheezy. No kidding. The player, pulseaudio and ALSA all are happy and still no sound… This is like peeling an onion. In the old days I would just fire up esound and it would work. Simpler is better for me. After returning to this matter, I found the thin client had dead audio-hardware. It died during my set-up just to maximize annoyance. I swapped another client and I had sound by ALSA but not by pulseaudio, and pulseaudio keeps crashing. Crap! I’m now looking at streaming audio from Beast to the client.
Well, the next thing to get working was printing. It turns out that’s not so easy. She was running i386 software because the printer driver is only available from Xerox in that architecture, and an rpm from old releases of Suse and RedHat to boot… I decomposed the rpm with rpm2cpio and set up a file-structure with cpio. Then I moved the files where they needed to go in a multi-architecture installation of cups:386. I set up CUPS for the printer and it worked right away. We can now print from any PC with cups-client installed via lp -d -h -U… I did have to set up /etc/cups/client.conf because otherwise some commandline parameters were ignored… Well, Beast is running beta-software.
I had to tune up xorg.conf on the thin-client’s chroot because DRI wasn’t working at first. It was pretty slow without (VGA compatible controller: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03), really primitive by today’s standards). Now scrolling is pretty snappy although video covering more than 1/4 of the screen at 1024×768 is jerky and makes the system sluggish. She has TVs and other PCs for video anyway, so it’s no great loss. This thin client is for her work computing. Everything but sound is working as expected. I will fix the sound using esound, I guess, and move her files and the ftp server over on her hard drive which is OK. It will be trivial to upgrade her thin client. We could even fix up her old machine and swap it in minutes, just by undoing the xorg.conf stuff.
To sum up: While a couple of things have gone backward: video and sound, she now has the raw performance of Beast not swapping and using 500gB hard drives with 4 AMD64 cores. Compared to 2 AMD64 cores in 32-bit mode, it’s a rocket. Her old machine swapped a bit and was generally much slower although still usable. She’s just fine with the responsiveness of the thin client to the scroll-wheel or clicking the slider or punching Page-Down. Here’s how bad the network gets clogged with some screensavers. I turned those off… Some pages with Flash drive it nuts, though. I could just disable Flash… Network I/O: with her logged in but inactive, it’s taking min: 2.2 KB/s, avg: 4.7 KB/s, max: 10.6 KB/s in and min: 8.3 KB/s, avg: 16.6 KB/s, max: 25.6 KB/s out on eth0 with her active, courtesy darkstat. While browsing MrPogson.com, the input peaked at 170KB/s and the output peaked at 1.3MB/s, just a fraction of the network’s capacity. Maxing out the network connection with dd reached 10.7MB/s to the thin client. So, the bottleneck is the thin client. I made a comment and use of the page was snappy, just a slight hesitation to load a page.
Well, all this for one thin client is a bit much, but with gigabit/s networking and a room full of thin clients, it would be no more work. There are the unmistakable advantages that her thin client uses much less power and is the size of a box of chocolates…