OpenVMS: EFI-E-BADGPTSYS, [000000]GPT.SYS incorrectly placed on target disk

[Larry Dillon]

I hope this is what you are looking for:

$ sb -s -f DKB0:[000000]GPT.SYS
%EFI-E-BADGPTSYS, [000000]GPT.SYS incorrectly placed on target disk
-EFI-I-TRYMBR, only MBR-only boot block operations possible; invalid GPT

$ sb -s -f DKB2:[000000]GPT.SYS
OpenVMS SETBOOT version V6.0-1
Boot Architecture : Unrecognized

This is after:

$ INIT/NOHIGH/LIMIT/STRUCT=5/SYSTEM/erase/gpt DKB2: scratch

[Hoff]

The first is either a bug in INITIALIZE /GPT, or a bug in the sys$setboot detection or reporting.  Ring up HP support.

The second disk looks to have a correctly-configured GPT, but probably doesn't have a boot block written to it.

As for the second disk and assuming that's NOT a system disk — that it's a semi-scratch disk — you can try writing a boot block onto that disk, and see if that resolves the "unrecognized" output.  To write an Alpha boot block, you can pick any old executable as the primary bootblock file and tell sys$setboot it's an Alpha system disk, or COPY /CONTIGUOUS an SYS$EFI.SYS partition file onto the disk and then tell sys$setboot that it's an Itanium system disk.  Then see if sys$setboot detects the disk correctly.

This Lithium forum software gets jiggly when the network connection drops out from underneath it, too.  The forum input box behavior is reminiscent of how the shift key worked on an old-time mechanical typewriter.  Upward and downward jumps.  That the forum software spell-checker still insists Itanium is a typo is adorable, too.

[GuentherF]

Oops, I meant to say "retrieval pointers" instead of "Mapping area".

DKB2 has a GPT.SYS size of 2*576 blocks. Unless a huge disk cluster factor has been used - which I didn't see mentiorned in the INITIALIZE command - this looks weird (aka wrong)!

Looking at the starting LBNs of the 2nd segments of the GPT.SYS file it looks like DKB0=64 GB, DKB2=256 GB, DKB3=256 GB). Have you tried a BACKUP/NOINIT to DKB3?

Does the BACKUP/IMAGE work without the /NOINITIALIZE?

Show us the "SHOW DEVICE/FULL" of all three disks. Either there is a huge disk cluster factor showing up or, the "total blocks" for DKB2 has an "interesting" value.

/Guenther

[GuentherF]

If there is a bug in INITIALIZE code where I think it is it should work with explicitly specifying /CLUSTER=64 with the INITIALIZE command.

Please try that and check with your SETBOOT after that.

/Guenther

[Larry Dillon · Accepted solution]

To try and close up this issue, I upgraded the p400 firmware from 4.x to 7.22 and reinstalled OpenVMS 8.4 from factory DVD and them was able to do a BACKUP /IMAGE from the new system disk to the other disks.  This process seems to have fixed the GPT issues. 

Thanks to all commenters!

[Hoff]

---

@Larry Dillon wrote:

To try and close up this issue, I upgraded the p400 firmware from 4.x to 7.22 and reinstalled OpenVMS 8.4 from factory DVD and them was able to do a BACKUP /IMAGE from the new system disk to the other disks.  This process seems to have fixed the GPT issues. 

Thanks to all commenters!

---

Log a bug with HP.   If this is a firmware bug with the old bits and in the best case, the (old) configuration should squawk at bootstrap.  If the I/O used here is going wrong due to the firmware level, then potentially rather more is going wrong, and that should be flagged to the user.