Recovering data from a HP Media Vault

I had a customer bring in a drive from a HP Media Vault that had failed (or flaked out or something, we're really not sure yet). It was kind of interesting trying to find data on the drive, so I thought I'd share...

First, the drive obviously didn't have a standard PC partition table.

# fdisk -l /dev/hdi

Disk /dev/hdi: 300.0 GB, 300069052416 bytes
255 heads, 63 sectors/track, 36481 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Disk /dev/hdi doesn't contain a valid partition table

I should note that I tried testdisk at this point too, but it didn't find anything. Next, I checked for anything recognizable at the beginning of the disk.

# dd if=/dev/hdi count=8 | strings
Broadcom NAS Version 1.1 MBR Tag
SYSTEM
8+0 records in
8+0 records out
4096 bytes (4.1 kB) copied, 0.00013262 s, 30.9 MB/s

After a little Googling for "broadcom nas", "hp media vault", and a few other things, I figured out there was a reiserfs filesystem on the thing somewhere. (Note: As pointed out in the first comment to this post, there is some great technical documentation on this thing online. Rather than follow it, I chose to cheat and do this the (relatively) easy way.) Google found me this nice document describing the on-disk structure of reiserfs. That's how I figured out that I was looking for a magic string "ReIsEr2Fs" (or "ReIsErFs" for version 1, or "ReIsEr3Fs" for version 3, according to some other search results). I used hexedit to find the offset of the magic string by doing hexedit /dev/hdi, hitting tab, hitting /, then typing in ReIsEr.

2685A020   84 03 00 00  1E 00 00 00  00 00 00 00  00 10 CC 03  06 00 01 00  52 65 49 73  ....................ReIs
2685A038   45 72 32 46  73 00 00 00  03 00 00 00  05 00 B7 08  02 00 00 00  CC A3 00 00  Er2Fs...................

In this case, the magic string was at hex location 2685A034, which means the beginning of the superblock was at 2685A000, or (decimal) 646291456 bytes. The beginning of the superblock is 64k bytes before that, so I set up a loop device there:

# losetup -o $[ 646291456 - 65536 ] /dev/loop0 /dev/hdi
# mkdir /mnt/tmp
# mount -r -t reiserfs /dev/loop0 /mnt/tmp

The files my customer needed were in /mnt/tmp/FileShare/.

Why I suck at business

So anyone who knows me probably knows about the store, but I try not to make a big deal out of it here or in my normal away-from-the-store interaction with people. The fact is, I just don't like mentioning it, for fear that people will think I'm advertising, and I'm only in it for the money. This post is already making me incredibly uncomfortable...

That said, I need some help figuring out some way to advertise some classes I'll be teaching starting in February. Kara and I have invested a lot in the training room in our new store (which makes the local Linux users group meetings much more comfortable), so we have to start making some money on it soon. As it happens, I'm a darn good sysadmin (IMHO), and I like to talk, so teaching is a natural thing for me. ;-)

The classes I'll be teaching are all Linux system administration-related. Half of them are LPI Linux certification classes (on account of the O'Reilly book on the subject I helped write). There's a Google Calendar with dates, but no class descriptions yet. (Details available on request, but I obviously need to get them posted somewhere...)

So I need to figure out a way to get the word out, preferably to the St. Louis area (and the midwest in general, I suppose) that a) doesn't cost a ton of money (because that's all tied up in the new shop), b) doesn't make me feel like a total weasel, and c) doesn't make the intended audience think I'm a total weasel. Suggestions (like, what advertising do you actually pay any attention to and maybe trust a little) would be most appreciated.

Oh, since I'm talking about work, and in case my lovely and talented wife reads this, I have to point out for the record that she owns and runs the business. (In addition to being extremely averse to "sales", I also happen to be horrible with money. On the other hand, she happens to be good at that and more. :-)

Hard drives suck

In my day job, we go through a lot of hard drives. It seems now that no matter how good a drive manufacturer is, drives still show up DOA, die early, die not-so-early, etc. This is the reason I like Seagate so much. While I fully expect their drives to start dying naturally at 18 months or so (they don't always, but that's when I really start keeping an eye on them), at least with their 5-year warranty I know I can get replacement drives without spending a lot of money constantly.

Anyway, a while back I got rather tired of replacing drives that were DOA or after less than 30 days of service, so I figured out that burning them in with a combination of SMART self tests and badblocks seemed to weed out the early failures rather well. I wrote this script to run those tests for me. All it needs is smartctl and badblocks (which are probably available on most live Linux CDs, but definitely on Fedora and Knoppix). It will work on any IDE or SATA drive. With a little work, it could probably handle SCSI drives, ATA drives on 3ware controllers, etc.

cpanspec 1.74

I released cpanspec 1.74 this morning. There's some information about it on the Fedora wiki, but the short version is that cpanspec generates spec files (or, optionally, rpms) for Perl packages on CPAN. As an example, you could build a source rpm for String::Random like this:

$ cpanspec -v -s String::Random
Updating /home/steve/.cpan/sources/modules/02packages.details.txt.gz...
Fetching /home/steve/.cpan/sources/modules/02packages.details.txt.gz from http://www.cpan.org/modules/02packages.details.txt.gz...
Fetching String-Random-0.22.tar.gz from http://www.cpan.org/authors/id/S/ST/STEVE/String-Random-0.22.tar.gz...
Trying to fetch description from String-Random-0.22/lib/String/Random.pm...
Writing perl-String-Random.spec...
Building source rpm from perl-String-Random.spec
Wrote: /home/steve/src/fedora/rpms/cpanspec/devel/tmp/perl-String-Random-0.22-1.fc7.src.rpm

Unlike most other automated (or semi-automated) solutions for building spec files for Perl modules, cpanspec actually gets the Summary, License, URL, description, and dependencies (if available) from the CPAN metadata and other sources. In many cases, packages generated with cpanspec are completely done and ready to use (or submit for package review).

Obviously there are a few things cpanspec doesn't handle well. See BUGS and TODO. Patches always welcome. :-)