Standalone Backup on another disk

[Dan Mellem]

Hi,

I'm trying to perform a standalone backup of the system disk. I have created a backup set:

@sys$update:stabackkit $1$dia10:

And the kit successfully runs, putting the files in SYS0. When I try to boot the kit, it fails:

b dia10:

?42 NOSUCHFILE, DIA10
?06 HLT INST
        PC = 00000F1D

Bootstrap failure.

However, I can boot the kit from the system disk, with b/e0000000.

What am I missing? Do I need to copy anything else or run WRITEBOOT?

Below are the files that were copied.

Thanks,
-Dan

Directory $1$DIA10:[SYS0]

SYS$LDR.DIR;1       SYSEXE.DIR;1

Total of 2 files.

Directory $1$DIA10:[SYS0.SYS$LDR]

CPULOA.EXE;1        CVDRIVER.EXE;1      CWDRIVER.EXE;1      DBDRIVER.EXE;1
DDDRIVER.EXE;1      DKDRIVER.EXE;1      DLDRIVER.EXE;1      DMDRIVER.EXE;1
DQDRIVER.EXE;1      DRDRIVER.EXE;1      DUDRIVER.EXE;1      DVDRIVER.EXE;1
DYDRIVER.EXE;1      EFDRIVER.EXE;1      EPDRIVER.EXE;1      ERRORLOG.EXE;1
ESDRIVER.EXE;1      ESS$DADDRIVER.EXE;1 ESS$LASTDRIVER.EXE;1
ETDRIVER.EXE;1      EVENT_FLAGS_AND_ASTS.EXE;1              EXCEPTION.EXE;1
EXDRIVER.EXE;1      EXEC_INIT.EXE;1     EZDRIVER.EXE;1      FPEMUL.EXE;1
FXDRIVER.EXE;1      GDDRIVER.EXE;1      IMAGE_MANAGEMENT.EXE;1
IO_ROUTINES.EXE;1   LCDRIVER.EXE;1      LIDRIVER.EXE;1      LOCKING.EXE;1
LOGICAL_NAMES.EXE;1 LPDRIVER.EXE;1      MESSAGE_ROUTINES.EXE;1
MKDRIVER.EXE;1      PADRIVER.EXE;1      PAGE_MANAGEMENT.EXE;1
PBDRIVER.EXE;1      PIDRIVER.EXE;1      PKBDRIVER.EXE;1     PKCDRIVER.EXE;1
PKIDRIVER.EXE;1     PKNDRIVER.EXE;1     PKRDRIVER.EXE;1     PKSDRIVER.EXE;1
PKXDRIVER.EXE;1     PRIMITIVE_IO.EXE;1  PROCESS_MANAGEMENT.EXE;1
PUDRIVER.EXE;1      PWDRIVER.EXE;1      SECURITY.EXE;1      SYS$SCS.EXE;1
SYS.EXE;1           SYSDEVICE.EXE;1     SYSGETSYI.EXE;1     SYSLICENSE.EXE;1
SYSLOA1202.EXE;1    SYSLOA1302.EXE;1    SYSLOA1303.EXE;1    SYSLOA1701.EXE;1
SYSLOA410.EXE;1     SYSLOA41D.EXE;1     SYSLOA41W.EXE;1     SYSLOA420.EXE;1
SYSLOA42D.EXE;1     SYSLOA42S.EXE;1     SYSLOA42W.EXE;1     SYSLOA43.EXE;1
SYSLOA43D.EXE;1     SYSLOA43S.EXE;1     SYSLOA43W.EXE;1     SYSLOA440.EXE;1
SYSLOA46.EXE;1      SYSLOA49.EXE;1      SYSLOA520.EXE;1     SYSLOA60.EXE;1
SYSLOA600.EXE;1     SYSLOA640.EXE;1     SYSLOA64D.EXE;1     SYSLOA650.EXE;1
SYSLOA65D.EXE;1     SYSLOA660.EXE;1     SYSLOA66D.EXE;1     SYSLOA670.EXE;1
SYSLOA67D.EXE;1     SYSLOA690.EXE;1     SYSLOA69D.EXE;1     SYSLOA700.EXE;1
SYSLOA70D.EXE;1     SYSLOA730.EXE;1     SYSLOA750.EXE;1     SYSLOA780.EXE;1
SYSLOA790.EXE;1     SYSLOA8NN.EXE;1     SYSLOA8PS.EXE;1     SYSLOA8SS.EXE;1
SYSLOA9AQ.EXE;1     SYSLOA9CC.EXE;1     SYSLOA9RR.EXE;1     SYSLOAUV1.EXE;1
SYSLOAUV2.EXE;1     SYSLOAWS1.EXE;1     SYSLOAWS2.EXE;1     SYSLOAWSD.EXE;1
SYSTEM_DEBUG.EXE;1  SYSTEM_PRIMITIVES.EXE;1
SYSTEM_PRIMITIVES_MIN.EXE;1             SYSTEM_SYNCHRONIZATION_UNI.EXE;1
TFDRIVER.EXE;1      TMDRIVER.EXE;1      TSDRIVER.EXE;1      TTDRIVER.EXE;1
TUDRIVER.EXE;1      TVDRIVER.EXE;1      VAXEMUL.EXE;1
WORKING_SET_MANAGEMENT.EXE;1            XQDRIVER.EXE;1

Total of 119 files.

Directory $1$DIA10:[SYS0.SYSEXE]

ISL_LVAX_062.SYS;1  ISL_SVAX_062.SYS;1  PAGEFILE1.SYS;1     STANDALON.EXE;1
STANDCONF.EXE;1     SYSBOOT.EXE;3       SYSINIT.EXE;1       VAXVMSSYS.PAR;1
VMB.EXE;1

Total of 9 files.

Grand total of 3 directories, 130 files.

[Bob Blunt]

Dan, you're really OK booting Standalone from the system disk to both save and restore.  Most of the system image gets loaded into memory and the system is very, very minimal.  It shouldn't be a problem even if you're compressing the system disk.  But, to be safe, it certainly can't hurt to boot from an alternate disk.

But your problem seems possible that you may not have a bootblock on $1$DIA10.  Your root is SYS0 on DIA10 where the bootable Standalone on the system disk is SYSE.  None of my VMS systems are booted right now so this is from memory.  I think you'll need to use, again I THINK, WRITEBOOT to write the bootblock on DIA10.  There are examples in some of the command procedures on the system disk and I thought that STABACKIT would have written a bootblock as part of it's procedure.  You might search for "WRITEBOOT" in command procedures on the system disk to find the syntax.  I'm also guessing that you're NOT running a mixed VAX and Alpha cluster with DSSI as your shared interconnect so you don't have any problems trying to write a VAX bootblock from an Alpha, are you?  If so there is a way to get this working but I'll have to research it to refresh those brain cells.

You should also check to make sure that there's a [SYSEXE] directory on DIA10 and that there are files in there, most importantly VMB.EXE.  What type VAX are you booting and have you checked the console setting for BFLG (some really old VAX models may not use BFLG so FYI) to see where that points?  Have you tried to boot using the console command:

b/00000000 dia10

     or

b/r5:0  dia10

?

An even more rudimentary question?  Is this on a "real" VAX or one of the emulated hardware models running virtually?

Sorry for all the questions...

bob

[Richard Brodie_1]

The details of how the primary bootstrap works differ a lot from machine to machine but I would have thought it was a ROM based VMB.EXE, so I would be looking for something odd with SYSBOOT.EXE or its directory path rather than a bootblock.

Have a double check with /FI and or /SIZ to make sure that you haven't got directory entries that point nowhere. See if ANALYZE/DISK shows something odd with the target volume.

[Bob Blunt]

There were only three command procedures on my VAX V7.3 system disk that executed WRITEBOOT, STABACKIT, CONSCOPY and VMSKITBLD.  For what it's worth, WRITEBOOT execution goes like this (for Dan's Standalone disk):

$ run sys$system:writeboot

Target system device (and boot file if not VMB.EXE): $1$DIA10:[SYS0.SYSEXE]VMB.EXE

Enter VBN of boot file code (default is 1) : 1
Enter load address of primary bootstrap in HEX (default is 200): 200

I'll admit that I haven't dug into VAX STABACKIT in many years but do recall that not always does the bootblock get written on an alternate device.  It would also be entertaining to know what type disk is $1$DIA10 (is it an RF disk with a dedicated ISE or is it a SCSI disk behind a HSD) and how is that disk initialized?

Another "just FYI," this is the result I got when I tried to boot my MV3100 "server" from a non-existing root:

>>> b/r5:40000000 dkb0


-DKB0
?42 NOSUCHFILE
?06 HLT INST
    PC = 00000C66

Not exact (this system is SCSI only) but close.  My guess would be a VAX4000-1xx or one of the larger Q-Bus machines and the setting for BFLG may be wrong?  Still waiting for Dan to respond with more details.

bob

[Dan Mellem]

Steven Schweda:
bflag depends on node, but they're what you'd normally expect-
node 1: 0
node 2: 10000000
node 3: 20000000

device is DIA0 for nodes 1 and 2, and DIA0 for node 3 (same disk, but alternate DSSI bus).

The output is pretty much complete. I can't capture the bootup sequence except to printer, so I'm retyping it. The only thing I didn't include was the initial start.

(BOOT/R5:0 DIA10)

  2..
-DISK10$DIA10

Bob Blunt:
Thanks. I was trying to get the kit working on another drive so I'd have a chance to restore it should the SYSTEM disk die. I have an 8mm and 9-track I could use for the kit but they're a bit slow.

The cluster is all VAX 4000-600, so no Alphas (and yes, physical nodes). Sorry, I had that in my original post but it got eaten when I had to log in and I guess I forgot to re-type that. I think VMB.EXE is in the firmware on the 4000, but it is also in SYSEXE.

Richard Brodie_1:
The disk checks out fine. I also tried to build a kit on a different volume (DIA6) just in case the size matters, but I got the same errors. DIA10 is an RF73 but DIA6 is an RF35.

Bob Blunt (#2):
Should I try writeboot? I wasn't sure if that was needed on the 4000, so I didn't want to shotgun it, especially since it's a production system. :)
The disks are RF35 or RF73 and were initialized with /owner=system/extens=100/nohighwater/headers=2500.

Thanks, guys, for your help.

-Dan

[Dan Mellem]

I meant DIB0 for node 3 for the system disk. Also, the tape drives are on node 1, so that's the one I'm trying to run the backup from.

[Dan Mellem]

I just rewrote the standalone backup kit again, exactly the same way I did before, but it's now booting. I'm not sure why that would make a difference but it made something happy.

Thanks again for your help.

-Dan

[Bob Blunt]

Dan, rewriting (or writing) the bootblock for the alternate disk won't hurt anything but it seems like you're past the problem now with the rebuild.  To be 'safe' when you boot your alternate disk S/A use:

b/r5:00000000 DIA10 (or DIB10 depending on what node)

That way you'll know for sure you're selecting the right root for your alternate standalone (unless booting from the system disk, of course).

Wow, REAL RF disks and a three-node DSSI cluster on top of that.   AND a 9-track tape, too!  I bet getting maintenance and spares is quite entertaining.

bob

[Dan Mellem]

Bob, thanks for the tips and confirming writing the bootblock won't hurt.

Yeah, getting spares can be a challenge. I have 3-4 spare RF35s from a drive cabinet we took out when I added the third node and we still maintain a maintenance contract for failures, which there seems to be about once a year (mainly with the 8mm exabyte drive). I've thought about virtualizing since these disks are getting pretty old and this system doesn't have the usage it once had, but it's so reliable (though backups take all night). I was hired just out of high school to help set this system up, and now I'm training our new guys how to manage a system that's now 21 years old. :)

-Dan