AXPVMS$PCSI_INSTALL_MIN.COM not working on V8.3 Alpha

[Volker Halle]

Bard,

just as a reference from a successful minsys boot, here is the Boot QIO log from my boot attempt. This should help you figure out, where your boot goes wrong.

...
%APB-I-BOOTDRIV, Selecting boot driver
%APB-I-BOOTFILE, Selecting boot file
%APB-I-BOOTVOL, Mounting boot volume
Boot QIO: VA = 200AE000 LEN = 00000200 LBN = 00000001 FUNC = 00000021
Boot QIO: VA = 200AE200 LEN = 00000200 LBN = 003FF02D FUNC = 00000021
Boot QIO: VA = 2009DBD8 LEN = 00000200 LBN = 003FF030 FUNC = 00000021
Boot QIO: VA = 200B0000 LEN = 00000200 LBN = 003FEF50 FUNC = 00000021
%APB-I-SYSROOT, System root is [SYSE.]
Boot QIO: VA = 200F0000 LEN = 00000200 LBN = 003FF037 FUNC = 00000021
Boot QIO: VA = 200F2000 LEN = 00000200 LBN = 003FF037 FUNC = 00000021
Boot QIO: VA = 200B0200 LEN = 00000200 LBN = 00000020 FUNC = 00000021
Boot QIO: VA = 200F2000 LEN = 00000200 LBN = 00000ABF FUNC = 00000021
Boot QIO: VA = 200B0400 LEN = 00000200 LBN = 00052030 FUNC = 00000021
Boot QIO: VA = 200F2000 LEN = 00000200 LBN = 003FF038 FUNC = 00000021
Boot QIO: VA = 200B0600 LEN = 00000400 LBN = 00000030 FUNC = 00000021
Boot QIO: VA = 200F2000 LEN = 00000200 LBN = 00000799 FUNC = 00000021
Boot QIO: VA = 200B0A00 LEN = 00001E00 LBN = 0001AA80 FUNC = 00000021
Boot QIO: VA = 200F2000 LEN = 00000200 LBN = 00000855 FUNC = 00000021
%APB-I-LOADFILE, Loading [SYSE.SYSCOMMON.SYSEXE]SYSBOOT.EXE;1
Boot QIO: VA = 200F4000 LEN = 00000200 LBN = 000254A0 FUNC = 00000021
Boot QIO: VA = 00000000 LEN = 00093200 LBN = 000254A2 FUNC = 00000021
%APB-I-SECBOOT, Transferring to secondary bootstrap
%SYSBOOT-I-WLCM, Welcome to Alpha Secondary Bootstrap
...

Volker.

[EdgarZamora]

Brad,

regarding your question about ODS-2/ODS-5, I use minimum system disks a lot. I've created on both ODS-2 and ODS-5 and they both work fine, so I don't think your problem is with that. Have you tried reinitializing your disk and running the axpvms$pcsi_install_min.com on it again?

[Bradford Hamilton]

Hi Edgar,

I've been attempting to resolve this problem since November of 2006; I've initialized and re-initialized *many* disks of differing sizes in that period of time.

I've considered that the problem might be using disks that are "too large" (72GB) or ones that might not have the "correct" firmware. I've tried using brand-new disks, or disks that have had the system software on them (and worked fine).

I've used this utility on V7.* for a number of years, and a number of different disks, and never had a problem until V8.3. The utility has been changed as of June/July 2006, and contains references in it to EFI$* files (which are Integrity-only) which never appeared in the utility in V7.*.

For all these reasons, (and because I don't have extensive facilities to test all my suspicions) I've come to the conclusion that there is a problem with this utility as of this version, (Alpha V8.3) and am asking others for help.

[Volker Halle]

Bard,

the key seems to be in LBN 0053840 (is this the file header for minsys:[syse]sysexe.dir ?) In my working case, APB continues to read more blocks, in your case it fails immediately afterwards.

Can you describe in more detail, what the various LBNs point to on your minsys disk ?

Note that you should be able to examine the data of the last block read from disk after the system halts:

>>> EXA -v -l -n 20 200E4400

Volker.

[Rolf Modin]

Hello Brad

I have not worked with OpenVMS professionally this millenium.

Once upon a time we used a standard script called something like:

stbkitbuild.com (stand alone backup kit build)

Is that replaced by the one You are trying to use, or might it work better?

Regards
Rolf Modin

[Bradford Hamilton]

Hi Volker,

I'll give the EXAmine a try later on tonight, probably.

I was using DFU to look at the LBN's referenced in the verbose console output; every one of them (except for the two mentioned earlier) were referencing MINSYS:[000000]INDEXF.SYS.

The DFU output is screen-oriented, and tedious to cut-'n'-paste; if I have some more time today or tonight, I can show the reference for each LBN listed on the console output, attached as another text file.

[Bradford Hamilton]

Hi Rolf,

I think you are referring to STABACKIT, which is (unless I am greatly mistaken) VAX-only. I'm working on an Alpha machine, which requires a different method to boot standalone backup.

Thanks,
Brad

[Volker Halle]

Brad,

I've lokked at the LBNs in my working examples and here they are in the order read by APB

00000001 - home block
003FF02D - INDEXF.SYS hdr
003FF030 - 000000.DIR hdr
003FEF50 - 000000.DIR contents

003FF037 - SYSE.DIR hdr
003FF037 - SYSE.DIR hdr
00000020 - SYSE.DIR contents
00000ABF - [SYSE]SYSEXE.DIR hdr
00052030 - [SYSE]SYSEXE.DIR contents
003FF038 - [000000]VMS$COMMON.DIR hdr
00000030 - VMS$COMMON.DIR contents
...

The same order should apply in your failing case:

00000001 - home block
008829F0 - INDEXF.SYS hdr
008829F3 - 000000.DIR hdr
008799E0 - 000000.DIR contents
%APB-I-SYSROOT, System root is [SYSE.]
008829FA - SYSE.DIR hdr
008829FA - SYSE.DIR hdr
00000020 - SYSE.DIR contents
008830B2 - [SYSE]SYSEXE.DIR header
00053840 - [SYSE]SYSEXE.DIR contents
%APB-I-FILENOTLOC, Unable to locate SYSBOOT.EXE

Your boot stops after accessing the contents of [SYSE]SYSEXE.DIR, which should just show 3 files. It should then continue and look for VMS$COMMON.DIR.

Can you verify with DFU or DUMP, that the LBNs I've mapped contain the expected data ?

Volker.

[Bradford Hamilton]

Hi Volker,

008829FA=8923642; DFU shows:

x%DFU-I-SEARCH, Start search on MINSYS: ($1$DKA600:) x
x x
x$1$DKA600:[000000]INDEXF.SYS;1 6154/93024 x
x x
x%DFU-I-EOF, End of file INDEXF.SYS, Primary headers : 1769 x
x x
x%DFU-S-FND , Files found : 1, Size : 6154/93024 x

(not repeating LBN for sake of space...)

LBN 00000020=00000032; DFU shows:

%DFU-I-SEARCH, Start search on MINSYS: ($1$DKA600:) x
x x
x$1$DKA600:[000000]SYSE.DIR;1 1/16 x
x x
x%DFU-I-EOF, End of file INDEXF.SYS, Primary headers : 1769 x
x x
x%DFU-S-FND , Files found : 1, Size : 1/16

LBN 008830B2=8925362; DFU shows:

x%DFU-I-SEARCH, Start search on MINSYS: ($1$DKA600:) x
x x
x$1$DKA600:[000000]INDEXF.SYS;1 6154/93024 x
x x
x%DFU-I-EOF, End of file INDEXF.SYS, Primary headers : 1769 x
x

LBN 00053840=342080; DFU shows:

x%DFU-I-SEARCH, Start search on MINSYS: ($1$DKA600:) x
x x
x$1$DKA600:[SYSE]SYSEXE.DIR;1 1/16 x
x x
x%DFU-I-EOF, End of file INDEXF.SYS, Primary headers : 1769 x
x x
x%DFU-S-FND , Files found : 1, Size : 1/16 x

...and there the LBN's end.

(I hope this post is read-able; it looks ugly in the text box!)

[EdgarZamora]

Hi Brad. I've used this procedure for years too and I love it. I am currently using it on ALPHA VMS 8.3 and on small SCSI disks and large (320GB) SAN disks, ODS-2/ODS-5, with no problems.

You mentioned that you have initialized many disks, etc. Are they all from the same "source"? Maybe your "source" (the system disk you are running the procedure from) has some corruption.