0

First, I'd like to thank James T & ct64116 for their help on my first question; I accidentally overwrote an ext4 partition with the Windows 7 installer and lost something like 300Gb of files.

I took their advice and used testdisk to analyse the lost filesystem. Everything seems to be OK, and I was psyched about restoring it, but I've hit a speed bump.

I'm running Ubuntu 10.04 on a 64-bit processor. In order to repair the filesystem, I need to find the backup superblocks (which I've done already) and then use them to fsck the disk back into usable condition. But it's not working, and I think I know why.

I'm using this tutorial to get the partition up and running. However, when I run fsck.ext4, I get different output than he does. First of all, the version numbers are different: he has 1.41.4, I have 1.41.11.

Second of all, even though I'm running fsck.ext4, the error message I get back tells me that the filesystem I'm examining isn't a correct ext2 filesystem.

So I think that the problem here is that the version of fsck I have doesn't understand ext4 yet, and the reason it doesn't understand ext4 (even though the compile date on mine is later than his) is because I'm running a 64-bit system and the newer fsck hasn't been ported to 64-bit yet. Does this sound right?

Anyway, if there isn't a newer fsck for 64-bit systems, I think my only hope now is to pick up an external 3.5" enclosure, pull out the drive, hook it up to my i386 laptop, and attempt filesystem repair from that machine (which uses version 1.41.9).

Does this sound like a good idea? Does anyone know if there's a simpler way to fix this (like, if there is a 64-bit build of the newer fsck available - I can't seem to find much information through Google - it's a bit dense for me to digest)?

Thanks a ton.

SS

edit: per nik's advice, here is the fdisk output for the system in question. The currently imperiled disk is the last in the list, at /dev/sdc1.
[nik edit: I've removed data from other disks to reduce clutter -- look at previous edit if it is required]

Disk /dev/sdc: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x05ced8ed

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1               1      182402  1465136128    7  HPFS/NTFS

UPDATE: I had no luck with the superblocks; however I was messing around with testdisk and I discovered that testdisk will copy out the folder structure into my home directory! HUZZAH

My home directory is on an SSD, though, and there is only about 30 gigs of space available at any given time, so I will have to stagger my copies and dump periodically to a larger platter - good thing I have an extra platter HDD available. I will just go through, folder by folder, until I've copied all the data out to the other disk. It will take time, but a lot less time than it takes to go through and rename EVERY SINGLE FILE, which is what I would have to do with photorec.

THANK YOU for all your help, especially you nik.

Improve this question

1 Answer 1

Reset to default
3

You might have something broken with your filesystem.
There is a fsck.ext4 in the Lucid amd64 filelist, and I don't think this is a case of architecture compatibility.

Maybe you should print the output from your 'sudo fdisk -l' for reference and point out the partition in question.

Update on your 'amd64' compatibility comment/query.

Ubuntu builds for the long_mode implementation are referred as 'amd64' to differentiate with 'i386' builds which are for 32-bit x86. So, amd64 is actually 64-bit build for x86-64 architectures.

In short, regardless of the 'amd' name, it will work on your x86-64 'i7' processor :-)

Returning to your original question on ext4 recovery,
Your disk is already declared as NTFS and there might be unrecoverable losses -- however, don't loose hope and throw away the disk-data; someone with different knowledge might help you out yet. Sadly, I don't know any more methods.

The 'fsck.ext4' is probably unable to detect any form of usable filesystem meta-data. At this point, it is useful to understand, 'ext4' is basically a variation of 'ext2'. So, you may have lost significant filesystem meta-data to make it difficult for fsck to even identify it as basic 'ext2'.

Hope this information helps you understand your predicament better.
Meanwhile, lets wait for some more answers to come up.
I'll update if I figure any new ideas.

Improve this answer
5
  • Probably a stupid question, but, will I be able to use the amd64 version even if my processor is Intel? It's an i7.
    – StormShadow
    May 1, 2011 at 5:42
  • 2
    @Storm: Yes, AMD64 works with i7 perfectly. AMD64 is just a name for the most used 64-bit nowadays. Don't worry about the AMD in its name. :)
    – Apache
    May 1, 2011 at 11:29
  • Hmm. Thanks, to both you guys. It's so frustrating - I'm able to browse through the filesystem no problem using testdisk, but because testdisk can't deal with ext4 it doesn't give me a "write" option. So I know it can be recovered. I did an "apt-get install e2fsprogs" and it says I'm already at the newest version; but if my version number is lower than the version number in a tutorial from March 2010, how can that be true?
    – StormShadow
    May 1, 2011 at 12:13
  • I think nik is right - I will just have to wait and see if anybody else comes up with a way to fix this. In the meantime I will go down the list of all the superblock locations that I got from testdisk. Maybe I will get lucky. If I do, I will update and close this question.
    – StormShadow
    May 1, 2011 at 12:13
  • Thanks guys! Even though I ended up fixing this via another route, your help was invaluable and got me thinking in the right direction.
    – StormShadow
    May 2, 2011 at 4:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .