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! :-)