OpenVMS v7.3-2 Bugcheck: PROCGONE, Process not in system

[Matthew Booth]

OpenVMS Alpha v7.3-2 Bugcheck: PROCGONE, Process not in system This happened after AXPVMS-VMS732_UPDATE-V0900 and AXPVMS-VMS732_TZ-V0300 was applied to my system disk in cluster. I need to back these products out to get my cluster back on it's feet. What's the proper procedure?



Please Help,
Thanks, Matt (VMS)

[Karl Rohwedder · Accepted solution]

Matt,

if your system is up and running, PRODUCT UNDO PATCH would undo the latest patch (PROD SHO RECOV displays a list of applied patches).
But it seems, as if your system is crashing during boot, so you could:
- either boot a CD and restore the latest backup
- or boot a CD and try a PRODUCT UNDO PATCH/REMOTE (but read the help before, I never tried this myself)

regards Kalle

[Matthew Booth]

Hi Karl, Thanks for the quick response! Apparently giving each of my servers a time to rest has allowed them to boot back up?.. I suspect that some sort of lock was still hanging around on the patched system disk. I will investigate further later today.

Thanks,
Matt

[Matthew Booth]

The v7.3-2 Alpha server are now booting not sure why this is happening but for know I'm back up and running.

Matt

[Hoff]

It looks almost like something bumped into a VAX or I64 image somewhere, or something that caused the bootstrap to think it bumped into a VAX or I64 image.

R0 is an interesting value for a PROCGONE.

$ x=f$mess(%x04D8CFC)
$ sho sym x
X = "%IMGACT-F-NOTNATIVE, image is not an OpenVMS Alpha image"

From that value and from some digging in the OpenVMS source listings, you can sometimes find additional details left in R1 or other registers, or from pieces left around in the carcass; in the dumpfile.

There seems to be an image header buffer referenced in the carcass, and a look at that in the carcass might help determine what image was involved when the bootstrap tipped over.

Another option is to enable a "gonzo" R5 boot, with diagnostics enabled. There are a couple of bitflags in the middle of the APB R5 list of flags that turn on some serious boot-time diagnostic displays. b fl=0,3xxxxx or some such, would turns on both of the boot diagnostic flags. (Not sure about the number of zeros on that, but the FAQ has the defined bits. I'll queue an example for the next edition of the FAQ, since that particular bitflag combo is a go-to boot command.)

Stephen Hoffman
HoffmanLabs