Posts Tagged recovery

Fixing a mangled NTFS partition: success

A follow-up from

Almost two years on,

Correcting errors in the Master File Table (MFT) mirror.
Correcting errors in the master file table's (MFT) BITMAP attribute.
Correcting errors in the Volume Bitmap.
Windows has made corrections to the file system.

My drive is back! And seemingly OK! I’m celebrating by setting up a Python script to recursively run through my current photo backup and the drive and compare file checksums.

How I did it

The key thing was to isolate the drive and not use it. If I hadn’t done that, it would have been utterly unrecoverable.

I also remembered the layout of the drive: Exactly 500GB on the first partition, and the rest of the disk as an NTFS partition. The first partition was a member of a RAID5 set, which had LVM setup on top of it.

I had used GParted to extend the NTFS partition backwards, to get the extra 500GB. However, this failed for… some reason. I’m not too clear.

TestDisk wasn’t successful – It identified the LVM partition, then promptly skipped everything between the LVM header and where the LVM header said the partition ended. Which meant it skipped to the middle of the drive, since the RAID5 set was 1TB in size. And thus TestDisk refused to restore the partition, because it doesn’t make sense that a 2 TB drive has 2 partitions which take up more than that.

The harddisk (2000 GB / 1863 GiB) seems too small! (< 3463 GB / 3226 GiB)
     Linux LVM                0  65  2 130541 139 30 2097145856
     LVM2, 1073 GB / 999 GiB
     HPFS - NTFS          65270 246  1 243201  13 12 2858446848
     NTFS found using backup sector, blocksize=4096, 1463 GB / 1363 GiB

Having tried a bunch of methods in the 1.5 years+ and failing each time, I decided to finally go all the way and wipe out the (screwed up) partition table and recreate it. I didn’t know the original commands run to create the partition setup, so I ended up booting into a Fedora 13 Live image, and doing the ‘Install to Hard Disk’ option, selecting the disk as the install target. I was worried because it wouldn’t allow me to create a partition without also formatting it (Kind of makes sense…), so I terminated the install process after seeing “Formatting /dev/sdd1 as ext4” – in other words, the first partition was being formatted.

I then turned to fdisk to create the partition, selecting the defaults which should have extended the partition to the end of the disk. However, there was some disagreement on what consistuted the end of the disk, leaving me with ~2MB of unallocated space. When I created the partition in Windows, it went all the way to the end of the disk. What this meant is that I ended up with a sector mismatch count (along the lines of “Error: size boot_sector 2858446848 > partition 2858446017”).

So I had a semi-working drive, just with a number screwed up. And what edits numbers on a drive? A hex editor, that’s what. So it was off to edit the NTFS boot sector, and the MBR. I had correct looking numbers from TestDisk’s analysis, so I plugged those in, and since I had the hex editor opened, I wiped out the LVM header at the same time.

Turned out wiping the LVM header was an excellent idea, because TestDisk then found the NTFS boot sector, and allowed me to restore it:

     HPFS - NTFS          65270 246  1 243201  13 13 2858446849
     NTFS, blocksize=4096, 1463 GB / 1363 GiB

After that, the disk still wouldn’t mount in Windows, but chkdsk at least picked it up. After letting chkdsk run overnight, I got my drive from August 2012 back, with (as far as I can tell) no data loss whatsoever.

That’s worth an awwyeah.

, ,

No Comments

Recovering a broken F18 installation

For some reason (possibly a broken F17 upgrade which moved /lib around?) there were a bunch of empty files in /lib. So F18 refused to boot, with error messages like “/lib/ :File too short”

I discovered yum doesn’t like chroots: Kept on getting a message regarding build_time_vars missing. (Spoiler: This was actually Python!)

I also discovered that yum doesn’t like running from an x86_64 arch when the install arch is i686. Solution was to use setarch as mentioned here:
Essentially, spawn a new bash shell with arch set to i686, so yum will pick everything up as i686 and (re) install the correct files

Final command (with the borked system drive mounted as /media): yum –installroot=/media –skip-broken –releasever=19 distro-sync

Fingers crossed it works, though it can’t get any worse now…
And nope, it didn’t work. –skip-broken seems to have sent it into (circular) dependency hell.

Next thing to try is booting an F18 image and copying over /lib/*. Fingers crossed it’ll fix the lib-systemd missing problem.

Yay! No need to boot the F18 image and copy over stuff!

It was a bugged fedup upgrade from F18-F19. yum installed a bunch of packages, left everything in an inconcsistent state – like Python 2.7.5 was ‘installed’. but build_info stuff was never added/created as it would normally be. Manually redownloading python and python-libs for F18 (python-2.7.3), removing Python 2.7.5 (rpm -e python-2.7.5, python-libs-2.7.5) and then installing Python 2.7.3 got yum up and running again.

However, rpm -e $(rpm -qa|grep fc19)’ also removed glibc… which is needed for practically everything. (Should have been rpm -e $(yum list installed|grep fc19|awk {‘print $1’}) ). So I rebooted into the live system and tried downloading glib for fc19 – since everything wanted GLIBC_2.17, and F18 only had glibc-2.16.

Whoops. Ended up with another inconsistent system. Glibc was the only thing that was for F19. AND, because it was a dependency for just about everything, I couldn’t erase it, and yum wouldn’t let me downgrade it either.

So I decided to just do the distro-sync over it. And one distro0sync later, I discovered that I *really* should have mounted /boot (since it lived on a different partition) before installing a new kernel/initrd. So reboot into live cd, copy the files over from the root’s /boot (bloody shadowing!) into the proper /boot, mount the proper /boot into the live cd’s /boot (since doing it in a chroot made grub2-mkconfig complain), and run grub2-mkconfig -o /boot/grub2/grub.cfg.

Other than it mysteriously picking up fedup (I thought that had been disappeared!), it seems to have booted F19… at least, gotten part way there and frozen, but it’s 11:40 at night, I have a flight in 9 hours, and I kind of need to sleep, so I’m off for now…


And correcting the root=/dev/mapper/live-rw to the proper path (/dev/mapper/vg_lantea-lv_root) got it to at least boot past the root switch, but now services are failing to start, and I don’t know why… Possibly SELinux trouble, so I’m going to try putting enforcing=0 on the boot command line…

And it kind of worked, in that it gets to the login screen at least, though it won’t let me login…

, ,

No Comments

Rebuilding a partition table after failed resize

So. When I decommissioned my NAS, I moved stuff off the drives incrementally. My RAID5 media partitions were the first to get nuked, and I reformatted that partition on one of the drives as an NTFS partition, for use on my desktop. I then moved my pictures off the RAID 6 onto that NTFS partition, and wiped the RAID6 partitions.

I ended up with 500GB of unallocated space, followed by 1.36TB of a NTFS partition with my pictures on it. So I wanted to make use of that 500GB of space. So I tried in in-place extension of the free space. Windows Disk Management didn’t allow it, so I tried GParted, and GParted worked. I now had a 1.86TB partition. I unplugged the drive and packed up for Canada, without testing it.

Now, I’m in Canada, and have discovered one crucial thing: GParted didn’t move/copy the NTFS data structures backwards, so the partition is unrecognizable. (Why it allowed this is a question I haven’t tried to answer, but might in the future.)  I haven’t reformatted the drive, so I should be able to get everything back if I rewrite the partition table back to its original state.

Problem is (when is anything ever simple) I don’t have a record of the partition table. I know I set it up as 500GB in one partition, and remaining space in the second when I first installed Fedora. But I don’t have the exact partition boundary. Thankfully, because I have a backup (with Crashplan, who I’m still annoyed with), I won’t have any data loss. But I’d prefer not to redownload 700+GB of pictures, so onward with mucking around with partition tables instead!

First off, data recovery is not what I’m looking for. So PhotoRec, which I remember using with good experiences, is out. (As is PC Inspector File Recovery.) What I’m trying to find is either a partition recover program, which would automatically recover everything, or a partition identifier program, which I could then use in conjunction with manually editing the partition table (yay parted, or alternatively, hex editors!).

Googling “Partition recovery software” gave me a few programs, most of which I ignored because they appeared to be the general commercial file recovery programs that scan your drive and attempt to detect files based on their headers.

I did find TestDisk – which is completely freeware, Active Partition Recovery – DOS version is freeware, Windows you have to pay for, and Find & Mount – crippled freeware, speed is limited to 512KB/sec.

So I started off with TestDisk, and ran that for a while. Then I interrupted it and restarted it, thinking I had passed the wrong options to it. And then I let it run for a while, but it still didn’t find anything, so I interrupted it to shutdown everything to fly to Halifax.

Which is where I am right now, without the drive, which is still in Waterloo. But I can plan a course of action – something which is probably better than trying stuff when I have the drive in front of me.

So my plan is to try TestDisk, get it to run the deep scanning method to try and discover the start of the NTFS partition boundary. I’m going to see if I can find an option that will specify searching from the 499GB mark onwards, since I’m quite sure the boundary’s at the 500GB mark. (There’s a step by step guide on the Testdisk wiki, but no mention of command line options.) If I can’t, then I’ll let Testdisk run overnight and see if that finds anything.

If that fails, I’m going to look at the Active Partition Recovery and see if the free version will show me the partition boundary so I can manually create the partition again.

If that also fails, then I’ll run Gpart, and see if that does anything.

Of course, the final thing to do would be to use parted to create a 500G partition, and then a partition that uses up the remaining space. And if that doesn’t work, run the Fedora installer again and try recreating the partitions, being very careful not to select the ‘format’ option.

I also found a few programs that I’ll try to remember if/when it comes to other hard drive stuff:

Read the rest of this entry »

, , ,

1 Comment