Welcome to my world

KDE4: Launching screensaver from commandline or shortcut

Remember the good old days of KDE3? It was so easy to start your favorite screensaver by hand: simply invoke dcop and there we go. But since the dcop framework is no longer part of KDE4 I found myself without a hint of how to create a shortcut to trigger the screensaver.

Until now... use the following commands to lock the screen with the screensaver running or display the screensaver without locking:

qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock

qdbus org.freedesktop.ScreenSaver /ScreenSaver SetActive 1

I hope this helps other as it took me too darn long to find this...

Migrating from VMware Server to KVM on Ubuntu

After being let down by VMware one too many times (this time after upgrading Ubuntu to the latest beta and finding out that kernel 2.6.30+ is not supported), I decided to move on to KVM. After all, my server has full virtualisation support in the CPU so why not put that to good use.

I’ve started off by making sure virtualisation support is enabled in the BIOS. In my case it was nowhere to be found and a quick search for the MSI KA780G (MS-7551) showed that users had varying experience finding the feature but everyone seemed to agree that a BIOS upgrade should help (most of the time). A quick ‘lshw’ showed that I indeed was using the 16.0 version of the BIOS which is more than a year old.

Next, how to flash the BIOS? I do not (like the guide from MSI suggest) have a floppy drive installed in my server nor do I have Windows installed. Luckily, updating the BIOS of the KA780G is pretty easy as it is supported by the Linux programmer ‘flashrom’:

apt-get install flashrom    
flashrom -r backup.bin
flashrom -w newbios.bin

Warning: the last command actually programs the new BIOS into your computer. Make sure you have the right BIOS for your motherboard and do not interrupt the flashing.

Read more...

VMware Server 2.x on Ubuntu 9.10 (Karmic Koala)

Many have taken the plunge and updated to the new Ubuntu due for release late October: Ubuntu 9.10 codename Karmic Koala. And even on my my 64-bit system pretty much everything updated without a hitch. Sure, I had to reinstall the nVidia drivers again for the new kernel but besides that – all was well.

Until I noticed my virtual machines were down. A manual start gave the dreaded “vmware is not configured for your system” message and after invoking “” I found myself looking at some compile errors about the vmmon module.

Like usual, the guys at VMware haven’t released a single update for their free flag ship in half a year now. Hence they have no support for newer kernels found on Ubuntu 9.10 but also for example in Gentoo Linux.

Luckily, someone has put together a fix that you can find here. Basically it is a patch set derived from a long thread on a forum somewhere but hey – it does the job.

It does make me seriously consider moving to an alternative virtualisation platform like Xen or KVM which seems to be part of the kernels and as such will always work after an upgrade…

**Update**: this did not work for me. Either the virtual machine does not start at all and the control panel is broken as well or the entire system goes down with a kernel crash after a few minutes… Guess I am migrating to KVM after all, good bye VMware it was fun while it lasted…

Fixing Midnight Commander Locale errors

If you have a pretty recent Linux system like I have, you most likely have had the pleasure or the following message when starting mcedit:

Chosen display charset or source codeset does not match one set via locale.

You can then "Fix" it or "Skip" and choose to remember it. For me, fixing or skipping the dialog does not seem to do anything but that is most likely because I don't use the charset completely (no 'weird' characters in my text files). Even worse, if you find it to do something -- chances are you want to use the Fix option -- and tick "Do not ask again", the next time the file is broken again! This is because the tick box does not respect your choice but rather takes it as "Skip any problem detection in the future"...

Annoying as it may be, the real cause is the fact that you are most likely not using the correct character encoding on your system by default. Chances are, when you update your system you get this annoying "Generating code page" message a million times over. If so, you just generated support to view every text encoding known to man -- good for you!

I on the other hand, will only view UTF-8 files and I'm not really interested in anything else. So I decided to reduce codepage support to 2 languages: Dutch and English. Note that the Dutch support in this case tends to translate messages in programs (ugh) but it also adds support for the Euro sign:  €

Open up /etc/locale.gen and add the following lines:

en_GB ISO-8859-1
en_GB.UTF-8 UTF-8
nl_NL UTF-8
nl_NL@euro UTF-8
nl_NL.utf8 UTF-8

I cheated a bit by replacing the default ISO-8859-1 or ISO-8859-15 character mapping for Dutch with the UTF-8 one. It seems this choice is allowed and gives me proper UTF-8 support with the nl_NL locale.

Save the file and run 'locale-gen':

cyberxps ~ # locale-gen
* Generating 5 locales (this might take a while) with 1 jobs
*  (1/5) Generating en_GB.ISO-8859-1...   [ ok ]
*  (2/5) Generating en_GB.UTF-8...   [ ok ]
*  (3/5) Generating nl_NL.UTF-8...   [ ok ]
*  (4/5) Generating nl_NL.UTF-8@euro...   [ ok ]
*  (5/5) Generating nl_NL.UTF-8...   [ ok ]
* Generation complete

Looks familiar? Yes that is the dreaded locale generation but this time it only created the locales we will use meaning it completes in a second instead of 10 minutes... Run 'locale -a' to make sure you got what you wanted:

cyberxps ~ # locale -a

Now open up '/etc/env.d/02locale' and put the locale selection in and reload afterwards:

cyberxps ~ # echo 'LANG="nl_NL.utf8@euro"' >> /etc/env.d/02locale
cyberxps ~ # env-update && source /etc/profile
>>> Regenerating /etc/
cyberxps ~ # export | grep LANG
declare -x LANG="nl_NL.utf8@euro"

All done, we switched to the new locale and mcedit can stop complaining now. As an added bonus each file you edit will be created in UTF-8.

Fixing 'interface claimed' printing problems

After leaving my printer unused for some time I suddenly found myself unable to print to my Canon ip4300 printer (which is connected using USB and should be run by CUPS). Dmesg showed the following after powering up the printer:

usb 1-3.1: new high speed USB device using ehci_hcd and address 5 
usb 1-3.1: configuration #1 chosen from 1 choice
usblp0: USB Bidirectional printer dev 5 if 0 alt 0 proto 2 vid 0x04A9 pid 0x10B6
usb 1-3.1: usbfs: interface 0 claimed by usblp while 'usb' sets config #1
usb 1-3.1: usbfs: interface 0 claimed by usblp while 'usb' sets config #1
usb 1-3.1: usbfs: interface 0 claimed by usblp while 'usb' sets config #1
usb 1-3.1: usbfs: interface 0 claimed by usblp while 'usb' sets config #1

The problem here is the USB Printer subsystem of the kernel called 'usblp'. Some people might have it compiled into the kernel (like me - seemd like a good idea at the time) and others might have it as a module. If you have it as a module, unload it and blacklist it so it won't be loaded automatically. Repower the printer and it should suddenly become available to CUPS.

If you have it compiled in - like I had - recompile your kernel after disabling USB Printing. The device manager will pick it up if you connect it again so the printing subsystem can use it.

On a side note: it would have been nice to have a warning in the kernel description that using printing subsystems will not work properly if you use 'usblp'...