I have an old, mid-2010 MacBook Pro that is too weak to do serious work now, so I thought I’d give FreeBSD a try. I downloaded an installer and put it on a USB stick.

sudo fdisk -l
# Find the one with 4 GiB capacity, that was sdf
sudo dd if=FreeBSD-12.0-RELEASE-amd64-memstick.img of=/dev/sdf bs=1M

I installed FreeBSD but then had trouble getting X to work; I confess that I don’t understand the FreeBSD package system very well, and even though I know exactly what graphics card I have, I have no idea which of the three NVidia packages I need to install in order to get my graphics card to work. Anyway.

After that failed attempt, I thought I’d try Ubuntu. So I downloaded another installer and put that on the stick, too.

sudo dd if=ubuntu-18.04.2-desktop-amd64.iso of=/dev/sdf bs=1M

Hmm, that went suspiciously quickly. Odd. Remove stick, reinsert stick, try again.

sudo dd if=ubuntu-18.04.2-desktop-amd64.iso of=/dev/sdf bs=1M

Ah, that took somewhat longer. I wonder what went wrong the first time? Anyway, it turns out that the most recent Ubuntu won’t run on that old MacBook Pro: it hangs while the splash screen is still displaying. So I try Debian:

sudo dd if=debian-9.9.0-amd64-netinst.iso of=/dev/sdf bs=1M

Funny, that went very quickly also. Oh well, remove stick, reinsert stick, try again. Insert stick into laptop. WTF, it’s an Ubuntu stick! Remove stick from laptop, reinsert into desktop, try dd again, remove stick from desktop, reinsert into laptop, finally begin installing Debian. Odd.

Then I noticed a disk named “Debian 9.9.0 AMD64 n” on my desktop, and thought, well this must have happened because there was some weird interaction between me inserting and removing sticks without properly unmounting them first. Probably Thunar thinks that the stick is still inserted. Oh well.

Later in the evening, I decide I want to watch a film. So I mount my media disk. But what’s this? There are no films on the disk! Instead there is something that looks suspiciously like a Debian install medium. It finally dawned on me that the meaning of /dev/sdf had changed while removing and reinserting the stick. I had dd’d the Debian installer over my media disk, deleting all of my films, photos, and music.

Attempt 1

Since I am a suspicious bastard by nature, and paranoid about data loss to boot, I keep very warm (not actually hot, just very warm) backups, so it was an easy task to restore them. Or so I thought.

First, I accepted the loss of data on my media disk. I probably could have salvaged most of the content using forensic techniques, but I would have to acquire these as I went along. Partitioning drives and rsync was something I new, so I chose that route.

Step 1: Create new partition

Easy. Just use the old standby fdisk to create a new partition table, then use mkfs.ext4 to create a new file system. Done and done.

Step 2: Copy the backup over to the drive

Also easy: rsync -av /backup-drive/ /media-drive. But what’s this? The rsync failed about a quarter of the way through, claiming No space left on device. WTF? Had I chosen the wrong target?

A quick df confirmed this to be apparently so: the target partition (my media drive) had 2 TiB of space whereas the source partition (the backup drive) had 4 TiB in use. But source and target were supposed to be identical disks. And I was pretty sure that I had no 2 TiB drive connected to my computer, so where did that 2 TiB partition come from?

Attempt 2

The solution is that fdisk cannot write GPT partition tables, which are needed for partitions greater than 2 TiB. I obviously knew this at some point, or the backup file systems couldn’t have been the size they are. But fdisk is apparently so ingrained in me that it’s my automatic standby, even when I should be using parted.

Now parted is not the world’s most user-friendly program and I had to wrangle it quite a bit. First, it helpfully tells me that the partition does not start on a cylinder boundary and is therefore not aligned for optimum speed, but does not in itself offer to rectify that situation. Second, using all available space on the drive for the partition size is not the default, as it is with fdisk. Rather you have to say 100% explicitly.

After creating a GPT partition table, I skipped the mkfs.ext4 and just mounted the partition. I was delighted to see that the part of the backup that could fit on the old 2 TiB partition was still there. Unfortunately, while the partition was now large enough, the file system wasn’t.

Finally, resize2fs to the rescue. This little program allows one to resize the file system to fill the entire partition. Now I had a large enough file system and could continue the rsync.

The Moral

While this was not an ideal situation, compounded in no small part by my stupidity, I was never very nervous. I knew I had a backup, and I new that if I did something really stupid, I had another backup, so I was never in a situation where a command absolutely had to work or I’d be screwed.

I’m not happy how this went, but, given the circumstances, I’m very happy with the setup that allowed me to weather what in other circumstances could have been a catastrophic loss of all my digital media.

As it happens I had not backed up the media disk in a while and so it looked as if I might have lost some 270 photos from a recent trip to the Engadin. But I had these photos on a stick, so even these were saved.