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
Desktop or Openserver.
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.
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.
READ THOSE BEFORE YOU REMOVE THE DRIVE FROM THE OLD MACHINE IF
You may also want to read
In any case, the general procedure to add the drive is this:
- For SCSI, set the SCSI ID to an unused ID. For IDE, connect the
drive to a controller with a free position, and adjust master/slave
jumpers appropriately. This may also require changing settings on
your master drive. If you don't understand that, YOU PROBABLY
SHOULDN'T BE DOING THIS, or at least you should seek the advice of
someone who understands the phyical installation of IDE or SCSI
devices. Consider this rather obvious statement: if the machine's
BIOS or SCSI adapter can't see the drive, Unix certainly won't
- Physically install the drive.
Some comments from Bela Lubkin:
For either SCSI or IDE, it is wise to check BIOS
settings at this time. IDE setting names (and meanings) vary
greatly from one BIOS to the next. generally want "LBA", but won't
necessarily have that name in all BIOSes. may need to revisit this
step multiple times because of delicate dance between BIOS settings
and convincing the kernel to see the drive with the right geom.
For SCSI, want to make sure drive is set for
right transfer rate, disconnect/reconnect, etc. -- advice here
should be something about "check, but don't change anything unless
you're sure it's wrong; _and_ be sure to write down both old and
new settings of anything you do change, in case have to change
- SCSI: Run "mkdev hd" to add the device to the kernel.
- Run "mkdev hd" again (first time if IDE). DO NOT overwrite or
change the partition table or the bad block table. Just quit out of
those menus to proceed.
You will get a WARNING that you could be overwriting existing
data. That is a warning; it means you CAN overwrite it if you WANT
Tell it you want block-by-block control of the layout of the
filesystems. That's important. This will bring you to the "divvy"
Alternately, you can invoke divvy directly on a device node that
points at the disk: see "man HW hd."
- Once in divvy, (n)ame the file systems appropriately (the name
field will be blank). "oldhdroot" "oldu" "oldboot"- whatever you
like, so long as the names are different from any existing name.
Alternatively, you could just create appropriate device nodes
manually, but if you knew that much, you wouldn't be reading this.
DO NOT CREATE NEW FILESYSTEMS! The "New FS" column should remain
set to "n".
Bela reminds me that on older OS versions, the file systems
without names the filesystem "Type" field will be incorrect. Don't
let that worry you for the moment.
- (q)uit and (i)nstall the division table as you would for any
The file systems can now be mounted wherever you like. Run
"mkdev fs" or mount them manually.
The posts below talk about a specific case but may be of
interest to you:
If this page was useful to you, please help others find it:
From: Bela Lubkin <email@example.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.firstname.lastname@example.org>
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
dparam -w /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
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.
Boyd Gerber <email@example.com>
ZENEZ 3748 Valley Forge Road, Magna Utah 84044
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.
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.