GS1280 will not boot with a good scsi, Ovms8.3 boot disk

[Clark Powell]

I sent this image backup of a system disk to our DR site and they couldn't use the restored image to boot the GS1280. (log below) He was able to boot successfully on an ES40 with the same disk. Any ideas? OpenVMS 8.3 with patches shown below log

P00>>>boot dka0
resetting all I/O buses
open fibre pgb0.0.0.102.1
(boot dka0.0.0.2002.0 -flags 0,1)

*** Warning: CDL buffer full - All errors may not have been retrieved from flash
block 0 of dka0.0.0.2002.0 is a valid boot block
reading 1226 blocks from dka0.0.0.2002.0
bootstrap code read in
base = f80000, image_start = 0, image_bytes = 99400(627712)
initializing HWRPB at 10000
GCT base = 556000
initializing page table at f6a000
initializing machine state
setting affinity to the primary CPU
jumping to bootstrap code
SYSBOOT> c

OpenVMS (TM) Alpha Operating System, Version V8.3
© Copyright 1976-2007 Hewlett-Packard Development Company, L.P.


%SMP-I-SECMSG, CPU #01 message: P01>>>START
%SMP-I-CPUTRN, CPU #01 has joined the active set.
%SMP-I-SECMSG, CPU #02 message: P02>>>START
%SMP-I-CPUTRN, CPU #02 has joined the active set.
%SMP-I-SECMSG, CPU #06 message: P06>>>START
%SMP-I-SECMSG, CPU #03 message: P03>>>START
%SMP-I-CPUTRN, CPU #03 has joined the active set.
%SMP-I-SECMSG, CPU #04 message: P04>>>START
%SMP-I-CPUTRN, CPU #04 has joined the active set.
%SMP-I-SECMSG, CPU #07 message: P07>>>START
%SMP-I-SECMSG, CPU #05 message: P05>>>START
%SMP-I-CPUTRN, CPU #05 has joined the active set.
%SMP-I-CPUTRN, CPU #06 has joined the active set.
%SMP-I-CPUTRN, CPU #07 has joined the active set.


STOPS RIGHT ABOVE**************************************
DEC AXPVMS VMS83A_PCSI V3.0 Patch Install Val 17-AUG-2010
DEC AXPVMS VMS83A_PPPD V1.0 Patch Install Val 24-FEB-2009
DEC AXPVMS VMS83A_SHADOWING V2.0 Patch Install Val 24-FEB-2009
DEC AXPVMS VMS83A_SYS V10.0 Patch Install Val 24-FEB-2009
DEC AXPVMS TCPIP V5.6-9ECO3 Full LP Install Val 24-FEB-2009
DEC AXPVMS VMS83A_UPDATE V8.0 Patch Install Val 24-FEB-2009
DEC AXPVMS TCPIP V5.6-9ECO2 Full LP Remove - 24-FEB-2009
HP VMS AVAIL_MAN_COL A3.0-2A Full LP Install (U) 15-JAN-2009
thanks,
Clark Powell

[Hoff · Accepted solution]

What is the configuration of the source system for the backup?

Was the source system insufficiently similar to the failing system?

It's fairly common to see disparate system configurations have difficulty booting from a replicated system disk due to differences triggered by the system parameter settings as compared with the delta in the server hardware.

This is part of the purpose behind the SYSBOOT> USE DEFAULT mechanism; the settings so provided are a bad compromise, but sufficient to get the box booted far enough to run AUTOGEN, and to then get the box booted the rest of the way.

That the box ended up at SYSBOOT is also odd; I'll assume y'all were intending to stop there.

While you're looking at the boot flags for the above, also consider the ubiquitous suggestion for boot-time wonkiness; boot the box with the flags set to 30000 to enable gonzo debugging.

>>> boot -flags 0,30000 ddcu:

The following contains the above flags and boot details, as well as some of the other common boot-time difficulties:

http://labs.hoffmanlabs.com/node/192

[Colin Butcher]

It's probably related to SYSGEN parameters, most likely memory related parameters.

- How identical are the GS1280s (hardware configuration, firmware version, etc.)?

- Are you using partitioning or Galaxy? If so, how identical are the partitions on the source and target GS1280s?

- Do you need to boot with different boot flags for different system roots on the source and target GS1280s?

- What are the differences in system parameters between the target GS1280's current system root and the source GS1280s current system root? I'd expect this to give you a good idea as to what's wrong.

- Will the target GS1280 boot from the correct root on the restored source system disc with a copy of the current system root's parameter file instead of the source system root parameter file? It's a nasty hack, but it should let you get the system up booted MINIMUM so that you can re-run AUTOGEN on the target GS1280.

If none of that flies, then these might help you find out more:

- Will the target GS1280 boot from a local SCSI disc containing a copy of the OpenVMS ALPhas V8.3 distribution media?

- Will the target GS1280 boot from a local SCSI disc containing a minimal bootable system created from the current system disc (which includes its patch state) using the equivalent of @SYS$UPDATE:STABACKIT?

- Will the target GS1280 boot from a local SCSI disc containing a copy of its current system disc?

After that, you're probably into debugging the boot process.

It's always worth having a copy of the distribution CD on SCSI disc sitting around ready for use. It's always worth having a minimal bootable environment created from the current patch state of the current system disc on a SCSI disc too.

It's always worth testing your DR systems and processes to make sure things can be restored from the primary site and that they will work when you need them. I assume that's what you were trying to do.

Hope that helps.

Cheers, Colin (http://www.xdelta.co.uk).


PS: For those of you who've been wondering where I've been for the past few months - I had to have a hip replacement back in March and ended up taking several months out to recover and get fit again. I've been catching up with work for the past 6 to 8 weeks and am now pretty much back to normal (whatever that might be!).



I seriously hate this ITRC form. It's useless for editing text. Remember to use a text editor to create your answer, then copy the results in place when you're done. I shudder to think how many carefully written replies I've managed to lose so far.