2018/07/30

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
./configure
make
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)

2018/07/17

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.

Very.

Very.

Very.

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.
MCE 0
CPU 0 BANK 4 
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
MCGCAP c07 APICID 0 SOCKETID 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.

2018/06/08

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
#!/bin/sh
#
# 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
    start)
 initctl emit rc-done
        ;;
    stop)
 initctl emit rc-start
        ;;
    *)
        echo $"Usage: $0 {start|stop}"
        exit 2
esac
exit $?
SH
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.

2017/12/08

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

2017/08/31

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
respawn
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:

A01
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
task
script
    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.

2017/08/29

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.

2017/05/10

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
vgscan
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