If your hard drives are currently doing fine and you're ready to skip this article, please just do this for me: run fdisk -l as root, maybe fdisk -u -l as well and store the output in a file on a usb stick or another machine. Thanks. That's the kind of thing you chuckle at until a twitch or update destroys your partition table and you're staring at a black screen with a blinking grey underscore instead of a boot screen, knowing that your data is there somewhere but the computer doesn't know where to find it. Neither do you. With that info you'll be able to recreate the partition table using fdisk or parted, following tutorials online.
Now let's assume you're like me and you don't have that data. Here are a few links and ideas that you can try out, most of which didn't work for me but all taken together ended up giving me a working system back. Arm yourself with a LiveUSB stick running Linux, and let's begin.
Try #1: gpart
Not to confuse with gparted, which by the way is the tool I messed up my laptop with. I was reading the menus wondering why the resize option was greyed out, when I had one of those finger twitches (too much caffeine?) and bam! An 'error' alert popped up and the layout of my hard drive changed to "Unallocated" -- and that was it. One twitch! I should try to reproduce the bug now that I have my fdisk output, but I'm not brave enough yet... (Working machines are so handy!)
...Anyhow. Gpart came with the recommendation that "it worked for me X years ago, and here's the actual web page I used to fix things", so I tried it. Gpart works non-destructively and tries to guess where your lost partitions start and end.
I'm afraid to say gpart failed miserably for me, only listing a 3Mb partition that I don't think actually exist, after a 2h run. It's still worth a shot, and won't do any harm if it doesn't work.
Resources:
- Recovering a lost partition table, including what to do after gpart gives you back accurate looking information
- Partition-Rescue HOWTO -- I was reading this while waiting for gpart to finish, it gives other tips on how to find/guess your partition table, including a command (cat /proc/partitions) that should work beautifully if you haven't rebooted the machine yet after erasing/losing the partition table
- gpart -- A bit more information, example output, manpage, changelog
Try #2: Testdisk
Running testdisk (quick search)
Googling more I came across Testdisk, a very cool utility that do the same thing as gpart and then more, and is also available in the Fedora repositories. The most important thing I can say is to read the site carefully. I found the step by step guide especially useful. The commands are not always straightforward (p to list files?) but it's incredibly powerful and the second the "Quick search" started running it was already listing a fairly good idea of my 6 main partitions and their types.
Running testdisk (deep search)
I thought deep search wasn't working for me but reading the step by step guide, I realised it gives back potentially overlapping partitions and it's up to you to examine them to find the most likely one. Considering I could list the files off all my partitions after the quick search, I decided to give up on the deep search output and start again, using what quick search gave me as my best bet for writing a new partition table.
Writing the partition table
Select the Write option when you feel ready. This is not a destructive option either, in that if you get it wrong you can try running gpart or testdisk again, and write another table based on a different guess.
Win #1: Data backup
The new partition table didn't actually quite work for me. Windows wouldn't boot, and Grub was gone so I had no access to my Linux partitions. I booted off the LiveUSB stick again, and mounted the newly remade partitions from the 'Places' menu to back up the files I sort of cared about (this is a 1-week old laptop! Not much data).
chroot magic + grub
Making sure I only had one partition mounted (Ubuntu in this case), I chrooted into it from its mount point in /media.
chroot /media/1234-5678-90ab-cdef
From there the idea was to use grub-install to reinstall grub. The hard drive I was trying to rehabilitate was /dev/sda, replace with the drive you want to fix.
grub-install /dev/sda
Now that didn't quite work for me. I forgot to write down the exact error messages, but it was complaining about not being able to write to /dev/null. This Ubuntu Forum post helped me solve that one, and by the way also contains more ideas to try out if you end up still grub-less.
Now, for the proper /dev directory to be picked up in your chroot environment:
mount -o bind /dev /media/1234-5678-90ab-cdef/dev
grub-install /dev/sda should now works handsomely :) Rebooting the machine, only Ubuntu was visible in the Grub boot menu. Running update-grub within Ubuntu resulted in an accurate list of every OS during the following boot, yay.
Note that I actually sort of lost a partition in the process, the OEM "Rescue partition" that Lenovo set up at the end of the drive. TestDisk picked it up properly, but this partition is supposed to run when pressing the blue ThinkVantage button, and wouldn't start anymore. I didn't feel too sorry and deleted it (one more primary partition slot for me!). I also had to recreate the swap partition, which is pretty minor.
Thanks TestDisk for saving the day! :)
Resources:
