Operating System - OpenVMS
cancel
Showing results for 
Search instead for 
Did you mean: 

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

 
SOLVED
Go to solution
Advisor

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

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

Honored Contributor

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

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.

 

Trusted Contributor

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

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

 

 

Trusted Contributor

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

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

Advisor
Solution

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

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!

Honored Contributor

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


@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.