iMac’s Homepage

Installing Google Gears is a piece of cake:

#apt-get install gears

This allows for offline blogging allowing you to make good use of authoring moments away from the Internet.

The interesting part is that Google nor Wordpress make it that evident that gears is available via the packaging system for Ubuntu.  The typical links on their respective help pages lead nowhere.  Enough said, it is well documented here. 

One new feature found in the recent Karmic (Ubuntu 9.10) release is a nice Gnome desktop notification provided by a tool called Palimpsest Disk Utility that interrogates SMART drive information.

Upon upgrading from Intrepid to Karmic last November, I was presented with a new notification from this tool.

Upon clicking with my mouse I was presented with some startling facts about my current drive health that have me wondering when my disk is going to fail. The details below suggest my data is in jeopardy and that I should start to plan a disk replacement in the near future. Since I run a RAID-1 setup the failure should result in a 10 minute disk swap at my convenience, and I look at this as more of an experiment. At nearly three months since first detection (who knows how long the issue was there prior to Karmic), my pseudo-dead Hitachi is doing quite well.

I have known about this type of information for a number of years and periodically used smartmontools to interrogate drives that sound funny, have been accidentally run hot for extended periods of time or exhibit other signs of impending failure. This is great for servers, where events from rolled-up syslogs are filtered by tools like logwatch which pass on key data for system administrators to act on. On my laptop however I do not run this daemon, preferring one less process running in the background, slowing my startup if only to send me an email (if my configured exim is even within reach of an outbound smtp gateway) or dump a few lines in a syslog file or a console screenlet I only peek at when something is obviously wrong.

For the convenient notification now in Karmic, I am grateful; I am sure others will also have more respect for this subtle addition when the time for impending disk failure is upon them. In my business operations we are pretty much split evenly with a strong Windows tier (running XP through 7 depending on tolerance for re-installation and cost justification) and a growing Linux tier running Ubuntu (Karmic at this point in time). I sure hope Windows 7 has something similar, as there is a lot of pressure to get the most out of laptop hardware as businesses are recovering from the recession.

Today I was following up on some harmless messages I have been seeing on some iSCSI Initiators I have setup that provide disk to a number of ESX servers over a Gigabit LAN. It appears that there may be some limitations running the newest flavour of ESX with current IET. One recent comment from an OpenFiler forum which implements a similar configuration to the one used on our Debian Lenny servers states very clearly that IET may not be robust enough to handle peak disk I/O on an optimized Gigabit LAN segment serving VMWare VSphere servers. This post by alhall explains a lot what people have been seeing in some other OpenFiler threads I have been reading today.

• https://project.openfiler.com/tracker/ticket/839
• https://forums.openfiler.com/viewtopic.php?id=4143

In any event, it also has my eye on SCST, another iSCSI subsystem, that is not as mature from a packaging perspective but appears to be a future contender based on the current feature comparison.

The bottom line here is to stick with ESX 3.x with IET for now. As a side note, there are a few IET.conf performance tweaks laid out nicely here with explanations on what each does.

A few years ago Toronto Hydro replaced my household hydro meter with a digital one (aka Smart Meter). Since logging in initially a few years back, I receive periodic updates reminding me of the fact that I can review my consumption levels and the impact of Time-Of-Use (TOU) billing online. Out of sheer curiosity, I decided to peek at my usage and perhaps stir up some interest with other individuals that have this same ability and do not realize it. After all, their web site states clearly,

Generally speaking I believe most Torontonians should now be able to access their meter information through Toronto Hydro’s digital meter web site for residential customers. Below are three graphs of my usage for the same period in each of the last three years for comparison.
Fall 2007:

Fall 2008:

Fall 2009:

Interestingly and surprisingly, our household has cut down on hydro consumption. Hopefully this trend will continue as there seems to be more motivation to do so now that data is easily reviewed in the web interface. I hope Toronto Hydro continues to improve this interfaces as it has a few issues around data selection and presentation that can make it a bit difficult to get the data you are looking for. Specifically the issues I discovered are

1. Some of the date range fields for the graphical output only function when you select data by billing periods, even thought there are secondary input fields (yes two tabs for date input) for specific start and end dates, and the supporting data for any range is viewable when you export in XLS format.
2. The tools are somewhat limited in their ability to do comparisons. i.e. There is no way to compare a range of dates from one year to one without comparing screen captures in a similar manner to how I have above.
3. Some of the functions return errors when you enter older dates (2007,2008 in my case), suggesting the data does not exist even though the data is viewable in other functions and exportable in XLS format.

Of course some of this could be issues relating to the site rendering in Firefox 3.5 (on Ubuntu), but I would expect this not to be the case, as IE-only compatibility is really considered a bug in by today’s standards IMHO. Likely they are aware of these issues, and simply waiting for a bit of user uptake to justify the investment in some updates and changes. Hopefully this post helps.

It seems that Virtualbox 3.1.x now implements a quick check to see if the hardware virtualization extensions are in use before launching AMD-V enabled guests. There seem to be two key issues with this change

1. Buggy BIOS’s that do not clear a VERR_SVM_IN_USE flag properly on boot
2. KVM modules that set the VERR_SVM_IN_USE flag when they load on boot

Either of these issues will prevent a VirtualBox 3.1.x guest from loading with AMD-V virtualization enabled. Depending on what type of guest you are running, you may not even notice this issue. Some virtualized 64-bit guests may not even operate as they require the extensions to boot (vt-x error message). Other virtualized 32-bit guests, like my Windows XP 32-bit guest, will load without the hardware virtualization extensions running resulting in a performance hit. In this second case, if the little computer chip icon with the “V” is faded then you are not using the AMD-V extensions. Shown below is a working VirtualBox guest with active AMD-V (not faded) icon highlighted as it should be normally.

Any system that shows “svm” in /proc/cpuinfo may benefit from AMD-V extensions running a virtualized guest OS. On my dual core laptop this looks like:

imac@dv7z:~$ cat /proc/cpuinfo | grep svm
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch osvw skinit
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow constant_tsc rep_good nonstop_tsc extd_apicid pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy 3dnowprefetch osvw skinit

Examining the second issue, the current qemu-kvm package loads kvm which sets the VERR_SVM_IN_USE flag checked by Virtualbox, even if the modules technically are not in use (IMHO, this seems like a kvm module bug to set this flag). One workaround if you have the issue described above is to disable the kvm extensions using module blacklisting, and modify the qemu init scripts to honour the blacklisting configuration.

Step 1: Apply a quick patch to /etc/init.d/qemu-kvm, adding --use-blacklist to the code snippet below as stated in this Ubuntu bug report. This should appear in Karmic *proposed* sometime soon.

case "$1" in
start)
log_begin_msg "Loading kvm module $module"
if [ -z "$module" ]
then
log_end_msg 1
exit 0
fi
if modprobe –use-blacklist “$module”
then
log_end_msg 0
else
log_end_msg 1
exit 1
fi
;;

Step 2: Create a blacklist configuration file in /etc/modprobe.d to prevent loading of the kvm modules. My configuration contained in a file I created/etc/modprobe.d/blacklist-kvm-im.conf is below, noting I used my initials in the filename to distinguish it from any current or future configuration files deposited by the package management system. Perhaps VirtualBox will ship with a similar one if this issue is not resolved with the KVM maintainers.

imac@laptop:~$ cat /etc/modprobe.d/blacklist-kvm-im.conf
#Workaround for KVM setting VERR_SVM_IN_USE flag
blacklist kvm
blacklist kvm_amd
imac@laptop:~$

Once completed the system should load without kvm confirmed by a quick check of running modules:

imac@laptop:~$ lsmod | grep kvm
imac@laptop:~$

Examining the first issue (Buggy BIOS), the simple thing to do would be to upgrade to a patched BIOS. Assuming the latest BIOS does not solve this problem, the second solution is to load the kvm_amd module and then unload it using the rmmod command. This actually clears the flag, and can be implemented in a simple startup script to work around a buggy BIOS until which point the kvm_amd module behaves differently (IMHO, it really should not set this flag until it is in use, and likely should also detect an IN_USE conflict similar to VirtualBox) and/or a BIOS upgrade/alternate workaround exists.

VirtualBox AMD-V guests should load just like the XP screenshot shown above. This issue is being tracked in various places, including the following related links:

• Ubuntu qemu-kvm bug
• Virtualbox 3.1.X AMD-V VERR_SVM_IN_USE bug
• KVM issue with VirtualBox drivers bug report

Recently somebody asked me about key verification and signing after noting that emails from some sources (in this case, the Debian Security team) contain key signatures for verification, and that by default the Evolution email client was not validating them. The simple answer is that by default Seahorse, the default key manager for Ubuntu Karmic, does not pre-populate public keyservers for lookup of digital signatures. The interesting thing is that even after making some straight forward changes to the Seahorse GUI which is supposed to manage your gpg.conf options, it does not enable the automatic key retrieval. The process would should work in the future, and may be used by other applications via seahorse. Adding the MIT PGP keyserver and the PGP Corporation keyserver is straightforward. First, launch the Passwords and Encryption Keys application from the Accessories menu in Gnome (this is the Seahorse application), and add the following keyservers through the Edit->Preferences dialogue with their respective types:

LDAP:keyserver.pgp.com
HTTP:pgp.mit.edu

A quick search for the work ’security’ in both keyservers should produce some results verifying that they are working correctly. Setting the flag for automatic retrieval of keys from key servers will ensure that keys listed in the servers will be found by the Seahorse engine from that point onwards.

Unfortunately this does not solve the problem of Evolution looking up keys in these servers. Clicking on a recent email from Debian Security still gives the following output.

gpg: armor header: Hash: SHA1
gpg: original file name=''
gpg: armor header: Version: GnuPG v1.4.9 (GNU/Linux)
gpg: Signature made Thu 31 Dec 2009 11:35:23 AM EST using RSA key ID 02D524BE
gpg: Can't check signature: public key not found

The simple solution is to add the following lines to your .gnupg/gpg.conf file manually, noting that the file itself contains only a single line with a comment stating it is updated by Seahorse. Looks like a bug to me. I found this information in the Evolution FAQ. The modified file with two additional keyserver lines appears as follows,

# FILE CREATED BY SEAHORSE
keyserver hkp://pgp.mit.edu ldap://keyserver.pgp.com
keyserver-options auto-key-retrieve


Once complete, evaluation of the same Debian Security email automatically produced a wax seal. The output on initial read was as follows:

gpg: armor header: Hash: SHA1
gpg: original file name=''
gpg: armor header: Version: GnuPG v1.4.9 (GNU/Linux)
gpg: Signature made Thu 31 Dec 2009 11:35:23 AM EST using RSA key ID 02D524BE
gpg: requesting key 02D524BE from hkp server pgp.mit.edu
gpg: armor header: Version: SKS 1.1.0
gpg: pub 2048R/02D524BE 2002-03-19 Florian Weimer (HIGH SECURITY KEY)
gpg: key 02D524BE: removed multiple subkey binding
gpg: using PGP trust model
gpg: key 02D524BE: public key “Florian Weimer (HIGH SECURITY KEY) ” imported
gpg: 1 keys cached (70 signatures)
gpg: 0 keys processed (0 validity counts cleared)
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
gpg: Good signature from “Florian Weimer (HIGH SECURITY KEY) ”
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: C8D3 D9CF FA9E 7056 3F32 FA54 BF7B FF04 02D5 24BE
gpg: textmode signature, digest algorithm SHA1

In the Seahorse GUI, this key now appears in my Other Keys section as it should too.

I cleared all the existing keys to demonstrate that the update works. After reading a few emails, checking again reveals that more keys have been automatically added.

For each email with a valid signature, the wax seal now appears as well.

Some dialogue on steak took place at a recent family dinner with the brothers, wives and girlfriends. In my experience, when preparing steak for guests there is typically a confirmation of preference, even if it is previously known, as a matter of politeness and/or courtesy from the chef. If there is more than mild satisfaction with the result, this is typically followed by a conversation during dinner that evaluates the accuracy of the chef, and explores the well known but often varied methodologies for preparing and cooking beef steak on the BBQ. Perhaps the relative success of my process is commonplace, but typically it includes one or two subtle steps that are not widely practised, and many that are similar to how everybody else does it. Sharing should only have a positive impact, so here goes.

Step 1: Purchase AAA Grade Loin From Costo

I found this picture on the web. Prices typically range from $9/kg up to $16/kg (last summer). Today it is about $10/kg and $11/kg in the photo I have borrowed. I learned at this site that my high opinion of Costco meat was supported in the Feb 2005 issue of Cooks Illustrated where it could not be beat for flavour, texture and price.
Step 2: Age the Meat
The one great thing about the Costco whole loin is that it comes in a cry-o-vac plastic that is suitable for additional ageing in your home refrigerator. It takes a lot of space, so a second refrigerator is particularly useful for this purpose. I learned from a colleague, who worked in a meat house earlier in life, that an additional ten days of ageing from the Costco package date (marked on the label) can give the meat a far superior tenderness in the long run. If you can’t store/age it, look for the oldest strip loin, typically identified at a distance by the most blood in the bag. Knowing that I will store the meat, I focus on evaluation of the gristle and marbling of the fat in my Costco meat selection.
Step 3: Cut the NY Strips
My process is to cut into 1″-1.5″ New York Strips, which brings the price range into about $5/steak, which are typically large enough to share between my wife and myself after preparation. The 1″-1,5″ range ensures that the steak is not difficult to cook (i.e. not easily overcooked) and is thick and juicy (personal preference). Chopping is a similar process to this blog however I put paper towels below the cutting board as the aged meat is very bloody, and use Zip-Lock freezer bags to ensure a protected deep freeze in my block freezer. The 14-16 steaks are not consumed at once, so therefore must be frozen. Usually I eat steak the same day I chop the meat to sample the product. Equal thickness across the steak is required for proper cooking. Usually the end cuts end up in a bag labelled purposefully “Fajitas”.
Step 4: Deep Freeze
My steaks are labelled with a Sharpie on the Zip-Lock bag with air removed and go directly into a block/deep freezer. The temperatures in a deep freezer are actually lower than the freezer that is on the fridge. The freezing process does considerable damage to the cell structure of the meat, contributing further to its tenderness and suitability for a King.
Step 4: Throw it onto the BBQ
This next step is the one that I hear the most often contended. I hear a lot of “Thaw it First”. In my humble opinion, this does nothing except ensure that your hard work softening the meat results in a puddle of juice under your thawed steak resulting in unavoidable increased dryness of the finished product. It can still be great, just not super. I allow my steak to warm up for about 30 min to the point where the frost (this actually builds up from moisture in the air only as it starts to thaw; a notable difference with a deep freeze) melts enough for the steak spice to stick to the meat effectively. I fire up the BBQ and apply my spice (usually Barbarian) five minutes before I throw it on the BBQ.
Step 5: Cook Side One
I am a strong believer of the single flip. Generally I let the BBQ warm up to 600-800 and throw my steaks on. Immediately I reduce the temperature to medium heat; the goal is to allow for a sustained 400-450 reached later in the cooking process. Too hot and you will get too much flare-up before the flip. Typical times for my steak, which I like medium rare (and Err on the Rare side if ever) are about 7.5 minutes per side at my thickness and frozenness. This is almost twice as long as the thawed versions cooked on the day I chop the meat. It is worth noting my BBQ is whimpy by all standards at 25,000 BTU. If you have a hot-spot, orient the fat towards that high heat (not over it) to enable a nice crusty edge, aka flavour country.
Generally I use knowledge of the clock to initiate a test of readiness to flip. The observations are usually that juices appear to be evenly appearing on the surface (glistening everywhere), and the steak appears to be sweating. Breakthrough of juice bubbling, or liquefied fat is a sure sign you have passed the mark. A lot of flare-up from juices coming out of the top is a sure sign that you are likely going to have a short cook on the second side too. All this depending on thickness and length.
Step 6: After “The Flip”
It is “the flip” because I believe in a single flip. I used to subscribe to the quick first searing flip after 30 seconds (which I still do on fresh steak), but have found only toughness downside with a frozen steak as the exposed top seals at 800 degrees whilst the centre is thawing before juices escape en-mass. I have a few hypotheses on why this results in a softer steak, predominantly based on the fact that heat rises and drives hot juices upwards in the meat as it cooks. With a single flip, the cooking juices only change direction once. If you imagine the individual cell structure being cooked by juices moving in one direction, it seems logical that the cell structures are like stationary sacs cooked more on the bottom where rising juices make their initial contact and most of the energy transfer takes place. Juices travel the path of least resistance, which likely changes each time the meat is moved on the grill. It would seem logical that each time the juices change direction, or follow a different path, the individual structures are cooked more thoroughly on more places resulting in a toughening the meat. I think of it as microscopic crusting of the cell structures from cooking juices passing by in more places.
Readiness for medium rare is determined by a feel with the tong, and generally gives a certain resistance that results in a 30-45 degree bend in the meat with slight springiness based on thickness and length. Prodding your steak with a thermometer or anything else is going to cost you precious juices if you pull it out before the steak sits for five minutes after cooking. Not to mention an accurate read of 125F at the centre of a New York Strip is likely somewhat prone to error.
Step 6: Let it sit for 5 Minutes
Often touted as the most important step, the resting of the cooked steak is very important. If you don’t think this step makes much difference based on experience, there is a good chance your steaks are not very juicy to begin with. This could probably as a result of any number of things, including cutting them on the BBQ to see if they are done, prodding them with a fork or thermometer whilst they are BBQ, or letting them thaw before cooking them.

If you wait until the steak has sat for 5-10 minutes depending on the environment and preference, the result should be a nice even red/deep pink colour from edge to edge, slightly darker in the middle and visibly juicy throughout with red hue right to the edges, like this photo. Note that there is no clear transition from red except right at the edge. If you do not wait, you end up with a red centre, that looks very juicy, a lot of juice on the plate and dryer, greyer meat along the edges, like this photo. Note the strong transition from red to grey. Its great, but again, not super. Now I need to take some of my own photos to backup some of these observations. Likely it will be some time before I rush a steak, and who’s to say if a camera will be at the ready.

Lately I have been getting a hard lockup on a work laptop, and I suspect it may be temperature related. Unfortunately with the latest Karmic kernel (2.6.31-17-generic x86_64) I am seeing the following message on boot:

[ 0.943491] ACPI Exception: AE_OK, No or invalid critical threshold 20090521 thermal-384

Additionally, there is no output reported from

# acpi -t

I am running the F.37 BIOS update, noting that some older BIOSes has some known issues around reporting thermal information and that there were some previously resolved kernel bugs related to dv5z thermal reporting that have been resolved.

The fix/workaround turned out to be a simple modification to my kernel command line. I modified my /etc/default/grub to include acpi_osi=Linux. It now looks like the following:

# This file is sourced by update-grub, and its variables are propagated
# to its children in /etc/grub.d/
GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
#Removed quiet, added usbcore.autosuspend for Blackberry and acpi_osi for Thermal Zones
GRUB_CMDLINE_LINUX_DEFAULT="splash usbcore.autosuspend=0 acpi_osi=Linux"
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true


After executing a #update-grub and rebooting, I now see thermal information,

imac@laptop:~$ acpi -t
Thermal 0: ok, 74.0 degrees C

Damm, this thing runs hot _ 74.0 nearly idle _ Yikes.

Recently I acquired a Novatel Ovation MC950D UMTS Modem. A quick google to find links on how to setup revealed a few generic methods, with nothing very Ubuntu specific. As is turns out, the Mobile Broadband setup is build right into the Network Manager.

I simply configured a udev script to activate the modem following some hints from this post, by creating /etc/udev/rules.d/80-umts_stick.rules and adding the line SUBSYSTEM=="block",ATTRS{vendor}=="Novatel",ACTION=="add",RUN+="/usr/bin/eject %k".

Once this was complete, the GSM modem self activated, and I had a new Mobile Broadband section under Wired Networks and above Wireless Networks in my network manager. A few clicks later the network manager wizard had me on the net.

The first time I connected I had no DNS (but was connected via IP), a quick re-plug after making the udev and modprobe changes, and ever since has worked fine. The nice multi-colour status indicator is great, as the connection type is not passed back up to the OS via the serial connection. A quick test from my home office gave me about 3mbit (360kB sustained) down and 0.7mbit (80kB sustained) up using some well known sites that can exceed those limits from my home High Speed connection. At a corporate office 40km away I received about 5mbit downstream and 1mbit upstream. The new limit is my data plan as to what I can now accomplish on the road.

Well, I caught a glimpse of what I expect will be the realm of my next computer purchase; A cheap, functional and powerful netbook with built in UMTS modem and a high resolution LED backlit convertible tablet display with SSD drive and enough RAM to do real tasks and drive a feature rich desktop.

Of course all of this would have to come with a bit of help from our friends at Google in the form of a subsidised netbook.

The idea of a non-Intel ARM (Cortex A9?) chip that is more powerful than the Atom is also very appealing, and opens the door for a sweet Debian based system, similar to my NSLU2, except a Desktop netbook.