IBM 9G disk thinks it's a SUN4
2007-12-25 9:58:00
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>
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
Comments
Got something to say?
You must be logged in to post a comment.
