News Group Posts

mounting old hard drive divvy disk geometry

From: Bela Lubkin <belal@sco.com>
Subject: Re: Can't mount drive with install disk.
Date: Wed, 13 Feb 2002 13:13:58 GMT
References: <XYfa8.4204$QQ3.1308363@news1.news.adelphia.net>
<20020212140241.N10348@mammoth.ca.sco.com>
<5dha8.4287$QQ3.1324669@news1.news.adelphia.net>
<20020212162333.P10348@mammoth.ca.sco.com>
<Ikka8.4430$QQ3.1358838@news1.news.adelphia.net> 

Chip wrote:

> > If it shows start/end blocks but not names, assign names.
> > I forget what release of the OS you're trying to recover
> > (_always_ include that information).
> SCO UNIX System V/386
> 3.2V4

Close.  That's enough information for this purpose, but there should be
another digit as in "3.2v4.2" or "3.2v4.0" or whatever.  Provide that in
future.

> > The geometry reported by FreeBSD is 1048 cylinders, 127 heads, 63
> > sectors/track.  Now, what is the geometry that OpenServer's seeing?
> > From your boot disk environment, run:
> >
> >   dparam /dev/rhd00
> >
> > and show us the results.
> 
> I could not run dparam from the boot disk
> environment so I got another SCO server
> ( I have 43 of these things) and went through
> all of the previous steps to change the root
> password with the install disk and CD and log
> in as root.
> 
> I now have the hard drive installed as the third
> drive on a SCO server that I can get to root and
> perform whatever needs to be done.

No, you can't.

SCSI disks on OpenServer obtain their geometry from a combination of the
motherboard BIOS, host adapter, host adapter BIOS, and disk.  Once the
geometry is established, it must be kept the same even if the disk is
moved to a different machine.  But you don't know what the original
geometry was, and you've just changed three of the four things that
determine it.

> I ran dparam /dev/rhd00   # which is now the new boot drive
> 1022 138 0 0 0 0 0 63
> 
> also ran dparam /dev/rhd01  # second drive on system
> 1022 138 0 0 0 0 0 63
> 
> The problem drive is now the third drive on this system
> which is SCO UNIX System v/386
> release 3.2
> 
> When I try to mount this drive I get the same error I
> got from the floppy and I if I run dparam /dev/rhd02
> ( for third drive) I get "Could not open special device,
> no such file or directory.

You are using wrong device names.  Read the man page hd(HW).  /dev/rhd00
is the "whole disk" device for the first hard disk.  /dev/rhd01 is the
"first partition" device for the first hard disk.  The two dparam's you
ran above both applied to the same piece of hardware, so it's no
surprise the numbers were the same.

There were two drives in this new machine before you touched it; those
would be /dev/rhd0? and /dev/rhd1?.

> I am a little confused about the hard drive numbering
> system with SCO.  I looked into the /dev and noticed
> the following types available:
> hd01 through 4
> hd0a and d
> hd10 through 14
> hd1a and d
> and the same with an r prefix.

The ones without "r" are block devices, with "r" are raw devices.

> I tried to fdisk, divvy and dparam all of the above options
> with no luck.

You should have had lots of luck as far as those commands doing
_something_ on the various devices you tried.  But none of those devices
applies to the new, 3rd hard disk.

> I'll look through the DOCS to learn more about them
> 
> I did run divvy on the new hard drive and saw that the
> file type was EAFS,  the root name was on 0 not on 2
> so I asume that it is an older OS version on the new server.

You must have run divvy on one of the existing drives, mistaking the
naming scheme.

You run a very high risk of damaging this new machine you've introduced,
since you're fiddling with devices that actually apply to its existing
drives.

If you were going to keep playing on the new system, you would have to:

  1. make sure the 3rd drive has a different SCSI ID from anything else
     on the bus, and that the cables are all correct

  2. run `mkdev hd` and tell the kernel about the new drive (it will ask
     for its coordinates in SCSI space: host adapter driver name,
     sequence number of that adapter within that driver, SCSI ID, and
     LUN -- I don't think 3.2v4.x was asking about bus numbers yet)

  3. relink, reboot to let the kernel see it

  4. run `mkdev hd`, give it the same SCSI coordinates, now it will run
     fdisk and divvy for you

  5. fail, because the geometry would still be wrong

Having gotten to that failure point, there is something you could try.
That is: once you have a whole-disk node for the disk (/dev/rhd20),
search it for evidence of the old geometry.  Every time the system
boots, it prints a "%disk" message that includes the geometry.  That
gets logged to /usr/adm/messages and /usr/adm/syslog.  You can't access
those files _as files_ until you have recovered the disk completely, but
you can still find the strings.

So, get the drive sufficiently set up (as above), then run:

  strings /dev/rhd20 | grep 'cyls=.*hds=' > /tmp/geometry-candidates

This might make a large file.  When it's done, look at it.

A system I tried here produces:

 14   -  type=W0 unit=0 cyls=7297 hds=255 secs=63
  -   -  cyls=1106 hds=255 secs=63 fts=stdb
  -   -  cyls=4462 hds=255 secs=63 fts=stdb

It has three disks.  I can see how big each is: multiply cyls * hds *
secs * 512.  These three are 60GB, 9GB and 36.7GB drives.  If your
`strings` exercise produces multiple different values, multiply them out
and decide which sounds like it applies to your drive, which (if I
remember right) is about 4.3GB.

Once you have that, you can attempt to stamp the right geometry.

Run:

  dparam /dev/rhd20

Write down all the numbers.  Now replace the first number with cyls, the
second number with hds, and the _last_ number with secs.  Now run:

  dparam /dev/rhd20 ...parameters...

filling in the original parameters with the replaced cyls/hds/secs
values.  Be sure you are doing this to the right drive.  I've used
/dev/rhd20, which is the whole-disk device for the 3rd drive in a
system.  While you're adding the drive with `mkdev hd`, pay attention to
what number it is assigned; it won't necessarily be 2.

Once you've stamped the right geometry, run:

  divvy /dev/rhd20

Since you're running 3.2v4.x, it will _not_ give sane filesystem types
until you've named the divisions.  So give them names (like "oldroot",
but the specific names don't matter).  Then quit divvy (tell it to
"install" the changes).  Then run it again.

If you've made it this far and gotten everything right, sane filesystem
types (like "EAFS") should now appear.

The very next thing you should do is mount the filesystems READONLY,
i.e.

  mkdir /oldroot
  mount -r /dev/oldroot /oldroot

and BACK THEM UP to tape or whatever you use!

>Bela<
 

Comments?

Jump to Comments

Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.

Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.

We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.