my english isn't very good,but i hope that you understand an can help me.

My Problem is, that i have an old Hp Vista Computer with Sco 5 OpenServer on
 a SCSI 2GB HDD.
Because the SCSI Drive is very old and seems to die in the next few week i b
ought a ide drive an used ghost to clone the drive. My Problem is that Sco f
ails to boot at stage 1. What can i do?

I searched the net but don't finde anything helpful


--------------=  Posted using GrabIt  =----------------
------=  Binary Usenet downloading made easy =---------
-=  Get GrabIt for free from http://www.shemes.com/  =-

[ Post a follow-up to this message ]

Thunder typed (on Tue, Aug 30, 2005 at 02:08:09PM -0500):

| my english isn't very good,but i hope that you understand an can help
| me.
|
| My Problem is, that i have an old Hp Vista Computer with Sco 5
| OpenServer on a SCSI 2GB HDD.  Because the SCSI Drive is very old and
| seems to die in the next few week i bought a ide drive an used ghost
| to clone the drive. My Problem is that Sco fails to boot at stage
| 1. What can i do?
|
| I searched the net but don't finde anything helpful

You cannot use your current kernel, which only knows about a SCSI drive,
to boot from an IDE drive.

Don't use ghost, use LoneTar or BackupEdge; you can get a demo version
from cactus.com or microlite.com.

Either one will let you boot from recovery media, and use a BTLD to
add in the driver, bore booting, for your SCSI drive.

But I suspect you need to find a consultant to help you accomplish this.

--
JP

[ Post a follow-up to this message ]

----- Original Message -----
From: "Thunder" <shadowman1@gmx.at>
Newsgroups: comp.unix.sco.misc
To: <distro@jpr.com>
Sent: Tuesday, August 30, 2005 3:08 PM
Subject: Importat Sco 5 Openserver Bootproblem


> my english isn't very good,but i hope that you understand an can help me.
>
> My Problem is, that i have an old Hp Vista Computer with Sco 5 OpenServer
> on a SCSI 2GB HDD.
> Because the SCSI Drive is very old and seems to die in the next few week i
> bought a ide drive an used ghost to clone the drive. My Problem is that
> Sco fails to boot at stage 1. What can i do?
>
> I searched the net but don't finde anything helpful

* Remove the ide drive. You can't mix ide & scsi, at least not the way you
have since you need to boot from the scsi.
Actually it's possible it's just complicated and not worth the hassle for
anyone, most importantly me. 

* If you have a tape drive:
Install a supertar and use it immediately. (BackupEdge, LoneTar, CTAR)
They all have free downloadable fully functional demos that will work long
enough to do what you need before you have to buy them to get you through
this emergency migration. They all have directions that are easy to follow.
Create boot floppies
Do a "Full Master Backup"
Swap out the old scsi drive for a new scsi drive
Boot from the floppies created above
Do a full restore to new drive
If you kept the same scsi card and the same computer and just replaced the
scsi drive with another scsi drive on the same cable and at the same scsi
id, the the software will automagically handle partitioning and formatting
the new drive. The new drive must obviously be the same size or larger. Try
to get as similar a drive as possible. Probably a 9 Gig is the closest
you'll be able to find.
Then of course you should buy whichever supertar you used. It will run every
night from now on and it will make this easier next time and you'll be saved
when the drive doesn't give you the nice warning signs like it did this
time. Usually you don't get the warning, you're lucky this time. 

* If you don't have a tape drive:
Too many possibilities, hire an experienced sco consultant who will decide
what to do based on your particular needs and situation.
Maybe install a 2nd scsi disk and do a "dd" copy.
Or install the OS fresh on a new drive and manually copy your data from
drive to drive on the same box.
Or install a tape drive and use the supertar as per above.
Or install a whole new system and manually rsync or ftp data from the old
box over the network.
etc...
It depends on things like:
just how old is the old box
how old is the version of sco
what (if any) updates have been installed
how good is the net connection to maybe make installing updates easy
how much data must be moved
how well or how poorly organized are the data, apps, users, cronjobs,
printers, & any other customizations on the old box
etc...

If you don't have a tape drive and can't just do the supertar
backup/restore, then the most sensible plan must be decided based on
consideration of a lot of details like that that we don't know and probably
can't really be described to us in a newsgroup post fully enough for a
*good* answer. It will take too long and the drive will die before you are
saved.

Get a sco consultant on-site and he will see a zillion factors all at a
glance and be able to advize you whats the best plan of action based on
that.

Not to mention he'll probably clean up various bad things software vendors
do to the sco boxes they install on. Like installing a full system nightly
backup for starters.
I often see software vendor supplied backup jobs that just cpio a few data
directories to a tape.
So the tape doesn't have many of the things you really need to get running
again:
basic OS hardware & network configuration
OS & user count license keys
printer configs, including hand edited printer interface scripts
other add-on software and it's installed license keys and custom
configuration like vsifax & facetwin/visionfs/samba
user accounts
user home directories with possible customized .profiles
cron jobs
special scripts that live outside of the main application directory in
places like /etc and /bin and /usr/bin
there are lots of things like this that it might take a long time to piece
back together or re-invent from scratch.
And, these vendor supplied cpio or tar backups do not verify the tape after
writing. When you write to a bad tape, sometimes the tape drive has no way
to know that the magnetic media isn't actually holding the charge any more.
You have to read the tape after writing it and compare the tape to the hard
disk. Only then do you know the backup is good and can be restored from.

The supertars do that verify, and they back up the entire OS, and they know
how to restore onto a completely bare new drive of a different size from the
original, and with only a little more fuss and some phone support, they even
know how to restore onto completely new hardware including different scsi
card or switching from scsi to ide.

Brian K. White  --  brian@aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>+
+.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!

[ Post a follow-up to this message ]

Thunder wrote:
> my english isn't very good,but i hope that you understand an can help me.
>
> My Problem is, that i have an old Hp Vista Computer with Sco 5 OpenServer 
on a SCSI 2GB HDD.
> Because the SCSI Drive is very old and seems to die in the next few week i
 bought a ide drive an used ghost to clone the drive. My Problem is that Sco
 fails to boot at stage 1. What can i do?
>
> I searched the net but don't finde anything helpful
>
>
> --------------=  Posted using GrabIt  =----------------
> ------=  Binary Usenet downloading made easy =---------
> -=  Get GrabIt for free from http://www.shemes.com/  =-

Another possibility is to find a exact brand/size SCSI drive and use
ghost to clone the drive.

Abid

[ Post a follow-up to this message ]

Jean-Pierre Radley wrote:
>
> Thunder typed (on Tue, Aug 30, 2005 at 02:08:09PM -0500):
>
> | my english isn't very good,but i hope that you understand an can help
> | me.
> |
> | My Problem is, that i have an old Hp Vista Computer with Sco 5
> | OpenServer on a SCSI 2GB HDD.  Because the SCSI Drive is very old and
> | seems to die in the next few week i bought a ide drive an used ghost
> | to clone the drive. My Problem is that Sco fails to boot at stage
> | 1. What can i do?
> |
> | I searched the net but don't finde anything helpful
>
> You cannot use your current kernel, which only knows about a SCSI drive,
> to boot from an IDE drive.
>
> Don't use ghost, use LoneTar or BackupEdge; you can get a demo version
> from cactus.com or microlite.com.

JP,

I have used Ghost to copy an SCO Openserver 5.0.5 system
disk to a new disk. This was on a client's Compaq Proliant
with 4G Compaq SCSI disk. I chose to Ghost the root disk
in order to preserve the Compaq utility partition and all
its files as Backup Edge will not restore non-UNIX partitions.

I sold the client an Adapted 2110S RAID controller and two 36G
Hitachi SCSI disks to replace the two 4G Compaq disks on the
cha controller.

The sequence I followed was to install the dpti5 btld driver
into the running kernel before taking the system down. I then
powered down  and installed the 2110S controller without the
hard drives. I rebooted the system to make sure that it will boot
with the 2110S installed (no hang on boot, etc. ).

Then I powered down and connected one of the 36G disks to the 2110S
and upon boot up, entered the Adaptec SMOR configuration utility
(Control-A) and verified that SMOR shows the 36G disk at ID0.

When I rebooted with the unconfigured 36G disk, the system
displayed the message: "Insert bootable disk and hit any key"
indicating that the 2110S has boot priority over the onboard
Compaq SCSI controller.

I then used a Ghost boot floppy and selected  "image all" to
copy the Compaq root disk to the new 36G disk on the 2110S.

Once Ghost finished, I rebooted and pressing F10 entered the
Compaq Utility without problems. I then booted the new disk
to maintenance mode by entering the defbootstr command:
boot: defbootstr Sdisk=dpti(0,0,0,0)  and the 30G disk booted ok.
I entered the root password and ran fsck -ofull on all the divisions
and fsck completed without an error message.

However, fdisk showed that the entire disk was configured as a UNIX
partition and dfspace showed only 4G (same size as the Compaq
root disk). I corrected this by running dparam and stamped the disk
as 4462 cyl by 255 heads by 63 sectors then after rebooting, fdisk
showed the unused space which I then  configured as a second UNIX
partition (/dev/hd02).  Divvy -m /dev/hd02 allowed me to create
additional divisions on the new partition.

I then rebooted and used SMOR on the 2110S to disable the 2110S from
booting. Upon reboot, the original Compaq root disk booted and
I ran mkdev hd and added the 36G disk on the 2110S as another
disk. I did not allow the disk initialization to recreate any of the
divisions on the 36G disk and just named them nroot, nswap, nboot, etc.
I mounted nroot (the Ghosted root on the 36G disk) on /mnt. I then
ran "find . -type f -mount -print > /tmp/bob" from / and edited
/tmp/bob to create a script to run sum -r on the original file
on the 4G disk root and on the same file on the 36G disk root
(root files copied via Ghost and mounted as nroot on /mnt) to make
sure that there were no errors in the files copied by Ghost.
The only differences were in log files created upon boot up, and
the link kit files modified after Ghosting the root disk and running
mkdev hd to add the 36G disk to the kernel on the original disk.

I used cpio to copy all the non-root file systems from the old
Compaq disks to the new 36G disk.

I powered down, removed the old Compaq disks, then mounted the two
36G disks and enabled the 2110S to boot. I used SMOR to create
a RAID1 mirrored array: copying data from ID0 to ID1.

The customer is still using this system today and the above installation
was performed on 8/18/2004.

Maybe I was lucky, but Ghost worked for me and it preserved the Compaq
utility partition and copied the SCO partition without error.

And, if the OP only needs to replace an old disk with a new disk and
does not need the additional space, he would not have to re-stamp the
disk geometry to recover the unused space on the new disk.

As to why he has the "stage 1" boot failure: He may not have used
the "image all" configuration in Ghost, and he may have failed to
issue the defbootstr Sdsk=wd(0,0,0) directive to boot the IDE disk.
(I can't remember the master vs slave vs primary vs secondary switches
to the wd(x,x,x) string and don't choose to look it up for this post.)


>
> Either one will let you boot from recovery media, and use a BTLD to
> add in the driver, bore booting, for your SCSI drive.
>
> But I suspect you need to find a consultant to help you accomplish this.
>
> --
> JP


--

Steve Fabac
S.M. Fabac & Associates
816/765-1670

[ Post a follow-up to this message ]

Steve Fabac wrote:

> I have used Ghost to copy an SCO Openserver 5.0.5 system
> disk to a new disk. This was on a client's Compaq Proliant
> with 4G Compaq SCSI disk. I chose to Ghost the root disk
> in order to preserve the Compaq utility partition and all
> its files as Backup Edge will not restore non-UNIX partitions.
>
> I sold the client an Adapted 2110S RAID controller and two 36G
> Hitachi SCSI disks to replace the two 4G Compaq disks on the
> cha controller.
>
> The sequence I followed was to install the dpti5 btld driver
> into the running kernel before taking the system down. I then
> powered down  and installed the 2110S controller without the
> hard drives. I rebooted the system to make sure that it will boot
> with the 2110S installed (no hang on boot, etc. ).
>
> Then I powered down and connected one of the 36G disks to the 2110S
> and upon boot up, entered the Adaptec SMOR configuration utility
> (Control-A) and verified that SMOR shows the 36G disk at ID0.
>
> When I rebooted with the unconfigured 36G disk, the system
> displayed the message: "Insert bootable disk and hit any key"
> indicating that the 2110S has boot priority over the onboard
> Compaq SCSI controller.
>
> I then used a Ghost boot floppy and selected  "image all" to
> copy the Compaq root disk to the new 36G disk on the 2110S.
>
> Once Ghost finished, I rebooted and pressing F10 entered the
> Compaq Utility without problems. I then booted the new disk
> to maintenance mode by entering the defbootstr command:
> boot: defbootstr Sdisk=dpti(0,0,0,0)  and the 30G disk booted ok.
> I entered the root password and ran fsck -ofull on all the divisions
> and fsck completed without an error message.
>
> However, fdisk showed that the entire disk was configured as a UNIX
> partition and dfspace showed only 4G (same size as the Compaq
> root disk). I corrected this by running dparam and stamped the disk
> as 4462 cyl by 255 heads by 63 sectors then after rebooting, fdisk
> showed the unused space which I then  configured as a second UNIX
> partition (/dev/hd02).  Divvy -m /dev/hd02 allowed me to create
> additional divisions on the new partition.
>
> I then rebooted and used SMOR on the 2110S to disable the 2110S from
> booting. Upon reboot, the original Compaq root disk booted and
> I ran mkdev hd and added the 36G disk on the 2110S as another
> disk. I did not allow the disk initialization to recreate any of the
> divisions on the 36G disk and just named them nroot, nswap, nboot, etc.
> I mounted nroot (the Ghosted root on the 36G disk) on /mnt. I then
> ran "find . -type f -mount -print > /tmp/bob" from / and edited
> /tmp/bob to create a script to run sum -r on the original file
> on the 4G disk root and on the same file on the 36G disk root
> (root files copied via Ghost and mounted as nroot on /mnt) to make
> sure that there were no errors in the files copied by Ghost.
> The only differences were in log files created upon boot up, and
> the link kit files modified after Ghosting the root disk and running
> mkdev hd to add the 36G disk to the kernel on the original disk.
>
> I used cpio to copy all the non-root file systems from the old
> Compaq disks to the new 36G disk.
>
> I powered down, removed the old Compaq disks, then mounted the two
> 36G disks and enabled the 2110S to boot. I used SMOR to create
> a RAID1 mirrored array: copying data from ID0 to ID1.
>
> The customer is still using this system today and the above installation
> was performed on 8/18/2004.
>
> Maybe I was lucky, but Ghost worked for me and it preserved the Compaq
> utility partition and copied the SCO partition without error.
>
> And, if the OP only needs to replace an old disk with a new disk and
> does not need the additional space, he would not have to re-stamp the
> disk geometry to recover the unused space on the new disk.
>
> As to why he has the "stage 1" boot failure: He may not have used
> the "image all" configuration in Ghost, and he may have failed to
> issue the defbootstr Sdsk=wd(0,0,0) directive to boot the IDE disk.
> (I can't remember the master vs slave vs primary vs secondary switches
> to the wd(x,x,x) string and don't choose to look it up for this post.)

That's a deliberate long quote.

The short summary response is: you did in fact get lucky.  But not very
lucky.

OSR5 is overly concerned about the "geometry" of a disk.  On all modern
disks, the geometry the OS is so worried about is an utter hallucination
-- but it must be a _shared_ hallucination.  The imaginary geometry used
when the disk is created must match the figment of the current kernel's
imagination, or it won't boot.

Many OSR5 HBA drivers make up a fake geometry of 255 heads and 63
sectors/track, as you used above.  You apparently transferred your Ghost
image from one HBA to another, both of which use that geometry.  (I'm
oversimplifying the relationship of HBA to geometry: many drivers use
different geometries depending on the actual size of the drive.  By
moving to a larger drive, you tempted fate by encouraging your driver to
switch geometries.)

There are things you can do to mitigate these issues.  On releases
before 5.0.7, the thing to do is: before you capture the drive image,
boot the system up and run:

# DRIVE=/dev/rhd00
# dparam -w $DRIVE
# dparam $DRIVE `dparam $DRIVE`

Let's break this down:

# DRIVE=/dev/rhd00

/dev/rhd00 is the raw device node for the first (usually boot) drive.
The first four drives in an OSR5 system are likely to have /dev/rhd?0
nodes.  All drives (including both the first four and any higher ones)
will have /dev/rdsk/?s0 nodes.  So if you were migrating your 14th
drive, you'd want to use  "DRIVE=/dev/rdsk/13s0"  ...

# dparam -w $DRIVE

This writes an OSR5 masterboot sector to the drive.  Your boot drive
likely already has this, but other drives won't.  The OSR5 masterboot
sector contains an optional structure that records the disk's geometry.
We can't write that structure if it isn't present.

Note: if you're doing this to the boot drive, and you use a different
MBR-resident boot manager (like some configurations of LILO and GRUB),
this will overwrite it.  To overcome that you would need to do a
different, non-geometry-dependent sort of backup (like a supertar).

# dparam $DRIVE `dparam $DRIVE`

This "stamps" the drive with the geometry by which the current kernel
knows it.  Now when you make an image backup of the drive, it will
contain this embedded notion of the geometry.  The kernel will know what
to do with it even on a different drive or HBA.

I said "before 5.0.7".  That's because the situation improves in 5.0.7.
Before doing the image backup, make sure you're updated to MP3 (and UP3
if you have a SCO Update license).  The OSR507 MP series includes
updates to how the geometry mechanism works.  You may also need to
separately install the "Wd Driver Supplement" that was issued with MP3;
I forget whether it was 100% included in MP3.  Adding the supplement on
top of MP3 or UP3 won't hurt, so install it.

Once all that is updated, the boot and kernel code will be able to
figure out the right hallucinatory geometry no matter where you take the
data...

I don't know the situation in OSR6.  The UW-based kernel also has a deep
dependency on geometry, but the details are different.  I don't know if
the device-independent geometry feature was ported.

>Bela<

[ Post a follow-up to this message ]

JP,

I have used Ghost to copy an SCO Openserver 5.0.5 system
disk to a new disk. This was on a client's Compaq Proliant
with 4G Compaq SCSI disk. I chose to Ghost the root disk
in order to preserve the Compaq utility partition and all
its files as Backup Edge will not restore non-UNIX partitions.

BackupEDGE will backup and restore non-UNIX partitions.
A great deal of work has gone in to giving BackupEDGE the ability
to backup, checksum, compress, encrypt, restore and disaster-recover
non-UNIX partitions, which we call "raw" partitions. You simply
identify the partitions you want protected.

If you weren't aware of this, perhaps this message will help.

If you were aware, tried it, and encountered a problem, please contact
our support department, or email support@microlite.com, with the
details.

Regards,

Tom
---
D. Thomas Podnar
tom@microlite.com         http://www.microlite.com
Microlite Corporation     724-375-6711 Voice
2315 Mill Street          724-375-6908 Fax
Aliquippa PA 15001-2228   888-257-3343 Toll Free Sales
-------------------------------------------------------
Developers of Microlite BackupEDGE

New England BackupEDGE Training / certification Classes
September 26, 2005 - Portland ME
September 27, 2005 - Boston MA
September 28, 2005 - Hartford CT

[ Post a follow-up to this message ]

OSR6 supports the independent geometry feature and in fact, an admin
needs to install the wd supplement or the latest mp pack in order to
migrate a disk to the OSR6 coorectly.

OSR6 fully supports editing an OSR506 or 507 disk  without a problem as
long the wd or mp pack is installed.  Things are quite seemless with
OSR6+divvy!  :-)!

Have faith...

-aps

[ Post a follow-up to this message ]

"D. Thomas Podnar" wrote:
>
>         JP,
>
>         I have used Ghost to copy an SCO Openserver 5.0.5 system
>         disk to a new disk. This was on a client's Compaq Proliant
>         with 4G Compaq SCSI disk. I chose to Ghost the root disk
>         in order to preserve the Compaq utility partition and all
>         its files as Backup Edge will not restore non-UNIX partitions.
>
> BackupEDGE will backup and restore non-UNIX partitions.
> A great deal of work has gone in to giving BackupEDGE the ability
> to backup, checksum, compress, encrypt, restore and disaster-recover
> non-UNIX partitions, which we call "raw" partitions. You simply
> identify the partitions you want protected.
>
> If you weren't aware of this, perhaps this message will help.

Tom,

Thanks for the information. My statement that Backup Edge won't
backup non-UNIX partitions was based upon my results when using
Recover Edge boot image written to DVD-RAM to restore a new 5.0.7
Enterprise system using  the "automatic" (may be called by some
other name) restore where RE recreates the root disk UNIX partition,
mounts the resulting file systems and performs a full restore. This
operation was performed on the same hard disk (not a replacement
disk) to restore a newly ISL'ed system to its base state
and undo test configurations (SCO Office server) evaluated
on the customer's new hardware prior to delivery.

RE announced that it will not recreate non-UNIX partitions and,
in fact, deleted the 40M DOS partition that I customarily place
at the start of all the SCO Openserver systems I build for my
clients. RE started the UNIX partition at the correct block number
leaving the space formerly occupied by the DOS partition blank.

Running fdisk after the restored disk was booted showed the
UNIX partition but the DOS partition was missing.

Now, I must confess that I have not read the Backup Edge
documentation cover-to-cover, so I may have missed important
configuration information for creating the RE DVD boot image
and to schedule a full system backup that would allow
me to include the DOS partition.

>
> If you were aware, tried it, and encountered a problem, please contact
> our support department, or email support@microlite.com, with the
> details.
>
> Regards,
>
> Tom
> ---
>  D. Thomas Podnar
>  tom@microlite.com         http://www.microlite.com
>  Microlite Corporation     724-375-6711 Voice
>  2315 Mill Street          724-375-6908 Fax
>  Aliquippa PA 15001-2228   888-257-3343 Toll Free Sales
> -------------------------------------------------------
> Developers of Microlite BackupEDGE
>
> New England BackupEDGE Training / certification Classes
>  September 26, 2005 - Portland ME
>  September 27, 2005 - Boston MA
>  September 28, 2005 - Hartford CT


--

Steve Fabac
S.M. Fabac & Associates
816/765-1670

[ Post a follow-up to this message ]

aps "pisymbol@gmail.com" wrote:

> OSR6 supports the independent geometry feature and in fact, an admin
> needs to install the wd supplement or the latest mp pack in order to
> migrate a disk to the OSR6 coorectly.
>
> OSR6 fully supports editing an OSR506 or 507 disk  without a problem as
> long the wd or mp pack is installed.  Things are quite seemless with
> OSR6+divvy!  :-)!
>
> Have faith...

Good show then...  I knew that support was underway when I left; didn't
know to what extent it was finalized and turned on in the shipping OSR6
product.

>Bela<

[ Post a follow-up to this message ]