hard disk problem no partitions showing

[coffeecat]

@srs5694, thanks for responding to the call and, as ever, your posts are an education. One comment/question.

There are apparently, according to fdisk, unused sectors between 78127102 and 205080576 which, according to my calculation are equal to 65GB (That's real GB = to base 10). The OP mentions a data NTFS partition of 60GB, on which presumably they have personal data which they would want to recover. If the OP really meant 60 GiB (seeing that 65GB = 60.5 GiB), then it's possible the NTFS data partition is in that "free" space within the extended partition. My question is: would it be helpful for the OP, when editing the partition table, to create an entry for a logical partition covering that span of sectors, with the ID code for NTFS? Then, if the filesystem is not corrupted, the OP might be able to mount and read the data there.

EDIT: I've just had another look at the Disk Utility screenshot and the 47GB partition at the end is showing up as "Data". So perhaps the 60/65 is "Music" and the OP got them the wrong way round in post #10. Whichever, data or music, I'm sure the OP wants to rescue anything inside.

[perspectoff]

Oh, I forgot something: One of your screen shots shows a SMART status output that's green but that reads "Disk has a few bad sectors." You should investigate this. It's conceivable that it was this "few bad sectors" that caused your problems to begin with.

In fact, you might want to consider just buying a new hard disk, creating suitably-sized (and sensibly-arranged) partitions on it, and then using ntfsclone, dd, tar, or other programs to copy your current disk to the new one. That way you won't need to deal with fixing the current partitions, although you may need to deal with making everything bootable from the new disk.

+1

I loved the advice about editing the Partition Table, also, something I have been trying to figure out for a long time (but certainly not something to be undertaken by amateurs).

I recently didn't realize that the Partition Table was within my second Windows partition (which I had thought was merely a Recovery Partition for the OS only). I reformatted that partition, intending to use it for a Linux OS. That erased the Partition Table entirely, and then no OS or partition was recognized at all and GParted definitely was of no use. So are the tools you mention available on a LiveCD? Ok, yes, I see from the wiki that SystemRescueCD, one of my favorites, has the tools on it already.

Fortunately, I had already backed up my NTFS partitions using partimage and my Linux filesystems using FSArchiver (which is also on SystemRescueCD).

I had wanted to re-organize my hard drive anyway, so I re-formatted it, used GParted to establish the partitions in the sizes and order I wanted them, and then copied the NTFS partitions back using partimage and the Linux OS(s) using FS Archiver.

Probably not as elegant as editing the Partition Table as CM suggests, but it did allow me to re-arrange my hard drive from the hokey way my original equipment reseller did it to the way I like it.

[srs5694]

There are apparently, according to fdisk, unused sectors between 78127102 and 205080576 which, according to my calculation are equal to 65GB
...
My question is: would it be helpful for the OP, when editing the partition table, to create an entry for a logical partition covering that span of sectors, with the ID code for NTFS? Then, if the filesystem is not corrupted, the OP might be able to mount and read the data there.

If you got very very lucky, you might recover the partition this way. The trouble is that it's impossible to know the precise start sector of the partition. You could make guesses based on both cylinder and 1 MiB alignment assumptions, but they'd just be guesses. TestDisk will actually scan that area to find the actual filesystem data, which takes the guesswork out of it -- at least in theory. (In practice, stray data from old partitions can sometimes cause TestDisk to produce "false alarms" in situations like this.)

I'm not going to speculate about what's what on the three known and one presumed NTFS partitions; just recover them all and then figure it out afterwards.

[srs5694]

I recently didn't realize that the Partition Table was within my second Windows partition (which I had thought was merely a Recovery Partition for the OS only).

With the exception of disk image files and certain types of partition backup files, you won't find partition tables inside Windows (FAT or NTFS) partitions. I see three possibilities to explain your statement:

• You're mistaken, and the problems that you describe when you tried to re-use the partition for Linux were a result of some other problem, like a damaged partition table.
• The partition you've identified as a "Windows partition" was actually an extended partition. (Linux's fdisk, for one, identifies one type of extended partition as "W95 Ext'd (LBA)", so this misidentification is understandable.) Extended partitions serve as placeholders for logical partitions, so if you attempted to overwrite the contents of an extended partition, you'd lose all your logical partitions; but you wouldn't lose your primary partitions, assuming everything else was OK.
• The partition you've identified as a "Windows partition" was a Windows SFS (aka logical disk management, or LDM; or "dynamic disks") partition, which is Windows' equivalent to Linux's LVM subsystem. If you overwrote such a partition, you'd destroy your Windows LDM volumes, but not any other conventional MBR partitions on the disk.

I had wanted to re-organize my hard drive anyway, so I re-formatted it, used GParted to establish the partitions in the sizes and order I wanted them, and then copied the NTFS partitions back using partimage and the Linux OS(s) using FS Archiver.

Probably not as elegant as editing the Partition Table as CM suggests, but it did allow me to re-arrange my hard drive from the hokey way my original equipment reseller did it to the way I like it.

In your situation, restoring from a backup was probably the best course of action, since when you installed Linux over whatever had been there before, you almost certainly overwrote critical NTFS data structures and file contents. This would make recovery of the original Windows partitions next to impossible. It doesn't sound like kirkface8 has caused this sort of damage, so recovery of the original partitions is probably still possible -- although the possibility of bad sectors developing on the disk makes transfer to another disk (before or after partition table repairs) advisable, at least if the bad sectors prove to be real and more than just one or two that the drive can remap and handle.

[kirkface8]

I'm one of the people coffeecat contacted.

Before you attempt anything, be sure to read this whole message, including my caveats at the end.

Anyhow, repair of the partition table is possible, but the end result will be a bit weird. Your goal state is to have an extended partition at the start of the disk with your two Linux partitions (currently /dev/sdb1 and /dev/sdb6) within it as logical partitions. There will also be a gap within the extended partition between the two Linux partitions. You'll then have room for three primary partitions, each of which will be one of your NTFS partitions (currently /dev/sdb3, /dev/sdb4, and /dev/sdb5). It's weird, but legal, to have an extended partition at the start of the disk. That's the only way I can see that these partitions could have been created, though.

You can do this with sfdisk, using a procedure similar to the one described on this Web page of mine; however, you'll need to do a lot of juggling to get it right. You must also have a good conceptual understanding of the difference between primary, extended, and logical partitions. (Googling on "primary extended logical partition" turned up this page, which seems to do a decent job of explaining the concepts, although I've only skimmed it and so can't vouch for it being 100% accurate.) If you attempt this approach, I recommend you first cut-and-paste the fdisk output you've posted, remove /dev/sdb2 (since it's useless as-is), and rearrange the partitions in order of their start sectors. This will show you how things should be grouped. Then get the sfdisk output, as described on my Web page, and re-order and re-number the partitions to match the re-ordered fdisk output. (You'll have to renumber at least /dev/sda1 and /dev/sda5; in fact, swapping those two numbers is one simple way to go. This would result in partition numbers that don't match the storage-space positions, which is legal but potentially a bit confusing. Whatever you do, remember that primary and extended partitions are numbered 1 to 4, while logical partitions are numbered 5 and up.) Once you've re-ordered the sfdisk output, tackle the extended partition: You'll need to give it a start sector that's at least one sector earlier than the first partition (in other words, 2047 or earlier) and a length to precisely cover all the logical partitions (234373121 if you use a start sector of 2047 and if I've done the arithmetic correctly -- please double- and triple-check that detail!). Once this is done, feed the result back into sfdisk, as described on my Web page, and hope for the best!

A somewhat simpler way to do this would be to use my GPT fdisk (gdisk) program, which is intended to edit GUID Partition Table (GPT) disks rather than the Master Boot Record (MBR) disks that yours is. GPT fdisk can convert back and forth, though, and GPT lacks the concept of a logical partition, so it should be able to load the MBR data (converting automatically to GPT format) and then save it out as MBR, which will cause gdisk to automatically create a legal extended partition. The procedure would be:

1. Download and install GPT fdisk from its Sourceforge download page. Do not use the version in the Ubuntu repositories; it's hopelessly out of date and will not work for this procedure. Alternatively, you can use the latest version (2.0.0) of System Rescue CD, which has a recent enough version of GPT fdisk to work.
2. Type "sudo gdisk /dev/sdb" to launch it on your disk.
3. Type "p" to display your partition table and verify that it's correct. If it's not, type "q" to exit without saving your changes.
4. Type "r" to get into the recovery & transformation menu.
5. Type "g" to transform from the in-memory GPT version of your partitions back to MBR form. You'll see a summary of what the program intends to do. It will probably have all the primary/logical assignments right (it won't mention the extended partition), but if not, you can change them here. You will need to change the type code of your Linux data partition (currently /dev/sdb1; it'll still be identified as such at this point) to "83". (In GPT form, Linux and Windows use one partition type code, so the distinction between MBR's 0x07 and 0x83 is lost, and you must re-create it manually.) See the "Converting from GPT to MBR" section of this page for details of how to use the GPT-to-MBR conversion feature of gdisk.
6. When you're satisfied, type "0" to save your changes. You'll have to type "y" to verify this.

If you've got GRUB installed in the MBR of your disk, you may have to re-install it with either procedure, and especially with the gdisk method. Since this is /dev/sdb, though, this may be necessary; GRUB might be installed on /dev/sda.

Now, the caveats I mentioned: Either of these procedures will repair the partition table damage. Your problem as a whole seems to involve much more than this. You've probably got damage to at least one NTFS filesystem, there may be Windows boot loader issues, and you seem to have one missing partition that this procedure will not recover. It's conceivable that juggling partitions around in this way will make Windows even more unhappy and unwilling to boot. Nonetheless, IMHO fixing the corrupt partition table must be your first priority; if you don't do that, you run the risk of causing more damage when you attempt to fix the NTFS or Windows boot problems.

If possible, I recommend you back up your important data before doing anything else. If necessary, go out and buy an external hard disk for this purpose. It's conceivable that attempting to repair the corrupt partition table will make matters worse, so having a backup is very very prudent.

As to your lost partition(s), your best bet at recovery is TestDisk, which can scan a disk for filesystem "signatures" and create new partitions to match any that it finds. I recommend you run TestDisk after repairing the damage in the way I've identified; however, I also recommend that you back up your partition table by typing "sudo sfdisk -d > sdb-parts.txt" and saving the resulting sdb-parts.txt file on a USB flash drive or some other medium other than /dev/sdb before you run TestDisk. That way, if TestDisk makes things worse (as it sometimes does), you'll be able to use sfdisk to restore your partition table as it will be prior to running TestDisk, even if there's a missing partition.

Good luck!

Thank you for your response. As you have said this is a large amount of work for an amateur. I have come to the conclusion that i want to back up the data on the 65gb "music" partition and can live without the rest. Whats the simplest way of restoring this data for backup?

You keep referring to a recovery cd. How does that work? Normally recovery dvd's are used, to my knowledge. The recovery program being too large for a cd. How was this recovery cd made? Through Control Panel?

I am using the windows recovery Cd as advertised on the Microsoft site.

EDIT: I've just had another look at the Disk Utility screenshot and the 47GB partition at the end is showing up as "Data". So perhaps the 60/65 is "Music" and the OP got them the wrong way round in post #10. Whichever, data or music, I'm sure the OP wants to rescue anything inside.

Yes sorry i must have got them mixed up.

Thanks all

[coffeecat]

I have come to the conclusion that i want to back up the data on the 65gb "music" partition and can live without the rest. Whats the simplest way of restoring this data for backup?

If I'm reading things correctly, that's going to be the most difficult to recover. Your music partition would seem to be somewhere in the space between sectors 78127102 and 205080576 which fdisk at the moment shows as not being allocated to a partition. Have a look at my post #21 and srs5694's reply at #23. What I suggested in #21 doesn't appear to be viable but srs5694 refers to testdisk which would be the way to go. If the thought of editing the partition table is too daunting, you could go straight to testdisk which seems to be your only chance of recovering the music partition. Believe me, testdisk is not as forbidding as it might first appear.

I don't believe you can run testdisk from your still bootable Ubuntu - you wouldn't be allowed to work on the disk you are running the OS from. Or so I believe - I'm happy to be corrected. But you can from the Ubuntu live CD so long as you can connect to the internet; you have to install testdisk in the live session.

Have a look here:

http://www.cgsecurity.org/wiki/TestDisk

and...

http://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

I really don't know how testdisk will fare with the impossibilities you already have in your partition table. You might want to wait for srs5694's comments before you go ahead. One tip I do have is to save the testdisk logs to a usb drive. You will be in a live session; anything saved will be lost when you power down unless you do. You might need those logs.

[srs5694]

Thank you for your response. As you have said this is a large amount of work for an amateur. I have come to the conclusion that i want to back up the data on the 65gb "music" partition and can live without the rest. Whats the simplest way of restoring this data for backup?

Try this from a Linux command prompt:

sudo mkdir /mnt/sdb3
sudo mkdir /mnt/sdb4
sudo mkdir /mnt/sdb5
sudo mount /dev/sdb3 /mnt/sdb3
sudo mount /dev/sdb4 /mnt/sdb4
sudo mount /dev/sdb5 /mnt/sdb5

The last three commands mount your three NTFS partitions. If they complain that you must specify the filesystem type, add "-t ntfs-3g" between "mount" and the device filename. These commands may or may not work. If they work (or if the partitions are already mounted), you should be able to identify their contents to figure out which is which. If one of them is your music, you should be able to copy it over to another disk.

If you can't mount one or more of those partitions, it'll be hard to identify, at least in Linux. Perhaps some Windows utilities would help, but I know relatively little about them. One that I do know is CHKDSK, which fixes disk errors; you'd call it like "CHKDSK C:" -- but what drive letters correspond to the Linux device filenames is something nobody can tell you with certainty at this point. Also, any utility that modifies the disk runs the risk of making things worse.

If none of those partitions is your music partition, you'll have to cross your fingers and use TestDisk; however, my suspicion is that TestDisk will be more likely to work if you've fixed your disk's partitions first. The strange partition table might confuse it. I don't know offhand if you could run TestDisk on an in-use disk. The limitation to which oldfred refers is a limitation of libparted; tools that work more directly on disks, such as fdisk and gdisk, don't have this problem. I don't know if TestDisk imposes such a limitation.

If you have problems with TestDisk and get really desperate, you could use Linux's fdisk to delete all your partitions and then run TestDisk from an emergency CD. There's a decent chance that TestDisk will recover everything, but if it doesn't, you won't be able to boot the computer at all. Do this only after you back up any important Linux-accessible data. Also, you can back up the partition table by typing "sudo sfdisk -d /dev/sda > parts-sda.txt" and saving the parts-sda.txt file on a USB flash drive, CD-R, or whatnot. This should at least give you the ability to restore the partition table by typing "sudo sfdisk --force /dev/sda < parts-sda.txt"; however, I can't promise that sfdisk won't choke on your bizarre partition table. You'd be able to recover, but only by editing it as I described earlier.

If even TestDisk fails, you could try PhotoRec, which scans a disk for individual files. The problem is that PhotoRec doesn't recover full filenames, so you'll have to manually rename all your files, which will be a pain.

In any event, before you do anything else, I recommend you look into that SMART status issue in more detail. A tool like GSmartControl (it's in the Ubuntu software repository) will produce far more data. Look for anything that's red-flagged as a problem, and look for a report on bad or remapped sectors.

[kirkface8]

Try this from a Linux command prompt:

sudo mkdir /mnt/sdb3
sudo mkdir /mnt/sdb4
sudo mkdir /mnt/sdb5
sudo mount /dev/sdb3 /mnt/sdb3
sudo mount /dev/sdb4 /mnt/sdb4
sudo mount /dev/sdb5 /mnt/sdb5

The last three commands mount your three NTFS partitions. If they complain that you must specify the filesystem type, add "-t ntfs-3g" between "mount" and the device filename. These commands may or may not work. If they work (or if the partitions are already mounted), you should be able to identify their contents to figure out which is which. If one of them is your music, you should be able to copy it over to another disk.

If you can't mount one or more of those partitions, it'll be hard to identify, at least in Linux. Perhaps some Windows utilities would help, but I know relatively little about them. One that I do know is CHKDSK, which fixes disk errors; you'd call it like "CHKDSK C:" -- but what drive letters correspond to the Linux device filenames is something nobody can tell you with certainty at this point. Also, any utility that modifies the disk runs the risk of making things worse.

If none of those partitions is your music partition, you'll have to cross your fingers and use TestDisk; however, my suspicion is that TestDisk will be more likely to work if you've fixed your disk's partitions first. The strange partition table might confuse it. I don't know offhand if you could run TestDisk on an in-use disk. The limitation to which oldfred refers is a limitation of libparted; tools that work more directly on disks, such as fdisk and gdisk, don't have this problem. I don't know if TestDisk imposes such a limitation.

If you have problems with TestDisk and get really desperate, you could use Linux's fdisk to delete all your partitions and then run TestDisk from an emergency CD. There's a decent chance that TestDisk will recover everything, but if it doesn't, you won't be able to boot the computer at all. Do this only after you back up any important Linux-accessible data. Also, you can back up the partition table by typing "sudo sfdisk -d /dev/sda > parts-sda.txt" and saving the parts-sda.txt file on a USB flash drive, CD-R, or whatnot. This should at least give you the ability to restore the partition table by typing "sudo sfdisk --force /dev/sda < parts-sda.txt"; however, I can't promise that sfdisk won't choke on your bizarre partition table. You'd be able to recover, but only by editing it as I described earlier.

If even TestDisk fails, you could try PhotoRec, which scans a disk for individual files. The problem is that PhotoRec doesn't recover full filenames, so you'll have to manually rename all your files, which will be a pain.

In any event, before you do anything else, I recommend you look into that SMART status issue in more detail. A tool like GSmartControl (it's in the Ubuntu software repository) will produce far more data. Look for anything that's red-flagged as a problem, and look for a report on bad or remapped sectors.

I get back an error after inputting above said commands.

Failed to read NTFS $Bitmap: Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

[srs5694]

If you get that error for all three partitions, then the only in-Linux solutions are rather drastic. You can try TestDisk to see if you can recover your missing partition and hope it's in better shape, but that runs the risk of doing further damage to your disk.

From here, this is what I recommend:

1. Buy a backup/replacement disk. Make it a little bit bigger than your current disk, just to give yourself some wiggle room in partition sizing.
2. Create partitions on the new disk in your desired layout. Be sure to include at least one partition for each partition on your current disk, and make each partition at least as large as its current-disk counterpart.
3. Use ntfsclone to copy the NTFS partitions to the new disk. The command to copy /dev/sdb3 to /dev/sdc1 would be "ntfsclone --overwrite /dev/sdc1 /dev/sdb3". If this fails, use dd instead, as in "dd if=/dev/sdb3 of=/dev/sdc1". Be very careful in your partition specifications; if you get them backwards, you'll wipe the data you're trying to preserve!
4. Use any tool like like (Clonezilla, tar, cpio, whatever) to copy your Linux partition to the new disk.
5. Use the Windows recovery tools on the new disk to try to recover the data in the NTFS partitions.
6. Use TestDisk on the old disk to try to recover the lost partition.
7. If TestDisk is unsuccessful, use fdisk to try to create a partition that matches the lost NTFS partition. Launch fdisk with its "-l" option and try creating partitions that start on 2048-sector, 16065-sector, and 63-sector boundaries; these are the most likely starting locations of the missing partition. Once you've created a partition, use blkid to see if it's valid NTFS data ("sudo blkid /dev/sdb7", or whatever the partition ID is). If it is, try to copy it with ntfsclone and recover it on the new disk. If not, try another start location. Note that you may need to delete some or all of the old disk's partitions before fdisk will let you create new partitions.