SUMMARY: IBM 9G disk thinks it's a SUN4

From: rsaddler@cccis.com
Date: Mon Apr 26 1999 - 14:04:32 CDT


Greetings,

Sorry this is so overdue.

Many thanks to the following:

    Don Barile <don@svweb.com>
    Navi Sirsena <navis@exchange.ml.com>
    P Wallis <p.wallis@x400.icl.co.uk>
    <sunsrv@blr.cmc.net.in>
And
    Edward Carpenter <Edward.Carpenter@East.Sun.COM>

My original scenerio was:

>After partitioning an IBM 9G drive on an Enterprise 450, Solaris 2.6,
>I was left with the following structure that I wanted (going to be
>swapping the current 4G c0t0d0 with it.....with lots of space to play
>with, but I digress.....):
>
>Current Disk = c2t1d0
><SUN9.0G cyl 4924 alt 2 hd 27 sec 133>
>/pci@4,2000/scsi@1,1/sd@1,0
>
>Vendor: IBM
>Product: DDRS39130SUN9.0G
>Revision: S98E
>
>Current partition table (original):
>Total disk cylinders available: 4924 + 2 (reserved cylinders)
........................................................................
>Part Tag Flag Cylinders Size Blocks
> 0 root wm 0 - 328 576.87MB (329/0/0) 1181439
> 1 swap wu 329 - 943 1.05GB (615/0/0) 2208465
> 2 backup wu 0 - 4923 8.43GB (4924/0/0) 17682084
> 3 var wm 944 - 1514 1001.20MB (571/0/0) 2050461
> 4 unassigned wm 2657 - 4922 3.88GB (2266/0/0) 8137206
> 5 unassigned wm 1515 - 2085 1001.20MB (571/0/0) 2050461
> 6 usr wm 2086 - 2656 1001.20MB (571/0/0) 2050461
> 7 unassigned wm 0 0 (0/0/0) 0
>
>Running newfs, fsck, and mounting went just fine.
>
>Now, for some dang reason, when I run format, select the disk, I get the
>following:
>
>---8<--- snip! ---8<---
>
> 4. c2t1d0 <SUN4.2G cyl 3880 alt 2 hd 16 sec 135>
> /pci@4,2000/scsi@1,1/sd@1,0
>
>format> cur
>Current Disk = c2t1d0
><SUN4.2G cyl 3880 alt 2 hd 16 sec 135>
>/pci@4,2000/scsi@1,1/sd@1,0
>
>format> inq
>Vendor: IBM
>Product: DDRS39130SUN9.0G
>Revision: S98E
>
>partition> p
>Current partition table (original):
>Total disk cylinders available: 3880 + 2 (reserved cylinders)
>
>Part Tag Flag Cylinders Size Blocks
> 0 root wm 0 - 545 575.86MB (546/0/0) 1179360
> 1 swap wu 546 - 1031 512.58MB (486/0/0) 1049760
> 2 backup wm 0 - 3879 4.00GB (3880/0/0) 8380800
> 3 var wm 1032 - 1980 1000.90MB (949/0/0) 2049840
> 4 unassigned wm 0 0 (0/0/0) 0
> 5 unassigned wm 1981 - 2929 1000.90MB (949/0/0) 2049840
> 6 usr wm 2930 - 3878 1000.90MB (949/0/0) 2049840
> 7 unassigned wm 0 0 (0/0/0) 0
>
>What evil now posesses my system?
>
>How do I get it back to what it should be?

In a nutshell, this was another episode of "What _was_ I thinking?!"
-or- "How to shoot yourself in the foot at close range"

The clincher was that I used dd to copy partition slices from one size
disk to one of a different vendor and size. This practice is fine for
similar, but _not_ for, dissimilar disks.

The thing that struck me odd is that, copying a slice at a time, running
fsck, and mounting as I went, all seemed fine. I'm sure it would have
made an obvious difference come boot time.

My /etc/format.dat did not have a description for a 9G drive of any
type/model. Sun sent me one they use as a generic template, which I
tweaked to suit my disk in question;

The following works great - I was back to desired partitions and new
filesystems in record time:

disk_type = "SUN9.0GB" \
        : ctlr = SCSI : fmt_time = 4 \
        : ncyl = 4924 : acyl = 2 : pcyl = 4926 : nhead = 27 \
     : nsect = 133 : rpm = 7200 : bpt = 69120

partition = "SUN9.0GB" \
        : disk = "SUN (IBM) 9.0G" : ctlr = SCSI \
        : 0 = 0, 1181439 : 1 = 329, 2208465 : 2 = 0, 17682084 \
        : 3 = 944, 2050461 : 4 = 2657, 8137206 : 5 = 1515, 2050461 \
        : 6 = 2086, 2050461 : 7 = 0, 0

Employing the following suggestion, my data was copied, and life became
good again:

"You can copy a local filesystem from one slice to another using ufsdump.
 You must be in the filesystem you are dumping to.
 Make sure the slice you are dumping to is mounted.

 /usr/sbin/ufsdump 0f - /dev/rdsk/cxtxd0sx| /usr/sbin/ufsrestore rvf -

 (/dev/rdsk/c0txd0sx represents the disk that data is coming FROM)"

I shut down, Swapped the drives, and booted. Life is good.

An observation that Don made is: "the firmware revision on these disks is
significant. Disks that are otherwise identical, except for a couple of
digits on the part number and firmware revision refuse to work in machines
like the 450 ( I've had a similar bad experience... ) while they work
perfectly in an A1000 for example."

Thanks again!

........................................................................
Ray Saddler - rsaddler@cccis.com & saddler@wwa.com http://www.cccis.com
Network Systems / UNIX Administration - CCC Information Services, Inc.
World Trade Center Chicago 444 Merchandise Mart Chicago, IL 60654-1005



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:18 CDT