FC3 can't read my old second harddisk (hdd), yet FC1 got no problem.

[tanm]

Hi guys,
Have to turn to guru in this forum.I just installed my Fc3 with kernel 2.6 and it does not see my second harddisk.(hdd)

on FC3
$ dmesg
...
Probing IDE interface ide1...
hdc: TSSTcorpCD-RW TS-H292B, ATAPI CD/DVD-ROM drive
hdd: QUANTUM FIREBALLlct20 10, ATA DISK drive
...
hda: 156250000 sectors (80000 MB) w/2048KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
hda: hda1 hda2 hda3 < hda5 hda6 hda7 >
hdd: max request size: 128KiB
hdd: 20044080 sectors (10262 MB) w/418KiB Cache, CHS=19885/16/63, UDMA(33)
hdd: cache flushes not supported
hdd: hdd1[DM]
...
FAT: invalid media value (0x7c)
VFS: Can't find a valid FAT filesystem on dev hdd1.
..

on FC1
$dmesg
...
hda: 156250000 sectors (80000 MB) w/2048KiB Cache, CHS=9726/255/63, UDMA(100)
hdd: attached ide-disk driver.
hdd: host protected area => 1
hdd: 20044080 sectors (10263 MB) w/418KiB Cache, CHS=19885/16/63, UDMA(100)
Partition check:
hda: hda1 hda2 hda3 < hda5 hda6 hda7 >
hdd: [DM6: DDO] [remap +63] [1247/255/63] hdd1 hdd2 hdd4
...
Still no clue after 2 weeks
Any suggestion ?help?guide/leads?
Thanks in advance

tanm

[bwkaz]

hdd: hdd1[DM] Hmm, [DM]?

What partition table format does this disk have on it? Are you using Linux's device mapper or something on that drive? (I'm not entirely sure what the device mapper does, but I think it's related to EVMS, which is some kind of logical volume management thing, perhaps to allow online resizing of partitions.)

If FC3's kernel doesn't have the device-mapper driver loaded at boot time, it won't be able to recognize this drive properly; that could be why you don't get either hdd2/hdd4 or a usable VFAT partition in hdd1.

[tanm]

Thanks bwkaz,
I have to admit I used the Quantum 's OnTrack Disk Manager (DM?) to format the old hard disk few years back.

For the format; hdd1 is vfat, and hdd2 is ext2.
And It is still running perfect under my triple-boot FC1 (kernel 2.4)


?????
Thanks again
tanm

[banzaikai]

tanm:
on FC3
hdd: hdd1[DM]
on FC1
hdd: [DM6: DDO] [remap +63] [1247/255/63] hdd1 hdd2 hdd4
I used the Quantum 's OnTrack Disk Manager
For the format; hdd1 is vfat, and hdd2 is ext2.
Yup. That's your problem. The Disk Manager installs a "Dynamic Drive Overlay (DDO)" that fools the BIOS into seeing a smaller drive than what's there, then re-mapping things once booted. When run, the utility will only install if it determines that the BIOS has a 2GB/8GB/32GB/132GB limit, depending on what drive you're installing. It looks as if the BIOS that was being used when the drive was prepped had either a 2 or 8 GB limit for drive size, and the DDO was installed. If you boot with the proper Windows boot disk and run fdisk, you'll see it as a "non-DOS Partition".

If the drive is now on a newer machine with a current BIOS, or the old BIOS has been flash updated, then you may be able to run the OnTrack utility to remove the DDO (I think they refer to it as "Drive Migration", IIRC). Backup everything before you do!. I've never done this when an ext# partition was on it, but FAT seems to survive pretty well after the "surgery".

Another thing just popped into my head: the DDO expects the drive to be set at a given C/H/S in the old BIOS. Typically, it's 1024 Cyl, 16 Hds, and 63 Sect. Try manually setting it to this in the new BIOS to see if the DDO behaves as advertised (the "+63" entry reminded me that it's using the 63-sector offset mode, which is supposed to emulate the 1024/16/63 setting). Also, it installs the DDO on the boot drive. If this was the slave in another system, and you moved just this drive over, then it's DDO is still on the boot drive in the old system. This may also explain why the older (FC1) system can use it, but the newer (FC3) can't. It's all a matter of where that DDO is sitting.

banzai "really offset" kai

[tanm]

Thanks a lot ,banzaikai
This seems like a major operation. Totally blank on this.
May be more reading again.
From your lead, I found out there is a module ide-geometry.c in kernel 2.4x that handle Ontrack Disk Manager's offset and EZ-Drive remapping but not in my FC3.
How do I include this old module in a new kernel?

Any help will appreciated.

Regards
tanm

[banzaikai]

Like I said, I'd just use the original Disk Manager to remove the DDO/Offset, since it put it there to begin with. Barring that, then I found this (http://www.linux.com/howtos/Large-Disk-HOWTO-8.shtml) , which seems a bit complicated (unless the 2.6.x kernel understands the "hdx=remap63" command, which it may not). From the looks of things...

Easy = add the remap63 option (if it'll work)
Harder = run OnTrack and have it remove the DDO (must have version used originally)
Harder Still = say "fsck it", put drive in old box, back up data, put drive in new box, re-prep from scratch
Bleeding Forehead = try recompiling kernel with a feature that may/may not work, without "screwing the pooch" (you should be able to fall back to an earlier kernel version if it doesn't work - mount the drive read-only just in case)

I can see the validity of having this deprecated in the newer kernels, as I haven't seen a DDO-laced HD in quite some time (due to the BIOS using Flash EEPROM and most people's aversion to running a modern OS on a 486SX25). You may have to check the drive manufacturer's website to see if the OTDM is still downloadable. It should be a floppy image that auto-boots into the setup program, where you select "Advanced Options", and scroll through 'til you find the "Remove DDO" or "63 Sector Offset" area.

Oh, and back up all data first - ya never know...

banzai "DD-doh!" kai

[tanm]

Thanks banzaikai,
hdd= remap63 still not working.( remap, noremap does nothing)
I will do more reading before deciding to go into the operation theater.

Thanks again
tanm