DVD install of OpenVMS on zx6000 ?

[Jim_McCarthy]

I'm trying to install OpenVMS v8.3-1 on an HP zx6000 workstation with dual 1.5GHz Itanium-2 processors. Firmware is up-to-date, and with VGA console disabled, via serial console I can navigate via the EFI shell to fs0:\EFI\VMS and I see the VMS_LOADER.EFI file. But executing that file crashes the system (red "System" LED and blinking red "#2" LED) after about 30-45sec of activity reading the DVD. The DVD-R media was verified after being written (on a WinXP machine with DVD burner).

This thread:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1049157

is unambiguous about the need to put the DVD drive on the IDE hardrive cable in a zx2000 in order to boot VMS. Was I wrong to assume that imperative applies only to the zx2000, and doing likewise would not be necessary on my machine (zx6000 = rx2600, a close(?) cousin of the rx2660 on which VMS is officially supported).

Hence I'm interested in others' experiences installing OpenVMS from DVD on zx6000. Should the install work correctly with the default IDE (I presume "optical" drive) cabling of the DVD-ROM drive ?

Thanks,

-- Jim

[Hoff]

Been there, done it, typically works.

Do you trust the box? Is the history and stability and configuration of this box and this DVD drive known to work? Are all the widgets in a known and probably functional (eg: known function or known supported on some other similar box) I/O configuration?

Given you're swapping drives and asking about cables, I might assume this isn't a drive that came with the box from HP.

Do you trust the kit? DVD media can have errors, replication can introduce errors, uncounted and popular and widespread commercial recording tools can have errors, the disk image can have errors, the media and the drive can have errors and media-level incompatibilities for specific drives, etc. Put another way, recorded DVD should be viewed with some skepticism in the absence of block (or SHA1/MD5) verification.

The rx2600 is basically a direct descendant of the zx6000; the same box, with some minor differences such as a different I/O cage. AFAIK, there's only one cable going to the right spot for the DVD in that box. (The zx2000 is a different physical box.)

Might try a USB DVD-ROM/+R/RW drive here, too, as that may well work sufficiently to get you going on your V8.3-1H1 install. (I assume you're on V8.3-1H1 here, and not on V8.2-1.)

That red LED is an error. Anything interesting in the error log related to this?

[Jim_McCarthy]

Thanks Hoff for confirming

> there's only one cable going to the right spot for the DVD

in the zx6000. So with zx6000 I can cross off (eliminate) "put DVD on hard drive IDE cable not optical drive cable" from the list of steps needed to install OpenVMS, and from the possible reasons why I'm having trouble.

The DVD-ROM in my zx6000 is the one that came with the box (as far as I know, not being the original owner myself). The "DVD-R burner" I mentioned resides on another machine (laptop, actually) that runs WinXP exclusively, and I've not (yet :-) resorted to any mix-and-match experiments involving DVD drives between machines.

I've used the DVD-ROM successfully in the past with the "HP Enablement Kit for Linux" (5013-2037) DVD which creates the system disk /efi/boot and tool utilities paritions for Linux, then facilitates installation of the Linux of your choice from that distribution's CDs. I installed "Scientific Linux v4.1 for IA-64" on this zx6000 from CD-R's I burned myself after downloading the ISOs, but this OpenVMS install is my first attempt to read homemade DVD-R media in the zx6000.

The zx6000 workstation has been running SL41 like a champ for 2-months -- the only sign of flakiness I've experienced has been that power-ups intermittantly do not get to the normal LED 1->2->3->4 cycling. After first describing my experience in the "integrity hardware forum" on openvmshobbyist.com, I subsequently found a previous description here:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1042245

(where I've just updated present status with my zx6000, rather than put that text here).

When I burned the DVD-R, the software tool I used (Gear) -- see:

http://www.djesys.com/vms/cdrom.html#gearcd

-- performed a verification pass and claimed the record operation onto the DVD-R was error-free (but I agree with you that this doesn't rule-out incompatibilities between DVD drives, or between the DVD-R media and the drive in the zx6000). The fact that on zx6000 I can navigate around inside the fs0:\EFI\VMS parition was to me at least minimally encouraging, however.

Later I'd also seen the comment you have on your site recommending the tool "CDburnerPro XP"

http://64.223.189.234/node/28#comment-123

which I might also try as an alternative to Gear. I've also seen compatible (? NEC ND-6650A) DVD-RW for auction that I thought could replace the DVD-ROM that came in my zx6000, so I could CDrecord with the zx6000 under Linux, then try installing OpenVMS off the DVD in the very same drive -- as one way to eliminate drive incompatibility ! (Plus I can see many advantages to having DVD-RW capability on the zx6000 down the road...).

But right now I'm heading down the path of using BACKUP/IMAGE on my DEC PWS 600au OpenVMS v8.3 Alpha workstation, to transfer the entire contents of the OpenVMS v8.31 I64 installation "dsk" file onto an 80-pin SCSI hard disk (i.e., BACKUP/IMAGE from the LD-mounted "dsk" image into a backup save_set, then BACKUP/IMAGE from that save_set onto the SCSI disk). I'm not expecting to have much difficulty sliding this disk into the zx6000 and navigating to the VMS_LOADER.EFI file from the EFI Shell on the hard disk, as an alternative (easier?) solution for me than troubleshooting DVD incompatibilities.

Thanks again, and wish me luck!

-- Jim

[Hoff]

The SEL System Event Log contents around the error, and the I/O bus contents -- particularly the graphics controller here -- might be interesting.

Linux and OpenVMS I64 do differ in supported controllers. AGP Graphics are not (based on what I've received for feedback) a particularly good choice for OpenVMS I64.

If you want an alternative to the disk-based approach, try DVD+R/RW media. For a while, HP was pretty firmly in the DVD+ media camp. Yeah, I know, they're supposed to be compatible.

Do check the DVD drive firmware, too, as there have been firmware upgrades.

[Jim_McCarthy]

Here's an update of the SCSI disk approach:

With some hints from Steven Schweda to get me started, the LD CONNECT, MOUNT/OVERRIDE=IDEN, and BACKUP/IMAGE steps all went fine. Save_set in hand, I then dismounted the LDA1 disk image. Mounted the target SCSI disk device, then BACKUP/IMAGE told me it needed to be mounted foreign (OK - in hindsight that probably should have been obvious). Dismount and MOUNT/FOREIGN. So far so good.

Then BACKUP/IMAGE from save_set to target SCSI disk gave a warning about the result of the operation being an ODS-2 disk, which I wasn't expecting and (my fatal mistake?) I didn't think was right. So I aborted that, dismounted again, and then initialized the disk with /STRUCTURE=5 option (using the same disk label I640831H1 reported previously by LD connect, from the original "dsk" file), mounted it foreign, and this time added /NOINIT to the BACKUP/IMAGE options. Seemingly more benign messages from BACKUP this time about SYSINDEX files needing to be extended as appropriate, etc., and the BACKUP/IMAGE operation then completed.

Unfortunately, now having moved the disk over to the zx6000, I cannot find and/or read the \EFI partition (like I could previously on the DVD) in order to initiate the install.

Did I shoot myself in the foot by not letting BACKUP/IMAGE initialize the target SCSI disk as ODS-2 as it wanted to by default? (I'm reminded of Steven Schweda's comment in a previous thread about not meaning "to disturb the delicate equilibrium of the time-space continuum" and thinking I may have accidently done this!) If there is content in the "dsk" disk image that isn't ODS-format (somewhere I read a comment suggesting the \EFI directory tree was on a FAT32 partition??), will that be lost or corrupted taking it through a backup/image save_set ?

Log of the console session(s) attempting to install from SCSI disk (and again attempting to install from DVD-R) is attached. I was reasonably certain I wanted to mount the HD(Part1,Sig***) blk5 device, but when that didn't work I reset (to reboot) an then also tried the blk4 device (didn't work either, although I wasn't really expecting it to).

My plan forward is to try to write from the backup save_set onto the target disk allowing backup to initialize it as ODS-2 by default, and see if I have better luck. (Or else try BACKUP/IMAGE direct from LDA1: to DKA200: , i.e., without the intermediate save_set on disk ??). I'm also thinking there may be a NEC ND-6650A in my future and a raw CDrecord on the zx6000 under Linux....

To be continued....

-- Jim

[Jim_McCarthy]

Taking care of a few loose ends:

I've had a PCI-bus version of the ATI Radeon 7500 in the zx6000 for about 4-6 weeks now, in anticipation of trying to install OpenVMS.

The file attached to this post contains the BMC System Event log, SD log, and Forward Progress Log (FPL). These are followed by the output from EFI shell "errdump mca".

The timeline is that "yesterday" (0:00h to 1:00h GMT) were my attempts to boot from the DVD-R. At end of yesterday's session was a spell where machine refused to start the 1->2->3->4 LED cycling, so I unplugged it overnight. Then "today" (19:40 to 21:00 GMT) were my attempts to boot from the SCSI disk, including a final attempt to boot from the DVD-R again.

I confess these logs are largely unintelligible as far as I'm concerned, but since Hoff asked if there were anything interesting, I'm posting the content.

Is there a recommended method of clearing these logs before performing a troublesome operation, to narrow-down the reams of output to only the problem-relevant items? Or do I just need to manually log the system time as reported by the EFI shell:

Shell> time

... command ? What approach do others use?

Thanks,

-- Jim

[Hoff]

Assuming your firmware is sufficiently recent, the EFI command is clearlogs. For example, clearlogs sel, et al.

What looks to be VMS_LOADER or IPB is failing pretty early on during the bootstrap. Off-hand you might try setting the boot flags to 30000; to gonzo diagnostics.

What sort of disk and I/O hardware is in this box? Pull it all, save for the DVD boot disk, and see if you can boot.

And this assumes there's not a bad spot on the DVD disk somewhere.

There are also differences in the boot structures; a block transfer from a DVD to a disk or a disk to a DVD won't work, as the boot offsets are wrong in the GPT. (512 versus 2048 byte blocks. Details are in the PDF at /node/28; in the DVD mastering and CD and DVD bootstrap discussion.)

[Jim_McCarthy]

> IPB is failing pretty early on during the bootstrap.
> Off-hand you might try setting the boot flags to 30000
> to gonzo diagnostics

Hoff -- Roger that. Thanks to Jur van der Burg's input to Brendan's recent forum thread on zx2000, I discovered the proper syntax for the boot flags is 0,30000 hence:

Shell> fs0:
fs0:\> \EFI\VMS\vms_loader.efi -flags 0,30000

does indeed produce "gonzo diagnostics" (see file attached). This confirms that the boot successfully gets to:

%VMS_LOADER-I-Transferring control to IPB.EXE

before dying a few seconds later, with no additional screen output and with the same audio and LED alarm response as always.

For the boot whose log file is attached, I pulled out the following PCI boards which had previously been in the machine:

SLOT 0 / AGP / Empty
SLOT 1 / PCI / ATI Radeon 7500 PCI
SLOT 2 / PCI / Compaq LSI Logic SYM8952U
68-pin SCSI controller (for
future support of external
SCSI devices)
SLOT 3 / PCI / Genius Sound-maker Live 5.1
audio card (present in the
machine when I bought it).

In fact I first pulled boards from 2 & 3, leaving the ATI video board, and when that had no effect, I pulled the video also (for the 0,30000 boot captured).

Hard drives present in the machine for the 0,30000 boot captured where the following:

SLOT 0 - ST336706LC - Ultra3 10K 36Gb
(future "SYSDEVICE" for VMS)
SLOT 1 - HP/ST373453LC - U320 15K 73Gb
(future "DATA" disk for VMS)
SLOT 2 - WDE9150 - Ultra2 LVD 10K 9.1Gb
(has BACKUP/IMAGE content)

I just pulled all three drives and repeated the boot attempt, with identical results as always (fails at same point as in the log file attached). So could be "bad spot on the DVD disk somewhere".

Thanks for the reference to the PDF here:

http://64.223.189.234/labsnotes/openvms_cd_dvd_recording_20070306.pdf

(readers will need to cut+paste this), which explains why (despite my original optimism) the "dsk -to- SCSI-disk" transfer via BACKUP/IMAGE failed to produce the desired result when moved over to the Itanium box. I'll go back to the Alpha and see if I can patch things up with

$ SET BOOTBLOCK/BLOCK_SIZE=2048/I64 dka200:

then try again in the zx6000. Any idea if ODS-2 or ODS-5 (see above on how I forced the BACKUP/IMAGE restore to ODS-5) is more likely to result in success ?

Thanks again,

-- Jim

[Steven Schweda]

IT $ mount /noassi /over = iden cd1
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, I640831H1 mounted on _IT$DQA0:
IT $ show devi /full cd1

Disk IT$DQA0:, device type HL-DT-STDVD-ROM GDR8160B, is online, allocated,
deallocate on dismount, mounted, software write-locked, file-oriented
device, shareable, available to cluster, error logging is enabled.

[...]

Volume Status: ODS-2, subject to mount verification, allocation inhibited
because of error on bitmap, file high-water marking, write-back caching
enabled.

Note: "ODS-2". The DVD holds an ODS2 file
system, not ODS5. Converting it to ODS5 may
be harmless, but can't be necessary.

> (Or else try BACKUP/IMAGE direct from LDA1:
> to DKA200: , i.e., without the intermediate
> save_set on disk ??).

Should work as well as with an intermediate
save set.

> I'm also thinking there may be a NEC
> ND-6650A in my future and a raw CDrecord on
> the zx6000 under Linux....

I wouldn't expect any difference in the
resulting DVD (but what do I know?). The
zx6000 (+ VMS) might do something differently
when booting from a different DVD drive.

> SLOT 3 / PCI / Genius Sound-maker Live 5.1
> audio card (present in the
> machine when I bought it).

Unlikely to be supported by VMS. (Could
still be harmless.)

> So could be "bad spot on the DVD disk
> somewhere".

I doubt it (but that's not proof).

One advantage of using the DVD is that you
can be pretty confident that the boot-related
fine print will be right. The path, DVD ->
image -> DVD, should be unable to mess with
these things, while BACKUP /IMAGE can.

[Hoff · Accepted solution]

I'd encourage swapping the disk over to another Itanium box and test booting there, and swapping a bootable disk from another Itanium box and testing it here. The usual process of elimination applies. Try to localize the error to the system or the media, here.

That there's no diagnostic output after the transfer over to IPB is troubling. Most centrally, IPB's job is to switch from EFI and its disk and system boot environment to OpenVMS and its disk and system environment; to find and then launch SYSBOOT.

The following (debug) tool will decode and display the contents of the boot block on the disk you're mastering.

$ sb :== $sys$setboot
$ sb -s -f dka200:

Or on pretty much any other disk, for that matter. Post that output, and the block addresses and block lengths and the FID of [000000]GPT.SYS on the target (boot) disk -- if that file exists -- and also the block address and length of the SYS$EFI.SYS file. (The FID isn't relevant here.) The block address and block length values are available from "DUMP /HEADER /BLOCK=END=0 file", among other ways.

The GPT file should have two extents, and these should be located at the front and back of the disk. The disk location of SYS$EFI.SYS should be referenced by the boot structures.

This may well not be the disk, but I've dealt with enough mis-created CD and DVD disks and disk images over the years to not completely trust these things. Whether it's the recording, the media, or the contents. And I would try the swap mentioned above, and would try to get a real distro kit. (Or both.)