SEO

I was curious if anyone successfully used Paragon drive backup version
5.5 to copy and restore a SCO partition. It is a drive imaging product
similar to norton ghost. They claim it can make a restorable image of
any type of partition because it can do a sector to sector copy. It has
work well for various windows and linux partitions but not successful
for a SCO partition. Paragon recognizes it as a Unix partition and
doesn't give any errors when backing it up but when I attempt to boot
from a cloned image I get a "NO OS" message when it boots.

Thanks,
Jay

Jay "Anonymous" wrote:

> I was curious if anyone successfully used Paragon drive backup version
> 5.5 to copy and restore a SCO partition. It is a drive imaging product
> similar to norton ghost. They claim it can make a restorable image of
> any type of partition because it can do a sector to sector copy. It has
> work well for various windows and linux partitions but not successful
> for a SCO partition. Paragon recognizes it as a Unix partition and
> doesn't give any errors when backing it up but when I attempt to boot
> from a cloned image I get a "NO OS" message when it boots.

This is due to OpenServer's dependency on the (mostly obsolete) concept
of disk geometry. If you write the partition image to a new disk which
has the same geometry as the old (according to OpenServer, mind you)
(has to be same heads and sectors/track, total cylinders doesn't
matter); and if you write it starting on a sector number which is the
same logical sector number within a cylinder; then it will boot. By
"same logical sector number within a cylinder" I mean: suppose the
geometry was 10 heads and 100 sectors/track. Then each "cylinder" is
1000 sectors. If the partition used to start on absolute disk sector
number 1234567, it started on sector 567 of cylinder 1234. If you wrote
it to sector 34567 of a new disk (with the same geometry), it would
start on sector 567 of cylinder 34, and it would boot. If you wrote it
to sector 34568 then it wouldn't boot.

A recently-issued supplement, the "Wd Driver Supplement", fixes this.
The supplement is so new that I think it still isn't on the web site
yet. It is for OSR506 and 507 only (may work with 504 or 505,
untested). It makes all stages of the boot process much less sensitive
to geometry issues. You'll notice that "Wd Driver Supplement" is an odd
name for this -- it's just one subfeature of the supplement. The
supplement causes some IDE drives to show up with a new geometry, thus
provoking this problem on existing systems; the fix is included, and
fixes other issues like the one you're seeing.

There is still one condition which cannot be handled. You cannot safely
transport partition data between IDE and SCSI drives. This is because
IDE drives have a `badtrk` table and SCSI drives have a `badblk` table,
and the two are incompatible. (These are OSR5 software structures, not
physical drive characteristics.)

Plus, of course, if you go from one drive type to another, you'll
probably need different drivers in your kernel.

I would say that on the one hand these things are caused by OSR5; on the
other, it is an overblown claim on the part of these partition-imaging
programs that they can operate on "any type of partition". Any type of
partition _could_ have deep dependencies on things like geometry,
location on the disk, drivers used to access the disk, etc.

This sort of drive transplant is much better handled by one of the
Unix-aware "supertar" products. They know not only how to safely build
and copy partitions, but also how to reconfigure kernels for new disk
hardware. (At least I think they know that...?)

>Bela<