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

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

Conclusion

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.

XBMC on CentOS 6

After years of putting it off I have finally taken the plunge into XBMC.

My plan is to hook it up as a front end for the Digital ORB pvr.

RpmFusion have packages for XBMC version 11 for CentOS 6. This is a good start as many of the audio & video packages from RpmForge (which I am sure most CentOS 6 users have) are too old for XBMC.

Unfortunately there is no package for XBMC version 12 which apparently has much better pvr support. The bug database entry suggested that it would be relatively easy to fix... and it was https://bugzilla.rpmfusion.org/show_bug.cgi?id=2699

So now I have a relatively stable base to start my integration. Lets hope that I get it working before XBMC version 13 comes out and changes everything again.

If you want to run XBMC yourself, you will need my xbmc and taglib packages from http://www.chrysocome.net/downloads and any dependencies from rpmfusion and epel.

You can also get the Digital ORB from my downloads directory. It does come with instructions but has not been widely tested yet. Stay tuned.

Large filesystem on CentOS-6

I had the pleasure of testing out a new server which came with 10 x 4Tb drives. Configured on and HP Smart Array P420 in RAID 50 that gave me a 32Tb drive to use.

I installed CentOS-6 but the installer would not allow me to use the full amount of space. It turns out the maximum ext4 filesystem on CentOS-6 is 16Tb. This is the limit of 32bit block addressing and 4k blocks. (2³² * 4k = 2³² * 2¹²= 2⁴⁴=2⁴⁰ * 2⁴ = 16T)

That did not make for a very exciting test. Only half the disk available was available in a single filesystem. Sure I could create two logical volumes and then create two filesystems but that seemed a bit like a DOS solution.

Some research turned up the options of using ext4 48bit block addressing. This enables a filesysem up to 1Eb in size and allows for future 64bit addressing for an even larger limit.

The catch was of course that 48bit addressing is not supported by the tools which come with CentOS-6.

Fedora 20 (rawhide) does come with the required updates to e2fsprogs (e2fsprogs-1.42.8-3) which enable 48bit addressing (somehow future-proofed by being called 64bit addressing).  I then set out to rebuild the fedora 20 rpm for CentOS-6. Amazingly the compile was clean though I did have to disable some tests which is a tad alarming. All in all it did not take long to produce a set of replacement rpms for e2fsprogs.

After installing the new tools I was able to create a new filesystem larger than 16Tb. I started at 17Tb to give me room to play. It seems that the CentOS-6 kernel does already have support for 48bit addressing. I ran a number of workloads and I could not find any problems. Still, I don't know what bugs may be lurking in there.

dumpe2fs shows the new filesystem feature '64bit'.

I also attempted to do an offline resize of the filesystem to the maximum size of my disk. This just worked as expected. Online resize is not available until a much later kernel version. I did not attempt this because there are know bugs.

The last limit I wanted to test was the file size limit. Even on my new filesystem the individual file size limit is 16Tb. It is not every day that I get to make one of them so I did
 dd if=/dev/zero of=big bs=1M count=$(expr 16 \* 1024 \* 1024)

At ~500Mb/s it still took 9 hours to complete.
And it turns out that the maximum file size is actually 17592186040320 and not 17592186044416. That is 4k (one block) short of 16Tb. (You can actually check that on any machine with the command truncate big --size 17592186040321 )

That also raised an issue which was a problem on ext3. How long does it take to delete a large file? Well this is the largest possible file and it took 13 minutes.

In conclusion, the 16Tb filesystem limit is easliy raised on CentOS-6 but it comes at the expense of using untested tools and kernel features. Although I did not find any problems in my testing, this could pose a substantial risk if you have over 16Tb of data which you do not want to loose.

If anyone is interested in my rpms you can get them from http://www.chrysocome.net/download

Windows 8?

My first brush win WinPE turned out to be rather successful http://blog.chrysocome.net/2013/02/pxe-boot-winpe.html but recently our Windows team upgraded the SCCM server. Now when I attempt to install Windows 7 in KVM on CentOS-6, I get a windows 8 logo and then the dreaded error 0x0000005D.

The cause for this is, as always, long and complex. The new SCCM release now uses WinPE version 4 which is bases on Windows 8. Windows 8 requires a minimum level of CPU features to run. If you don't meet the minimum you get a well worded error message (well, at least it is easier to search for than a BSOD report).

I can't do much about SCCM, WinPE or Windows 8 so the next part of the problem is why does my KVM virtual machine not meet the Windows 8 requirements?

You guessed it. Bugs! It seems (more or less) that the 'sep' cpu feature was forgotten by libvirt and there is no fix coming soon.

What is needed then is a well implemented work around. KVM does support the required flag (-cpu +sep) but libvirt has no method to pass the flag to kvm. I already have a wrapper around kvm http://blog.chrysocome.net/2013/05/can-kvm-guest-found-out-who-its-host-is.html so it seemed logical to extend that script to add the missing flag.

Below is my solution which adds the +sep flag to the existing CPU configuration as well as set the serial number, as per the original script. Installation is the same as shown in my other blog post, edit the guest and set the <emulator> path to /usr/local/libexec/qemu-kvm (either using virsh edit or your favourite XML editor).

/usr/local/libexec/qemu-kvm
#!/bin/bash
# This is a wrapper around qemu which will supply
# DMI information
# and correct a bug with the CPU type required for winpe4 (Windows 8)
max=${#@}
index=0

for i in $(seq 1 $max) ; do
   p=${@:$i:1}
   if [ "$p" = "-cpu" ] ; then
      (( index = $i + 1 ))
      break
   fi
done

if [ $index -gt 0 ] ; then
cpu=${@:$index:1}
cpu="$cpu,+sep"

(( ibefore = $index - 1 ))
(( iafter = $index + 1 ))
set -- "${@:1:$ibefore}" $cpu "${@:$iafter}"
fi

if [ "$1" = "-name" ] ; then
    SERIAL=$(/usr/bin/hal-get-property --udi /org/freedesktop/Hal/devices/computer --key system.hardware.serial)
    exec /usr/libexec/qemu-kvm "$@" -smbios type=1,serial="KVM-$SERIAL"
else
    exec /usr/libexec/qemu-kvm "$@"
fi

Using xorg without a mouse

I always like it when I learn something new. Particularly when I read something one the web which turn out to work.

I wanted to find a way to move the mouse cursor without a mouse. I can actually do this with my lirc based remote but I have a new wireless keyboard for my linux 'TV' and I wanted to have a way to use that too.

A google search turned up an interesting page which suggested the X.org has this functionality built in and to my surprise it worked. It even had instructions for keyboards without a numeric keypad (like mine). Apparently "MouseKeys" and "PlotMode" has always been a feature in X.org and XFree86.

I must be in PlotMode at the moment which is quite slow. I will have to practice enabling Accelerated mode <Fn><Alt><Shift><Num Lock> should be the key I need.

puppet augeas and sudo

I wanted to configure some sudo rules using puppet.


The default sudo config has an directory called /etc/sudoers.d which makes dropping in the actual entries rather easy:

file { "/etc/sudoers.d/example" :
        ensure => present,
        owner => 'root',
        group => 'root',
        mode => 0440,
        content => template('example/sudo.erb'),
}

but alas, the default RHEL6 sudo has requiretty set which prevented my sudo rules from working correctly.

Naturally I wanted to use augeas to remove that flag but it turned into a nightmare trifecta of puppet + augeas + sudo. Three tools with so much potential and a great lack of real world documentation.


I remember having battled with this before and giving up. This time I was determined to succeed. I revisited the only information on the internet but I still could not get it to work. After looking at the code for the sudo lens I was pretty sure that I had the correct version and eventually I was pointed in the right direction. Instead of removing the requiretty I needed to negate it. After some more mucking around I came up with a working incantation:

augeas { "turn off sudo requiretty":
        changes => [
                'set /files/etc/sudoers/Defaults[*]/requiretty/negate ""',
        ],
}

I hope that will be of use to someone.