James G. Sack (jim) wrote:
Gus Wirth wrote:
rbw wrote:
I'm stuck... maybe someone has seen this before...
I have a PIII 450 PC with a 160Gb Western Digital HD which is managed
by "Dynamic Drive Overlay v9.88" by OnTrack. I need to run Knoppix
(v5.0.1 or v5.1.1) and mount that HD. Supposedly the solution is to ad
the following parameter when booting Knoppix like so:
knoppix hda=remap63
[snip]
Don't know if you have recovered this yet, but you might be able to take
a different approach to recovering the partitions. For all intents and
purposes, the disk is acting as if the partition table were damaged and
no longer valid. But the actual partitions are still there. In that
case, there are two tools I'm aware of that can find "lost" partitions
and help rebuild the partition table.
The first is called TestDisk <http://www.cgsecurity.org/wiki/TestDisk>
and is included in the SystemRescueCD <http://www.sysresccd.org> and
also in Knoppix.
The second is called PRecover <http://precover.sourceforge.net> Not sure
if any of the rescue disks have this on them.
To recover the partitions I suggest moving the disk to a newer machine
that can handle the large disk natively in the BIOS. The reason for
using the OnTrack in the first place was probably because of the BIOS
disk size limit. The OnTrack software intercepts BIOS Interrupt 13 (Disk
Services) and provides new mapping and functionality.
Once the disk is in the new machine, try using one of the above tools to
see if you can recover the partitions.
rbw sent me some data that revealed the presence of EZ-Disk rather than
Ontrack DriveManager.
The remap63 trick says to ignore 63 sectors (per the DriveManager
trickery), which produces nonsense if you _aren't_ using DriveManager!
There is a remap option (as opposed to remap63) which says to skip _one_
sector, which is supposed to be the way EZ-Disk does its magic.
AFAIK, Rodney hasn't gotten a chance yet to go back and look with the
1-sector offset hda=remap.
Recovery tools can do irreversible things. Best to:
a) have a backup .. the old recipe of working on a bit-copied disk is
appropriate for serious recovery (or forensic) work.
b) don't use a tool without understanding what it's going to do <heh>.
Regards,
..jim
Hey all...
Jim's eagle eye noticed what I missed and saved me the hunt. The fact is
that "hda=remap" worked for this drive w/ DiskManager installed as
advertised in the knoppix tips. (I kept using "hda=remap63" ... I think
I was tired...)
For the other part of the discussion which indicated you shouldn't use
the disk managers, the reason is that this particular PC (for the
nephews, kids, games, etc.) is an old PIII450 that actually performs
quite nicely. The BIOS doesn't recognize the 160Gb HD and they run XP on
it so thus the DiskManager.
The exercise I have been engaged in is to perfect a method of backing up
a broken WinDoze system (not this one, I'm just testing on the kids' PC)
without ever having to boot into WinDoze... AND end up with a backup I
can hand to the WinDoze victim customer/client/friend which requires
ZERO special knowledge to access their info/data on the backup media.
It took me a long time to think this through (I'm a compassionate sucker
and every time someone I know who is a a WinDoze victim asks for help I
end up wasting my time on their broken WinDoze box), but Jim Sack gave
me the last little piece of "Ah, HA!" that I needed to work this method
(besides this help with this switch). I just have to do some actual
testing under different circumstances to do some final proofs on the
concept.
In actuality this situation is actually fortunate because even though
you would only see this DiskManager situation once in 1000 chances it is
good to know what the correct switches are to make this procedure work.
Once I get it nailed down I'm going to volunteer to demonstrate it at
one of the meetings... Maybe we will be ready with video capture by
then, eh?
Thanks again Jim!
rbw
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
