dd to the rescue… again!

On my laptop (a macbook), I dual boot between Mac OS X and Gentoo.
Up to last week I only booted into Mac OS X once a month to see if there were
any firmware updates (which only come in .dmg archives), so in fact I was
single booting Gentoo.

Last week, of course in front of a customer, grub failed for no apparent reason.
I just shut down my laptop cleanly in the morning and in the afternoon it
didn’t want to work any more. Luckily, I could still boot into Mac OS X, so
not all was lost.

When I realised that I couldn’t access my Linux partitions from within Mac OS
X (due to imcompatible partitioning scheme types (GPT <vs> MBR)), I knew this
problem wouldn’t be that easy to fix, especially because of this extra
handicap: no CD-drive to boot a Linux rescue CD from. I had the same DVD stuck
into my macbooks internal superdrive for over 4 months (yes, Thomas, this was your qeimc DVD :-p). After having it surgically
removed by S&S they told me I would never be
able to use my internal superdrive again, because the drive itself got
displaced so it doesn’t fit with the opening in the casing any more.

Another thing I suddenly realised was that I did have good backups of all my
data… but not of my working environment (/etc, dotfiles, $HOME/bin, …).
That made me really want to get my Gentoo working again.

First try: boot into a rescue system. I tried with two bootable USB disks,
which work nicely on another PC at the office. My macbook choked on both with a nice
“boot error”.

Second try was at Barcamp.
Thomas (another one) was so kind to bring along an
external firewire cd drive, so I could boot into a resuce system and fix my
grub. No candy. I sure got the live CDs (tried multiple ones) in my rEFIt boot manager, but actually booting from
one was too hard a task for mr. macbook.

Third try: dd to the rescue! Here’s what I did.


$ fdisk /dev/rdisk0


Disk: /dev/rdisk0       geometry: 9729/255/63 [156301488 sectors]
Signature: 0xAA55
         Starting       Ending
 #: id  cyl  hd sec -  cyl  hd sec [     start -       size]
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
 1: EE    0   0   2 -   25 127  14 [         1 -     409639] <Unknown ID>
 2: AF   25 127  15 - 1023 254  63 [    409640 -   60817408] HFS+
 3: 83 1023 254  63 - 1023 254  63 [  61227048 -   54685260] Linux files*
*4: 83 1023 254  63 - 1023 254  63 [ 115912308 -   40384077] Linux files*

I knew the start and size columns were expressed in sectors.

Then there’s dd. I knew I needed something like


$ dd if=/dev/rdisk0 skip=... count=...


The manual explains that dd works with 512-byte blocks. So I
only needed to figure out what the relation was between 512-byte blocks and
sectors. df told me just that!

Filesystem              512-blocks     Used   Avail Capacity  Mounted on
/dev/disk0s2              60817408 54925160 5380248    91%    /

Seems like partition disk0s2 has 60817408 512-byte blocks and 60817408
sectors. Therefore 1 sector = 1 512-byte block.

The fdisk manual also told me that the start-column is 0-based
and the size-column 1-based. Bringing all this together brought me to


$ dd if=/dev/rdisk0 skip=61227048 count=54685260 | ssh bbbart@elisa \
"cat > mnt/tuxiwan-home.dd"
$ dd if=/dev/rdisk0 skip=115912308 count=40384077 | ssh bbbart@elisa \
"cat > mnt/tuxiwan-root.dd"

and yup… these dd images on elisa (another PC on our network) are
loop-mountable.

Okay, my laptop isn’t fixed yet, but now at least I can try out some things
without having to fear losing all my precious stuff! :-)