APLawrence.com -  Resources for Unix and Linux Systems, Bloggers and the self-employed

SCO Unix, Xenix and ODT General FAQ

This article is from a FAQ concerning SCO operating systems. While some of the information may be applicable to any OS, or any Unix or Linux OS, it may be specific to SCO Xenix, Open This article is oriented toward SCO Unix. Some of it is applicable to Linux, but the main focus is SCO. There is lots of Linux, Mac OS X and general Unix info elsewhere on this site: Search this site is the best way to find anything.

I need to transfer a SCO Unix hard drive to another machine as a secondary, mount it and recover the data.

This is something that is fairly easy to do though a little scary if you haven't done it before.

You may need to be concerned with drive geometry. There are two posts from Bela Lubkin reproduced below that disuss this at length, but the basic problem is that the geometry needs to match what it was in the old machine.


You may also want to read

In any case, the general procedure to add the drive is this:

The posts below talk about a specific case but may be of interest to you:

From: Bela Lubkin <belal@sco.com>
Subject: Re: OSR 5.0.6a Strange problem after BIOS upgrade FLASH and IDE
Date: Sun, 13 Jan 2002 22:46:45 GMT
References: <3C41B914.8D64B3E0@tkg.ca> <Pine.SC5.4.43.0201131003210.15491-100000@xenau105.zenez.com>

Boyd Lynn Gerber wrote:

> > 1. Add 80G HD, MB BIOS not able to boot.
> > 2. Upgraded MB BIOS, Unix bootable, hence BIOS upgrade not the problem.
> > 3. mkdev hd to add disk, reboot Unix so all HW and BIOS tested twice.
> > 4. Unix can find the 80G HD and FDISK it, so Unix is not having a problem.
> > 5. On reboot now getting a stage 1 boot error. The last thing that was done
> > was the fdisk, any chance of 'fdisking' the wrong drive? I normally
> > run 'mkdev hd' a second time, not a manual fdisk. What was the reason
> > to run fdisk and reboot?
> This is correct for the most part. The second mkdev hd all that was done
> was show partition table... no partition was shown on disk, i.e. blank
> partition. Create partition use whole disk. quit install partition. hit
> the delete key to stop mkdev hd. Then with fdisk all I did was show the
> partition and quit no update just quit.
> > > partitions with the sizes all being correct but did not have the EAFS or
> > > HTFS in the filesystem type. The only time I have seen this with SCSI
> > > devices is with the adaptec BIOS being in different modes LBA vers non
> > > LBA.
> > >
> >
> > Yes, changing a disks parameters and running FDISK on it leaves a partition
> > table, but generally no correct filesystems.
> >
> > Can you HD the raw device that points to the boot filesystem? Does it
> > still have data? It may be possible to recover the filesystems with
> > a raw disk editor. Tough work.
> hd on boot and root show data. It even looks good compared to the booting
> 80G HD.

We're not going to be able to solve this in cookbook manner for you --
you have to be at the controls with a clear understanding of what you're

It sounds like, during all the gyrations, you overwrite the disk
parameters for the 40GB disk (equivalent of running `dparam /dev/hdx0
bunch of numbers`). To restore access to the disk, you need to restamp
it with the right parameters, where "right" means "whatever they were
before the drive became inaccessible".

There are many ways to learn the old parameters. Perhaps the easiest is
this: connect it to a working system and dump the contents of the drive,
searching for "cyls=". See, somewhere on the root filesystem on that
drive are the files /usr/adm/messages and /usr/adm/syslog, both of which
will have a whole bunch of messages similar to:

%disk 0x01F0-0x01F7 14 - type=W0 unit=0 cyls=2434 hds=255 secs=63

You're looking for the messages associated with "type=W0" (i.e. primary
wd1010/IDE controller), "unit=0" (master).

Since you have a new blank-slate Unix install on the 80GB drive, and
have the 40GB drive in place, you're most of the way there. You need to
do something like:

strings -a /dev/rhd10 | grep cyls= > /tmp/old-parms

Then look through the output. You will have lost the "%disk... 0x"
parts because `strings` things a TAB is a non-printable char. So the
output will look like a bunch of:

14 - type=W0 unit=0 cyls=2434 hds=255 secs=63

lines. Pick out the W0/0 entries. If they aren't all identical, choose
the one that appears most frequently. Apply those parameters to the
drive. Then look at it with fdisk & divvy, see if things look sane (in
particular, you're looking for divvy to report sane filesystem types).

By "apply those parameters to the drive", I mean something like:

dparam /dev/rhd10 # print existing parms
dparam /dev/rhd10 cyls hds ... cyls secs

where "..." should be the middle 4 of the existing parameters. (cyls
appears twice, once for the size of the drive and once for landing


Boyd Lynn Gerber wrote:

> On Sun, 13 Jan 2002, Bela Lubkin wrote:
> > Since you have a new blank-slate Unix install on the 80GB drive, and
> > have the 40GB drive in place, you're most of the way there. You need to
> > do something like:
> >
> > strings -a /dev/rhd20 | grep cyls= > /tmp/old-parms
> I found 9693 128 63 as the correct parameters.
> > dparam /dev/rhd10 # print existing parms
> > dparam /dev/rhd10 cyls hds ... cyls secs
> dparam /dev/rhd20 9693 128 0 0 0 8 19157 63 and setting the bios to auto
> was the solution.
> I have found through a bit of testing that after a HD has been installed
> and working to not run the BIOS HD detect when adding a new HD. It is
> better to manually set it up with the proper HD settings.
> Thanks to every one. I was finally able to recover my friends data.

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).

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.

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:

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

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.

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.


And finally this from Boyd

I think maybe what I have learned could possible go into the FAQ. I am
not really sure how to write it up. This is what I have learned.

1. If system is running a HD greater than or equal to 40G do not run the
BIOS IDE auto detect. I had a 80G HD that I did a lot of testing with. I
ran the IDE auto detect after the installation and the system would not
boot. I would get a boot stage 1 error. To make sure it was not just the
gigabyte GA-BX2000 MB I tried it on 2 other different gigabyte MBs, 4
different Asus MB, and 2 other No brand name MB. In every case if I ran
the BIOS detect I would get a stage one boot error. The key to getting it
back is you have to find the

%disk 0x01F0-0x01F7 14 - type=W0 unit=0 cyls=9729 hds=255 secs=63

on the HD with a strings -a and then a dparam with the correct settings.

I found that after wiping out the stored values that setting the BIOS to
Auto and Auto for the type of (LBA, NORMAL, LARGE) then the system would
boot as long as a BIOS auto detect was not run. The BIOS auto detect
could be run on disks less than 40G and it did not matter.

Good Luck,

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

This may also be helpul: Need help cloning drive..

Got something to add? Send me email.

(OLDER)    <- More Stuff -> (NEWER)    (NEWEST)   

Printer Friendly Version

-> (SCO Unix) I need to transfer a hard drive to another machine as a secondary.

Printer Friendly Version

Have you tried Searching this site?

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.

Contact us

Printer Friendly Version

FORTRAN's tragic fate has been its wide acceptance, mentally chaining thousands and thousands of programmers to our past mistakes. (Edsger W. Dijkstra)



Unix/Linux Consultants

Skills Tests

Unix/Linux Book Reviews

My Unix/Linux Troubleshooting Book

This site runs on Linode