Device offline during startup

[Peter Zeiszler]

Hi,

I have a question that just needs a little feedback. Problem occurred when I as rebooting a system I had just performed patches on. Not sure if this error was there before or not. Its not a box I can reboot alot but have to take advantage of it during next reboot.

OpenVMS 7.3-2. Alpha.
-----
%CNXMAN, Now a VMScluster member -- system XXXXX
%MSCPLOAD-I-CONFIGSCAN, enabled automatic disk serving
%STDRV-I-STARTUP, OpenVMS startup begun at 18-JUN-2008 12:42:21.30
%MSCPLOAD-I-CONFIGSCAN, enabled automatic disk serving
%SYSTEM-F-DEVOFFLINE, device is not in configuration or not available
-------------

Right after the devoffline it runs the sypagswp and mounts the swap disks. I checked sysman and have a few files running there and those do get started - processes show up. Not sure if the sysman startup starts before sys$startup:systartup_VMS.com completes or not.
There is no satellite_page.com file to run.
I don't see any devices in the sylogicals.

So really the questions are:
After MSCP load is enabled what is the boot sequence from there to sypagswp?

Does sysman start file run after the sys$startup:systartup_vms.com completes or prior? Does it start prior to sypagswp?

I looked at the startup files. Didn't find anything referencing devices.

I know I could reboot with -fl 0,20000 to get tons more data. Might get to do that during the next reboot window.

Any suggestions?

[Hoff]

Post attempt two. ITRC cratered. Again. Verified no post was visible, but with this ITRC software, who knows?

The usual recommendation for this has been to insert a delay, and retry the MOUNT in a loop. Try some number of times at five or ten second intervals, until you succeed or until you reach a threshold and punt out of the loop with some local diagnostics.

IIRC, this was once documented as a requirement.

There were and likely still are cases where MSCP servers and such required a fair amount of time to instantiate the devices, whether after a cold start or some other context.

I long ago bracketed the SYCONFIG.COM and SYPAGSWPFILES.COM files I manage with WRITE statements to indicate the relative context of the startup.

As for the approach I'd use? Enable startup verification. And expect you can have some fun finding this for some classes of timing problems, and particularly if it's not reproducible. Boot with STARTUP_P2 set to "C" or "V" or "PV" or such. Check the system parameter help text in SYSMAN or SYSGEN for details. And consider instrumenting your own startup-related files with some "WRITE" commands at entry and at departure.

[Volker Halle]

Peter,

booting with -fl 0,20000 won't most likely help here, as the error happens after SYS$SYSTEM:STARTUP.COM has already been started. Running with verify turned on (see Steves reply) would be the best way to go. Capture the data in SYS$SYSTEM:STARTUP.LOG.

SYPAGSWPFILES.COM is called from VMS$DEVICE_STARTUP.COM. It also starts the CONFIGURE process earlier.

The DEVOFFLINE message is most likley NOT from a MOUNT command, as that would also return some MOUNT-... message.

Volker.

[Jan van den Ende]

Peter,

we HAVE the advice of Hoff about that retry loop in place, max 6 retries with 5 sec interval.
Just for our own peace of mind, whenever it does NOT suceed the first time, we output a message to a boot log file.
About 50% of times, 1st pass succeeds, -> no message.
Surprisingly, we _DID_ get to 4 retries once!
So, yes, DO put a retry loop in your boot procedure --WITH loop counter & max retries--

Success.

Proost.

Have one on me.

jpe

[Peter Zeiszler]

We have the loop thing also - we check if the device exists prior to attempting to mount it.

This doesn't show up like thats the error unless for some reason its returning an error when checking if the disks exist first.

I am updating the sypagswp to include "start" and "end" outputs so I can see it. probably with time stamps.

I will look into the vms$device file - see if thats doing something. I also thought it might be part of the autoconfigure all but have not had that return an error before since thats normally a discovery as part of the boot.

[Volker Halle · Accepted solution]

Peter,

the 2nd %MSCPLOAD-I-CONFIGSCAN message is being issued immediately after the CONFIGURE process has been started by

@sys$startup:vms$initial-050_configure

The invocation of SYLOGICALS.COM would have happened next, following by

@SATELLITE_PAGE.COM
and
@SYPAGSWPFILES.COM

SYSTARTUP_VMS.COM is invoked a lot 'later'.

Volker.

[labadie_1]

For an example of how to loop to mount disks, wait and retry, have a look at
sys$examples:mscpmount.com

[Volker Halle]

Peter,

just saw the same error when rebooting a V7.3-2 production system today. The %SYSTEM-F-DEVOFFLINE showed up in SYS$SYSTEM:STARTUP.LOG (STARTUP_P2="D" was set) and was followed by some other (un-related) message from SYLOGICALS.COM.

So this puts the error BEFORE the end of SYLOGICALS.COM !

I did not get a chance for further analysis. The system functioned normally despite the error message.

Volker.

[Peter Zeiszler]

Volker - Did you have something indicating the start of the sylogicals? I haven't gotten another reboot on the system (doubt I will for awhile) but I have added outputs on my sylogicals to show when it starts and stops.

I had same thing of system coming up cleanly with everything starting fine. Just kind of an odd message to show up without anything really showing as wrong.

[Volker Halle]

Peter,

there was no explicit output at the start of SYLOGICALS.COM. There only was a %SYLOGICALS-I-... type of message, this is what I typically use as informational output in the startup procedures.

All I'm trying to say is: the DEVOFFLINE message happened before the end of SYLOGICALS.COM and it does not seem to be a unique incident at your site.

The %MSCPLOAD message is coming from CONFIGURE (module [CLUSTER]STACONFIG_MSCP) and it's being explicitly sent to _OPA0:

Volker.