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

[Bradford Hamilton]

Hi Folks,

I have been using this utility to create SA backup disks since V7.2-1. The utility has been working fine, up through V7.3-2, but I've not been able to create a successful SA boot disk under V8.3 on Alpha.

The .COM file runs fine with no errors, but when I boot from the disk, I get the initial boot messages which indicate that the boot file was found, and then an informational message indicating that the system cannot boot from this file.

Has anyone else run into this problem, and perhaps has found a work-around?

Thanks,
Brad Hamilton

[John Gillings · Accepted solution]

Brad,

Please post the exact and complete error message.

Can you boot from the V8.3 distribution CD?

[Bradford Hamilton]

Hi John,

Thanks for the quick reply.

I can use the minimum environment from the CD, if absolutely necessary, but I find it faster and easier to boot from a minimum environment on disk.

Following is the boot sequence, including messages:

>>>b dka600 -fl e,0

System will be reset prior to boot.


ff.fe.fd.fc.fb.fa.f9.f8.f7.f6.f5.CPU 0 speed is 2.31 ns (433MHz)

ef.ee.ed.ec.eb.f4.ea.e9.e8.e7.e6.
ewa0: link up : Negotiated 100BaseTX: full duplex
e5.e4.
Digital Personal WorkStation 433au
Console V7.2-1 Mar 6 2000 14:47:02

CPU 0 booting

(boot dka600.6.0.1008.0 -flags e,0)
block 0 of dka600.6.0.1008.0 is a valid boot block
reading 1226 blocks from dka600.6.0.1008.0
bootstrap code read in
base = 1d8000, image_start = 0, image_bytes = 99400
initializing HWRPB at 2000
initializing page table at 1ca000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code
%APB-I-FILENOTLOC, Unable to locate SYSBOOT.EXE
%APB-I-LOADFAIL, Failed to load secondary bootstrap, status = 00000910

halted CPU 0

halt code = 5
HALT instruction executed
PC = 20004048
warning -- HWRPB is invalid.
>>>

Thanks,
Brad

[Hoff]

The %x910 is the "file not found" error code.

Does the disk have a sysboot image in syse? (APB is common across all roots)

Have you tried the sys0 root boot? (or checked to see if that's where everything ended up?)

If you're building the bootable root into syse, the AXPVMS$PCSI_INSTALL_MIN.COM tool looks to be busted.

[Volker Halle]

Brad,

you seem to have reported this problem in c.o.v already on 13-NOV-2006.

I have just run this procedure on your CHARON-AXP/4000 system and successfully booted with the equivalent of

>>> B -fl E,30000 DKB200
...
%APB-I-LOADFILE, Loading [SYSE.SYSCOMMON.SYSEXE]SYSBOOT.EXE;1
...

This OpenVMS Alpha V8.3 system is fully patched (all patches until 27-JUL-2007), although I can't see any problem description matching this problem.

Try booting with B -fl E,30000 and capture the output. Then append it as an attached .TXT file to your next reply.

Volker.

[Bradford Hamilton]

Reply to John's question -
Directory MINSYS:[SYSE.syscommon.SYSEXE]

APB_BOOTP.EXE;1 996/1008 29-JUN-2006 18:18:45.38 29-JUN-2006 18:18
:45.54
SYS$SETBOOT.EXE;1 93/96 29-JUN-2006 18:18:45.48 29-JUN-2006 18:18
:45.52
SYSBOOT.EXE;1 1179/1184 21-MAR-2007 13:47:04.20 8-AUG-2007 21:09
:32.10
WRITEBOOT.EXE;1 20/32 29-JUN-2006 18:19:03.54 29-JUN-2006 18:19
:03.55

Total of 4 files, 2288/2320 blocks.

Volker, I'll reply to your request later today. Just for the record, HW is a DPW 433au.
Yes, SYSE seems to have the proper file:

[Bradford Hamilton]

Hi,

(to Hoff - sorry for mis-identifying you as John!)

Volker - I'm attaching the .txt file for the console boot session, as requested.

Thanks to all for your suggestions so far!

[Hoff]

Load up DFU and issue SEARCH/LBN=n commands for the specified blocks. LBN 00000001 is the primary home block (VBN 2 of INDEXF.SYS), check 008829F0 and subsequent. You should see a sequence of directory block reads leading up to where SYSBOOT should be. Also issue a DUMP/HEADER/BLOCK=END=0 on the SYSBOOT image, to ensure it's actually present, and a DIRECTORY/FULL to ensure it is contiguous.

'John'

--

http://en.wikipedia.org/wiki/Files-11

[Bradford Hamilton]

Hi Hoff,

DFU may take a bit of time, (I'm on vacation this week, but I have "real" errands to do!) however...

Identification area
File name type: ODS-2

The above bit is cut from the DUMP/HEADER (etc.) command listed previously. Does this mean that the disk *must* be ODS-2, rather than ODS-5? I figured that there were no restrictions, since a system disk can be ODS-5.

A dir/full lists the file as being "Contiguous best try".

[Bradford Hamilton]

Hi Folks,

I was able to grab and install DFU off of the Freeware disks.

All the LBN's (when translated) point to INDEXF.SYS, except for LBN 20 (32) which points to minsys:[000000]syse.dir, and LBN 0053840 (342080), which points to minsys:[syse]sysexe.dir.

Since the file SYSBOOT.EXE lives in minsys:[syse.syscommon.sysexe], there seems to be a disconnect somewhere.

The only files that live in minsys:[syse.sysexe are:

dir MINSYS:[SYSE.SYSEXE]

Directory MINSYS:[SYSE.SYSEXE]

ALPHAVMSSYS.PAR;1 22/32 8-AUG-2007 21:09:47.37 8-AUG-2007 21:09
:47.43
PAGEFILE.SYS;1 200/208 8-AUG-2007 21:09:48.51 8-AUG-2007 21:09
:48.65
SYS$ERRLOG.DMP;1 8202/8208 8-AUG-2007 21:09:33.96 8-AUG-2007 21:09
:34.12

[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.

[Volker Halle]

Brad,

so my analysis was correct. LBN 00053840 is the contents of [SYSE]SYSEXE.DIR - SYSBOOT.EXE will not be there.

APB should continue to look at the contents of SYSE.DIR (read earlier and to be found at VA 200E4200) and look for the FID of [SYSE]SYSCOMMON.DIR - then read the file header of that file and it's contents and look for SYSEXE.DIR ...

You can use DUMP/BL=(COUNT=1,START=%X)/FILE minsys: to dump the contents of those LBNs. /FILE will format them as a file header, if they are a file header. Use DUMP/DIR to dump the LBNs which are directories.

Volker.

[Bradford Hamilton]

OK Folks,

I re-init'ed the disk as an ODS-2 disk, re-booted, and...

the SA procedure boots fine.

I went to ODS-5 on all my disks (including system disk) in the V7.3-2 time-frame. I just naturally assumed (ha!) that I could create an SA boot disk as ODS-5, as well.

Bug or feature? :-)

[EdgarZamora]

Brad,

I'm glad you solved your problem. I have an ODS-5 disk though (initialized under 8.3) that works. I just booted it this morning to test again.

[Bradford Hamilton]

Hi Edgar,

Well, I "solved my problem", but my implicit hypothesis (that the problem arose from ODS-5 vs. ODS-2) has apparently been disproven, based on your experience.

While I'm satisfied that I now have a method for ensuring a "usable" SA environment, I'm troubled by the (apparent) lack of a reproducible "cause"; and I'm also unsure that an ODS-2 environment can properly back up (and restore?) my ODS-5 disks. Perhaps my fears are unfounded, but it would be nice to have more "certainty" around this problem.

[Volker Halle]

Brad,

as a simple test for reproducability of this problem, please just INIT/STRUC=5 the disk and try again...

Volker.