OpenVMS 7.3-2 boot problem after Autogen

[Paul Janssen]

I have a DS10 with 7.3-2.
I installed the OS and everyting works fine.
I installed patch PCSI-V0300 and rebooted well.
Then I tried to install UPDATE_V1300. It needed more global sections (I needed 384 but only had 370). So I let autogen calculate (savparams to genparams) the values and the agen$params.report did not show any problems.
I ran autogen from savparams to reboot and could not boot as a result of this.
The error message just comes after %pka0...:

Error opening primary input file sys$input.
File specification syntax error.

I cannot boot in an emergency (with minimum startup, with default system parameters, without startup and login procedures) so it must be earlier on. Startup.com looks well to me, but it does not show the text: "The OpenVMS system is now executing the system startup procedure".

Anybody any ideas?
An inconsistency between sysboot, sysinit?
An hardware problem?
A timing problem? (it takes almost 2 minutes to pass byond the %pka0 line when booting from CD, but this may be normal).

Thanks

[Karl Rohwedder]

Did you mess with the startup file?

Boot conversational (b -fl 0,1 dk...) and check with

SYSBOOT> SHOW /STARTUP
Startup command file = SYS$SYSTEM:STARTUP.COM

Can be set with
SET /STARTUP=SYS$SYSTEM:STARTUP.COM

regards Kalle

[Paul Janssen]

I did not mess up with any file, including the startup.com. I did not alter nor moved any of these files.

The show /startup nicely shows:
startup command file = SYS$SYSTEM:STARTUP.COM.

I assume that when the file is not there it would have shown me:

Error opening primary input file SYS$INPUT
File not found.

Which is not the case here.

[Robert Gezelter]

Paul,

This may be brute force, but have you considered doing a SET /STARTUP=OPA: and then doing a SET VERIFY before invoking SYS$SYSTEM:STARTUP.COM?

It does produce voluminous output, but it does show you the context of the actual error, which can be helpful.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

Was that really the string
SYS$SYSTEM:STARTUP.COM.
or was it actually
SYS$SYSTEM:STARTUP.COM
not sure if that trailing dot was intended or if it would derail the primitive file system, but it might...

[DECxchange]

Hello,
Did you check your console parameters? Have any of those changed? Also, do you need to upgrade your firmware version to handle the patch? Since you're already at 7.3-2, have you considered just going to 8.3? My experience is that 8.3 is a much more stable version. You will need to upgrade your firmware.

Also, did you check your PK* parameters at the console? Can you provide some more of the output from the bootup?

Do you have the old version of the OS before the patch? Does that still work? If so, then there might be an issue with the patch vs. the firmware version, just guessing.

[Paul Janssen]

I did some more investigations.
First of all I put a write sys$output "starting startup.com" as the first line in startup.com. So I would know by seeing this line it got that far. I could still add a set verify if needed.
After reboot I never saw the message, so the error must have been earlier in the boot process. I found 57 files with an _old extension, including sysboot.exe and sysinit.exe.
I restored them adn could reboot normally.
I got the following error %SYSBOOT-E-NOPARAMS, no such paramter SHADOW-HBMM-RTC.
I decided to restore my image backup from before the update.
I bought this system to be a file backup, so I have no intention to install the Update13 again (13=bad number?).
Going to 8.3 is not an option as I bought the licenses for 7.3 with this system.
Conclusion: engineering could have done a better job by setting or warning that a fresh installation only has 370 gblsections where it needs 384. Secondly it should restore all _old files, not parially, leaving you with an unbootable system due to an inconsistency between sysboot and sysinit.

[Robert Gezelter]

Paul,

After many years of discovering that I had to re-do GBLSECTIONS and GBLPAGES after installations and updates, I cannot but wholeheartedly agree that there is always room for improvement on that point.

However, I do not think that the need to add to those parameters is what actually caused the problem. With all due respect, I am not sure that I agree with the diagnosis of ".. incompatible SYSBOOT and SYSINIT ...".

Was an image BACKUP taken of the system BEFORE the restore so that detailed examination is possible?

- Bob Gezelter, http://www.rlgsc.com

[DECxchange]

>I did some more investigations.
>First of all I put a write >sys$output "starting startup.com" as the >first line in startup.com. So I would know >by seeing this line it got that far.

I would agree that the %PKA0 error you're seeing is very early on in the startup process. This could be a controller or a console parameter setup problem, which could manifest before startup.com runs.

>Going to 8.3 is not an option as I bought >the licenses for 7.3 with this system.

Sorry, i did not mean that you must update to 8.3. In fact, I support a large Galaxy cluster and they are running 7.3 and everything works fine. I just thought that since you are going to 7.3-2 with a patch, it is generally better to go the next step higher than to deal with patches.

>Conclusion: engineering could have done a >better job by setting or warning that a >fresh installation only has 370 >gblsections where it needs 384.

Perhaps. But usually they have info on what GBL... parameter values need to be set in either the release notes or the Installation Guide for the repsective VMS OS version.

Also, did you add the following statement to sys$system:modparams.dat:

add_gblsections=384

Then run autogen?

You might also need to increase PQL parameters and SYSTEM account parameters in AUTHORIZE.

> Secondly it should restore all _old >files, not parially, leaving you with an >unbootable system due to an inconsistency >between sysboot and sysinit.

I'm not sure the _old files you are seeing are a VMS OS issue. It might be something that a previous System Manager did for some reason.

>A timing problem? (it takes almost 2 >minutes to pass byond the %pka0 line when >booting from CD, but this may be normal).

Did you check at the console prompt:

>>> sho pka*
You might want to consider whether the value for PKA0_FAST (or whatever is the correct syntax ) to be either 1 or 0, depending on your situation. You might want to experiment with this value. I've run into problems with this being set to 0 when it should be 1, or vice versa, depending on the disc drive technology and controller you are using.

Also, at the console:

>>> show * |more

Make sure what these are set to make sense, like OS_TYPE = OpenVMS

It's possible this used to be a Unix box and the console parameters were set for Unix. This will not work properly for VMS, trust me.

Anyway, I hope that helps. I may not have explained it right or understand your situtation completely, but these are some areas where I've personally run into strange problems and they were fixed by setting things to the correct values.

[Paul Janssen]

The lack of sufficient system headroom made the update stop prematurely:

Portion done: 0%...10%...20%...30%...40%...50%...60%...70%...80%...90%
%PCSI-I-PRCOUTPUT, output from subprocess follows ...
%INSTALL-E-FAIL, failed to REPLACE entry for DISK$ALPHASYS:G>SYSMSG.EXE
-SYSTEM-F-SECTBLFUL, process or global section table is full

%PCSI-E-INSTALLERR, error executing DCL INSTALL command
%PCSI-E-OPFAILED, operation failed
Terminating is strongly recommended. Do you want to terminate? [YES] YES
%PCSI-E-CANCEL_WIP, termination resulted in an incomplete modification to the sy
stem
%PCSI-E-S_OPCAN, operation cancelled by request

Recovery pass starting ...

%PCSI-I-PRCOUTPUT, output from subprocess follows ...
%INSTALL-E-FAIL, failed to REPLACE entry for DISK$ALPHASYS:E>COPY.EXE
-SYSTEM-F-SECTBLFUL, process or global section table is full
%PCSI-E-S_OPFAIL, operation failed
%PCSIUI-E-ABORT, operation terminated due to an unrecoverable error condition

In the patch details there is no mention of any of these requirements.

And I have no image backup before the restore. My reaction is mostly to make image backups of working systems. But I have a listing of some the files that were on the sys disk before the restore:

$$$ dir start* /date

Directory DKA0:[SYS0.SYSCOMMON.SYSEXE]

STARTUP.COM;1 1-OCT-2003 20:42:52.12

Total of 1 file.

$$$ dir ap* /date

Directory DKA0:[SYS0.SYSCOMMON.SYSEXE]

APB.EXE;1 1-OCT-2003 21:18:59.32
APB_BOOTP.EXE;1 1-OCT-2003 21:19:00.37

Total of 2 files.

$$$ dir sys* /date

Directory DKA0:[SYS0.SYSCOMMON.SYSEXE]

SYS$BASE_IMAGE.MAP;1
1-OCT-2003 21:17:29.12
SYS$CONFIG.DAT;1 12-APR-2004 14:37:56.56
SYS$CONFIG.DAT_OLD;1
27-AUG-2003 14:31:26.47
SYS$DAYLIGHT_SAVING.EXE;1
5-JAN-2004 20:17:55.66
SYS$DAYLIGHT_SAVING.EXE_OLD;1
1-OCT-2003 21:19:32.99
SYS$NET_SERVICES_SHUTDOWN.COM;1
21-JUL-2003 14:05:09.00
SYS$POWER_MONITOR_0C.EXE;1
1-OCT-2003 21:19:21.87
SYS$QUEUE_MANAGER.QMAN$JOURNAL;1
28-NOV-2007 14:07:28.09
SYS$QUEUE_MANAGER.QMAN$QUEUES;1
28-NOV-2007 12:15:17.51
SYS$READ_TIME_ZONE_RULE.EXE;1
5-JAN-2004 20:18:02.18
SYS$READ_TIME_ZONE_RULE.EXE_OLD;1
1-OCT-2003 21:19:34.36
SYS$SMHANDLER.COM;1
1-OCT-2003 20:43:50.50
SYS$SMHANDLER.EXE;1
10-MAY-2006 10:13:30.33
SYS$SMHANDLER.EXE_OLD;1
1-OCT-2003 21:19:36.62
SYS$SMHANDLER_SLAVE_2308.EXE;1
1-OCT-2003 21:19:11.38
SYS$SMHANDLER_SLAVE_2608.EXE;1
1-OCT-2003 21:19:11.03
SYS$TIMEZONE.DAT;4 28-NOV-2007 14:07:34.38
SYS$TIMEZONE.DAT;3 28-NOV-2007 11:41:00.57
SYS$TIMEZONE.DAT;2 28-NOV-2007 11:37:21.94
SYS$TIMEZONE.DAT;1 28-NOV-2007 10:44:21.21
SYS$TIMEZONE_SRC.DAT;1
28-NOV-2007 10:44:01.03
SYS$USER_CONFIG.DAT;1
28-MAR-1996 15:42:31.67
SYSBOOT.EXE;1 10-AUG-2005 11:30:49.58
SYSBOOT.EXE_OLD;1 1-OCT-2003 21:19:35.86
SYSGEN.EXE;1 20-AUG-2004 17:02:27.79
SYSGEN.EXE_OLD;1 1-OCT-2003 21:19:34.09
SYSINIT.EXE;1 10-OCT-2006 08:48:39.37
SYSINIT.EXE_OLD;1 1-OCT-2003 21:19:26.20
SYSMAN.EXE;1 26-JUN-2005 19:51:34.04
SYSMAN.EXE_OLD;1 1-OCT-2003 21:18:46.70
SYSUAF.DAT;1 28-NOV-2007 10:42:00.66
SYSUAF.TEMPLATE;1 1-OCT-2003 21:24:22.95

On the subject of the PKA0, this was actually not an error, just a message:

© Copyright 1976-2003 Hewlett-Packard Development Company, L.P.


%PKA0, Copyright (c) 1998 IntraServer Technology Inc. PKW V2.1.21 ROM V2.0
%PKA0, SCSI Chip is SYM53C895, Operating mode is LVD Ultra2 SCSI

Installing required known files...

Perhaps an update of any sort is better if one has a running system tuned again after some workload period. But I am unsure of that would set the parameters high enough. The autogen as part of the installation should have taken care of the minimal settings. By examining the agen$params.report I saw that is was raised enough:

GBLSECTIONS parameter information:
Feedback information.
Old value was 370, New value is 460
Current used GBLSECTIONS: 384
Memory resident sections: 0

And yes this was a Unix box before. But I changed all the necessary parameters at the console prompt, including pka0_fast. But I have seen different behaviour with either booting from the CD against booting from the disk attached to the controller. So the 0|1 setting is not absolute as you rightly indicate.