intel drivers on CentOS 6

Furthermore, to get X working nicely on a Shuttle DX30 with CentOS 6, you have to install a newer intel driver:

yum install libpciaccess-devel.x86_64 xorg-x11-server-devel.x86_64 libXfont-devel.x86_64 libXfont2-devel.x86_64
git clone git://anongit.freedesktop.org/xorg/driver/xf86-video-intel
cd xf86-video-intel
git checkout d39197bb10b7d88cb4c456e7a5e8d34c1dc6eeaf
autoreconf -i
sudo mv /usr/lib64/xorg/modules/drivers/intel_drv.so /usr/lib64/xorg/modules/drivers/intel_drv.so.ORIG
sudo rsync -a ./src/.libs/intel_drv.so /usr/lib64/xorg/modules/drivers/intel_drv.so

(Copied from https://www.centos.org/forums/viewtopic.php?t=64780)


CPUs are computers

So I wanted to get a Shuttle DX30 working under LTSP. First step, it uses a pxe-client-id that's 9 bytes long. CentOS's dhcpd throws away anything that doesn't have a 17 byte pxe-client-id. I have no idea why. I tried poking around the RFCs but didn't find much of interest.

Once I patched dhcped, PXE booting worked and I managed to load a kernel. Except it was slow.





Just how slow? It took over 30 minutes to get to a XDM prompt slow.

I saw Machine check events going past. To track those down, I put my laptop's 2.5 inch HDD into it. This was also slow. While not as bad, it was clearly not working properly. But I got mcelog to grab the following:

mcelog: failed to prefill DIMM database from DMI data
mcelog: mcelog read: No such device
Hardware event. This is not a software error.
ADDR fef5d200 
TIME 1531800239 Tue Jul 17 00:03:59 2018
MCG status:
MCi status:
Error overflow
Uncorrected error
MCi_ADDR register valid
Processor context corrupt
MCA: Internal unclassified error: 408
Running trigger `unknown-error-trigger'
STATUS e600000000020408 MCGSTATUS 0
CPUID Vendor Intel Family 6 Model 92

After some messing around, cursing the Gods, discussing Intel NUCs on #ltsp, general lack of sleep, I found the solution : kernel-ml

yum -y  --enablerepo=elrepo-kernel install kernel-ml
joe /etc/grub.conf # set default=0

It should be noted it took over 10 minutes for dracut to create the initrd for kernel-ml. But once I then booted into the new kernel, everything was fine. I installed kernel-lt as a test, because it needs the CPU and the disk to run smoothly and it took 2 minutes, which is annoying but expected. For reference, installing kernel-ml on my desktop takes 1.5 minutes but it has an SSD.

kernel-lt was a failure, 9m54 to install kernel-ml-4.17.5-1.el6.elrepo.x86_64. I booted back into kernel-ml, removed and reinstalled kernel-ml-4.17.5-1.el6.elrepo.x86_64 and it took 1m52. So kernel-ml is the clear winner.

Now to find out how to install kernel-ml into LTSP.


upstart after rc

I run daemontools from upstart. I ran into a problem that one of my daemons needed dbus to be working, but upstart was starting daemontools before rc had a chance to start it. The bigger problem is that CentOS 6 is only a partial conversion to upstart in that it still uses rc files for most things.

I used to have start on runlevel [345] in /etc/init/daemontools.conf but that means daemontools is started at the same time (or even before) as rc.

I tried start on started rc but that means daemontools runs after rc is launched, not after rc has finished.

The solution is a custom event :

cat <<'SH' >/etc/init.d/rc-done
# rc-done Emits events when rc has finished or nearly
# chkconfig:   2345 99 01

[ -e /etc/sysconfig/rc-done ] && . /etc/sysconfig/rc-done

case "$1" in
 initctl emit rc-done
 initctl emit rc-start
        echo $"Usage: $0 {start|stop}"
        exit 2
exit $?
chmod +x /etc/init.d/rc-done
chkconfig --add /etc/init.d/rc-done

Now we put start on rc-done into daemontools.conf

Of course the interesting part is initctl emit rc-done. We could just as easily have put that at end of rc.local.


gmail G3 SSL certs

The error messsage:

fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: This means that the root signing certificate (issued for /C=US/O=Google Trust Services/CN=Google Internet Authority G3) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
139677826279240:error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed:s3_clnt.c:1178:
fetchmail: SSL connection failed.
The solution:
cd /your/sslcertpath
wget https://pki.goog/gtsr1/GTSR1.crt
wget https://pki.goog/gtsr2/GTSR2.crt
wget https://pki.goog/gtsr3/GTSR3.crt
wget https://pki.goog/gtsr4/GTSR4.crt
wget https://pki.goog/gsr2/GSR2.crt
wget https://pki.goog/gsr4/GSR4.crt
for n in *.crt ; do openssl x509 -in $n -out ${n/crt/der} -outform DER; done
for n in *.der ; do openssl x509 -in $n -inform DER -out ${n/der/pem} -outform PEM; done
c_rehash .
killall fetchmail


Uptstart and Digi Etherlite 32

Here's how to get your Etherlite working with upstart. But really, this technique would apply to any serial connection.

First we need /etc/init/dgrp.conf.

# Digi EtherLite
# Starts a agetty for each serial port
# Normally run from the start-dgrp.conf task

stop on runlevel [S016]

env TERM=vt100
env BAUD=19200
instance $ID
exec /sbin/agetty -L tty$ID ${BAUD:-19200} ${TERM:-vt100}

usage 'dgrp ID=XX [BAUD=YYYYY] [TERM=ZZZZ]  - where XX is terminal id (A10) and YYYYY is baud (12900) and ZZZZ is the termcap entry (vt100)'

You can test this by starting an agetty on ttyA01 with:

initctl start dgrp ID=A01

Stop it with:

initctl stop dgrp ID=A01

Now create /etc/sysconfig/dgrp. Each line is the ID with an optional baud rate (default 19200) and TERM (default vt100) setting:

A02 9600 vt100
A10 19200 wy60

Now we create the controlling task. This gets run after rc?.d is finished. It reads /etc/sysconfig/dgrp and runs dgrp.conf where needed.

# Digi Etherlite
# This task will read /etc/sysconfig/dgrp and will run dgrp.conf for each line in it
# It is run after all rc?.d the scripts are run

start on stopped rc RUNLEVEL=[2345]

env CONFIG=/etc/sysconfig/dgrp
    test -f $CONFIG || ( logger -t start-dgrp.conf "$CONFIG doesn't exist"; exit 0 )
    test -d /proc && test -d /proc/dgrp || ( logger -t start-dgrp.conf "drpd daemon is not running" ; exit 3 )

    temp=$(mktemp --tmpdir)
    grep -v '#' $CONFIG >$temp

    while read ID BAUD TERM ; do
        ID=$(basename $ID)
        initctl start dgrp ID=${ID/tty} BAUD=$BAUD TERM=$TERM
    done < $temp
end script

We use a temporary file so that we can ignore comments in the dgrp config file.


Far to many spelling options in Thunderbird and Firefox

Mozilla projects offer to check the spelling in every language installed on your computer. Which is great, except I don't need South African English, nor will I ever use Swiss French. And wading through the 20 items in the menu to switch from Canadian English to Qu├ębecois French is annoying.

And there is no easy way to fix this.

The hard way is to go into /usr/share/myspell and remove all the .dic and .aff files you don't want.

$ sudo su -
Password for fil@scott: 
# cd /usr/share/myspell/
# mkdir NOT
# mv *.dic *.aff NOT
# ln -s NOT/fr_CA.aff
# ln -s NOT/fr_CA.dic
# ln -s NOT/en_CA.aff
# ln -s NOT/en_CA.dic
Restart Thunderbird and you will now have 2 spelling options.

Yes, these changes are system-wide. There is currently no other way to do it, apparently.


vmware-vdiskmanager and CentOS 6

This is how you install vmware-vdiskmanager on CentOS 6. I needed to do this so I could read my old vmware-server vmdk.

First go this old KB article and download 1023856-vdiskmanager-linux.7.0.1.zip. It's at the bottom, in the Attachements section. Now you do the following little dance:

unzip 1023856-vdiskmanager-linux.7.0.1.zip
cp 1023856-vmware-vdiskmanager-linux.7.0.1  /usr/local/sbin/vmware-vdiskmanager 
chmod +x  /usr/local/sbin/vmware-vdiskmanager
yum -y install zlib.i686 glibc.i686 openssl098e.i686
md -pv /usr/lib/vmware/lib
cd /usr/lib/vmware/lib/
ln -s /usr/lib/libcrypto.so.0.9.8e 
ln -s libcrypto.so.0.9.8e libcrypto.so.0.9.8 
ln -s libcrypto.so.0.9.8e libcrypto.so.0
ln -s libcrypto.so.0.9.8e libcrypto.so
ln -s /usr/lib/libssl.so.0.9.8e
ln -s libssl.so.0.9.8e libssl.so.0.9.8
ln -s libssl.so.0.9.8e libssl.so.0
ln -s libssl.so.0.9.8e libssl.so

That fucking around in /usr/lib/vmware/lib is because even though VMware claims this is a static binary, it in fact dynamically loads crypto libraries at run time from non-standard places.

You can now convert your split vmdk to a single file and mount it:

vmware-vdiskmanager -r sda.vmdk -t 0 sda-single.vmdk
modprobe nbd max_part=8
qemu-nbd -r --connect=/dev/nbd0 sda-single.vmdk
kpartx -a /dev/nbd0
vgchange -a y YOURVG
mount -o ro /dev/mapper/YOURVG-YOURLV /mnt

Aren't you glad you created a unique VG for each of your VMs?

To unmount:

umount /mnt
vgchange -a n YOURVG
kpartx -d /dev/nbd0
qemu-nbd -d sda-single.vmdk