Reboot from dka0: to ewa0:

[Marko Klingner]

I have a running VMS-Machine (AlphaStation200). The system is startet with dka0 (OpenVMS).
Now, i will reboot the machine into the ewa0-device (diskless NetBSD) from OpenVMS. But i dont now how.
At the moment i shutdown the system manually and on the SRM-console i enter the comands:
> boot dka0 (for OpenVMS)
or
> boot ewa0 (for diskless NetBSD)
How can i reboot from dka0: to ewa0: ?

[Karl Rohwedder]

As far as I know, there is no possibility to write console variables from VMS. If it would by possible, you could write the variable BOOTDEF_DEV to setup the next boot.

regards Kalle

[Volker Halle]

Marko,

as Kalle said, there is no 'supported' way of rebooting from a device other than BOOT_DEV, i.e. the last device the system has booted from (typically same as BOOTDEF_DEV).

I've found an unsupported program called DEFAULT_BOOT.C at:

http://wwwvms.mppmu.mpg.de/vmssig/src/C/default_boot.c

This example program seems to come from Steve H. from OpenVMS engineering.

With appropriate modifications, this UNSUPPORTED program might do want you want to do.

Volker.

[Kris Clippeleyr]

Marko, and Volker,

A word of caution regarding the UNSUPPORTED stuff by Steven H.
It has crashed a dual CPU DS25.
I'm still investigating why. On a single CPU system it seems to work.

Regards,
Kris (aka Qkcl)

[Joseph Huber_1]

Kris, I have put Your warnings in default_boot.c for people downloading from my site.
Joseph

[Volker Halle]

Kris,

feel free to mail me the CLUE file from the crash.

According to the Alpha ARM, some console callback routines must only be invoked from the primary CPU, but GET_ENV and SET_ENV do not seem to be affected by this restriction.

Volker.

[Kris Clippeleyr]

To Volker:


feel free to mail me the CLUE file from the crash.

Unfortunately, shortly after the crash we experienced another one (in DECnet) that has overwritten the one caused by default_boot.


According to the Alpha ARM, some console callback routines must only be invoked from the primary CPU, but GET_ENV and SET_ENV do not seem to be affected by this restriction.


I'm currently adapting the program so it can run on the primary CPU only. Still have to find a window for testing it (do not want to crash that system again in the middle of the day (development system)).

Regards,
Kris (aka Qkcl)

[Volker Halle]

Kris,

CLUE files won't be overwritten, you'll find the most recent of them in CLUE$COLLECT:CLUE$*.LIS. As the CLUE file is automatically created from the dump during startup, the crash information will only be lost, if there is a crash during startup before the CLUE$SDA detached process created by @SYS$STARTUP:CLUE$STARTUP has completed.

Volker.

[Kris Clippeleyr]

To Volker:


CLUE files won't be overwritten, you'll find the most recent of them in CLUE$COLLECT:CLUE$*.LIS

Somehow that particular CLUE file got lost. Don't know why yet. So sorry.

Kris (aka Qkcl)

[Lachnitt_1]

Hi out there,

I'm thinking about a totally other way:

If the console is plugged into a Terminalserverport, you can use Kermit or a console manager (like PCM) to give the instructions!

Like:
SHUTDOWN
(Wait until "shutdown completed")
CTRL/P (If necessary)
BOOT EWA0:

Hope that helps!
Bye Kuddel