The story began like this: I needed a hfs (Mac OS) to do some testing. I remember the first 3 partitions on my HDD functioned as test-subject during my Amsonia adventures. So I thought, why not merge these into one larger partition. In the beginning my HDD had this structure:

This structure is then altered using fdisk and resulted in this state:

So the process of freeing space was done beautifully. The data on my logical partitions remained intact as they should be. The next step would be of course connect the disc to the macbook and launch Disk Utility to create the partition and format it. I double checked it won’t touch the partitions by reviewing the options hidden in options. Everything seems fine, so let’s apply the changes…. and there comes the surprise: Disk utility failed to apply the changes and ejects the device.

Apparently Disk Utility did modify the partitiontable but failed to do it successfully. Here I am, my partitions inaccessible. A quick web-hunt resulted in trying out gpart. The process of scanning 500GB took around 10 hours to complete; the disc was connected over usb 2.0. Average readspeed was 16mb/s. When gpart was done scanning, it didn’t report anything useful. So the hunt continues till I stumbled against Recovering lost ext2 Linux filesystems. After reading the article I decided to give their hand-crafted utility a try. My article is written with the hope to add value to the information you’ve gathered. It should not be seen as a replacement!

After scanning the whole disc, Scandrive produces a ~2mb report. As the article indicates, lines of the following format might indicate partition start:

ext2 432180492 # size=68095510 #0

So, let’s filter out these interesting line with grep:

grep -w "#0" /path/to/file

The key here is to find a pattern in the less cluttered data. With pattern I mean consecutive large groups having the same size. All found groups are potential partitions, the first block of the group minus two might be the start of a partition.

Once you’ve gathered the offsets and sorted by group size, you can start trying to recreate the partitiontable (preferably one by one) using sfdisk.

Back to my situation, after some trial and error attempts I found logical 1, but the size appears to be incorrect. Because the system could only read that partition partially (some directories could not be read). So I decided to calculate the maximum size of my HDD and use it as the right-boundary. This allowed me to recover all files on logical 1. When the copying process was done, the second partition can also be found and treated in the same way.

You can define the boundaries (your new partitiontable structure) in a text file like this:

# partition table of /dev/sdc
unit: sectors

/dev/sdb1 : start= 432003978, size=544764087, Id=83

Then write it to the disc using sfdisk:

sfdisk -n /dev/YOURDEV < /path/to/new/pt

If you think it is good, commit to disc:

sfdisk --force /dev/YOURDEV < /path/to/new/pt

Then try to mount the new partition. If mount bails out with an error, don't panic, continue trying other potential starting offsets.

Notice the start offset is calculated this way, say you found this line:

ext2 432180492 # size=68095510 #0

The start offset should be: 432180492-2 = 432180490
You only have to do this for the first offset in a group!

The recovering adventure lasted 1.5 days with a happy ending. I've learned a lot during this process, I hope you find this information useful. Special thanks go to Steve Friedl's Unixwiz.net Tech Tips.

No related posts.

Setup – The environment I tested consists of the following components:

1. A server, in my case a Debian Etch
2. A client, mac OS X Tiger on a macbook
3. X11 on OS X
4. freenx server-3.2.0-13 from No Machine
5. nxclient-3.2.0-9, there are other platforms.
6. A window manager on the server, I use e17 (see screenshot in the end)
7. In case you wonder, my connection is an Adsl 2+ with 14mbps down and 1mbps up.  Ping to the server under normal network load is 20ms.

Performance – “Wow”, that’s all I can say. The performance is just great! Compared to RDP, I think they are on the same level, or possibly better: the special effects (animations) in e17 worked flawlessly, the transitions were smooth. Flipping desktop had a little delay, not quite noticable though. During usage it uses approximately 20kb/s (kilobytes) of the pipe.

Security – You shouldn’t worry about security as NX traffics are tunneled through SSH by default, hence you only need to open port 22 on the server side.

QtNX – George Wright released a QT-based nxclient for OS X. This is an alternative of nxclient if you dislike the X11-aqua-like interface components.

Drawbacks – First is its X11 requirement, this means a lot of things; like no clip-board integration.  GDM (or any Desktop manager) doesn’t support NX (as of this writing). This can be worked around pretty easily with a wrapper (or I hope so). I’m considering to add it to my projects queue.

Experiments – In the future some hard-benchmarks can prove freenx’ competence. For now it has convinced me enough.

No related posts.

Another not very pleasant behavior is that Sidenote also shows up in Expose. Even worse… as a static window without any meaning whatsoever. I’m not sure whether that was intended or was overlooked during implementation.

Until the author fixes these small glitches, I’ll pass. These are my verdict and insights. You can read why you should give it a try at Tuaw.

No related posts.

No related posts.