Tuesday, April 1, 2014

Windows 8.1 in KVM

As Windows XP comes to its end of life, I have to get with the times and test my windows programs in Windows 8.1.

Naturally I am drawn to KVM which is where I run all my Windows instances.

Despite some initial concerns regarding the lack of the +sep flag (covered in my winpe pxe blog), installing Windows 8.1 turned out to be a breeze. I just used the settings for Windows 7 64bit.

After the install I was prompted to log. I have no interest in using a 'Microsoft Account' so I used the obscure procedure of 'Don't have an account' -> 'Sign in without a Microsoft account' which would be better described as 'Create local account'.

The next confronting issue was the start menu or whatever they call it these days. I worked out that I should not to look at it, just to start typing. That works more or less the same as the 'search' on Windows 7 (but possibly faster. It makes by mind boggle that it can take so long to run cmd.exe on Windows 7).

Once I had the basics under control, I set about installing the VirtIO & Spice drivers for extra performance and GUI features (like screen resizing). Alas, spice-guest-tools-0.74.exe does not support Windows 8 and fails during the install complaining about an unsupported version of Windows.

I know the virtio drivers work because I have used them in WinPE so I set about installing them manually. Although they are compatible, installing them is not straight forward.

The driver files are made available under Program Files (x86)\SPICE Guest Tools

The method I normally use is to use guestfish to install the driver file and configure it in the Critical Driver Data Base (CDDB) using a registry patch. Windows 8 no longer has a CDDB so this method does not work.

In the end I reverted to an old method:
  • Add a new (temporary) VirtIO disk to the VM
  • Boot into Windows
  • Install the drivers for VirtIO
  • Shut down windows
  • Remove the temporary disk
  • Change the main disk from IDE to VirtIO
This method works much like it has since Windows 7 allowed changing of the boot path.

The VirtIO network seems to work fine.

Talking to a Samba sever required adjusting some settings. First there are some updates which are apparently required (according to Microsoft) so I make sure all the OS patches were installed first.

Next I adjusted some policy settings under Administrative Tools -> Local Security Policy -> Local Policies -> Security Options:
  • Network security: LAN Manager authentication level = Send LM & NTLM - use NTLMv2 session security if negotiated
  • Network security: Minimum session security for NTLM SSP based (including secure RPC) clients = No Minimum
Then restart the workstation service or reboot.

Finally, the graphics drivers. For reasons which don't seem to be explained, the QXL video driver is not compatible with Windows 8.1. The performance of the 'Microsoft' driver is not too bad but it means no resizing which is annoying.

I am hoping that the spice people make their drivers and installer work soon.

One final observation is to do with the windows version number. Windows 8.1 is NT 6.3 but unless your program is manifested for windows 8.1, you will get the version number 6.2. This is by design. Some kind of new design which means the the GetVersion... API has been deprecated. What are they doing over at Microsoft???

Tuesday, January 28, 2014

OpenSCAD for CentOS 6

I am thinking about getting a 3D Printer but before jumping in, I wanted to test out some software to see how hard it is to drive these things.


It was suggested that I check out OpenSCAD, the programmers 3D CAD program.

As usual, for CentOS-6, it did not exist. Building it was tricky and required a bit of finesse. You can download my beta build and dependencies from http://www.chrysocome.net/download

Installation Instructions

Note: gmp 5.0 is named gmp5 so it can co-exist with the system version 4.3
Note: mpfr 3.1 is names mpfr3 so it can co-exist with the system version 2.4
yum install gmp5-5.0.5-3.el6.x86_64.rpm mpfr3-3.1.0-2.el6.x86_64.rpm CGAL-4.1-1.el6.x86_64.rpm opencsg-1.3.2-6.el6.x86_64.rpm openscad-2013.06-8.el6.x86_64.rpm --enablerepo=epel

I also need to make sure that the MCAD libraries are correctly packaged. I'll try and make an updated version soon.



FreeCAD is a more traditional click and draw interface which is apparently very good and has many features. It can also be scripted with python. RPMs are available from RPM Fusion Nonfree


I need a lot of practice before I will be making any 3D objects!

Friday, January 17, 2014


On my old TV setup I used nvclock to get the NVIDIA GPU temperature and graph it using rrdtool (along with other temperatures and fan speeds).

nvclock was always a bit of a hack and does not work any more (at least, it won't do anything useful for me).

I know the nvidia-settings tool can display the temperature (and much more information) so there must be a modern way to access this data. A quick google showed up the nvidia-smi tool.

Quick and dirty,
nvidia-smi -q | grep Temperature -A 1
will show the current temperature.
        Gpu                     : 72 C

Interestingly, the output can also be in XML format. Combined with some xslt magic, it is possible to get the temperature in a more structured way.
echo '<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output method='text'/>
<xsl:template match="/">
<xsl:for-each select="//gpu_temp">
<xsl:value-of select="."/>


' > nvidia-temp.xml
nvidia-smi --dtd > nvsmi_device_v6.dtd
nvidia-smi -q -x | xsltproc nvidia-temp.xml -

Note: Your driver might be using a different dtd version. Adjust as required. (nvidia-smi --dtd | head -1 | cut -d ' ' -f 2 will give the correct name)

If you have multiple cards and want to know which card has which temperature then you can alter the xsl to format it as you require with something like
<xsl:value-of select="ancestor::gpu/@id"/> or <xsl:value-of select="ancestor::gpu/uuid"/>
0000:04:00.0 Quadro K2000 31 C
0000:05:00.0 Quadro K2000 32 C

Friday, January 10, 2014

The new TV is almost here

Now that summer has hit, it is time to head indoors and tinker with the TV. Some clever planning when I last upgraded the disk in my CentOS-4 machine meant that the required partitions and space for CentOS-6 was available without having to alter anything.

That meant that installing CentOS-6 was relatively easy. (I did it the hard way and PXE booted off the work server via VPN). After a minimal install I configured the machine in puppet and managed to leverage most of my Linux SOE config.

After that was finished, I had a workstation but not a TV. Next step XBMC. That installed without any trouble but would not play any audio and the video kept going choppy. Not what I was expecting.

The choppy video was being caused by high load caused by the sosreport program. I don't know what crashed, and I don't much care. There is no point sending me an email about it.

I remember wrestling with this in the past without any satisfactory result. This time, rpm --erase sos did the trick. (I have to make sure puppet does not put it back.).

The audio seemed to be a problem with PulseAudio. I don't much care for this either. I have never needed it before and it does not appear to support S/PDIF / EC958 which I need so it has to go. Once again, no satisfactory instructions so rpm --erase alsa-plugins-pulseaudio seems required.

After a restart (I hate that!), all traces of pulseaudio are gone and XBMC is offering me S/PDIF again. Audio and video now working.

Next hurdle, Remote Controls. I have lots of experience with LIRC in the past because I had to make some modifications to the old version to get it to do everything I wanted. As hoped, there has been some improvement in this area but alas, also some steps backwards.

The first remote is a DVICO Fusion remote. This is a supported model but requires configuration in /etc/sysconfig/lirc and /etc/lirc/lircd.conf
/etc/sysconfig/lirc wants to know the device but it is a dynamically assigned USB HID device. This means UDEV rules ahead. It would be ideal if LIRC came with these but it seems not. Luckily I have my old EL4 rule but the new new udev uses a new format for rules. This was what I came up with in the end:
SUBSYSTEM!="usb", GOTO="end"
KERNEL!="hiddev*", GOTO="end"
ATTRS{idVendor}=="0fe9", ATTRS{idProduct}=="9010", SYMLINK+="dvico"

Now I can configure lirc and it should work reliably (unless I have two receivers, which I do but I only use one!).

Copy the lircd.conf config file from the files supplied in lirc-remotes and that is ready to go.

It seems I still need to build a Lircmap.xml file for XBMC before it will work there. Lets hope I can find a sample on the internet. Writing XML by hand is not what I call fun.

The next challenge with LIRC is my IR Blaster which controls the stereo. This uses the kernel driver called lirc_serial. I understand that this is not an enterprise solution but if lirc_dev can be in the kernel, why no lirc_serial? Well, no worries, perhaps I'll find a package which has the driver. I do require that the driver will work after a kernel update so the atrpms package is no good. And is is only version 0.8 and I am using LIRC 0.9 (may not be an issue but I want them to match).

I guess I'll just build one myself.  Enter a world of 'lirc_serial: disagrees about version of symbol' errors. Briefly, some lirc drivers are now in the EL6 kernel. lirc_serial depends on lirc_dev. The lirc_dev in the kernel is back ported so checking kernel version numbers for the correct API does not work reliably. Also, modversions seem to be cached so once the errors are fixed, the resulting module still does not work.

Finally, I abandoned the LIRC build scripts and went straight to the kernel Makefile. After tweaking a few #defines I had a working build. I then packages in into an elrepo style kmod package and now I have a working ilrc_serial driver (which you can download from http://www.chrysocome.net/download). LIRC does not come with the definition for Panasonic remotes but I have the old one on hand which still works (yay). The LIRC init script does not handle starting multiple instances so I will have to hack that up too. At least I can specify the location of the .pid file which I think was a show stopper in the old version.

The next job is to work out if I can use my IR Blaster to turn the TV on too. For a SMART TV, there are not many options for turning it on...

Tuesday, December 31, 2013

musescore - sheet music on linux

Recently I was helping a friend who had written a song. We wanted to produce some sheet music so I though it would be worth checking out any open source music authoring software.

Many years ago I looked at software in this space and some promised much but in the end, none seemed to deliver on any front. At that time, shareware windows software was all that could be found.

This search was a lot more successful. It did not take me long to find MuseScore. This is a cross platform, open source sheet music editor (with playback). The windows version worked out of the box and we soon had the basics mastered; chords, notes, repeats, lyrics etc.

My next instinct was to get it to work on Linux, specifically CentOS-6. After installing a few requirements from rpmforge, I had the code compiled and running (with just a few minor bugs). Once I know that it worked, I wanted to make an RPM. Unfortunately, musescore (or mscore as it is called under Linux) uses an unusual build procedure based on cmake. Adding that into an RPM seemed a little daunting so I found the closest thing I could on the internet to use as a starting point.

Opensuse has an RPM but it would not build on CentOS. After a few simple tweaks I had the package building but it was not being packaged correctly. The %makeinstall macro was trying to install files into the filesystem and not the package buildroot. After much internet searching and testing, I found the answer (which is quite simple. So simple I don't know why no one had written it down before).

The same as you might use for a normal Makefile, just set the DESTDIR environment variable. My %install now has:
export DESTDIR=%{buildroot}
cd build && %makeinstall

And with a few more minor tweaks I had the RPM finished.

Now I just have a few issues to sort out with playback on Linux. musescore does not like the default ALSA settings or ALSA devices (like my USB headset) disappearing and reappearing when I suspend and resume. Portaudio might fix that but it does not seem to work on my home machine.  The topic for another blog no doubt.

Sunday, December 22, 2013

Lazarus has come to life

Most of my windows programming is still done in Delphi 5. This was released in 1999 which makes it positively ancient. (Even more scary is that some programs started life in Delphi 2).

Not long after Delphi 5, Borland lost the plot (or prehaps they already had when they changed their name to Inprise). Although Delphi 7 was available, when I looked up upgrading the .net experiment was under way and it seemed like the end of the road for Delphi. I had hoped for a cross platform modern version to appear but that never really happened. Eventually the crazy was transferred to Embarcadero (whatever that is) and I still don't understand what works with what.

While all that was going on, I kept an eye on another program, Free Pascal. Free Pascal always showed such promise but the IDE was reminiscent of programming c++ under DOS.

Finally it seems though, I might have found what I have been looking for.  Lazarus, the Delphi styled IDE for Free Pascal. Matured enough for a 1.0 release and soon to be 1.2. Native unicode support and cross platform (Linux, Windows, OS-X).

Although there are a few sharp corners (don't import a unit called strings!), I am planning on converting my projects over to Lazarus and hopefully bringing them back from the dead too. My initial testing has been positive.

With any luck my programs will be playing nice with Windows 7, running on Linux and being recompiled without having to pay any license fees. It has taken a long time but I think it has been worth it.

Now if I could just press for Android support too...

Thursday, November 21, 2013

CentOS 6 on Apple hardware

I don't know how long Apple have been using intel hardware. I have never owned or used any and I know pretty much nothing about OS-X.

Inevitably, a user asked me if they could have Linux on the their mac. They have both a MacBook Pro and in iMac. I said I would look into it and my findings are listed below.

There are two main areas which cause trouble installing on to Mac hardware, drivers and booting. Drivers is relatively easy. Most hardware is supported by recent OS versions. Booting is much more complex. UEFI, GPT, 64bit support, bootcamp and rEFIt are all intentionally shrouded in mystery and made unnecessarily complex.

The aim is to leave a working OS X install for admin tasks but boot into linux for every day use. The starting point is a working OS X install with GPT partitioning.

MacBook Pro 7,1 (13-inch, Mid 2010)

Status: Not Supported

The Nvidia MCP89 is not supported. This means no hard disks to install onto.
There are a number of setpci commands floating around the internet which promise to activate the chipset as an AHCI controller. None of the commands I tried could get this to work.

Some other observations:
CentOS 6 UEFI boot did not work. The GRUB menu works but it will not boot any entries. Escape will return you to the menu. Entering quit on the command line will take you back to the OSX boot environment (I was using rEFIt).

I wanted to use our corporate PXE boot environment. I burned an iPXE boot CD which worked once. It successfully booted into pxelinux and booted CentOS-6 installer. After the initial success, I could not get it to work ever again. It would lock up after prompting to press ^B.

iMac 27"

Status: Supported (using bootcamp and rEFIt)

Installation was a bit involved and seems to vary depending on the current version of OS X and bootcamp. The procedure was:
  • Boot into OSX
  • Install rEFIt (not rEFInd) (and reboot two times to activate)
  • Run bootcamp (because we will not use EFI booting)
  • Create a fat32 filesystem to keep bootcamp happy
  • Boot off a CentOS-6 CD
  • Remove the fat32 partition
  • Create a /boot partition (/dev/sda3)
  • Create a LVM partition (/dev/sda4)
  • Select /dev/sda as the boot loader location
  • Complete the install and reboot
  • Boot into the CD rescue mode
  • open a shell
  • chroot /mnt/sysimage
  • grub-install /dev/sda
  • parted /dev/sda
  • toggle 3 legacy boot
  • quit
  • exit
  • exit
  • reboot
  • Open rEFIt partition tool
  • Synchronise partition tables
  • Boot linux from rEFIt
  • Install ATI binary video drivers
  • Done

iMac 7,1 (20-inch, Mid 2007)

Status: Supported (using rEFIt)

Installation was done using our PXE network install. Substituting a CentOS Install CD for iPXE would presumably also work.
  • Boot into OSX
  • Install rEFIt (and reboot two times to activate)
  • Boot into OSX
  • Run the Disk Utility
  • 'Partition' the disk and change the size of 'Macintosh HD' to make room for linux (I used 50Gig)
  • Download iPXE and burn to CD
  • Reboot into rEFIt
  • Boot of iPXE CD (by selecting the CD icon from rEFIt)
  • PXE boot into the CentOS-6 installer
  • Select 'Use free space'
  • Install boot loader to /dev/sda
  • Complete the install and reboot
  • Reboot into CentOS rescue mode
  • open a shell and run these commands:
  • chroot /mnt/sysimage
  • grub-install /dev/sda (probably not needed if grub was installed to /dev/sda during the install)
  • parted /dev/sda
  • toggle 3 legacy boot
  • quit
  • yum update (there seems to be a bug in the kernel/initd shipped with 6.4 where a fresh install can't find the hard disk. Fixed with an update)
  • exit
  • exit
  • reboot
  • Open rEFIt partition tool
  • Synchronise partition tables
  • Boot linux from rEFIt
  • ATI binary video drivers are not compatable
  • Done


It is possible to run CentOS on your Mac. The procedure is complex and unpredictable.

I will update this page if I identify any ways to simplify the process.