A.P. Lawrence

reconstructing dparam disk geometry changed

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Boyd Lynn Gerber <gerberb@zenez.com>
Subject: Re: OSR 5.0.6a Strange problem after BIOS upgrade FLASH and IDE
Date: Thu, 17 Jan 2002 00:35:15 GMT

On Wed, 16 Jan 2002, Bela Lubkin wrote:
> You seem to think that the most important thing learned here is "don't
> run BIOS HD detect after the HD is already working with OpenServer".  I
> say you've learned something far more important (which ought to be
> written up for the FAQ).

For a novice I think knowing that if they run the HD detect after they
have installed the system will make it unbootable and unmountable is
important.  I would never have guess that even though the BIOS was
orignally set using the BIOS HD detect, that running it again would make
the system unbootable.  I agree totally about writing it up.  I have done
the first part and already sent it to tony.  I am trying to decide how
best to write up the rest.

> That is: if you _do_ run the BIOS HD detect, and lose control of the
> drive, you can recover it.
>
> First, learn the "right" parameters according to Unix.  You might have
> previously recorded them, might be able to `strings` the drive, might be
> able to examine /usr/adm/messages or /usr/adm/syslog from a prior backup
> of the drive.  Or you might, in fact, be able to use one of the BIOS's
> parameter sets (does 9693/128/63 match any of the configs the BIOS came
> up with?)  -- that is, it may be the case that even with the BIOS
> claiming the same parameters as it always did, you still need to have
> Unix restamp the drive.

I have done alot of different recovery with SCSI drives.  I have mucked
with drives after a BTLD I wrote for a SCSI controller skrewed my disk and
I did not have a backup.  I just have never done it wit IDE drives.  So
the procedure was already well know on what to do once I found the correct
parameters.  With SCSI devices and unknowns I often look at what is
happening with a SCSI sniffer or SCSI bus analyzer and then with dd I can
play with it and massage it to do what I want.  I do not know if they make
such things for IDE, they may and I just have never used them.  Sadly the
BIOS once upgraded would not give the magical 9693 128 63 parameters.
And all the syslog and messges file were compress using gz.  To make a
long story short I dumped all the strings -a to a file and looked for know
file names.  Then I used dd to get the data off the drive till I got the
file and was able to gunzip it.

I must admit I did find out that the IDE drive did have to be stamped with
the Unix restamp to get the drive to work after running the BIOS detect.
I did have a drive that I did not care what was on it.  So I was able to
play and learn by distruction.  I do not think I have ever done as many
installs as I did learning about how the IDE drives and OSR worked
together.  I did this on 9 totally different Mother Boards (MB) and 40
different sizes of HDS on each MB.

Control Spam and Viruses

Run your own mailserver

> Second, restamp the drive.  That means getting the Unix kernel up and
> running, could be from a boot floppy, the install CD with "tools", a 3rd
> party crash recovery floppy (RecoverEDGE, AirBag, etc.), or by putting
> in a different hard disk and doing a minimal install.  Get to a shell
> prompt.  Find or create a device node that points to the drive in
> question (/dev/rhd00 if it's primary/master; could be rhd10 or something
> else).  Run:

I agree this would have been a lot easier with a thrid party backup, but
it was my friends drive and he has not purchased one and he did not have
any boot disk specific to his system.  I did try at various stages with
with the F8 key while booting from the OSR 5.0.6 CD and with generic OSR
5.0.6a boot floppies.  I never could get the generic boot floppies to
work.  I did find that if my friend had made boot floppies specific to the
machine it could be done, but I never could get generice boot floppies to
to work.  Part of the problem may have been my combination of different
SCSI controllers and IDE devices that I have.

>   dparam -w /dev/rhd00
>   dparam    /dev/rhd00
>             # or rhd10 or whatever

The dparam -w /dev/rhd20 did not fix the problem or what ever device
needed depending on where the drive was located.  This often does fix the
problem with SCSI devices.  I did find I had to match exactly the correct
parameters with how the device was configured.

> to print existing parameters, then run:
>
>   dparam    /dev/rhd00 cyls hds ppp qqq rrr sss cyls secs
>             # or rhd10 or whatever
> where ppp/qqq/rrr/sss are the middle 4 of the existing parameters, and
> cyls/hds/secs are the "right" parameters.  "cyls" gets stamped twice,
> once for the size of the drive and once for landing zone.

Good advice to get them.

> Third, go into BIOS setup and set the drive back to "auto".
>
> Fourth, if necessary, rearrange drives (e.g. if this was once, and is
> desired again to be the boot drive, move it back to primary/master).
>
> This won't necessarily work in all cases, it's just _one_ discovered way
> of recovering from an IDE disk geometry problem.  Also, steps "Second"
> and "Third" might need to be done in the reverse order, and you will
> probably have to change things again in the BIOS if you physically
> rearrange drives.

Thanks for the previous good advice and words above.  I did find that even
if the BIOS setting did match the drive it would not necessarily boot.  I
did find that for all the 40 different drives I tested 32 being less than
40G and 8 being 40G or larger that on these 9 different MB's any thing
less that 30G worked great with the BIOS detect, but 40G and larger the
only setting that worked all the time was... (BTW I am trying to give this
below from memory so it may not be totally accurate.)

TYPE    SIZE    CYN     HEADS   PRE     LZ      SECTORS MODE
AUTO            XXXX    YYYY    N       NNNN    NN      AUTO

in my case you could not set the MODE to anything but AUTO because the
BIOS would give a hard disk failure with the correct CYN HEADS...SECTORS
after the BIOS had been flasked.  What I did learn is different version of
Mother Board BIOS can and often do set things different.  Fortunately auto
setting with a valid UNIX stamp/restamp does work.  Getting it will varry
upon how the system is being used.  I setup his system so I knew there was
a file called messages.org.gz syslog.org.gz so all I had to do was find it
and uncompress it.  I have mucked with the dd images before and laid them
back on a hd not a lot of fund but it too does work.

Thanks,

--
Boyd Gerber <gerberb@zenez.com>
ZENEZ   3748 Valley Forge Road, Magna Utah  84044

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

/Bofcusm/1411.html copyright 1997-2004 (various authors) All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here