VMS 5.5 system restore not working

[Chinraj Rajasekaran]

Hi

I am trying to restore VMS 5.5 system disk on MicroVAX 3100/20 model but it seems to be the restore command is not completely restoring the system disk as it was.

So the system doesn't recognize the system disk boot partiton or boot files.

I tried, initialize new disk and complete image restore and also tried WRITEBOOT but nothing helps.

I also checked for VMS$common and syscommon issues, nothing strange on file names and i don't see any "no such file" issues.

I see two strange things.

1. If the put the restored disk on microVAX 3100/20 model microVAX it says ...

>>> b dkb200

-DKB200
?50 SCB2NDINT, DKB200

83 BOOT SYS
?41 DEVASSIGN, 0
84 FAIL
>>>

2. If i put the same disk on the microVAX 3100/90 i see it is booting but just after the VMS version and then it crashes immediatelty with the message "Unable to bugcheck at this point during bootstrap bug check code 214...."


So can you tell me what are the known issues with backup and restore on VMS 5.5.

the backup was done on VMS 5.5 and i am trying to restore from OpenVMS 5.5.2 standalone boot on the same machine and also tried restore from another machine with OpenVMS 5.5.2-H4.

Thanks in advance.

Raj

[Karl Rohwedder]

What were the exact commands to create the backup and to restore it? Did you change any hardware, e.g. the older MicroVAXes have some limits on the system disk size?

regards kalle

[Chinraj Rajasekaran]

Kalle,

here is the whole story...

The microVAX had some issues with memory onboard, so the vendor replaced the whole motherboard and infomed us the motherboard is exactly is the same as the old one.

But the originonal system disk did not boot.

The old system disk is 4GB disk and i am trying to restore to similar 4 Gb disk.
I tried restore on 3 different disks and from 3 different backups. but all gives same error.

So may be possibility that the new motherboard is not supporting 4 gb disk?

The version on console shows.. KA41-D

thanks
Raj

[Chinraj Rajasekaran]

Sorry karl...spelled your name wrong:-)

but the system with new montherboard allowed to restore from standalone backup boot from other data disk >> the restore was successful from tape to this new 4 gb disk.

Does this mean the motherboard supports the 4 gb disks.

But it is not booting from the 4 gb disk?

[Chinraj Rajasekaran]

commands used:

for backup...
$ backup/image/ignore=interlock dkb200: mkb500:dkb200.sav/save

To restore:
$ backup/image mkb500:dkb200.sav/save dkb200:

[Karl Rohwedder]

Those older system have limitations in the console software to access blocks beyond ca. 1GB on the bootdisk. Disks > 1GB as data disks were o.k.
If the VMB.EXE happens to be stored on lower blockaddresses, all is fine. If during restore it gets stored beyond 1GB the boot loader may not be able to address it.
Perhaps you are running into this sort of problem. You may want to try with a 1GB system disk, aka. Rz26 e.g.

The comp.os.vms newsgroup has discussions about these sort of problems, e.g. http://groups.google.de/group/comp.os.vms/browse_thread/thread/762b5b786eb428a0/2f2dc55c1a9e8c41?lnk=gst&q=%2Bvax+%2Bboot+%2B1gb&rnum=4&hl=de#2f2dc55c1a9e8c41


regards kalle

[Hein van den Heuvel]

Hmmm, do you still have the original drive?
I would focus on why that did not boot.
Fewer variables/changes that way.

The 1GB restriction has often been mentioned in the past and is very real. Google will probably find some articles.

If you had a workign 4GB drive and it was backed-up then it is unlikely that it'll fit back on a 1GB drive. So you'll have to get that VMB.EXE into the lower LBN range.

First check where it is with DUMP/HEAD/BLOCK=COUNT=0
Look at the LBN for that mapping pointer (just 1 in all liklelyhood.

If it is wrong, move it!
Two possible ways to approach that

1) Use an FDL with PLACEMENT options in the AREA 0 section. Then convert the file with that FDL. You can dump bitmap.sys to find free space early on the disk (remember... multiply the bit number by the cluster size (9?) to find LBN. A couple of free bits inthe first quarter of the file will do.

2) Find a host/donor file which is in the right place (trial and error? dfu? Save (copy) that file as needed, and use COPY /OVER to plnk down a clone of the VMB.EXE. Now rename the original VMB and SET FILE/ENT the donor to become VMB.EXE and writeboot.

Disclaimer.... I'm making this up as I go. Not tested, and did not have my morning coffee yet. But it should be close...

Groetjes,
Hein.

[kumarasamy]

hi Raj!

boot from stand alone mode by
>>>b/e0000000 dkb200:
and retore stand alone backup if you have one
this will initialize disk then restore,.
this will help for normal boot.
you do not have stand alone backup, try to create one to restore.
first creat standalne kit in the disk that is to be used as system disk.

kumar

[Hoff]

I'd tend to suggest replacing the box with an available VAX emulation, or with a "newer" VAX box. This VAX is ancient, and has some definite limits. And you've almost certainly encountered one.

It's almost certainly the 1.073 gigabyte limit of older VMB involved here, and this is described in the OpenVMS FAQ. These older VAX boxes use six-byte SCSI commands within the VMB image in the console ROM, and these ROMs are rather older than gigabyte-sized disks. Six-byte SCSI commands cannot address disk storage past 1.073 GB -- and addresses references will wrap back to zero, and there are cases where the writes will wrap back to the front of the disk and (over)write that area of the disk.

If you do choose to restore to a larger disk, ensure that the VMB image and the system dump file are always and completely and entirely below 1.073 GB. If the dump file gets above that and the writes wrap, disk corruptions can ensue upon crash.

The /IGNORE=NOBACKUP allows and permits silent data corruptions in the created saveset. At a minimum, you'll likely be recreating the queue database. If the data is important, this qualifier should be avoided; it's not an online BACKUP command.

Newer VAX systems are available, and (if you have the source code, or can successfully translate the code) newer Alpha systems are available for US$1000 and less. Emulation is available for VAX systems, as well. Emulation and newer VAX systems are usually a straight sequence, and an Alpha port usually isn't that difficult; it's often little more than a compile, link and go -- if you have the code.

Stephen Hoffman
HoffmanLabs LLC

[Chinraj Rajasekaran]

All,

I initilized new disk and created standalone backup kit on new 4gb disk and I also tried booting other running 4 GB sysdisks .....NOTHING works.

It is very clear that the new motherboard is not capable of booting 4gb disks. It boots only 1 gb and 500 MB disks.

I will ask the hardware vendor to see if they can find any other motherboard with higher version of firmware that can boot 4 gb disks like the old one.

Thanks
Raj

[Karl Rohwedder]

I suppose, there are no motherboards with newer firmware for Microvax 3100/10 or /20.
Perhaps you can get a used Microvax 3100 model 80/90 or such, which is also a lot faster than your model.

regards Kalle

[Chinraj Rajasekaran]

Kalle,

I have spare one 3100/90 model but VMS 5.5.2 can not boot from 90 and it crashes just after the VMS version?

If i boot on model 90 on single user mode i get sysboot> and then if i say "continue" it crashes with same message.

I checked, the minimum supported VMS version for model 90 is OpenVMS 5.5.2-H4.

Is there anyway to run VMS 5.5.2 on model 90?

Thanks
Raj

[Hoff]

You will need a smaller disk for the MicroVAX 3100 model 20, or you need to ensure all of the console-related structures on the disk are located at block addresses entirely below the six-byte SCSI command address wrap; below the 1.073 GB value. (VMB, SYSBOOT and the page and dump files are probably key here.)

The VAXstation 4000 model 90 -- the base box and integrated hardware -- can bootstrap OpenVMS VAX V5.5-2. V5.5-2HW is an early version of the V5.5-2 release; it's older than V5.5-2.

Here are the other boxes:
VAXstation 4000, Model 90
v5.5-2HW or later

VAXstation 4000, Model 90A
v5.5-2 or later

VAXstation 4000, Model 95
v5.5-2H4, or v6.1 or later

VAXstation 4000, Model 96
v5.5-2H4, or v6.1 or later

You cannot boot the VAXstation 4000 model 95 or model 95 below V5.5-2H4; V5.5-2H4 added support for these boxes, and various others. It is otherwise identical to V5.5-2.

There can be various hardware configured in any of the VAXstation 4000 series -- boxes configured with disks larger than of 8.38 GB, for instance -- that can and will require later OpenVMS VAX releases.

If you're seriously stuck here, call in assistance from a services organization.

[Stephen Eickhoff_1]

Hoff:

He didn't have "/ignore=nobackup" in his command, he had "/ignore=interlock". For which qualifier was your recommendation intended?

[Hoff]

I was aiming at my usual warning around the hazards inherent in the use of BACKUP /IGNORE=INTERLOCK, and erroneously typed NOBACKUP in my response.