On Being S.M.A.R.T

After reading "Watching a hard drive die", "Checking Hard Disk Sanity With Smartmontools" and the Wikipedia article about S.M.A.R.T, I decided to install smartmontools and test my hard drives for problems:

aptitude install smartmontools

The first hard drive that I diagnosed with smartctl was my laptop's primary hard disk:

smartctl -a /dev/hda

This showed a few unsettling results, but luckily no reallocation errors or other critical errors.

I got similar results for my external Western Digital Elements hard disk. That was good, because that's my backup disk. Phew.

My other external hard disk is an old Western Digital hard disk that's in a USB connected disk enclosure. I tried diagnosing it and got the following error:

root@machine-cycle:~# smartctl -a /dev/sda
smartctl 5.39 2009-10-10 r2955 [i686-pc-linux-gnu] (local build)
Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net

/dev/sda: Unsupported USB bridge [0x04b4:0x6830 (0x001)]
Smartctl: please specify device type with the -d option.

Use smartctl -h to get a usage summary

I did as I was told (i.e. read the usage summary) and then tried the following:

smartctl -a -d usbcypress /dev/sda

Cypress happens to be the manufacturer of this enclosure's USB to IDE bridge, but smartctl doesn't seem to recognize it without my help.

Well, now I got a report from smartctl but it showed that one DMA CRC error was logged.

I ran tests on all hard disks with smartctl -t short ... for each device and they were all completed successfully. Phew. /Me wiping cold sweat off brow/

Next thing to do was to enable smartd to monitor all my hard disks:

1. edit /etc/default/smartmontools and make sure you have the following line in it:

   start_smartd=yes

2. start the daemon:

   invoke-rc.d smartmontools start

On my system this doesn't work as is, and I had to edit the daemon configuration file /etc/smartd.conf, based on the examples in the comments and the manual page:

1. comment out the line that starts with DEVICESCAN (i.e. prepend it with a sharp sign #)
2. add lines per each hard disk to be tested:

   # primary disk                                                                                                                               
   /dev/hda -a -o on -S on -s (S/../.././05|L/../../7/04) -m root -M exec /usr/share/smartmontools/smartd-runner
   # /dev/gigapod (multimedia)                                                                                                                  
   /dev/disk/by-path/pci-0000:02:00.2-usb-0:1.4:1.0-scsi-0:0:0:0 -a -d usbcypress -d removable -o on -S on -s (S/../.././05|L/../../7/04) -m root -M exec /usr/share/smartmontools/smartd-runner
   # /dev/elements (backup)                                                                                                                     
   /dev/disk/by-path/pci-0000:02:00.2-usb-0:1.1:1.0-scsi-0:0:0:0 -a -d sat -d removable -o on -S on -s (S/../.././05|L/../../7/04) -m root -M exec /usr/share/smartmontools/smartd-runner

   Note that this schedules short self tests to run each morning at 5AM and long self tests to run on Sunday mornings at 4AM.
   
   Also note that I use the /dev/disk/by-path links to the external disk block device, in order not to be hit by udev's tendency to reorder device names.

Testing, 1, 2, 3 !

One Liner: Synchronize Digital Camera Clock

The clock on my Canon Powershot A620 is yet another clock that I want to synchronize with my PC.

Hook the camera over USB to the PC and run:

gphoto2 --set-config /main/settings/synctime=1

Use the following to read the camera clock and verify that it's synchronized:

gphoto2 --get-config /main/settings/time

(requires gphoto2)

Wine and Missing MFC42.DLL

Every once in a while I need to run a Window$ application. If the application at hand is a standalone application that does not require installation, I'll usually attempt to run it first with Wine, instead of launching a full blown WinXP virtual machine.

Using Wine is a no brainer:

wine /path/to/application.exe <command-line-arguments>

and if the file happens to have executable permissions (chmod +x ...) then it's even easier - just launch it like any other script or binary executable, by typing

/path/to/application.exe <command-line-arguments>

Last time I tried it I hit a problem:

err:module:import_dll Library MFC42.DLL (which is needed by L"Z:\\path\\to\\application.exe") not found
err:module:LdrInitializeThunk Main exe initialization for L"Z:\\path\\to\\application.exe" failed, status c0000135

This means that a required DLL is missing - in this case it's MFC42.DLL. This specific DLL is needed for (older) GUI applications that use MFC, and it isn't part of Wine.

Whatever you do if this happens to you - don't try getting this DLL from any of the websites that Google will list when you search for it. Google marks quite a few of these sites as sites that can harm your computer. You have been warned.

Window$ users can get MFC42.DLL and other DLLs by installing the Microsoft Visual C++ Redistributable Package.

The recommended way of doing this under Wine is to follow the instructions on the Wine wiki:

1. download winetricks:

   wget http://www.kegel.com/wine/winetricks

2. make it executable:

   chmod +x winetricks

   (optional: place the file in a system directory such as /usr/local/bin)
3. install cabextract:

   aptitude install cabextract

   (actually, I'm not sure it's necessary for fixing the MFC problem, but it's definitely recommended for fixing other Wine problems)
4. run

   winetricks mfc42

The winetricks script has lots of other options for fixing a host of issues and installing a rather long list of third party packages that are not part of Wine.

Bottoms Up!

It Works. Again. (or: ZIP Archives and non-English Filenames)

The wait is over. My wife's laptop came back from the lab. They've replaced the motherboard. Again.

My wife has commandeered my laptop during the past few weeks, trying to get some work done on a VirtualBox hosted WinXP machine, with her My Documents folder pointing to a VirtualBox shared folder in my home directory.

She wasn't happy: I think that the virtual machine is surprisingly fast; she thinks that it's dead slow.

Anyway, the bottom line is that she did manage to modify a few documents and created several new ones. So all that remained to be done, before reverting my laptop to its Debian self, was to synchronize between the My Documents folder on the fixed laptop and the documents directory on my laptop's hard drive.

I used the following to create a ZIP archive containing only the files that my wife modified recently:

cd ~/docs/wife/                                              
find -newermt "Sep 23 2009" | grep -v Thumbs.db | grep -v Desktop.ini | zip -@ /tmp/wife-docs.zip

My intention was to copy this archive over to my wife's laptop and extract its contents to her My Documents folder.

Unfortunately, the Unicode encoded file names in the archive showed up as garbage when the archive was opened on the Window$ box. So I re-archived the files with 7zip (Debian package p7zip-full), which seems to handle non-English file names in a more sensible manner:

mkdir /tmp/wife-docs
cd /tmp/wife-docs
unzip ../wife-docs.zip
7z a ../wife-docs.7z .

Next time (hopefully never - but I don't kid myself) I'll probably mount my wife's documents folder over CIFS and then use rsync to synchronize the files. It's supposed to be The Right Way™ to do this.

The warranty on my wife's laptop expires in a month. Wish us luck.

Synchronize HP Printer/Fax Clock

After the stellar success of my cellular phone clock synchronization script, I had an idea: why not synchronize the printer clock too?

We have an HP OfficeJet 5510 printer/fax/scanner/copier combo, which is hooked directly to my laptop over USB. Its front panel clock tends to drift quite a bit, and I usually forget to switch it from/to Daylight savings time.

It took about two minutes to find hp-timedate, and here's the corresponding cron job specification:

 10 4    *   *   *   /usr/bin/hp-timedate

Now, how do I interface my laptop with the microwave oven?

Synchronizing Cellular Phone Date and Time with Gammu

After becoming the proud owner of a Bluetooth to USB adaptor, I started looking around for a way to automate the backup process of our cellular phones.

I've installed Wammu and was pleasantly surprised by how easy it was to get it up and running. But as soon as I had it configured to talk with both our phones, I realized that what I really wanted was to use Gammu, its command line alter ego.

My plan is to run a backup script every night that will copy contents and settings from the phones to my laptop over Bluetooth. I'll post my backup script as soon as it's up and running for a few days.

In the meantime, let me present another script that I run as a scheduled task every night. It's job is to synchronize the date and time on both our phones to the laptop clock. This has several benefits:

1. the phone clocks are more accurate (because the laptop clock is updated by NTP)
2. the phone clocks switch automatically to and from Daylight savings time,
3. the phone clocks become synchronized to each other

And here it is:

#! /bin/bash
section=0
grep port= ~/.gammurc | cut -d= -f2 |
while read phone 
do
    name="$(grep -m $(( $section + 1 )) name= ~/.gammurc | tail -1 | sed s/name=//)"
    echo $name
    gammu -s $section setdatetime
    let section++
done

I run the script as a Cron job at 4:05 AM. The idea is to synchronize clocks after 2:00AM, which is when the switch to/from Daylight savings time occurs where I live:

1. launch crontab:

   crontab -e

   this should launch a text editor (you can configure which one by modifying the EDITOR environment variable)
2. add the following line

     5 4    *   *   *   /full/path/to/sync-phones.sh

3. save the file and exit the editor

It Hit the Fan. Again.

My wife's laptop is busted.

Again.

This time it just died. No lights, no sounds, no nothing. It's still covered by extended warranty. Which expires next month. Timing is everything.

Down time for my wife was less than 20 minutes, and that's only because I wanted to finish going through my RSS feeds for the day, before handing over my laptop to her hands.

Thank you Bacula.

Thank you VirtualBox.

Again.

Customer service was horrible this time, but they finally obliged and the laptop was sent to the lab. I'm pissed as hell.

If you're looking for a used laptop DO NOT buy this model: HP Pavilion dv6000. It's a piece of crap. And quite heavy at that (2.7KG).

If you're buying a new laptop - DO invest in extended warranty. You'll thank me later.

And now we wait.

Again.