Lost one primary and two extended partitions - testdisk isn't working

Question

Hey everyone... long time no see. I needed a break
("Conclusion" below if the following is TL;DR)
Background:
First up... don't pull the plug on your PC, even if you are over-fatigued, and try to minimize the number of times you have to force-switch your system off. Read on if you would like to know why.
About four days ago, I was working on something, and everything was all good. Nothing was wrong, awry, or weird, and the only thing I could've written home about my partition structure was that cfdisk showed all the metadata for my extended entries.
That all changed one simple reboot later.
Three days ago, I greeted a system that booted up perfectly, and before entering X I decided to work on a document in textmode. Once I'd had enough of that, I fired up X and continued working on some changes to the QEMU VGA BIOS that makes it look like an old 512K VGA card from 1991 that I have. Or rather, tried to. I fired up my editor and a console and tried to compile... and /stuff, /dev/sda4, wasn't mounted. No problem; it isn't in my fstab. I should get around to adding it one da--whoa, what the...? /dev/sda4 is SWAP?!
It got worse from there. Three days ago I was extremely fatigued because I left a CRT plugged in that I don't usually plugged in (and I didn't know until the next morning!), and being tragically sensitive to radiation, I was rather unreasonable (and had been all day, even while away from the computer), so didn't think clearly about what I did next.
First, I proceeded to use cfdisk to change the partition type from 82 (Swap/Solaris) to 83 (Linux). The partition table decided not to "catch", so cfdisk pointed out that the prudent thing to do would be to reboot, which I ignored (major failure #1) and fired up TestDisk to try and fix (major failure #2) and was like "Enter, enter, enter, enter, enter, enter, ^C, reboot" (catastrophic failure #1).
***************** FILESYSTEM CHECK FAILED ****************
* Please repair manually and reboot. Note that the root *
* file system is currently mounted read-only. To remount *
* it read-write type: mount -n -o remount,rw / *
* When you exit the maintenance shell the system will *
* reboot automatically. *
The rest was history, unfortunately.
I had a 26GB "hole" of free space in my hard disk and... eek. Deciding I'd done enough damage, I fought off my OCD/Autistic "GAH, the computer is DEAD, DO SOMETHING" and got some sleep.
The next day (the day I discovered the CRT was off but plugged in) I decided to have a crack at fixing the problem.
Conclusion:
Worst case scenario, I thought, would be that the 26GB of data was simply gone, and best case, I'd have a ~5GB hole in the disk someplace that would hold my two Syllable AFS partitions (partition type 2A), which I was sure no utility I knew of would be able to figure out. I was almost completely correct: I got my 17GB /storage partition back (WHEW), but I lost my two Syllable partitions as well as a third primary partition of unknown filesystem type.
Here's my evidence:
Going through /var/log reveals files showing lines like
messages.log.2:May 14 10:27:53 hornet sda1 sda2 sda3 < sda5 sda6 sda7 sda8 sda9 sda10 sda11 sda12 sda13 > sda4
This proves that sda4 did once exist as a real partition and wasn't mountable as the result of a freak accident on the disk.
In addition, sda4 is indicated to be a primary partition at the end of my extended partitions. This makes me wonder what on earth's happened here, because I only have a single "Free Space" hole inside my extended header, not after it. Did the extended partition header somehow manage to get resized? :S
I remember - and have the .bash_history to prove - that I chowned and chgrp'd /stuff (ie /dev/sda4) such that I could read/write it as my own user, and this isn't possible with FAT* partitions - you have to dive into /etc/fstab to make them user-writable, and I know I didn't do that. So this partition is possibly ext2, ext3, or JFS (and I'm thinking JFS).
While probably not useful, the fact that the "Free Space" hole is after sda9 but before sda10 lines up with the fact that I had to move sda12 and 13 (a FAT32 partition as well as a JFS partition, the one I mount at /storage) down two notches in order for my system to boot up without complaint.
TestDisk is only listing what I've already got fixed and in working order at this point. In other words, it isn't seeing the other partition. Incidentally, PhotoRec, a program analogous to TestDisk, probably wouldn't be useful here since I doubt that partition contains images.
-dav7
Last edited by dav7 (2009-06-24 04:10:59)

Answer 1

You really got yourself into a big mess ....
As for the partitions magically changing places .... have you recently used gparted (or parted which I believe is the program that actually does the changes) to resize or move any partitions? If you have that's the reason why the partition table is so messed up.
If testdisk can't fix that I have no idea of what can ... once I had a similar problem and testdisk saved the day but I had only ntfs/ext3/swap/extended primary partitions and logical ext3/ntfs partitions.