Booting VMS 7.2-1 on AlphaServer DS20

[Gary Hurst]

Hi
My AlphaServer DS20 developed a serious fault and the hp engineer has replaced the system board. That was just the start of my troubles !! It seems all the boot information was lost when the system board was replaced and now I can't start it up.

The DS20 is attached to a SAN with fibre channel via HSG80 controller. Now after much effort I've got it partially booting the operating system but it's seeing a 'different' machine (ie. not the correct node name). Seems that it's booting out of a different root ?? If so, how do I change the root that it boots from ?? I've looked at >>>Bootdef_dev but haven't been able change it. Am I on the right lines ??

Thanks for your help.

G

[Richard Brodie_1]

"It seems all the boot information was lost when the system board was replaced and now I can't start it up."

I would consider it best practice to record things like that before replacing the system board. On the other hand, it's something you ought to have a record as well.

os_flags is what you are looking for.

set os_flags n,x

where n is the root, and x is the boot options (usually 0).

[Ian Miller.]

There is a console variable boot_osflags

See
http://h18002.www1.hp.com/alphaserver/docs/userguide/WebHelp/boot_osflags.htm

[Volker Halle]

Gary,

the console environment variable BOOT_OSFLAGS defines the boot flags.

>>> set boot_osflags 0,0

would be the default value. You should specify the root, from which you want to boot, before the ',', i.e. to boot from SYS1, use

>>> SET BOOT_OSFLAGS 1,0

Use $ SEARCH disk:[SYS*.sysexe]MODPARAMS.DAT SCSNODE to find the root which you want your system to boot.

Volker.

[Richard Brodie_1]

"It seems all the boot information was lost when the system board was replaced and now I can't start it up."

I would consider it best practice to record things like that before replacing the system board. On the other hand, it's something you ought to have a record as well.

os_flags is what you are looking for.

set os_flags n,x

where n is the root, and x is the boot options mask (usually 0).

[Richard Brodie_1]

Doh, managed to post the wrong variable name twice. boot_osflags is the thing.

[Volker Halle]

Gary,

re: documenting the console environment variables

It is a good practise to issue the following commands and capture the output (using a console management application or a terminal emulator program):

>>> SHOW *
>>> SHOW DEV
>>> SHOW CONF

This is especially important if you are going to replace some component and you never know when this is going to happen, so you better do it now ;-)

Volker.

[Gary Hurst]

Thanks for the very helpful replies. I'm very impressed with the response speed.

This Alpha was configured back in 2000 (before my time!) and the documentation is sadly lacking. It boldly stated that the system disk was unit 100 which, it appears, had VMS installed but must have been in another SAN in the distant past. Hence why it was partially booting with a different node name. The SAN has three other mirror sets so I worked my way through each one using wwidmgr and setting the unit number accordingly. Hey presto, it was unit 102 !! It's now up and running.

I've certainly taken on board your tips for recording configuration. This sort of incident just highlights the importance of that.

Thanks once again for all your help.

Gary

[Deb Kenney]

You can always back up your console data to a floppy. See below:
>>> show config >fat:config.lis/dva0:

Good Luck.

Deb