Find the answer to your Linux question:
Page 2 of 2 FirstFirst 1 2
Results 11 to 19 of 19
sda1 is an Extended Partition and you can't mount that. Mount /dev/sda2 only and try to re-install GRUB. If it doesn't work, use SuperGRUB CD....
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #11
    Super Moderator devils casper's Avatar
    Join Date
    Jun 2006
    Location
    Chandigarh, India
    Posts
    24,729

    sda1 is an Extended Partition and you can't mount that. Mount /dev/sda2 only and try to re-install GRUB. If it doesn't work, use SuperGRUB CD.
    It is amazing what you can accomplish if you do not care who gets the credit.
    New Users: Read This First

  2. #12
    Just Joined!
    Join Date
    Jul 2007
    Posts
    12
    If I try to install GRUB on /dev/sda2, it just spits out the error 'Could not find device for /boot: Not found or not a block device'. Well... this is no surprise since the /boot partition is on /dev/sda1.


    I'm going to try SuperGRUB! now.



    Update: SuperGRUB hasn't been able to do anything so far, but I'll keep trying... GParted always shows /dev/sda as all unallocated space but testdisk says otherwise.

    Update2: Whenever I try to do anthing with hda sda in SuperGRUB, it doesn't list a single extended partition.

    Update3: I think I've pretty much exhausted the options available; much as I am with this whole situation. If testdisk is able to see all of the partitions under /dev/sda1... everything should still be intact, right?

  3. #13
    Super Moderator devils casper's Avatar
    Join Date
    Jun 2006
    Location
    Chandigarh, India
    Posts
    24,729
    According to fdisk -l, there are only two partitions. First of all. restore Partition Table using Testdisk. Post the output of fdisk -l command after Partition Table recovery. grub-install command will not work untill you recover Partition Table.
    It is amazing what you can accomplish if you do not care who gets the credit.
    New Users: Read This First

  4. $spacer_open
    $spacer_close
  5. #14
    Just Joined!
    Join Date
    Jul 2007
    Posts
    12
    Last night, fdisk and testdisk picked up the two partitions.

    Today, fdisk simply says...

    Disk /dev/sda: 80.0 GB, 80000000000 bytes
    255 heads, 63 sectors/track, 9726 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes

    Disk /dev/sda doesn't contain a valid partition table


    ...and testdisk says the same, initially. After analyzing the drive, it picks up the superblock (which is good) but no /dev/sda2 and I'm unable to view the other partitions or files. When I try to view the files, it says 'No file found, filesystem seems damaged.'


    I have no idea what could have changed between last night and today. I was fiddling around with SuperGRUB but I can't see how that could have caused any problems.


    If I'd written the partition table to disk last night, I wouldn't even be having this problem.

  6. #15
    Super Moderator devils casper's Avatar
    Join Date
    Jun 2006
    Location
    Chandigarh, India
    Posts
    24,729
    I dont know why are you playing with Partition Table. You will loose all of your valuable data in this way.
    As I have mentioned earlier, GRUB or MBR has nothing to do with Partitions or Partition Table. If your Partition Table has been corrupted somehow, you should re-create or recover it with Testdisk. But its not recommended to run Testdisk again and again. You should recover Partition Table and leave it as it is.

    SuperGRUB or any GRUB related command will not work untill you create/recover healthy Partition Table.
    It is amazing what you can accomplish if you do not care who gets the credit.
    New Users: Read This First

  7. #16
    Just Joined!
    Join Date
    Jul 2007
    Posts
    12
    So you're thinking that since I've run testdisk multiple times, it's possible the partition table was corrupted..? That would be extremely aggravating since I was thinking I should write the partition table information to disk last night but I never got around to it. I wouldn't have figured simply running a scanning tool like testdisk could cause corruption.

    I didn't think playing around with SuperGRUB could possibly cause any problems, but that's the only thing I did up to this point.


    Am I out of luck now or are there additional options available?

  8. #17
    Just Joined!
    Join Date
    Jul 2007
    Posts
    12
    Should I call it quits and take the drive to a professional data recovery service?

    This seems to be my only option left; unfortunately.

  9. #18
    Super Moderator devils casper's Avatar
    Join Date
    Jun 2006
    Location
    Chandigarh, India
    Posts
    24,729
    You have run testdisk several times. Didn't you accept Partition Table recommended by testdisk even once?
    It is amazing what you can accomplish if you do not care who gets the credit.
    New Users: Read This First

  10. #19
    Just Joined!
    Join Date
    Jul 2007
    Posts
    12
    No, I never did, and there's not a moment I don't wish I could travel back in time and change my decision. At the time, I didn't really think about accepting the partition table. I don't know exactly why. It never occurred to me that running testdisk many times in a row could cause corruption, or whatever has transpired here.

    Recently, I ran 'mke2fs -n' to get potential ext2 superblocks backup locations on disk. Then, I ran 'fsck -b num device' but none of the backups were links to good superblocks. When I run the mke2fs command above, it knows that the OS type is Linux but is stumped by the filesystem label.

    I recently read in a Linux book that there are certain cases where a professional data recovery service is the only option. I'm coming more and more to the conclusion that this is one of those instances .


    Update: I'm now aware that the partition table is stored in the MBR, which is something I wasn't completely aware of until now. This makes perfect sense because--one I wiped the first 512 bytes of the drive--I received the 'GRUB error 5' which translates to 'Invalid partition table.'


    Update2: I've been thinking... would it be possible to somehow use the information from testdisk in post #10 to recreate the partition table?

Page 2 of 2 FirstFirst 1 2

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •