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











(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
->
-> (SCO Unix) I need to transfer a hard drive to another machine as a secondary.


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

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.

READ THOSE BEFORE YOU REMOVE THE DRIVE FROM THE OLD MACHINE IF POSSIBLE.

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

  • 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 back.

  • SCSI: Run "mkdev hd" to add the device to the kernel. Reboot.
  • 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 to.

    Tell it you want block-by-block control of the layout of the filesystems. That's important. This will bring you to the "divvy" screen.

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

    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:


From: Bela Lubkin <[email protected]>
Subject: Re: OSR 5.0.6a Strange problem after BIOS upgrade FLASH and IDE
Date: Sun, 13 Jan 2002 22:46:45 GMT
References: <[email protected]> <[email protected]>

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

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

>Bela<

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.

>Bela<

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 <[email protected]>
ZENEZ 3748 Valley Forge Road, Magna Utah 84044

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




If this page was useful to you, please help others find it:  





Comments?



Click here to add your comments
- no registration needed!


Don't miss responses! Subscribe to Comments by RSS or by Email

Click here to add your comments


If you want a picture to show with your comment, go get a Gravatar

Kerio Samepage


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

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.

I am a Kerio reseller. Articles here related to Kerio products reflect my honest opinion, but I do have an obvious interest in selling those products also.

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.

g_face.jpg

This post tagged:

       - FAQ
       - SCO_OSR5















My Troubleshooting E-Book will show you how to solve tough problems on Linux and Unix systems!


book graphic unix and linux troubleshooting guide



Buy Kerio from a dealer
who knows tech:
I sell and support

Kerio Connect Mail server, Control, Workspace and Operator licenses and subscription renewals



Click and enter your name and phone number to call me about Kerio® products right now (Flash required)