For a limited time all international subscriptions to the print edition of Linux Journal will be reduced to the low price of $49.50 for 1 year (a savings of over 30% off the regular price) AND upgraded to include a free digital subscription. As a special bonus you will also receive Linux Journal’s System Administration Special Issue free of charge.

I’ve been a Linux Journal subscriber since the late 90s and can recommend it as one of the better general-interest computer publications. To take advantage of the special offer, visit the Linux Journal site. It seems the promo code to take part in this offer is M96INTL.

Update: Fixed the link to the subscription page, courtesy of Mark at Linux Journal. Whoops!

When I rebooted, I spotted the first problem – GRUB presented me with the kernels from 8.10 (2.6.27.*) but not the 9.04 kernel (2.6.28.*). During the installation I had elected not to overwrite GRUB’s menu.lst, thinking that it would still get updated when the kernel package was configured. Oddly, that didn’t happen. My solution was to edit /boot/grub/menu.lst and add entries for the 9.04 default kernel (doing a dpkg-reconfigure on the kernel package would probably also have fixed it).

Once I had booted the correct kernel, I tackled the second problem – X didn’t work. With 8.10 I had been using the proprietary VIA DRM kernel module, which enabled hardware-accelerated 3D on the 2133’s Chrome9 chipset, but it didn’t work with the updated 9.04 kernel. I moved my /etc/X11/Xorg.conf out of the way and restarted X, which then started correctly with sane defaults (newer releases of X.Org no longer require a configuration file). Rather pleasingly, the OpenChrome driver being used by X.Org started with the correct 1280×768 resolution. The one downside of not using the VIA module is that compiz et al. don’t work – not a big issue for now and one that should be rectified once VIA update their DRM kernel module for 9.04’s kernel. One possible workaround is to boot the most recent kernel from 8.10 (which is still installed), but I haven’t tried that yet.

The third problem, and the most annoying, relates to the 2133’s Broadcom wireless. With 8.10 I had been using ndiswrapper and it worked perfectly. For some reason, as soon as I tried to connect to my home wireless network after upgrading to 9.04, WPA authentication failed (I kept getting prompted for my key and the key I entered was never saved). I then switched to using the Broadcom STA driver, which authenticates successfully, but exhibits a few problems of its own – it often looses the connection to my access point and sometimes doesn’t work correctly after resuming from a suspend. I’m going to switch back to using ndiswrapper to see if it’ll work with a bit more coaxing.

Overall, I’m reasonably happy with the upgrade – other than the issues mentioned above, it went smoothly and the system is working well. The only issue that’s really causing me pain at the moment is the wireless (but then it is Broadcom…).

For example:

[0] mj@majestic:~/tmp$ mount |grep home
/dev/mapper/data-home on /home type xfs (rw)
[0] mj@majestic:~/tmp$ mkdir test
[0] mj@majestic:~/tmp$ ls -ld test
drwxr-sr-x 2 mj mj 6 Jun 18 15:28 test
[0] mj@majestic:~/tmp$ touch -t 200801011530 test
[0] mj@majestic:~/tmp$ ls -ld test
drwxr-sr-x 2 mj mj 6 Jan 1 15:30 test
[0] mj@majestic:~/tmp$ stat test
File: `test'
Size: 6 Blocks: 0 IO Block: 4096 directory
Device: fd00h/64768d Inode: 951267331 Links: 2
Access: (2755/drwxr-sr-x) Uid: ( 1000/ mj) Gid: ( 1000/ mj)
Access: 2008-01-01 15:30:00.000000000 +0000
Modify: 2008-01-01 15:30:00.000000000 +0000
Change: 2008-06-18 15:29:08.173750666 +0100
[0] mj@majestic:~/tmp$ mv test test1
[0] mj@majestic:~/tmp$ ls -ld test1
drwxr-sr-x 2 mj mj 6 Jan 1 15:30 test1
[0] mj@majestic:~/tmp$ mv test1 ..
[0] mj@majestic:~/tmp$ ls -ld ../test1
drwxr-sr-x 2 mj mj 6 Jun 18 15:30 ../test1
File: `../test1'
Size: 6 Blocks: 0 IO Block: 4096 directory
Device: fd00h/64768d Inode: 951267331 Links: 2
Access: (2755/drwxr-sr-x) Uid: ( 1000/ mj) Gid: ( 1000/ mj)
Access: 2008-01-01 15:30:00.000000000 +0000
Modify: 2008-06-18 15:30:02.814078187 +0100
Change: 2008-06-18 15:30:02.814078187 +0100


I’d never seen this happen before, so I tried to reproduce the behaviour on systems using ext3, UFS and HFS+ filesystems. None of them updated the moved directory’s mtime when the parent directory changed, which is what one would expect. XFS does have an active mailing list, so I reported my findings and was quickly provided with a patch that fixed the problem. Kudos to the XFS developers for providing a fix so quickly.

Rather odd that no-one had spotted this behaviour in the past though…

Sadly, my laptop still generates spurious ACPI overheating events, which cause an unwanted shutdown. That’s something I’ll probably have to fix with a new DSDT or by patching the kernel myself to ignore nonsensical temperatutes (783 degrees!).

After a bit of judicious Googling, it seems that the above libpng errors are red herrings and that the problem is caused by an incorrect libdbus being loaded by VMware. The solution is to preload the correct version of libdbus. For more information, including a solution, see this thread on the VMware forums. Apparently newer versions of Ubuntu exhibit the same problem.

I’ve made my donation (guess who I am on the list – have you?

Until quite recently, Xgl was only supported on machines that could use the proprietary ATI or NVidia X drivers, which excluded me, as my laptop has an Intel 915DM display subsystem (one of those horrible shared memory systems). This has since changed and the 915DM is now supported. Rather fortuitously, today Jonathan kindly passed along a copy of the latest Gentoo-based Kororaa Xgl Live CD 0.2. When I booted it on my laptop, I was very impressed with what I saw – the performance was good (much better than, for example, the composite extension of X.org 6.9, as I’m using currently) and the eye candy certainly is purrty

The code is revolting, the user interface is opaque and highly buggy, it exhibits the “I know better than the user” interface paradigm as much as almost any system utility I’ve ever seen (note how it’s impossible to run “grub-install” on a root-on-RAID netbsd system because it *ignores* the “impossible” values in the disk map even if the correct values were hand-entered there), it is poorly documented, it doesn’t know how to pass arguments to a modern NetBSD kernel, and, even worse, the support for booting BSD kernels *at all* relies on header files copied directly from an old version of FreeBSD with their copyrights stripped off in blatant violation of the BSD license.

The NetBSD installation went very smoothly, and I installed into a primary partition that I’d left empty when installing Debian GNU/Linux (/dev/hda3 in Linux terminology). Once the installation was complete, I booted into Linux and edited my /boot/grub/menu.list to add NetBSD. I added the following entries:

title NetBSD 3.0
root (hd0,2,a)
rootnoverify (hd0,2,a)
chainloader +1

Once that was done, NetBSD appeared in my GRUB menu and booted like a charm. More on my NetBSD laptop experiences in a later post…

After much Googling, I discovered that the cause of the problem is the init script that sets the system clock. It is called before /usr is mounted, which means that /etc/localtime (which points to the correct timezone in /usr/share/zoneinfo) is a dangling symlink. To work around the problem, I copied the correct timezone file to /etc/localtime, thereby making it available before /usr is mounted. An ugly workaround, but it seems to have solved the problem.

For more information, see bug #342887.

I had backed up the N620c (which was running Debian GNU/Linux 3.1) and my plan was to partition and format the 6220’s disk and untar the backups onto it. Sadly, things didn’t go according to plan… I managed to stuff up /lib, which meant I couldn’t sync(1) and had to power off the machine to boot from a rescue CD. When I fixed /lib, it seemed /dev had been corrupted by the unclean shutdown. I started again and, after reformatting, extracted my backups a second time. All went well this time and the machine booted fine first time.

Once the backup had been restored, it was fairly straightforward getting everything configured for the new hardware. I built a 2.6.15 kernel and got X.Org 6.9 working on the Intel 915GM graphics at 1400×1050 (see the links below for detailed instructions). The Intel wireless is supported by the vanilla 2.6.15, which made setup trivial (I just needed to grab the firmware).

Some useful links:

• My vanilla 2.6.15 kernel .config file
• My 2.6.15 dmesg
• Gentoo on the nc6220
• Ubuntu Breezy on the nc6220
• HP information on Linux on the nc6220 (it’s even Linux certified!)

I’m pretty happy with the machine – peformance is good (even the X11 composite extension is usable) and it’s a fair amount thinner and lighter than my N620c. My only complaint is that the vesafb framebuffer console doesn’t support 1400×1050 and so I have to use a 1024×768 console (1280×1024 has the wrong aspect ratio and suffers from some strange visual artifacts). I haven’t installed Suspend 2 yet, but will do so in the next day or two.

Now that my Debian installation (since upgraded from 3.1 to “testing”) is working well, it’s time to install my operating system of choice, NetBSD…

You can grab it from ftp://ftp.sap.com/pub/sapgui/java/640r6/.

In my environment I have a home directory that is exported via NFS from a server, running Debian GNU/Linux, to various clients, running a mixture of operating systems. GConf, being an application that needs to accept configuration updates from a number of applications running concurrently, needs to lock its data files, which are stored in a user’s home directory. Of course, having an NFS mounted home directory tends to complicate things, particularly because NetBSD doesn’t support NFS locking. The nasty thing is that when GConf cannot lock a file, it just blocks indefinitely, waiting to obtain the lock. As you can imagine, any application using GConf hangs while GConf waits for the lock to succeed. Great design…

It’s taken me quite a lot of fiddling, but I seem to have found a workable solution to this annoyance. The key is to get GConf to lock to a local filesystem, rather than to one mounted via NFS. To do this, set GCONF_LOCAL_LOCKS=1 in the appropriate shell rc file. When using local locking, GConf creates lock files in /var/tmp/gconfd-$USER instead of ~/.gconfd.

Sheesh, why can’t it do this automagically?