Creating a bootable disk using BACKUP /IMAGE (VAX-VMS)

[Chris Smith_23]

Hi,

I've been tasked with producing a bootable copy of a customer's VAX-VMS system disk to use (with new licences) on a 'back-up' system. The hardware is VAXstation 3100-M38. The new 'back-up' system has 2 x RZ28-E drives. I have taken an image backup of the original system disk (VMS 5.5-2) onto an RZ26L-E and I can boot this on the new system. However, if I make an image backup copy from this RZ26 onto the RZ28-E in the new system the image is not bootable. The message at the console is:
-DKA0:
?42 NOSUCHFILE
?06 etc..
If I boot from the RZ26 and mount the RZ28 and perform an ANA/DISK DKA0: I get messages refering to SWAPFILE.SYS and SYSDUMP.DMP having 'inconsitent highwater-mark & EFBLK'.

A quick Google search informed me that, on the boot device, the VAXstation 3100's console firmware can only handle CDB6 SCSI commands i.e. maximum 2^21 addressable sectors as opposed to the CDB10 SCSI command's 2^32 addressable sectors. I would have thought that an image backup copy would put all the files in an orderly contiguous group at the front of the disk so this limitation wouldn't be a problem until the disk started to fill up and a vital file was placed at a sector who's address was greater than 2^21.

Can anyone shed light on why I can't make a bootable image copy on the RZ28? I can build a bootable VMS 5.5-2 from the distribution CD on the RZ28 without any problem. This process relies on copying VMS2055.B/SAV in image form onto the system disk so why is that any different?

Puzzled!

Any help gratefully received.

Chris Smith

[Galen Tackett]

Chris,

I've never run into this problem myself but perhaps the WRITEBOOT utility would help:

$ RUN SYS$SYSTEM:WRITEBOOT
Update VAX portion of boot block (default is Y): Y
Update Alpha portion of boot block (default is Y): N
Enter VAX boot file: device-name:[vms$common.sysexe]vmb.exe

You might want to check the online documentation at http://h71000.www7.hp.com/doc/73final/6629/6629pro_013.html#index_x_359 yourself before trying this.

Maybe someone with more experience in this area will check in here too...

Galen

[Steven Schweda]

I'd expect it to boot, too, but what do I
know (or, normally, care) about
physical/logical placement on the drive?
See HELP INITIALIZE /INDEX. How far out is
"MIDDLE" on an RZ28?

Assuming that an RZ28 is bigger than 1.07GB,
what was your plan for dealing with the disk
corruption problem when the system crashes
for any reason at all? The VMS FAQ says:

There are numerous discussions of this
VAXstation 3100 in the comp.os.vms newsgroup
archives. Please use Google newsgroup search
to search the archives for further details,
for discussions of the workarounds, and for
details of the potential for a simple failed
bootstrap and particularly for discussions
of the potential for severe system disk
corruptions on crashes.

[Chris Smith_23]

Hi Steven

My plan was to inform the customer that the system he had specified i.e. with a system disk > 1.07GB, had the potential for major disk corruption in the case of a system crash and recommend that he substitute an RZ26 for the system drive RZ28.

I suspect, following on from your prompt, that the 'middle' of an RZ28 is at a sector address > 1.07GB so that probably accounts for the inability to boot from that drive. There doesn't seem to be any way round this as it isn't possible to pre-initialise the RZ28 with /INDEX:1024538 which would put the index in roughly the same place as an RZ26 would have it, then perform the BACKUP /IMAGE /NOINIT as that just brings up a (fatal) message that the index file on the destination disk is too small!

So it looks like I will just have to persuade the customer to change his specification so that the system disk is <= 1.07GB i.e. an RZ26.

Many thanks. I'll let you know how I get on.

Chris

[Jan van den Ende · Accepted solution]

Chris,

yes, it is a known restriction, and workarounds can fail. Not only they CAN, but I have had the rather unpleasant experience that they really DO !!
It is long ago, but I still have bad memories of an emergenciy move-over of the contents of a small-enough disk, various hardware reconfigs, and a complex restore.
(restore to a bigger disk, delete all kinds of things not vital for VMS itself, an image backup of that to the small disk, and then shoehorsing the extra stuff to another disk. Brrrr. And still the customer was glad that he _ONLY_ suffered downtime!! )

But I am afraid that for sufficiently small disks nowadays you will have to go to a used-hardware vendor.

Wishing you luck & success.

Proost.

Have one on me.

jpe

[Steven Schweda]

> [...] with /INDEX:1024538 [...]

Eh? "/INDEX = BLOCK: 1024538"?

> [...] (fatal) message that the index file
> on the destination disk is too small!

You still have /HEADERS and /MAXIMUM_FILES
with which to play, but as it's a disaster
waiting to haoppen, I'd spend my time
searching Ebay for Seagate ST11* and/or
ST31*. An RZ is ok with me, too.

I've had a new-in-box ST11200N in the closet
for a few years now, just waiting for the day
when the system disk in my VAXsta 3138 fails.
Lucky find at the local junk store. A $10
insurance policy seemed cheap enough at the
time.

[Jan van den Ende]

Re Steven:


You still have /HEADERS and /MAXIMUM_FILES
with which to play
/quote>

.. but on pre-7.2 version (and on ANY Vax version for that matter) those offer VERY little exra room to move!

Proost.

Have one on me.

jpe

[Chris Smith_23]

OK Guys! I get the message. I have already informed the intermediary in this transaction that a system disk > 1GB is a no-no. I'm expecting to speak to the end user very soon and will try and get them to agree to modify their specification. I'm wondering if the end user is already 'at risk' as I don't know if they are using 2GB drives as system devices on their existing systems! That is the trouble with being a sub-sub-contractor. ;-)

Many, many thanks to you all for your assistance.

Chris

[Stanley F Quayle]

It's time to move the client from the 3100 to a more-modern box like a VAXstation 4000-90. They're generally available pretty cheaply, and you can certainly boot disks bigger than 1.037 GB.

If the client doesn't need the display capabilities, you could move to most any VAX, or CHARON-VAX [Shameless Plug (tm) from a reseller] http://www.stanq.com/charon-vax.html

If you're REALLY stuck on that system, you can make a patched boot ROM. It's a "don't try this at home" option, but some digging on Google will turn up the images.

[Chris Smith_23]

Hi Stanley

Unfortunately that is totally beyond my control. To me their use of 'legacy' hardware and software is frightening knowing how and where this is used!

Cheers

Chris