This is an ancient post with no relevance to modern systems.

From: Bela Lubkin <fi...@armory.com>
Subject: Re: what to do about "cannot dump to dumpdev hd(1/41): space for
Date: Wed, 17 Sep 2008 21:43:47 -0700
Message-ID: <200809172143.aa29462@deepthought.armory.com> 
References: <43d41a32-8d53-41c3-ac34-03b69a72aa09@a1g2000hsb.googlegroups.com> <41c086e1-742e-40b7-a240-6b64cfdee212@l42g2000hsc.googlegroups.com> <48CB54F4.5010002@att.net> <200809130017.aa16291@deepthought.armory.com> <fb35d8bd-1b77-43fe-86e5-b3c1e7e8a4be@l42g2000hsc.googlegroups.com> <48CF3907.7020905@att.net> <48CF9E9B.7070609@ntelos.net> <48D019F9.8020403@att.net> 

Steve M. Fabac, Jr. wrote:

> Bela will likely chime in here, but I don't think it is possible to install
> SCO 5.0.5 with root anywhere but in part2. By default 0 is boot, 1 is swap,
> and 2 is root. Unless this is SCO UNIX 3.2v4.2 (pre SCO 5.0.0) in which
> case 0 is root and 1 is still swap.

I don't really enjoy being "invoked" like that...

It's possible to install OSR5 onto any division of any partition.  To
install anywhere other than the default division-2-of-active-partition
requires hackery that few people know; the original poster's system
probably isn't that strange.

I haven't read the very latest posts on this thread yet, but so far it
looks like everyone is missing the probable cause here.  It looks like
the drive's perceived geometry has changed.  The OP should first look at
his live system, at the files /usr/adm/hwconfig and /usr/adm/syslog, to
get a feel for what these look like.  For instance:

  $ grep cyls /usr/adm/hwconfig
  %disk     0x01F0-0x01F7  14   -  type=W0/0 unit=0 cyls=60321 hds=255 secs=127
  %Sdsk     -               -   -  cyls=4462 hds=255 secs=63 fts=stdb
  %Sdsk     -               -   -  cyls=17849 hds=255 secs=63 fts=stdb
  %disk     0x01F0-0x01F7  14   -  type=W0/1 unit=1 cyls=60801 hds=255 secs=63

This system has two SCSI and two IDE drives, thus the two formats.
Next:

  $ strings /usr/adm/hwconfig | grep cyls
   14   -  type=W0/0 unit=0 cyls=60321 hds=255 secs=127
    -   -  cyls=4462 hds=255 secs=63 fts=stdb
    -   -  cyls=17849 hds=255 secs=63 fts=stdb
   14   -  type=W0/1 unit=1 cyls=60801 hds=255 secs=63
  
Notice that `strings` cuts of the "%what" part -- this is because it's
separated by a TAB char, and `strings` thinks TAB isn't a printable
char.  Now you can do:

  # strings /dev/hd20 | grep cyls=

(where hd20 is the old drive's whole-disk device node), and you'll
likely get a _lot_ of output, some of which will be the original
geometry of the drive.  Other parts will be various sorts of noise, so
it's up to you to separate the wheat from the chaff.  If there were
multiple drives on the old system, you'll see several sets of geometry
to choose from.  Multiply (cyls * hds * secs * 512) to get the size in
bytes; for the above 4, I get:

  1,000,189,739,520 (~1TB)
     36,701,199,360 (~36GB)
    146,813,022,720 (~146GB)
    500,105,249,280 (~500GB)

Calculate this and pick out which size correctly applies to the make &
model of the old drive.

Now look at /usr/adm/hwconfig on the new system.  What is it giving for
the old drive's geometry?

If it matches your discovered geometry from the old drive, I'm wrong,
this isn't a geometry problem.  Report that and we have a new basis for
further discovery.

If it doesn't match, it's a geometry problem.  Then we need to think
about how to fix it.

Two classes of geometry problem.  One is a case where the "hds" and
"secs" values match, but the "cyls" is much too low.  This happens when
you have a drive larger than is supported by the new HBA driver.  For
instance, a previous version of the LSI Logic 53c1030 driver, "lsil",
couldn't handle drives larger than 64GiB.  It saw drive sizes as (actual
size mod 64GiB), so a 100GiB drive showed up as 36GiB, etc.  The fix for
this is (1) update to the newest version of the driver for that HBA
(that fixes the "lsil" case); (2) if no newer driver exists, throw out
the HBA, get one with a working driver.

The other class of geometry problem is where the numbers just don't
match at all.  Look at the 36GB drive:

  %Sdsk     -               -   -  cyls=4462 hds=255 secs=63 fts=stdb

Many HBAs like a geometry of 64 heads, 32 sectors/track.  They would
show this same drive as:

  %Sdsk     -               -   -  cyls=35000 hds=64 secs=32 fts=stdb

(probably 35001 cylinders).  In such a case, what you have to do is
"stamp" the drive with the correct (original) geometry so OSR5 will know
how to find stuff on it.  This used to be very easy, you would just:

  # dparam -w /dev/rhd20   # where /dev/rhd20 is the drive in question
  # dparam /dev/rhd20 `dparam /dev/rhd20`

It's still that easy unless your new system is OSR507.  507 shipped with
a broken masterboot which makes this more difficult.  I believe that's
been fixed along the way, so if it's 507, update the new system with
OSR507MP5 before proceeding.  Then do the above commands.

After "stamping", reboot, then go back to `divvy` and see if the
filesystem sizes & types make any more sense.  Run `dtype /dev/part1`
on each division's device node; do those filesystem types make sense?
Finally, run `fsck -n -o full /dev/part1` on each of the divisions that
looks like a mountable filesystem type.  Do they still whine about wrong
sizes?

Ideally you should be doing all of this on a copy of the original data,
mirrored onto another drive of the same (or larger) size.  You can do
the mirroring with something like Ghost or simply by:

  # dd if=/dev/hd20 of=/dev/hd30 bs=64k

where hd20 & hd30 are the whole-disk device nodes for two drives.  This
command is dangerous: you need to be 150% certain that /dev/hd30 is
really the trashable new empty drive!

BTW, nothing prevents you from using an IDE/SATA drive as the mirror.
The OSR5 "wd" driver tends to choose different geometries than many of
the SCSI HBA drivers, but this is irrelevant since you will be stamping
the new drive with the original drive's geometry.

What we refer to as "disk geometry" these days has nothing to do with
the actual number of cylinders, heads & sectors/track of the drive, it's
just an accounting trick to help the OS keep track of where things are
on the drive.  For a new drive, the only requirements for the chosen
geometry are that it fit within constraints (<256 heads, <256 sectors,
<65536 cylinders) -- and that it multiply out to the actual size of the
drive.

That last requirement is actually almost never met, since the drive
is unlikely to have exactly [some number < 256] * [some number < 256]
* [some number < 65536] total sectors.  The geometry must multiply
out to the drive's exact size _or less_, which is what almost always
happens.  For a drive that already has partitions and divisions on it,
the requirement is: geometry Must Not Change even if you move the drive
from one HBA to another, or move the logical contents of the drive to
another drive using an image/mirroring technology like Ghost or `dd`.

OSR5 tries to enforce the Must Not Change clause by stamping SCSI
drives at install time.  Three things go wrong with this: it doesn't
stamp IDE drives; stamping of SCSI drives was added relatively late
(506?); and the broken masterboot in 507 prevents the stamping from
working.  And possibly a 4th problem (I'm not sure about this one): I'm
sure it tries to stamp the root drive at install time (subject to the
other 3 constraints), but I'm not too sure about drives added after
installation.  Not sure if `mkdev hd` also tries to stamp new drives.

Starting with OSR507MP1 or MP2 or so, a new utility `geotab` stamps
drives with a new kind of geometry stamp which is supposed to be more
resiliant to movement between HBAs and/or imaging to different drive
types.  Again, I forget whether it includes a tweaked `mkdev hd` script
that does this newfangled stamping to newly installed drives.  (I should
remember since I invented the new stamp, wrote the utility that
implements it, and wrote the script that stamps all existing drives
during the installation of the supplement that adds `geotab`.  But it's
been long enough that I can't say for sure, even though I know it
_should_ have tweaked `mkdev hd`...)

(Ok, I downloaded the newest wd BTLD and I still don't know the answer.
It replaces one of the mkdev scripts (.scsi), but the new version
doesn't mention either `dparam` or `geotab`.  But it's also possible
that the _kernel_ stamps a geotab onto new drives.  If not, something
probably should -- probably `mkdev hd`)

Hmmm, I've written a tome, will bcc to Tony Lawrence...

>Bela<

Phone and Email Support at Monthly rates

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.