I suppose that, strictly speaking, this is not a hardware issue but it seemed to fit best here?

Anyway, I had an old computer. A few years ago I bought an 80 GB disk for it, only to discover that it did not support such large disks. However, IBM provided something called OnTrack Disk Manager from their website. After installing this on the drive I could use the its full capacity.

The drive was installed as hda and the original 6 GB drive was installed as hdb. IIRC, hda contained 2 FAT32 partitions, 2 ext3 partitions and a Linux swap partition.

Then I installed Ubuntu on hdb, because I did not want to mess with my existing systems (Red Hat, Win98, Debian) on hda. However, even though I installed Ubuntu on hdb, it still installed Grub on hda (whithout my permission I might add) and over wrote OnTrack Disk Manager rendering hda useless. I had nothing I really needed on hda and I had work to do so I just ignored this at the time and went on using my freshly installed Ubuntu system on hdb.

But now I would like try and recover my files. I don't use that computer anymore and I have mounted the disk in one of them external cases that you plug into the USB port. I had hoped that would be enough, since this computer shouldn't have a problem with large disks. But of course it wasn't that easy.

I have tried testdisk and it finds two of my partitions but gets the sizes wrong. It seems promising, though. It seems that if I could only figure out the (fake) CHS value set by OnTrack I should be able to recover the partitions?

Any hints on how to proceed?

OnTrack Disk Manager shifts all disk accesses by 63 sectors and you can try to use sda=remap (change sda to the device ID the drive) of the boot parameter to enable this shift. I do not know if this will work with the drive connected using USB.

REF:
http://www.faqs.org/docs/Linux-HOWTO...isk-HOWTO.html

That seems promising. But it did not work. Possibly because the USB disk is discovered later in the boot process (even if it is plugged in) and so does not exist at boot?

If so, is there a way to set that parameter later?

Didn't think it would work. Next suggestion is to compile the USB and SCSI modules into the kernel or add the SCSI/USB modules into the initial ramdisk(initrd).

Whoaaa! I think there's a good chance I'll end up trashing my current system as well... Will have a look at those methods as soon as I have time.

What about sticking the drive back into the computer?

Yes, that does seem like the logical solution. I'll have a look at it when I get back home this weekend and see if I left enough parts in it. I use only my laptop nowadays and I remember ripping out the only parts that I thought could be usefull and then putting the rest of that old computer in a pile of things that await transportation to some dump... But I think there should be enough parts left to make it boot.

No, there was no RAM left in that computer but as soon as I can borrow some it should be in a bootable condition. ;-)

Just thought I'd post an update in case anyone else ever finds themselves in a situation like this. I've had the disk just lying around since I didn't have a suitable computer to put it in. Now I've finally put it in another old computer and managed to save my data. (Not that there was anything important on there, or I wouldn't have waited this long)

The drive was installed as hdc and it was just a matter of adding hdc=remap63 before booting (in GRUB, press E to edit the options before booting).

Might have worked. But it's non-free. And for my particular problem, the above solution seems the best way (now that I've figured it out and tested it), provided you have a computer to put the drive in, of course.