Hard drive got messed up by fedora installer crash!

the_mulletator · 06-05-2009, 02:07 PM

My friend was trying to install fedora 10 from a live usb.
I told him all about linux and he was ready to switch from windows.
He was trying to install on an external hard drive.
During the install the fedora installer crashed and said there was an unhandled exception and the process could not be completed. It also said "This is probably a bug"

He rebooted and he could no longer read his internal hard drive!
It had two partitions on it and a windows recovery partition now the two appear to be one larger partition and the recovery stilll exisits.

What a disaster. I'm trying to help him get the data off but I can't mount the drive. I can mount the recovery partition but nothing else.

It shows up like this in fdisk -l:

Code:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          25      200781   12  Compaq diagnostics
/dev/sdb2   *          26       19457   156087540   8e  Linux LVM

fdisk gives me this:

Code:

[root@localhost ~]# fdisk /dev/sdb2
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xef7ec2db.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.


The number of cylinders for this disk is set to 19432.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
   (e.g., DOS FDISK, OS/2 FDISK)
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

PVS gives me this:

Code:

[root@localhost ~]# pvs /dev/sdb2
  No physical volume label read from /dev/sdb2
  Failed to read physical volume "/dev/sdb2"

unSpawn · 06-05-2009, 07:09 PM

So apparently he didn't install to the external harddrive but his internal one. That unfortunately is a human error and one no installer can compensate for. Maybe it is one of the reasons installation documents emphasise making backups.

In laymans terms priming a disk before installation means first creating one or more partitions. This alters the partition table. One tool for recovering partition tables based on remnants of partitions is testdisk. After partitioning is complete a filesystem is created. If the partition area already contained another filesystem then formatting basically overlays a mesh-like structure over the existing data. Because files are referenced in the meta-data of the directory being cut off from the filesystem structure means they become orphaned. If files occupy a continguous area or are easily recognisable by a starting and end signature then "file carvers" like photorec, foremost or scalpel can be used to try and recover files. Mucking with live partition data, mounted in read-write mode, is ill-advisable if you have not made a backup. Note that testdisk and photorec both have test and log options. I suggest you do a dry run with both before actually doing anything.

the_mulletator · 06-05-2009, 10:56 PM

Thanks!
I used testdisk to create a new partition table and the drive is totally fixed.

I still don't understand how this happened though. It was not human error. He did not get to the point in the install where you choose what drive to install on. The installer crashed before that point. I have installed many different kinds of linux in different ways and never had this happen.

My friend's faith in linux is restored along with his data so this story has a happy ending.

syg00 · 06-05-2009, 11:25 PM

Deleted - it had all been said.