I finally fell into the dd trap. I dd’d a FreeBSD Beaglebone black image to /dev/sdb, where my home directory lives. It should have been /dev/mmcblk0, but I trusted tab completion and didn’t check dmesg.

After a quick check of gparted, it was obvious what had happened. I’ve nuked the partition table on the drive. Well done.

The data in /home/hibby was intact, however. My home directory was still responding, I could load new files ith no corruption. A quick check of mtab tells me ~ lived at /dev/sdb6. It turns out the first ~200GB of data on the drive were taken up by an old windows install or something. So, I had to work out how best to recover that partition and that one alone. I didn’t care about the rest. Step 1: Do not turn the computer off, as it still works.

Gparted has an inbuilt “attempt to recover partitions” mode, which I set to run. After about 7 hours (and many beers), this had turned no results. It’s been scanning 700GB @ 5M/s (iotop’s unit, not mine). Scrap this. A quick google revealed a tool called testdisk. I apt installed testdisk and pointed it at /dev/sdb. An hour later (and 70% of the drive scanned) I had no results. That’s no good. Try again, but this time pick an msdos partiiton table, not GPT… there it is!

Testdisk built me a new partition table - I confirmed the partition I was concerned about losing was completely defined using fdisk -l /dev/sdb and comparing the start sector and size in sectors with the details stored by the kernel in /sys/class/block/sdb6/start and /sys/class/block/sdb6/size. They matched. Goal #1 complete: Data partition safe. Probably.

Next up, to boot properly I know that /etc/fstab requires the correct UUID for the block device. However, I am lacking this information currently, as I don’t know what UUID it’s been set up with. By this time it’s late, I’ve had a few more beers and I’m feeling cocky - I dropped in /dev/sdb2 as the location, :wq my way out of vim and get ready for the Big Reboot(tm).

Worst case scenario, I just get bounced to the rescue console, run blkid and update the UUID from there.

reboot

grub rescue >

This… doesn’t meet expectations. Think. Think.. Think…

Some fuckwit doesn’t have an efi partition on his system disk. Some fuckwit had also written over his EFI partition with FreeBSD 12 for Beaglebone Black. Bedtime.

Long story short, the next morning with a bit of a hangover, I had to use fdisk to once again build myself a 512MB bootable partition at the start of the disk, (conveniently type ef), write that, and then enter expert mode x, and fix partition order f.

I had a Debian installer on a USB drive to hand - I used the recovery console in that to chroot into my system on /dev/sda1, mounted the newly made /dev/sdb1 as /boot/EFI and ran a grub-install as detailed on the Debian wiki.

I also had to update my partition UUIDs in /etc/fstab - blkid /dev/sdb1 & blkid /dev/sdb2. After a reboot, it all works nicely!

Tom tells me I need to reinstall, but I tell him real men don’t have bootloaders on their system drive.

TL;DR:

  • I dd’d over the start of a hard drive and deleted the partition table, my EFI partition & lost the location of my /home partition on that drive.
  • I used Testdisk to rebuild my partition table from.
  • I had to manually make a new EFI partition using fdisk and Debian wiki
  • I had to update the partition UUIDs in /etc/fstab.
  • Everything is fine again