(last updated: 08-Aug-2016)
The current configuration is in its original 'as acquired' condition. I haven't changed any of the modules/cards or their order in the backplane.
| "PELE" | A | B | C | D | |
|---|---|---|---|---|---|
| 270-pin NMI | 1 | (empty) | |||
| 2 | (empty) | ||||
| 3 | (empty) | ||||
| 4 | L4004-CT : MA650 : 64MB RAM | ||||
| 5 | L4002-CA : KA675 CPU (62.5MHz) : Console SLU : DSSI cntlr (x2) : Ethernet | ||||
| Q22/CD | 6 | M5976-SA : KZQSA : SCSI controller | |||
| 7 | (empty) | ||||
| 8 | (empty) | ||||
| 9 | (empty) | ||||
| 10 | (empty) | ||||
| 11 | (empty) | ||||
| 12 | (empty) | ||||
04-Sep-2009
This system was included in a larger truckload of equipment, primarily a large PDP-11/70 system, rescued from Sparks, Nevada. The system is in a BA400 box mounted horizontally in a short rack, along with a Storage Shelf with two add-on SCSI drives mounted in the upper part of the rack.
Both the BA400 box and the Storage Shelf each have an 'Property of IGT' asset tag. International Gaming Technologies, a gambling technology company, is based in Reno, Nevada, so it should be no surprise that I'd find this system in that area. Who knows what is on the disk drives?!
06-Sep-2009
As part of a larger effort to relocate several cabinets from my garage to my basement workspace, this unit was cleaned up and partially disassembled and cleaned using my normal process of vacuuming and wipe-down with Windex.
First, I removed and cleaned the side panels, then the top panel. I then removed the entire BA400 box from the slide mounts. I finished cleaning the rack and then relocated everything to the basement workspace.
There, I began to disassemble the BA400 box, cleaning as I go. I removed the CPU panel and the PCBs. The backplane is actually pretty clean, except for a few 'dust bunnies' which I removed by vacuuming. I continued by removing all sub-components including the disk drives, the power supply, and the cooling fan assembly. At each step I vacuumed and cleaned with Windex.
07-Sep-2009
After cleanup, the system was in pieces. (photos) I reassembled by first installing the fan subsystem, then the power supply, then the PCBs. (photos) AS I installed the three PCBs, I checked the configuration of each:
L4002-CA : KA675 : VAX 4000 CPU : s/n KA322RU648 (no on-board configuration)
L4004-CT : MS650-xx : 64MB RAM : s/n ZG24602454 (no on-board configuration)
M5976-SA : KZQSA : QBus SCSI controller : s/n AS11502653 Jumpered: W1,W2,W4,W10,W15,W16 Removed: W3,W5-W9,W11-W14,W19
Finally I installed the DSSI drives. I did not reinstall the Storage Shelf box or its two drives. The Storage Shelf apparently is also missing it's power supply, so there is no purpose in installing it now. The system's main storage is on the DSSI so we should be able to move ahead with system checkout without the SCSI subsystem.
07-Sep-2009
After examining the construction of the power supply and finding no dismountable capacitors, and since this system is of more modern construction, I decided to forego any capacitor reformation. I don't know how long it has been since the system has been powered, but I believe there should be enough control and fault protection circuitry in the power supply that I'm probably safe in just hitting the power switch.
I set the 'Write Protect' switch, and after cutting a power cord socket end to accept the notch in the power supply plug socket, and connecting up a VT320 terminal, I powered up. Fans started, the power supply shows life, with a green 'Power OK' light, and the drives all started up. This is good!
On the terminal I saw the normal ID and countdown. I do get a bunch of diag info on count '8' which I don't understand. To be checked in the future. But I can issues console commands, and communicate with the DSSI drives using the 'SET HOST/DUP/DSSI n' command, so I think the basic system is definitely alive. I then connected to the local network. The ethernet address is 08-00-2B-30-6C-41. So far so good.
07-Sep-2009
During preparation of my Linux box (aero-6) to serve as a MOP/BOOTP/NFS server for netbooting NetBSD, I tried to find the specific steps that I used to netboot my other VAXen. Unfortunately, I can't locate that information. I thought I'd have in the notes file for these other VAXen, but I can't find them. I'll have to study this out all over again. Argh!
XXXXXXX Here's how to netboot a VAX:
[ CONFIRM THIS! ... THEN DESCRIBE IT IN PERFECT DETAIL! ]
On Debian (Woody) box:
/etc/inetd.conf : enable bootp /etc/inetd.conf : enable tfpt /etc/bootptab : add entry for client machine (VAX needs 5 lines) /etc/exports : add entry exporting /tftpboot/... (location of netbsd.ram.gz) /tftpboot/mop/ : add file or softlink named for MAC-addr to boot.mop /tftpboot/.../ : locate boot.mop and netbsd.ram.gz /tftpboot/.../ : add softlink (if desired) to netbsd.ram.gz stop dhcpd start mopd start nfs-user-server
I got it working finally, but the VAX would halt when booting the NetBSD 1.5.3 installation kernel. I suspect that the VAX 4000 is not supported in that version. I tried NetBSD 3.1 and it successfully comes up, but it doesn't show any disk devices in the system. It sees the SHAC device (DSSI controller), but says that it isn't configured. I wonder if the SHAC is a supported device, but it is not configured into the install kernel. The install kernel did not recognize the SCSI controller at all.
Checking NetBSD's online information strongly suggests that DSSI is not supported. The model 400 isn't mentioned specifically in the expanded supported hardware section, though it is given in the summary list. But it is stated that DSSI is not supported in VAX 4000 model 200 or model 300. Newsgroup discussions also lament the lack of DSSI support in NetBSD, in general. I also checked OpenBSD (which has a VAX port) but that distribution does not support DSSI either.
I checked to see if ULTRIX supports this machine, but apparently not, from what I was able to google. So I believe UNIX is NOT an option for this machine. Looks like it'll be VMS right down the line.
I checked HP's OpenVMS hardware support page at:
http://h71000.www7.hp.com/openvms/hw_supportchart.html
and found the this system is supported by OpenVMS v5.5-2HW or later.
So, I'm not going to be able to image the disks directly on this machine (I don't know VMS so can't use that, as yet). My plan now is to move the drives to my DECsystem 5400 which is running ULTRIX 4.5 and supports DSSI drives, and image them from that system. Then I'll return them to this system.
09-Sep-2009
Using the DECsystem 5400 running ULTRIX as a host platform, I started imaging this VAX's drives.
On the DS5400's R215F expansion box, I removed the power and DSSI cables from the drive in the lower bay. Then I removed the VAX's RF31 disk and without unmounting from it's sled/slider I disconnected it's DSSI cable and power cables, but left the drive's front panel connected. I was now able to connect the RZ31 to the DS5400 system, supporting it on a cardboard box. (photo)
After swapping the drive ID plugs so that this drive became Unit #5, I imaged the disk with this command:
# dd bs=512 if=/dev/rra5c of=/mnt3/VAX4000_RF31_2.dsk conv=noerror,sync 744400+0 records in 744400+0 records out 744400+0 records in 744400+0 records out #
[I'm not sure why it gives the record count twice.]
The imaging process for this 381MB drive took about an hour. I didn't specifically time it.
I moved on to the next drive, Unit #3, a RF35:
# dd bs=512 if=/dev/ra5c of=/VAX4000_RF35_3.dsk conv=noerror,sync; date read: I/O error 1664628+0 records in 1664628+0 records out 1664628+0 records in 1664628+0 records out Wed Sep 9 21:55:44 MDT 2009 #
Next drive, Unit #4, a RF35.
# date; dd bs=512 if=/dev/ra5c of=/VAX4000_RF35_4.dsk conv=noerror,sync; date
Unfortunately, I was unable to capture the output of this command. I presume that all blocks were copied because the file size is identical to the sizes of the other RF35 images. I'm moving on.
Next drive, Unit #5, a RF35.
# date; dd bs=512 if=/dev/ra5c of=/mnt3/VAX4000_RF35_5.dsk conv=noerror,sync; date Thu Sep 10 11:30:45 MDT 2009 read: I/O error 1664628+0 records in 1664628+0 records out 1664628+0 records in 1664628+0 records out Thu Sep 10 13:04:10 MDT 2009 #
10-Sep-2009
Next drive, Unit #6, a RF35.
# date; dd bs=512 if=/dev/ra5c of=/VAX4000_RF35_6.dsk conv=noerror,sync; date Thu Sep 10 13:17:22 MDT 2009 read: I/O error 1664628+0 records in 1664628+0 records out 1664628+0 records in 1664628+0 records out Thu Sep 10 14:50:02 MDT 2009 #
The last drive, Unit #1, a RF73, is proving to be a little different. It shows up in a >>>SHOW DSSI inventory as:
DSSI Node 5 (RF737) -DIA7 -rf(5,7,*) (RF73)
and when I boot the host DS5400 system, it doesn't complain, but neither can it find the /dev/ra5a device. I'm sure it is coming up as the /dev/ra7a device, and I don't have that many devices compiled into the kernel.
The DSSI settings in the drive have this unit with:
ALLCLASS 2 [0, default] UNITNUM 7 [0, default] FORCEUNI 0 [1, default]
So, I think that I need to set FORCEUNI to 1 so that the drive ID plug will make it into unit #5, not only the on-board controller, but the drive too. I got into the MOP system and changed it:
>>>SET HOST/DUP/DSSI 5
...
Task Name? PARAMS
...
>>>SHOW DSSI ... DSSI Node 5 (RF737) -DIA5 -rf(5,5,*) (RF73)
So now it shows up as I need it too, and it should be recognized by Ultrix as /dev/ra5a. It is, so here we go!
# date; dd bs=512 if=/dev/ra5c of=/mnt/VAX4000_RF35_1.dsk conv=noerror,sync; date Thu Sep 10 15:38:40 MDT 2009 read: I/O error 3907908+0 records in 3907908+0 records out 3907908+0 records in 3907908+0 records out Thu Sep 10 20:27:29 MDT 2009 #
As I worked each tray of drive(s) I remounted the prior one into this system. After re-mounting the last, I called it a night.
TODO: Need to re-set the 'SET FORCEUNI 0' parameter in the RF73.
11-Sep-2009
With the disk imaging complete, I set the DSSI configuration parameters on the RF73 back to their original values:
>>> SET HOST/DUP/DSSI 1
...
Task Name? PARAMS
...
>>>SHOW DSSI DSSI Bus 0 Node 1 (RF737) -DIA7 (RF73)
DSSI Bus 0 Node 2 (RF312) -DIA2 (RF31)
DSSI Bus 0 Node 3 (RF353) -DIA3 (RF35)
DSSI Bus 0 Node 4 (RF354) -DIA4 (RF35)
DSSI Bus 0 Node 5 (RF355) -DIA5 (RF35)
DSSI Bus 0 Node 6 (RF356) -DIA6 (RF35)
DSSI Bus 0 Node 7 (*)
DSSI Bus 1 Node 7 (*) -- terminators not present or not working >>>
So, short of terminators for the second DSSI bus, looks like the system is in good shape.
When I reset the system, and watch the countdown, this is what I see:
KA675-A V4.9, VMB 2.12 Performing normal system tests. 9D..42..D0..52..52..55..DB..35..33..32..D2..DF..DC..D1..D0..46.. 35..DE..DD..DA..54..60..91..90..C6..53..C1..34..C5..49..4F..4E.. 4B..4A..4C..3F..3F..48..48..48..48..48..48..48..48..48..4D..47.. 40..40..37..C2..80..37..51..5F..5C..
?5C 2 06 FF 0000 0000 00 ; SUBTEST_5C_06, DE_SHAC.LIS
[...and a page full of registers and values...]
Since we know that the second DSSI bus is not properly terminated, and the test message indicates it is for the SHAC (which I believe is the DSSI bus controller) it may simply indicate that the second DSSI bus is defective (because of no termination), and I think we can move forward. If and when I can located the correct terminators, I'll definitely add them to this system.
Now the question is, what drive is the normal bootstrap device? I'm going to start with unit #1, the RF73, which shows up as 'DIA7' and just go down the line. With the 'Write Protect' switch engaged:
>>> BOOT DIA7 (BOOT/R5:0 DIA7)
2.. -RF737$DIA7 ?42 NOSUCHFILE, DIA7 ?06 HLT INST PC = 00000D8D Bootstrap failure. >>>
Trying it as DIA1 gives:
>>> BOOT DIA1 (BOOT/R5:0 DIA1)
2.. ?42 NOSUCHDEV, DIA1 ?06 HLT INST PC = 00000D8D Bootstrap failure. >>>
Hmm, a slightly different response. In one case NOSUCHFILE and in the second, NOSUCHDEV. So, let's keep at it. I tried all of the rest of the devices, DIA2, DIA3, DIA4, DIA5, DIA6 and received the same response:
>>> BOOT DIAx (BOOT/R5:0 DIAx)
2.. -RFxxx$DIAx ?42 NOSUCHFILE, DIAx ?06 HLT INST PC = 00000D8D Bootstrap failure. >>>
So, while the devices have data on them, it appears that none are directly bootable. I wonder if there is a specific boot file that should be specified given that the TOY battery had run down and the contents of the NVRAM lost.
I'll need to learn more about this system to proceed.
Just for kicks, I powered off and moved the single DSSI terminator that I have from the DSSI Bus 0 expansion port to the DSSI 1 expansion port and repowered. Now the countdown proceeds to completion:
KA675-A V4.9, VMB 2.12 Performing normal system tests. 9D..42..D0..52..52..55..DB..35..33..32..D2..DF..DC..D1..D0..46.. 35..DE..DD..DA..54..60..91..90..C6..53..C1..34..C5..49..4F..4E.. 4B..4A..4C..3F..3F..48..48..48..48..48..48..48..48..48..4D..47.. 40..40..37..C2..80..37..51..5F..5C..5C..9A..83..84..85..86..41.. 90.. Tests completed. >>>
This is good! It indicates to me that all of the major system and subsystems in this machine, hardware-wise, are operating as they should. So the machine isn't a lemon, or someone's cast-off because of hardware failures. Good! I'll leave this terminator in this position for now.
15-Sep-2009
After cracking open the shells around the two SCSI drives from the Storage Shelf, I connected them to my SGI Indy #1 which was easily netbooted with NetBSD. That gave me a platform from which I could image these drives, since I am missing all of the connecting cables and so on from the SS.
The RZ28 is an older half-height drive labeled with only DIGITAL information, while the RZ28M is a newer third-height drive and is clearly OEMed from Seagate. It's Seagate designation is ST32430N "Hawk".
With the drives pulled from their shells, the SCSI ID needs to be set using the following information:
RZ28 jumpers ===============PCB :::.:::::: 124
RZ28M jumpers ===============PCB XXXX:::::: 421
Starting with the RZ28, SCSI ID set to #1, I imaged it with:
# date Tue Sep 15 16:33:11 MDT 2009
# mount 192.168.1.10:/home/jared /mnt # dd bs=512 if=/dev/sd0c of=/mnt/RZ28.dsk sd0: no disk label 4110480+0 records in 4110480+0 records out 2104565760 bytes transferred in 5213.253 secs (403695 bytes/sec) # date Tue Sep 15 18:02:39 MDT 2009 #
So we have a good copy of this drive, in about one and a half hours.
Next I swapped in the RZ28M, SCSI ID set to #2, which I imaged with:
#date Tue Sep 15 18:19:19 MDT 2009
# mount 192.168.1.10:/mnt/win /mnt # dd bs=512 if=/dev/sd0c of=/mnt/RZ28M.dsk sd0: no disk label 4110480+0 records in 4110480+0 records out 2104565760 bytes transferred in 5264.804 secs (399742 bytes/sec) # date Tue Sep 15 20:18:10 MDT 2009 #
With both drives imaged, I burned them to DVD for archival. Neither appears to be bootable, but both drives do contain a VMS file system, by the looks of a 'strings' dump, and the files are mostly source code files for IGT gaming systems (slot machines).
16-May-2011
Some months ago (?????when?????) I received two RZ26-VA StorageShelf drives from ebay seller 'tuber'??? . These have been awaiting imaging, and today is the day.
Like the RZ28 drives that came with the system, I cracked open the cases and pulled the bare drives in order to attach them to my host imaging system of the day, an IBM PS/1 with an Adaptec AH-1420 host controller running the NetBSD 3.0 installation kernel. It appears that the jumper posts are the same as the RZ28 drives, so I'll go ahead accordingly.
The first drive I imaged thusly:
# dd if=/dev/sd0a bs=1k of=/mnt/Donzelli_RZ26-VA_#1.dsk
Alas, for some reason, while the system appears to recognize the drive's size during kernel boot (dmesg), executing 'dd' stops after 131076 blocks (2*65536) as if it had reached the end of the drive. No error, it just stops. I tried again with the same results. Hmmm.
23-Apr-2013
After seeing a recent post on the cctalk: mailing list from Paul Anderson having some BA350 gear available I pinged him with an email. We later talked by phone. He said that he has quite a few Storage Shelves, shelled drives (SBBs) as well as raw drives, and other related pieces. We agreed that I would prepare a wish list after doing a little more work to confirm what I already had and what I need.
This prompted my to re-examine the BA350 that I have. Looks to be a BA350-SB subsystem, with the so-called jumper and termination modules installed so that the system has a single 7-drive SCSI bus. All I need is the power supply module, and more drives, or slot covers to close the front of the shelf to maintain proper cooling air flow.
31-Aug-2013
It has been years since this sytstem has had any real attention. I finally replaced the top and side covers to the rack, then attached my VT-320 terminal as the console device. Then I fired it up. Came up to the chevron prompt without any trouble. All seems in good shape. It's nice to have systems that use switching power supplies, instead of linear ones! There are no large capacitors that need to be reformed after sitting for some lengthy time. So, now that we're up and cooking, we still need to solve the issue of having no bootable OS installed.
Previous examination has shown that the drives (all without boot loader) contain VMS filesystems. The system does contain a SCSI MCSP controller though, and I hoped a connected external CD-ROM drive could be used to load software. I used the Legasys CD-ROM drive, borrowed from my HP 9000 715/100 workstation, and connected it to the exposed 50-pin Centronics port on the KZQSA module in slot 6. Lo, when I repowered the system and performed a >>> SHOW SCSI command, the CD-ROM drive is recognized as DKA200!
A renewed investigation tonight shows that this system can run VMS or NetBSD. I've used NetBSD extensively in the past with other VAXen and wanted to use it for further investigations. I downloaded the latest NetBSD-vax 6.1.1 ISO image and burned a CD. Sadly, it didn't work as planned.
The system recognized the CD drive, and actually loaded the initial NetBSD bootloader, but then after the countdown it drops out to the bootloader prompt after printing "Machine check PC=xxxxxxxx PS1=xxxxxxxx". Further keyboarding drops to the >>> prompt. A review of the NetBSD site's VAX section suggests that the KZQSA SCSI controller is not supported, at least as a boot device for installation. However, the good news is that the system does have a SCSI channel and it is alive and working.
Then I had a brainstorm, I'll just connect up my RF215 expansion box (used with my DECsystem 5400) and use one of the DSSI drives in it as the target boot device, for now anyway. I have two drives in that subsystem that are available for scratch. I cabled the unit up to the DSSI channel 1 port on the main bulkhead panel and powered up. I confirmed that the additional drives were visiable to the system using the >>> SHOW DSSI command and I saw the additional three drives. This confirms that the second DSSI channel is alive!
Then, I tried to netboot NetBSD from the my Debian Linux box (aero-6) just to play with that on the new drive, but I never could get a good load of either the loader itself, or if that worked, the INSTALL OS. Finally I gave up, removing the external RF215 expansion subsystem, and had a new brainstorm.
I'll pull the current RF73 from the unit and slide in one of my spare RF72s. I already had some spare drive mounting brackets for the BA440 chassis and so I removed one of my spare RF72s from storage, mounted it in the bracket, and replaced the original RF73 with this one. It was recognized as 'R2AIJC$DIA1:'.
Now, to install VMS!
02-Sep-2013
I had a complete Consolidated Software Distribution package for VMS 5.5-2 on hand, and decided to give it a go. There is a special incantation required to get the CD #1 to boot into the standalone BACKUP facility used for installation:
>>> boot/r5:e0000000 dka200
Without the /rf:e0000000 switch, the system will not find a boot file.
Using the manuals from VMS 7.0 as a guide I tried to install with this command:
$ backup/image/verify dka200:vms552.b/save_set_$ r2aijc$dia1:
but that DID NOT work!
Further considerations suggest that I have to install the baseline VMS 5.5 first, then apply the -2 update. So, after consulting the Master Index sheets that came with the CDs, it looks like there are two directories with the OS: 'VMS055' and 'VMSU2055'. I tried:
$ backup/image/verify dka200:vms055.b/save_set_$ r2aijc$dia1:
and that worked! In about three minutes the installation was complete. The installation instructions then say to halt the processor and reboot to the target device just written to.
>>> boot dia1:VAX/VMS Version BI55-52I Major version id = 1 Minor version id = 0
VAX/VMS Version 5.5 Installation Procedure
Model: VAX 4000-600 System Device: RF72 - _R2A9JC$DIA1: Free Blocks: 1907478 CPU Type: 19-01
* Please enter the date and time (DD-MMM-YYYY HH:MM) 01-sep-2013 20:10
I entered the day and the system started up. A dozen or so messages of various kinds went by, one of which reminded me that I don't have a license, and then it stopped asking for a system volume name. I chose the default 'VAXVMSV055':
* Enter the volume label for this system disk [VAXVMSV055]: _
Then entered the name of my CD drive:
* Enter name of drive holding the VMS Distribution meda: DKA200:
I then finished the installation taking the defaults, in general. In a short time I was rebooted into a working VMS system! Now to explore!
02-Sep-2013
Tonight I explored the system for a couple of hours, learning how to navigate the directory structure and get various status information with the SHOW command. Once I had that down pat, I wanted to mount each drive to examine its contents. I tried to mount the DIA2: device with:
$ MOUNT $2$DIA2:
but was stuck since I didn't know the volume label. Furthe use of HELP MOUNT and a little web searching showed that you can bypass the label requirement with:
$ MOUNT/OVERRIDE=IDENTIFICATION $2$DIA2:
which worked, and reported that the drive's label is 'BLANK'.
I tried this with each of the other drives. For the RF73 that I removed to install my scratch RF72, I shutdown and removed the RF31 (DIA2:) and re-installed the RF72 in it's place which showed up as DIA7:. So here are the results:
device type label contents
-------------------------------------------------------------------
DIA2: RF31 BLANK empty but a few .SYS files in [000000]
DIA3: RF35 BACKUP1 empty but a few .SYS files in [000000]
and three sets of PAGEFILE.SYS and SWAPFILE.SYS
DIA4: RF35 SYS_PRJ2 Lots of ASM, LST, OBJ files from IGT work
DIA5: RF35 SYS_TM6 Lots of ASM, LST, OBJ files from IGT work
DIA6: RF35 SYS_OBJ Lots of OBJ files from IGT work
DIA7: RF73 QUEEN_1852 empty but a few .SYS files in [000000]
So, it would appear that I would have two drives that I could use for new installations or scratch devices without having lost any interesting files, DIA2: and DIA7:, or even DIA3:, too.
03-Sep-2013
With these new basic skills learned with VMS 5.5, I thought I might as well install the Hobbyist VMS that I have on the Hobbyist CD. In this case, I DO NOT use the /R5 switch when booting, instead I simply boot to the device:
>>> BOOT DKA200:
which loads up the stand-alone BACKUP tool. At this point I just adjusted the version number in my command and installed with:
$ backup/image/verify dka200:vms073.b/save_set_$ r2aijc$dia1:
06-Sep-2013
Today a BA35X-HF power supply (s/n CX51504559) arrived from eBay seller "expertcomsvc", packaged well. It was just a tad dusty and I cleaned it with my usual Windex wipedown. Now need to test it out!
I installed it into the left-most slot in the BA350 StorageShelf and connected up the AC through a switched power strip. With four drives also intsalled in the shelf -- alas, without empty slot covers -- I switch on the power. I have two solid green lights on the power supply, the fans (at least one) and the drives all light up. The drives show two green lights each, then fairly rapidly the lower light goes out, then over the next minute, three drive's top lights went out also. One drive had its top light remain on for the four or five minutes that I had power to the system.
One item to possibly look into: the left shelf fan is on and pushing air that I can feel, the right fan is not pushing air, and I can't tell if it is turning at all or not. Might need to remove the shelf from the rack and investigate.
But on the whole, I'm happy. I now have power for the shelf and hope to cable up the box to the VAX and enjoy SCSI storage in addition to the DSSI devices.
21-Jul-2016
I removed the storage shelf from the rack. On the bench, I powered it up and found that both fans are indeed pushing air, so that is not a problem. I had my VAXstation 3100m30 running NetBSD 1.5.3 at the time, and I connected the shelf to the VS3100 for exercise. Might as well reimage the drives while I'm at it.
Turns out that one of the Donzelli RZ26s was not responsive. I could see that it had power, but the top LED would never extinguish after spin up, nor would it respond to reads. I removed that BSS from the shelf and cracked open the shell (push the tabs on the sides to release the clamshell about 1/4-inch, then pop the front bezel off, then open up completely) and removed the drive from the bottom shell. Close examination shows that the printed cable had separated from the +12V solder joint at the power connector, probably a result of my earlier imaging efforts (NB: don't open new SBBs in the future, just image them in the StorageShelf!). I could see that the printed trace ran from the +12V post to a capacitor soldered right onto the printed cable, so I jumpered the post to the capacitor's solder pad with 26-gauge wire, restoring the connection. I reassembled the drive in its shell and tested it. It now works!
So, with the shelf connected to the VS3100, and the SBBs in appropriate slots in the shelf (VS3100 uses SCSI ID#6 as host controller and ID#3 for internal HDD) I mounted a target directory over NFS and imaged each device again. With the 10Mbps Ethernet connection it was slow, but worked.
Copyright © 2006-2025 Jared Blaser. All rights reserved.