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

[Larry Dillon]

I'm having some issues with some SAS disks a customer purchased and put in an rx2660 running OpenVMS 8.4

I was doing an IMAGE backup and got this error:

$ backup /IMAGE/NOINITIALIZE  /ignore=interlock DKB0: DKB2:

%BACKUP-W-GETBOOTERR, error reading boot information
-EFI-E-BADGPTSYS, [000000]GPT.SYS incorrectly placed on target disk
%BACKUP-W-GETBOOTERR, error reading boot information
-EFI-E-BADGPTSYS, [000000]GPT.SYS incorrectly placed on target disk
%BACKUP-F-STRUCLEV, inconsistent structure level on DKB2:

I've tried Initializing the disk:  $ INIT/NOHIGH/LIMIT/STRUCT=5/SYSTEM/erase/gpt DKB2: scratch

I've tried: $ setboot -r -a 3 DKB2:

There's nothing on the disk of value, so I could completely erase it/re-format it, but INIT doesn't seem to do that job.

I've tried setboot -s on both DKB0: and DKB2: and both have the issue with the GPT.SYS.

Any ideas?

P.S. This thread has been moved from Disk to OpenVMS > System Management. - Hp Forum Moderator

[Martin Walker]

I had a similar problem a couple of years ago - here are the notes I made...

I did a BACKUP/IMAGE from original system disk to new target disk and ran @sys$startup:BOOT_OPTIONS then option 1.

Error was

efi$bcfg: Invalid MBR/GPT on Disk.efi$bcfg: Unable to execute the Add Option.Status = 2

Fixup the GPT by

$ init/sys <target_disk> system1 /struct=5 $ backup/image <original _system_disk>: <target_disk>: /noinit

$ SET BOOT <target_disk>:[SYS0.SYSCOMMON.SYS$LDR]SYS$EFI.SYS

$ @sys$startup:boot_options

Take option: 2 - Display current boot devices

Then option: 1 - Add a boot entry (target_disk:)

Answer the questions

Shutdown and boot from the new disk

[Hoff]

Ignoring that the BACKUP /IGNORE=INTERLOCK command is not an online backup and is prone to silent data corruptions, the GPT-related errors are indicating that the GPT on the target disk structure is hosed — there's probably a GPT.SYS file present, and it's not occupying the correct locations on the disk.   Tthere was probably a non-/IMAGE backup, or something of a similar ilk.  Retrofiting a GPT would have involved locating the current file(s) occupying that range and relocating those, and then instituting and populating the GPT file.  

There are also cases where there are GPT structures present on the target disk, but not protected by a GPT.SYS file.  (Dangling GPTs have caused corruption issues in the ancient past — those problems should long ago have all have been fixed in the EFI firmware — though this is one of the reasons to use INITIALIZE /ERASE with any new-to-you disks.)

You can prove this with a DUMP /HEADER /BLOCK=END=0 GPT.SYS.  On a good (and non-DVE-expanded) disk, you'll see a file extent at the beginning of the disk and a second file extent at the highest block range of the disk.   For example:

Map area

    Retrieval pointers

        Count:         64        LBN:          0

        Count:         64        LBN:   35565024

Your numbers will likely not match these.  There's some "slop" in the specific number of blocks allocated due to the volume cluster factor in use, and the high LBN range will obviously vary by the target disk capacity.

More detailed background on the low-level disk structures is included here  http://labs.hoffmanlabs.com/node/28 and here http://labs.hoffmanlabs.com/node/112

You can reinitialize these disks as non-GPT disks and use the old boot structures, or INITIALIZE /ERASE and get rid of any GPT-related structures.

n.b. original author of the code involved here

[Larry Dillon]

Hoff, thanks for the reply and the awsome  http://labs.hoffmanlabs.com website.

Is there any way to fix these disks so they could work normally with GPT? I suspect that they may have been used in a Windows environment, but can't prove anything.

Under Linux, I would think that using dd to wipe the first few KB of disk space woudl fix the problem.  Is this a good approach or am I just better off using the INIT /NOGPT /ERASE and use them taht way?

On the BACKUP /IGNORE=INTERLOCK, this isn't a production system. 

BTW:  is there any chance of an updated edition to "OpenVMS System Management Guide"?

Thanks!

[Hoff]

You could dd to overwrite both the beginning and the end of the disk, and aiming a couple of IO$_WRITELBLK requests would similarly clobber any GPT present.  

I'd discussed always overwriting the first and last sections of a disk as part of any "normal" non-/ERASE INITIALIZE with the engineer that was maintaining that tool, but I don't know (and haven't checked) if that was implemented.

As stated in my reply, the INITIALIZE /ERASE command will work here and will (by default) zero everything, and the associated I/O load activity can also sometimes reveal latent disk errors.    If this is Itanium, /GPT is the default.

I don't know all of the folks with rights to parts of the "OpenVMS System Management Guide" book, and nobody's asked me about an update.   In general and not referencing that particular book, if VSI gains (enough) market with VMS, then there'll be more books and updates to existing books.  If not, probably not.

[Larry Dillon]

That's my problem, INIT/ERASE doesn't seem to fix the issue (unless I completely don't understand what I'm doing and that's always a possibility):

$ init/erase dkb2: scratch
$ 
$ boot -s dkb2
%EFI-E-BADGPTSYS, [000000]GPT.SYS incorrectly placed on target disk
-EFI-I-TRYMBR, only MBR-only boot block operations possible; invalid GPT
$ 

[Hoff]

---

@Larry Dillon wrote:

That's my problem, INIT/ERASE doesn't seem to fix the issue (unless I completely don't understand what I'm doing and that's always a possibility):

$ init/erase dkb2: scratch
$ 
$ boot -s dkb2
%EFI-E-BADGPTSYS, [000000]GPT.SYS incorrectly placed on target disk
-EFI-I-TRYMBR, only MBR-only boot block operations possible; invalid GPT
$ 

---

Check your command syntax:

$ sb:==$sys$system:sys$setboot

$ sb -s -f sys$sysdevice:

OpenVMS SETBOOT version V6.0-1

Boot Architecture           : IA-64

Boot Address                : 0x005bad20 : 000006008096

Boot Size                   : 0x0003e800 : 000000256000

Boot Identifier GUID        : 3BC93EC9A0004BBA11D2F81FC12A7328

Boot Signature GUID         : E0DE1E6E300072A611E3C3EADD55FB11

Boot Relative Offset        : 0x00000001 : 000000000001

Diagnostics Address         : 0x008cf860 : 000009238624

Diagnostics Size            : 0x000927c0 : 000000600000

Diagnostics Identifier GUID : 000000A0037B82A611D632E3E2A1E728

Diagnostics Signature GUID  : E0DE1E6E300073A611E3C3EADD55FB10

Diagnostics Relative Offset : 0x00000003 : 000000000003

Master Boot Record          : Protective MBR

$

[GuentherF]

Need to see the DUMP/BLOCK=COUNT:0/HEADER of GPT.SYS of both disks - allocation table only, please.

Also a SHOW DEVICE/FULL  - just the total block count and the cluster factor.

Chance that these disks report some odd highest block number which exploits a bug in the INITIALIZE code.

/Guenther

[Larry Dillon]

I'm not seeting anthing titled Allocation Table, so here's the whole thing.  DKB0:, DKB2: and DKB3: all have this issue.

Dump of file DKB0:[000000]GPT.SYS;1 on 18-NOV-2014 19:42:19.85
File ID (11,11,0)   End of file block 96 / Allocated 96

                             File Header

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (11,11,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Fixed
        File organization:                Sequential
        Record attributes:                <none specified>
        Record size:                      512
        Highest block:                    96
        End of file block:                97
        End of file byte:                 0
        Bucket size:                      0
        Fixed control area size:          0
        Maximum record size:              512
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 MoveFile disabled
    Caching attribute:                    No_caching
    Map area words in use:                5
    Access mode:                          0
    File owner UIC:                       [1,1]
    File protection:                      S:RWED, O:RWED, G:RE, W:E
    Back link file identification:        (4,4,0)
    Journal control flags:                <none specified>
    Active recovery units:                None
    File entry linkcount:                 0
    Highest block written:                96
    Client attributes:                    None

Identification area
    File name:                            GPT.SYS;1
    Revision number:                      2
    Creation date:                        29-OCT-2014 11:29:54.89
    Revision date:                        29-OCT-2014 12:08:11.37
    Expiration date:                      <none specified>
    Backup date:                          <none specified>

Map area
    Retrieval pointers
        Count:         48        LBN:          0
        Count:         48        LBN:  143305872

Checksum:                                 53935
$ 

Dump of file DKB2:[000000]GPT.SYS;1 on 18-NOV-2014 19:45:22.11
File ID (11,11,0)   End of file block 756 / Allocated 1152

                             File Header

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (11,11,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Fixed
        File organization:                Sequential
        Record attributes:                <none specified>
        Record size:                      512
        Highest block:                    1152
        End of file block:                757
        End of file byte:                 0
        Bucket size:                      0
        Fixed control area size:          0
        Maximum record size:              512
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 MoveFile disabled
    Caching attribute:                    No_caching
    Map area words in use:                6
    Access mode:                          0
    File owner UIC:                       [SYSTEM]
    File protection:                      S:RWED, O:RWED, G:RE, W:E
    Back link file identification:        (4,4,0)
    Journal control flags:                <none specified>
    Active recovery units:                None
    File entry linkcount:                 0
    Highest block written:                1152
    Client attributes:                    None

Identification area
    File name:                            GPT.SYS;1
    Revision number:                      1
    Creation date:                        13-NOV-2014 18:25:10.08
    Revision date:                        13-NOV-2014 18:25:10.08
    Expiration date:                      <none specified>
    Backup date:                          <none specified>

Map area
    Retrieval pointers
        Count:        576        LBN:          0
        Count:        576        LBN:  585858240

Checksum:                                 53702
$ 

Dump of file DKB3:[000000]GPT.SYS;1 on 18-NOV-2014 19:45:50.91
File ID (11,11,0)   End of file block 84 / Allocated 96

                             File Header

Header area
    Identification area offset:           40
    Map area offset:                      100
    Access control area offset:           255
    Reserved area offset:                 255
    Extension segment number:             0
    Structure level and version:          2, 1
    File identification:                  (11,11,0)
    Extension file identification:        (0,0,0)
    VAX-11 RMS attributes
        Record type:                      Fixed
        File organization:                Sequential
        Record attributes:                <none specified>
        Record size:                      512
        Highest block:                    96
        End of file block:                85
        End of file byte:                 0
        Bucket size:                      0
        Fixed control area size:          0
        Maximum record size:              512
        Default extension size:           0
        Global buffer count:              0
        Directory version limit:          0
    File characteristics:                 MoveFile disabled
    Caching attribute:                    No_caching
    Map area words in use:                5
    Access mode:                          0
    File owner UIC:                       [1,1]
    File protection:                      S:RWED, O:RWED, G:RE, W:E
    Back link file identification:        (4,4,0)
    Journal control flags:                <none specified>
    Active recovery units:                None
    File entry linkcount:                 0
    Highest block written:                96
    Client attributes:                    None

Identification area
    File name:                            GPT.SYS;1
    Revision number:                      1
    Creation date:                        14-NOV-2014 21:23:58.73
    Revision date:                        14-NOV-2014 21:23:58.73
    Expiration date:                      <none specified>
    Backup date:                          <none specified>

Map area
    Retrieval pointers
        Count:         48        LBN:          0
        Count:         48        LBN:  585858384

Checksum:                                 24342
$ 

[Hoff]

Apparently I was a little too obscure in my earlier "syntax" comment.

You have not specified the command properly.  

Please specify the proper command syntax, and see if that works better.

In particular, the switch that specifies the target device is: -f filename

That -f switch was originally (and still does allow) the full GPT.SYS filename to be specified.  That the tool now allows partial filename specifications was added along the way, hence -f ddcu: is commonly used.  The -f switch was never renamed or aliased to something more appropriate for what's now usually a device name.  Here ends the history lesson.

The command parser on that (undocumented, diagnostic) tool is clearly not very robust, and I'll have to talk to me about this when I see me next.  Or VSI.

My ISP link is having problems, so whether this reply gets posted?   The HP Lithium Javascript is clearly not dealing well with bad links, either.