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: <email@example.com> References: <firstname.lastname@example.org>
<48D019F9.email@example.com> 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<
Got something to add? Send me email.
Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind. (Alan Kay)