Hi,

I've run into problems with my 120 GB Seagate HDD. It used to hold four primary partitions
(hdb1 -reiserfs, hdb2 - swap, hdb3 - reiserfs, hdb4 - ext2). I took the disk out of computer for a while, then put it back and found it wouldn't boot. fdisk says

> fdisk /dev/hdb

The number of cylinders for this disk is set to 19483.
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)

Unable to seek on /dev/hdb

Here is what sfdisk says:

-----------------------------------------------------
> sfdisk -l /dev/hdb

Disk /dev/hdb: 14593 cylinders, 255 heads, 63 sectors/track
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
llseek: Invalid argument

sfdisk: seek error on /dev/hdb - cannot seek to 2180031657
Warning: The partition table looks like it was made
for C/H/S=*/191/63 (instead of 14593/255/63).
For this listing I'll assume that geometry.
Units = cylinders of 6160896 bytes, blocks of 1024 bytes, counting from 0

Device Boot Start End #cyls #blocks Id System
/dev/hdb1 178468+ 1749- 180213- 1084248621+ 83 Linux
start: (c,h,s) expected (1023,190,63) found (128,129,1)
end: (c,h,s) expected (1023,190,63) found (959,190,63)
/dev/hdb2 180212+ 1837- 178558- 1074288353 82 Linux swap
start: (c,h,s) expected (1023,190,63) found (959,190,63)
end: (c,h,s) expected (1023,190,63) found (959,190,63)
/dev/hdb3 180299+ 2707- 179341- 1079003430+ 83 Linux
start: (c,h,s) expected (1023,190,63) found (959,190,63)
end: (c,h,s) expected (1023,190,63) found (959,190,63)
/dev/hdb4 181171+ 19482- 195245- 1174686251+ f Win95 Ext'd (LBA)
start: (c,h,s) expected (1023,190,63) found (959,190,63)
end: (c,h,s) expected (1023,190,63) found (959,190,63)

---------------------------
> sfdisk -d /dev/hdb
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.
llseek: Invalid argument

sfdisk: seek error on /dev/hdb - cannot seek to 2180031657
# partition table of /dev/hdb
unit: sectors

/dev/hdb1 : start=2147516479, size=2168497243, Id=83
/dev/hdb2 : start=2168497306, size=2148576706, Id=82
/dev/hdb3 : start=2169541212, size=2158006861, Id=83
/dev/hdb4 : start=2180031657, size=2349372503, Id= f

It seems to me the partition table gone mad. Does anybody have a clue if the partition table can be recovered somehow or, at least, how to recover the data from the disk.
Any help is very much appreciated!

Have you changed anything in your bios setup since you removed an reinstalled the drive? In particular, if you changed from/to lba/auto mode for your hard drives in your bios that could cause a problem. Try switching that and see if it detects properly.

No, I haven't changed anything in bios, always used auto detection. The disk still detects as 120GB in POST. Do you think it is safe to change BIOS settings (C/H/S) and try to read the disk? I mean, can this damage anything if I try just to read the disk?

Also, I was thinking about changing the start address of partition /dev/hdb1 to 63 with sfdisk (this is what I have on /dev/hda1) and then perhaps using gpart to find partition boundaries. But as I am totally newbie on this, I do not know if this could help or all my data will be destroyed.

You apparently have two hard drives, hda and hdb. Was that the original configuration? Are you using a drive overlay program on any of the drives? Overlay programs are used to get around hard drive size limitations in the bios; they can frequently cause problems since they use a different method for sector translation than the bios.

Changing anything in the partition table risks losing the data on the drive so that's the last thing I would try. If you have any livecds around like knoppix, try booting off that and see if it can read the data on hdb. If it can, back anything on hdb that you want to save since your at risk of losing the data. If you have space on hda, knoppix has a partition imaging program included called partimage which can be used to image each partition on hdb assuming hdb can be read in knoppix. If you can do this, it would be the safest since you can image the hdb partitons and save them on hda then if you screw things up on hdb you can repartition it and restore the the hdb partitions from the image files. Partimage has about 2 to 1 compression.

If the data on hdb is important your first priority should be to access and back up the data since it's in danger of being lost.

Here's a link that discusses sector translation problems from a windows perspective that you might find useful in troubleshooting:

http://service1.symantec.com/SUPPORT.../1996112575859

After backing up, I think the first thing I would try is setting the bios to lba and see if that helps.

Hi,
Writing to say that my nightmare is over! When no bios manipulations helped (actually, auto was equivalent to lba, so setting it manually had no effect), I desperately googled around one more time and was lucky to come across a small GPL(!) utility named testdisk

http://www.cgsecurity.org/index.html?testdisk.html

This utility has miraculously discovered what partitions I had on /dev/hdb and wrote the corrected partition table. I got all my data back intact. Highly recommended!

Anyway, many thanks for the advice and response I received on my post!