I recently picked up a 9.1 gig Seagate Barracuda and a SCA to 50 pin scsi adapter.
I"m running Openstep 4.2 and the drive is a Seagate ST19171WC (although my system doesn't seem recognize the "C" at the end of the model number).
Drive seems to work, but the rom monitor "sees" the drive as a SEAGATE ST19171W with disk capacity of 491 MB. After initialization, the file viewer now "sees" the drive as 1.51 gig.
So far so good - or so I thought.
I then ran sdformat to change the sector size from 512 to 1024 and format the disk.
sdformat -i2 -b1024 -vf which returned:
Vendor and Product Identification: 'SEAGATE ST19171W '
Number of Blocks = 1005896
Block Length = 512
sr_io_status = 0x3 "check status, sr_esense not valid"
SCSI status = 02H "Check Condition"
Formatting started as requested & after about 43 minutes returned:
sr_io_status = 0x5 "sr_ioto exceeded"
SCSI status = 00H "Good"
Segmentation fault
I've run sdformat a number of times with the same result.
After running sdformat, the rom monitor now tells me:
ERROR: Can't read device capacity
DISK UNFORMATTED
Now when I attempt to initialize the drive after logging in I get the message:
Cannot initialize disk. See console for errors.
The Console reports:
Target 2: MEDIA ERROR; block 0H retry 1
... (repeated through retry 9)
sd1 (2,0): sense key: 0x3 additional sense code : 0x31
SCSI Block in error = 0 (no valid label)
...
...
...
/usr/etc/disk -i -h localhost -1 "UntitledDisk" /dev/rsd1a
disk name: SEAGATE ST19171W
disk type: fixed_rw_scsi
writing disk label
Target 2: MEDIA ERROR; block 0H retry 1
... (again repeated through retry 9)
sd1 (2,0): sense key: 0x3 additional sense code : 0x31
SCSI Block in error = 0 (no valid label)
Target 2: MEDIA ERROR; block 0H retry 1
... (again repeated through retry 9)
sd1 (2,0): sense key: 0x3 additional sense code : 0x31
SCSI Block in error = 0 (front porch)
...
...
sd1 (2,0): sense key: 0x3 additional sense code : 0x31
SCSI Block in error = 0 (front porch)
...r/w returned -1; expected 50176
Write of boot block 0 failed
No boot blocks on disk
Soooo, can anyone tell me what I'm doing wrong (I don't really understand what most of the above means :? - although I can tell it's not good :roll: )?
Any help getting the drive to work would be appreciated. Thanks.
James
The block error messages you are seeing would imply that there are errors on the media. Try doing a low level format (zeroing the drive) on the drive in a Mac or <shudder> PC.
This will tell you if there are actually errors on the drive or not.
Yes, you'll really want do a low-level format. Also recommend you do a media check using the BIOS of whatever scsi system you have (not the one in the black hardware, you'll need white). Then bring it back to the black hardware and partition it keeping partitions to 2GB or less. Some have said 4GB works on 4.2 but might as well be conservative. You can find disktab entries to help with this on the net and probably in here.
OK, I've been playing with several of these Seagate ST19171WC 9.1 Gig drives (they were cheap).
They all seem to work initially, although the rom monitor only sees them as 491 MB. After initialization, the file viewer sees 1.51 GB (on startup, however, the rom monitor still only sees 491 MB). Checking the console after initialization, it appears that 5 equal sized partitions of 1736.6 MB (/dev/rsd1a through /dev/rsd1e) were created, although the system only "sees" and I can only access the 1st one (/dev/rsd1a). I have been able to successfully install OS4.2 in this partition.
Since OS4.2 can use 4 GB partitions, however, I've been trying to format the drives so that I can create two 4 GB and one 1GB partitions.
The problem only arises after I attempt to format the drives with sdformat. Running sdformat seems to render the drives unusable. I've tried this with two separate drives with the same result: sdfromat ends with sr_io_status = 0x5 "sr_ioto exceeded" and either "segmentation fault" or "hardware error" (I've run sdformat many times on both drives).
Both of these drives worked as 1736.6 MB drives before running sdformat. Now, after running sdformat, if I attempt to initialize them I get the error messages described in my original post - ending with:
Write of boot block 0 failed
No boot blocks on disk
Apparently, sdformat wipes out the boot block and I can't figure out how to recover from this. Again, the first time I attempted to use these two drives they initialized and I was able to access and copy into and out of /dev/rsd1a. After running sdformat, however, they seem to be unusable except maybe as paper weights.
Can anyone tell me where I'm going wrong?
James
You might want to try setting the sector size back to 512 to see if that's the problem. I seem to remember reading that some disks won't work with 1024k sectors. Make sure that you have the latest version of sdformat, which is 2.0. Also, verify that you have OPENSTEP 4.2 patch 4 applied, because the versions of "disk" and "mkfs" that shipped on the original CD were broken. As Harbourmaster and Cubist suggested, do a low level format and check the media for bad sectors. Then run the "scsimodes" command on the disk and see what information it returns. You can use that information to create a disktab with your desired partition sizes.
I played with a 9 and 18gb seagate last year and some of the notes are in the "Cloning" a NeXTstep system thread in Nextstep/Openstep forum.
The long of the short is
I took 9g Seagate [SEAGATE ST39102LCSUN9.0G] using no disktab I issued this command.
disk -i -p 2000000 /dev/rsd1a
What happened was it created a 2gb /dev/rsd1a and then proceeded to create 1.7gb slices until it ran out of room. I was able to mount all of them and verify they worked.
betelgeuse:52# df
Filesystem kbytes used avail capacity Mounted on
/dev/sd0a 1020237 200597 717616 22% /
/private/vm/swapfile 1020237 200597 717616 22% /private/vm/swapfile.front
/dev/sd1a 1980942 9 1782838 00% /disk1
/dev/sd1b 1694781 9 1525293 00% /disk2
/dev/sd1c 1694781 9 1525293 00% /disk3
/dev/sd1d 1694781 9 1525293 00% /disk4
/dev/sd1e 1694782 10 1525293 00% /disk5
If any are corrupt use "newfs /dev/rsd1a" or what rsd#[a-e] part you need fixed.
-Mike
I've been going round and round on this with no success.
As Nitro suggested, I've verified that OS4.2 patch 4 is installed. Just to make sure, I've reinstalled the patch.
I've also verified that I'm running sdformat 2.0.
Same result: after running sdformat, scsimodes tells me that there are now "0 alternate tracks per volume" and "0 usable sectors on volume" I've run sdformat at 512 and at 1024 numerous times with the same result - drives that had been usable as 1.7 gig drives can no longer be initialized - at any size after running sdformat.
I should mention that I've had the Seagate 9.1 gig drives attached as external drives - although it doesn't seem like it should make any difference to me - I've employed the same method with other drives in the past.
Interestingly, if I run sdformat from the internal 1.2 gig Quantum "Fireball" 1280S drive it takes 75 minutes to complete. However, if I boot from my external 1.9 gig HP 3010 drive, it only takes 15 minutes for sdformat to complete. Both are 5,400 rpm drives.
Also tried Mike's suggested method:
disk -i -p 2000000 /dev/rsd1a
"Requested partition size larger than disk"
Same thing with:
disk -i -p 4000000 /dev/rsd1a
"Requested partition size larger than disk"
disk -i /dev/rsd1a returns
disk name: SEAGATE ST19171W
disk type: fixed_rw_scsi
writing disk label
...r/w returned -1; expecting 50176
Write of boot block 0 failed
No boot blocks on disk
Again, I'm getting the same results with two identical drives. When I first tried to use them, they initialized and gave me one usable 1.7 gig partition (apparently along with several additional 1.7 gig partitions which I can't seem to access). After running sdformat, however, the drives become unusable. sdformat seems to wipe out the boot block & I can't figure out how to recover from this.
I've successfully installed OS4.2 and can boot from the 1.7 gig partition on a third identical drive which I initialized - but did not run sdformat on - so, it seems to me that the problem is somehow with sdformat rather than with the drives themselves.
Unfortunately, I don't have access to a Mac and the only Windoze I have is 98 on an old P1 Fugitsu laptop that someone gave me - no scsi, so I don't have another system to use to do a low level format - but, I thought that was what sdformat was supposed to do....
Any suggestions would be appreciated. Thanks.
James
Quote from: "jheis"
Unfortunately, I don't have access to a Mac and the only Windoze I have is 98 on an old P1 Fugitsu laptop that someone gave me - no scsi, so I don't have another system to use to do a low level format - but, I thought that was what sdformat was supposed to do....
Any suggestions would be appreciated. Thanks.
Try these:
Make a new friend who has a new computer.
Go to a local LUG meeting and challenge the penguin fanbois to format your disk.
Get some junk machine off of freecycle to do the work.
Buy an Adaptec PCMCIA card for your P1 laptop.
That is odd? Did you get these all from the same place? I wonder if something get set on them that OS4.2/NS3.3 just can't deal with. It does sound like they need to be poked at with a low-level format on something else just to test them. The question is how to get that done? Any one on this board close to Napa or San Francisco? I'd offer to fiddle with one but I sold my Slab to Un_ so currently I only have Virtual Machines.
-Mike
Seen a similar problem with some 4Gb seagate drives I picked up last year. They were apparently pulled out of a storage array, and were not standard drives. They had a strange block size and even a custom firmware that apparently only supported a subset of the SCSI commands. I had found a related post online about them needing to replace the firmware or something to get them working, but the link was dead. Ended up selling them, as they were not going to work for me.
Chef
That's what I was suspecting also. I've read about drives from a storage array giving some of the Irix people trouble but someone was able to clear them and get them working. So I think it is possible to fix it but probably will not be easy.
-Mike
Quote from: "mgtremaine"That's what I was suspecting also. I've read about drives from a storage array giving some of the Irix people trouble but someone was able to clear them and get them working. So I think it is possible to fix it but probably will not be easy.
-Mike
Now that you mention it, it might have been a thread over on nekochan about it, as I was messing around with a few Indy's at the time. Time for a little searching when I get a free moment, as this is going to bug me now. :?
Chef
Thanks Guys:
I'm sure these drives were pulled from some sort of storage array - they still had the latch/handle hardware attached. I picked them up at HSC which is a local electronics surplus shop - they had a whole bin of them.
The frustrating thing is that they will work "out of the box" as 1.7 gig drives. It's only when I try to utilize the rest of the drive that I run into the sdformat problem.
Running sdformat without any flags returns:
_______
INQUIRY
Peripheral Qualifier: 0
Peripheral Device Type: 0x0 (read/write disk)
Removable Media: No
ANSI-Approved Version: SCSI 2
Response Data Format: 0x2
Relative Addressing: No
32-bit Wide Data Transfers: No
16-bit Wide Data Transfers: Yes
Synchronous Data Transfers: Yes
Linked Commands: Yes
Tagged Command Queuing: Yes
Soft Reset: No
Vendor Identification: 'SEAGATE'
Product Identification: 'ST19171W'
Product Revision Level: 'S09C'
Vendor Specific: 'AUSPEX 63-0028'
____________
MODE SENSE
Write Protect: No
Density Code: 1
Number of Blocks = 1005896
Block Length = 512
James
Quote from: "jheis"
Vendor Specific: 'AUSPEX 63-0028'
Yup, an Auspex NAS/SAN device from the look of it. They went bankrupt back in 2003, at least according to the link below.
http://www.storagesearch.com/auspex.htmlHere is a FAQ page I found through google which talks a little about the drives. The key point is that you really had to get replacement drives from them for the units, which leads me to believe they did some "custom" stuff to the drives.
http://web.cecs.pdx.edu/~rootd/auspex/auspex.t.htmlChef