An upgrade too far

I should work for the Canonical QA team. Whenever I do something on an Ubuntu based machine, hell brakes loose.

Here I am, working on my LTS 12.4 machine, when suddenly I notice that an upgrade to a new LTS is being proposed. Weird, I thought, as 12.10 isn't a LTS. But I couldn't resist, as I got daily errors on my desktop and upgraded, only to find myself in a far worse unstable situation. So I decided to opt for the upgrade to 13.4, hoping this would fix some of the obvious bugs. Alas, something with the nautilus upgrade must have been corrupted, as my new desktop was completely unworkable. Crashing window managers, slow Xorg and worse of all, USB didn't seem to work.

This is probably not even the fault of the people at Ubuntu or Canonical. This is a workstation that has been upgraded from Dapper Drake onwards, and which contains a horrible Nvidia card which is hardly supported anymore by the nvidia/nouveau drivers.

I decided to bite the bullet, and to completely wipe my installation, and reinstall Debian 7.0 aka Wheezy from scratch. Luckily, I had my /home on an separate partition, so the upgrade path would be minimal. Top of all, it seemed that Wheezy had the nvidia-legacy-173 driver, which worked like a charm with my video card.

A default Debian desktop is still crude and spartan, so there is some more work in order to obtain a nice looking graphical environment. The Adwaita/Cupertino theme offers a nice mix of OSX and Elementary components which can compete like that with an Ubuntu setup. And yeah, Gnome-shell is a breeze to work with in comparison with Unity.

bosboot: missing proto file: /usr/lib/drivers/pci/sissas64_dd

I just upgraded my AIX6.1 NIM server to AIX7 with a DVD I received from my vendor. I noticed that I got an AIX7 TL0 SP1 DVD, which is quite old, so I hoped not to have too much trouble upgrading. Alas.

As the upgrade nearly finished, it asked to load DVD #2, but when I did that, it barfed an error message about some drivers not being able to load. As I had booted from the first DVD, I suspected an error on DVD2 (maybe it was corrupt ?) and switched back to DVD1. Once that was loaded, I was greeted with the following error message :

0301-154 bosboot: missing proto file: /usr/lib/drivers/pci/sissas64_dd

The installation stopped, and I had no other choice than rebooting. But as the bosboot command had failed, no bootable disks were found. Panic ! The only choice I had, it seemed, was to revert to the AIX6 mksysb I luckily had prepared before the upgrade, but I decided to boot the lpar from the AIX7 DVD in maintenance mode and see what I could rescue. After all, only the bootblock was missing.

The missing driver in /usr/lib/drivers/pci/sissas64_dd was indeed missing from the DVD, and it seems that this is a bug in the AIX7 TL0. Fix was provided in TL0SP3.

I decided to try some last command, by copying the /usr/lib/drivers/pci/sissas_dd to sissas64_dd, after which the bosboot command wonderfully worked ! After rebooting the LPAR again, it booted nicely from the bootdisk and I was greeted with the AIX7 login prompt. Pffew !

Querying AIX device attribute values with the AIX kernel debugger

We all know that you can modify online certain attributes on AIX devices, like queue_depth on disks for example :

# chdev -l hdisk15 -a queue_depth=16

However, some attributes changes need a reboot as the device property is in use at that time. You can modify the property by specifying that it will be modified at boot time, with the 'chdev -P' option. This can lead to quite some confusion : imagine a junior sysadmin changing the property, but forgetting the reboot. The 'lsattr' command will report the modified value, but not if it is effectively in use.

We can obtain the currently used value by interrogating the AIX kernel with the kernel debugger, quite a handy feature.
The following command shows the current value of cmd_num_elems on the virtual fiber adapter :

echo vfcs fcs0 | kdb | grep num_cmd_elems 

The following command lists the current values of the queue_depth parameter on hdisk15 :

# echo scsidisk hdisk3 |kdb |grep queue
    ushort queue_depth   = 0x8;


Over the years, I've fallen in love with the AIX multibos command. Here's a little procedure howto test patches without even a reboot of the system :

  • First, clear out all references to old multibos instances :
# multibos -R
  • mount the patch server directory with the patch bundle :
  • # mount nim:/patches /mnt
  • Create a multibos instance of the running kernel and update it :
  • # multibos -Xs
    # multibos -Xac -l /mnt/6100-07-07
  • Check the Standby BOS and review any problems :
  • # multibos -S
    	MULTIBOS> oslevel -s
  • WARNING : adding multibos, will change bootlist, if not wanted, use -t flag :
  • # bootlist -m normal -o
    hdisk0 blv=bos_hd5 pathid=0
    hdisk0 blv=bos_hd5 pathid=1
    hdisk0 blv=hd5 pathid=0
    hdisk0 blv=hd5 pathid=1


    You're one in a million
    that's what you are
    to us so very special
    like a bright shining star !

    On March 24th, we got blessed with a baby daughter Luna, 3.4kg and 52 cm large (small).