Recovering lost disk geometry

[Esa]

Hello!

I'm having problems trying to get an old hard disk configured so that BIOS
can boot the OS as it was before removing the CMOS battery. I know I
should have put down the correct setting before pulling the battery, but I
had forgotten what the PCs of the mid 90's were like... Too bad the BIOS
doesn't have auto mode for disk geometry (old Siemens-Nixdorf PCD-4H
486DX) and the CHS parameters reported by the drive manufacturer don't
seem to work. Booting up always end with "NO OS" message...

The drive is Western Digital WDAC1210-00F, with the following info on
the cover: C/H/S: 989/12/35. I verified this from the web. The disk should
thus be about 202 MB (or 212*10^6 B) and have max 415380 sectors. From
what I recall from the running system, it couldn't have been configured
much smaller, since there was about 100-150 MB of free space beside an
ancient SCO Xenix and Informix database installations.

The reason I even bother with this is the system should run still for one
year as a information db for telephone operators, and I just succeeded in
reviving a messed up database on the same system. I would like to either
somehow dump the partition on another disk or to figure out the correct CHS
geometry for the disk. The disk can be attached either to Linux or Windows
workstation, if that helps.

I searched the Net for quite a while and among others, found a utility
called TestDisk (v.5.0), which (at least I understood so) should be able
to locate lost partitions. It did, in fact, find one on the disk. It said
after selecting Analyze from the main menu:

----(manual screencopy ----

disk 80: CHS 989 12 35 - 202 MB

4 * XENIX root 0 1 4 987 3 11 414618
Bad ending sector

-----

I presume this means the partition starts at 0/1/4 and ends at 987/3/11,
and probably the last would be the sector count for it.
While searching for info I found that the 1st primary partition should
start at 0/1/1, but I don't know if the disk was actually partitioned
bearing that in mind. I'm also aware that partitions should (in many
cases) end on cylinder boundary, which is still quite abstract idea for
me. However, I don't know whether Xenix used that rule.

If someone could help me with this - either by checking the geometry and
other BIOS settings from a similar factory installed system with the same
drive (if there is one anywhere anymore), or by directing me to a good
explanative resource on the subject, or by giving a method of figuring out
the correct geometry based on what can be found from the disk - I would
be very happy
Also, if someone has a working crystall ball, I'd appreciate a quick peek


Best regards,
Esa

 

[Jan van Wijk]

Hello Esa,

I'm having problems trying to get an old hard disk configured so that BIOS
can boot the OS as it was before removing the CMOS battery. I know I
should have put down the correct setting before pulling the battery, but I
had forgotten what the PCs of the mid 90's were like... Too bad the BIOS
doesn't have auto mode for disk geometry (old Siemens-Nixdorf PCD-4H
486DX) and the CHS parameters reported by the drive manufacturer don't
seem to work. Booting up always end with "NO OS" message...

The drive is Western Digital WDAC1210-00F, with the following info on
the cover: C/H/S: 989/12/35. I verified this from the web. The disk should
thus be about 202 MB (or 212*10^6 B) and have max 415380 sectors. From
what I recall from the running system, it couldn't have been configured
much smaller, since there was about 100-150 MB of free space beside an
ancient SCO Xenix and Informix database installations.

OK, what I would do if I where you, is setting the disk to the
WD-supplied geometry
in the BIOS to start with. (that will make sure you see the whole
disk).

Then, with a program that can find partition-records, bottsectors and
so on,
scan the whole disk and analyse the results.

Most likely you will be able to determine the correct geometry as used
before from that. Changing to this geometry might solve your error
message on booting. The most likely cause for the error message
is the fact that translating from the entries in the partition tables
results
in the wrong sector being accessed to read the XENIX bootsector.

The reason I even bother with this is the system should run still for one
year as a information db for telephone operators, and I just succeeded in
reviving a messed up database on the same system. I would like to either
somehow dump the partition on another disk or to figure out the correct CHS
geometry for the disk. The disk can be attached either to Linux or Windows
workstation, if that helps.

You can use my DFSee program for this analysis (and recovery if
needed).
It is a single distribution that contains a DOS, Windows and OS2
version.

You can either leave the disk in the current system and use a bootable
DOS
diskette, or mount the disk in a Windows (NT,W2K or XP) workstation.

For the DOS solution, you can download a self-extracting
diskette-image
that contains FreeDOS and the DFSDOS executable from:

http://www.dfsee.com/dfsee/dfsee6xx_dsk.zip

You can run the executable enclosed in the ZIP file on any DOS or
Windows
commandline, and it will create the bootable disk on a (formatted)
diskette in the A: drive.

If you mount the disk in a Windows system, you need the DFSWIN.EXE
executable
and DFSUNFD.DFS script from the standard disrubution:

http://www.dfsee.com/dfsee/dfsee6xx.zip

In both cases, you can search for partitioning info using the menu:

Actions -> Find partitions, All sectors -> 1 ... (select the disk)

As an alternative you can ru the DFSUNFD script (BAT file) as shown
below:

++++++++++ Runing the DFSUNFD procedure

You would need the DFSUNFD.DFS script that comes with DFSee, plus:
- For DOS or Win9x bootdiskettes DFSUNFD.BAT and DFSDOS.EXE.
- For Win-NT/2000/XP DFSUNFD.BAT and DFSWIN.EXE
- For OS/2 DFSUNFD.CMD and DFSOS2.EXE

You simply run the batch-file (.BAT or .CMD) without any parameters
and it will
collect FOUR files for every physical disk you have. (DFSUNFDI.*)

Based on the DFSUNFDI.* information a recovery script can be created.

You will most likely need assistance to do that, and that DOES require
you to have (or buy) a registration, see:

http://www.dfsee.com/dfsee.htm#register

Send all DFSUNFDI.* files (zipped to one file) to DFSee support at:

(e-mail address removed)

++++++++++

I searched the Net for quite a while and among others, found a utility
called TestDisk (v.5.0), which (at least I understood so) should be able
to locate lost partitions. It did, in fact, find one on the disk. It said
after selecting Analyze from the main menu:

----(manual screencopy ----

disk 80: CHS 989 12 35 - 202 MB

4 * XENIX root 0 1 4 987 3 11 414618
Bad ending sector

TestDisk might be comparable to DFSee (in finding partitions
but I am not familiar with it. From the result, it seems that
partition
was not aligned to cylinder boundaries.

-----

I presume this means the partition starts at 0/1/4 and ends at 987/3/11,
and probably the last would be the sector count for it.
While searching for info I found that the 1st primary partition should
start at 0/1/1, but I don't know if the disk was actually partitioned
bearing that in mind. I'm also aware that partitions should (in many
cases) end on cylinder boundary, which is still quite abstract idea for
me. However, I don't know whether Xenix used that rule.

I think XENIX did NOT obey those rules, which will make determining
the correct geometry a bit harder. However, I do think they did use
a regular bootsector, so finding that, and comparing its position to
the entry in the partition table (MBR sector) should be enough ...

If someone could help me with this - either by checking the geometry and
other BIOS settings from a similar factory installed system with the same
drive (if there is one anywhere anymore), or by directing me to a good
explanative resource on the subject, or by giving a method of figuring out
the correct geometry based on what can be found from the disk - I would
be very happy

There is some info (and links) about partitioning on my web-site, and
some more explanations about geometry in the DFSee documentation.

There is lots of info on the WEB too, but it is hard to find, and
often hard to understand ...


But I'll be happy to assist you

Also, if someone has a working crystall ball, I'd appreciate a quick peek

Sorry, no crystal ball here

Regards, JvW

 

[Esa]

Then, with a program that can find partition-records, bottsectors and
so on, scan the whole disk and analyse the results.

Most likely you will be able to determine the correct geometry as used
before from that. Changing to this geometry might solve your error

Yep, this was it. The partition table said the 4th partition (I've no idea
why it is #4 and not #1) starts at 0/1/1 and ends at 681/15/38, having
414618 sectors. I even verified this reading hex dump of the partition
table, which was both painful and fun at the same time
Finally I came up with the idea of writing a short script for finding out
all the possible combinations of CHS parameters which result disk size
between the size of the partition and the max sector count of the drive
(luckily there were only four of them!), and found the magical
combination which worked like charm

I just can't understand why the Siemens techie who installed that system
did use so odd geometry... Maybe they wanted to force customers to rely
on their support

You can use my DFSee program for this analysis (and recovery if
needed).

Thanks for the kind ad, but I prefer programs I feel I can use, and I was
quite lost with the interface of DFSee It prints out awfully lot of
stuff...

I used an util called partinfo to see a bit more than what testdisk
printed, but finally I noticed that plugging the drive in a linux box and
using linux fdisk (in expert mode) was the easiest for me. I could even
flexibly try alternate CHS values and see whether the partition table and
logical geometry agreed, and besides it printed both the partition table
info (with it called physical) and logical geometry side by side. But of
course, I'm familiar with linux fdisk, not all are

It seems testdisk printed the partition info after conversion with the
supplied CHS values, not the partition table data. This was a bit
confusing first.

I think XENIX did NOT obey those rules, which will make determining

Actually this one did end at cylinder boundary, after all, but that
doesn't mean it is forced by Xenix...

the correct geometry a bit harder. However, I do think they did use
a regular bootsector, so finding that, and comparing its position to
the entry in the partition table (MBR sector) should be enough ...

Yep, I think comparing the sector count of the partition from the
partition table and (ending_sector - starting_sector) from the logical
geometry would show whether the logical geometry is equal to the
original. I didn't check this after finding the correct geometry, though.

Thanks for the moral support

Esa

 

[Jan van Wijk]

Hi Esa,

Glad you got your problem solved.

Thanks for the kind ad, but I prefer programs I feel I can use, and I was
quite lost with the interface of DFSee It prints out awfully lot of
stuff...

Yes it does, but with the menu-system most basic things are
not that difficult anymore.

It is very powerfull and great to use for semi-remote analysis
using logfiles, and then scripts to make any corrections

I used an util called partinfo to see a bit more than what testdisk
printed, but finally I noticed that plugging the drive in a linux box and
using linux fdisk (in expert mode) was the easiest for me. I could even
flexibly try alternate CHS values and see whether the partition table and
logical geometry agreed, and besides it printed both the partition table
info (with it called physical) and logical geometry side by side. But of
course, I'm familiar with linux fdisk, not all are

Yes, if you know that very well that would be the better choice.

You could have done the same using DFSee by the way, after selecting a

disk you can use the 'geo' command to display or modify the geometry
used
to translate between linear and CHS addressing ...

You can even load the whole partitioning scheme in a 'virtual disk' to
play with it there without the risk of damaging anything.

Regards, JvW