OpenVMS x86 doesn't create/update the GPT on disks correctly.

[pocketprobe]

• Start with a Fresh Install of 9.2-2 on a 32GB Disk, Install Update 1

  Code: Select all

  $ show dev dka200:/full
  
  Disk MORDOR$DKA200:, device type ATA QEMU HARDDISK, is online, mounted, file-
      oriented device, shareable, available to cluster, error logging is enabled.
  
      Error count                    0    Operations completed               5954
      Owner process                 ""    Owner UIC                      [SYSTEM]
      Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
      Reference count               28    Default buffer size                 512
      Total size               32.00GB    Sectors per track                     0
      Total cylinders                0    Tracks per cylinder                   0
      Logical Volume Size      32.00GB    Expansion Size Limit             1.98TB
  
      Volume label            "X86SYS"    Relative volume number                0
      Cluster size                  16    Transaction count                   112
      Free space               12.46GB    Maximum files allowed          16711679
      Extend quantity                5    Mount count                           1
      Mount status              System    Cache name    "_MORDOR$DKA200:XQPCACHE"
      Extent cache size             64    Max blocks in extent cache      2615129
      File ID cache size            64    Blocks in extent cache          2443584
      Quota cache size               0    Maximum buffers in FCP cache       4550
      Volume owner UIC           [1,1]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD
  
    Volume Status:  ODS-5, subject to mount verification, protected subsystems
        enabled, file high-water marking, write-through XFC caching enabled,
        write-through XQP caching enabled, hard links enabled, special files
        enabled.
  
  $ 

• Check the partition table in Linux

  Code: Select all

  ubuntu@ubuntu:~$ sudo fdisk /dev/sdb
  
  Welcome to fdisk (util-linux 2.37.2).
  Changes will remain in memory only, until you decide to write them.
  Be careful before using the write command.
  
  
  Command (m for help): p
  Disk /dev/sdb: 32 GiB, 34359738368 bytes, 67108864 sectors
  Disk model: QEMU HARDDISK   
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: gpt
  Disk identifier: 408EC654-FDFE-11EE-BDEC-AA000400FEFF
  
  Device       Start      End  Sectors  Size Type
  /dev/sdb1  2453696  2709695   256000  125M EFI System
  /dev/sdb2       48  2453695  2453648  1.2G unknown
  /dev/sdb3  2709696 67108830 64399135 30.7G unknown
  
  Partition table entries are not in disk order.
  
  Command (m for help): 

• Resize Disk to 64G, and resize the volume in OpenVMS

  Code: Select all

  $ show dev dka200 /full
  
  Disk MORDOR$DKA200:, device type ATA QEMU HARDDISK, is online, mounted, file-
      oriented device, shareable, available to cluster, error logging is enabled.
  
      Error count                    0    Operations completed               3623
      Owner process                 ""    Owner UIC                      [SYSTEM]
      Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
      Reference count               28    Default buffer size                 512
      Total size               64.00GB    Sectors per track                     0
      Total cylinders                0    Tracks per cylinder                   0
      Logical Volume Size      32.00GB    Expansion Size Limit             1.98TB
  
      Volume label            "X86SYS"    Relative volume number                0
      Cluster size                  16    Transaction count                   112
      Free space               12.46GB    Maximum files allowed          16711679
      Extend quantity                5    Mount count                           1
      Mount status              System    Cache name    "_MORDOR$DKA200:XQPCACHE"
      Extent cache size             64    Max blocks in extent cache      2615120
      File ID cache size            64    Blocks in extent cache             1936
      Quota cache size               0    Maximum buffers in FCP cache       4550
      Volume owner UIC           [1,1]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD
  
    Volume Status:  ODS-5, subject to mount verification, protected subsystems
        enabled, file high-water marking, write-through XFC caching enabled,
        write-through XQP caching enabled, hard links enabled, special files
        enabled.
  
  $ 
  
  $ SET VOLUME/SIZE DKA200
  $ show dev dka200 /full
  
  Disk MORDOR$DKA200:, device type ATA QEMU HARDDISK, is online, mounted, file-
      oriented device, shareable, available to cluster, error logging is enabled.
  
      Error count                    0    Operations completed               6872
      Owner process                 ""    Owner UIC                      [SYSTEM]
      Owner process ID        00000000    Dev Prot            S:RWPL,O:RWPL,G:R,W
      Reference count               28    Default buffer size                 512
      Total size               64.00GB    Sectors per track                     0
      Total cylinders                0    Tracks per cylinder                   0
      Logical Volume Size      64.00GB    Expansion Size Limit             1.98TB
  
      Volume label            "X86SYS"    Relative volume number                0
      Cluster size                  16    Transaction count                   112
      Free space               44.46GB    Maximum files allowed          16711679
      Extend quantity                5    Mount count                           1
      Mount status              System    Cache name    "_MORDOR$DKA200:XQPCACHE"
      Extent cache size             64    Max blocks in extent cache      9326001
      File ID cache size            64    Blocks in extent cache          2615120
      Quota cache size               0    Maximum buffers in FCP cache       4550
      Volume owner UIC           [1,1]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD
  
    Volume Status:  ODS-5, subject to mount verification, protected subsystems
        enabled, file high-water marking, write-through XFC caching enabled,
        write-through XQP caching enabled, hard links enabled, special files
        enabled.
        
  $

• Check the partition table in Linux now

  Code: Select all

  ubuntu@ubuntu:~$ sudo fdisk /dev/sdb
  
  Welcome to fdisk (util-linux 2.37.2).
  Changes will remain in memory only, until you decide to write them.
  Be careful before using the write command.
  
  GPT PMBR size mismatch (67108863 != 134217727) will be corrected by write.
  The backup GPT table is not on the end of the device. This problem will be corrected by write.
  
  Command (m for help): p
  
  Disk /dev/sdb: 64 GiB, 68719476736 bytes, 134217728 sectors
  Disk model: QEMU HARDDISK   
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: gpt
  Disk identifier: 408EC654-FDFE-11EE-BDEC-AA000400FEFF
  
  Device       Start      End  Sectors  Size Type
  /dev/sdb1  2453696  2709695   256000  125M EFI System
  /dev/sdb2       48  2453695  2453648  1.2G unknown
  /dev/sdb3  2709696 67108830 64399135 30.7G unknown
  
  Partition table entries are not in disk order.
  
  Command (m for help): 

• It seems we also don't create a GPT on a secondary disk on x86.

  Code: Select all

  $ init dka300 /gpt /struct=5 
  _Label: test
  $ set proc/unit=bytes
  $ mount dka300 test test
  %MOUNT-I-MOUNTED, TEST mounted on _MORDOR$DKA300:
  $ show dev dka300 /full
  
  Disk MORDOR$DKA300:, device type ATA QEMU HARDDISK, is online, allocated,
      deallocate on dismount, mounted, file-oriented device, shareable, available
      to cluster, error logging is enabled.
  
      Error count                    0    Operations completed               1537
      Owner process           "SYSTEM"    Owner UIC                      [SYSTEM]
      Owner process ID        00000411    Dev Prot            S:RWPL,O:RWPL,G:R,W
      Reference count                2    Default buffer size                 512
      Total size               20.00GB    Sectors per track                     0
      Total cylinders                0    Tracks per cylinder                   0
      Logical Volume Size      20.00GB    Expansion Size Limit            20.00GB
  
      Volume label              "TEST"    Relative volume number                0
      Cluster size                   1    Transaction count                     1
      Free space               19.99GB    Maximum files allowed          10485760
      Extend quantity                5    Mount count                           1
      Mount status             Process    Cache name    "_MORDOR$DKA200:XQPCACHE"
      Extent cache size             64    Max blocks in extent cache      4193014
      File ID cache size            64    Blocks in extent cache                0
      Quota cache size               0    Maximum buffers in FCP cache       4550
      Volume owner UIC        [SYSTEM]    Vol Prot    S:RWCD,O:RWCD,G:RWCD,W:RWCD
  
    Volume Status:  ODS-5, subject to mount verification, file high-water marking,
        write-through XFC caching enabled, write-back XQP caching enabled, special
        files enabled.
  
  $ 
  
  ubuntu@ubuntu:~$ sudo fdisk /dev/sdc
  
  Welcome to fdisk (util-linux 2.37.2).
  Changes will remain in memory only, until you decide to write them.
  Be careful before using the write command.
  
  Device does not contain a recognized partition table.
  Created a new DOS disklabel with disk identifier 0x00117d51.
  
  Command (m for help): p
  Disk /dev/sdc: 20 GiB, 21474836480 bytes, 41943040 sectors
  Disk model: QEMU HARDDISK   
  Units: sectors of 1 * 512 = 512 bytes
  Sector size (logical/physical): 512 bytes / 512 bytes
  I/O size (minimum/optimal): 512 bytes / 512 bytes
  Disklabel type: dos
  Disk identifier: 0x00117d51
  
  Command (m for help): 
  

[hb]

• Start with a Fresh Install of 9.2-2 on a 32GB Disk, Install Update 1 ...

Looks like two bugs to me: a) it seems that SET VOLUME/SIZE misses some code to update the GPT, b) the init code for the user disk is very also missing some code. If you look at the user disk's first LBNs you will not see a protective MBR, but an incomplete GPT header and no GPT entry.

And, I assume this is not new on x86. It think I saw b) on IA64.

That said, for what do you want/need to get to the partitions?

If you want to mount the ESP, aka EFI partition of the system disk on a non-VMS system, it should work. You can access it. It's probably not supported by VSI. You are on your own.

VMS file systems do not use partitions at all, they use the whole disk. If you want to get VMS files from the disk with whatever tool/kernel module you have, it will mount and use the whole disk, as VMS does. In other words, I don't think that a GPT on a VMS user disk makes much sense.

[pocketprobe]

In the most recent webinar and discussion of backups I was reminded about this bug/bug set and originally thought this had something to do with shadow sets (which shadowing the volume with an incorrect header will copy the incorrect header.)

I figure this would have some importance with fiber channel passthrough, where virtual machines can see raw targets and the chance of having the wrong disk assigned to a vm isn't zero. Having the GPT be present and correct, hopefully with the volume label in the GPT will make identification easy. I would imagine that some of the platform agnostic backup software such as Veeam would care.

TL;DR GPTs with correct size and label will help with disk/target identification, and probably for backup software to make better estimates and/or have better inventory.

[hb]

TL;DR GPTs with correct size and label will help with disk/target identification, and probably for backup software to make better estimates and/or have better inventory.

On VMS, you can look at the GPT (of any mounted disk) with "$ mc sys$setboot -s -e [-f ddcu:]". The default is the system disk. The output will include the disk GUID, the partition GUIDs, and the partition names.

The GPT header does not contain a (disk) name. All the x86 VMS system disks have the same partition names: X86_EFI, X86_OPENVMS_SYSDISK_LOW and X86_OPENVMS_SYSDISK_HIGH. (On IA64 you will see more partitions and the prefix IA64_). The VMS volume name/label is not included in the GPT. It is a part of the file system.

I can think of a way to modify/create the GPT entries, but it's probably not supported and I wouldn't really suggest trying it.

[pocketprobe]

On VMS, you can look at the GPT (of any mounted disk) with "$ mc sys$setboot -s -e [-f ddcu:]". The default is the system disk. The output will include the disk GUID, the partition GUIDs, and the partition names.

Thank you for this. There is something new to learn every day.

I do apologize for using partition and disk name interchangeably. I do see the partition names in the GPT of the system disk, which the names do make enough sense for it to garner reasonable sense as to what the disk is.

Still, I'd like the system disk when expanded to fix the table, and when initializing a secondary disk, to have a valid table so standard tools will easily identify it by the name of the partition containing the Files-11 volume. As it stands, I could think of installers for other systems claiming the disk is uninitialized leading to possible data loss. Or knowing which disk you've attached to by mistake.

[imiller]

I see there are more options to setboot than I knew about..
I would like to see a SHOW BOOT command which does what the -s option does. It could have an option /FULL to do what -s -e does

Code: Select all

$ mc sys$setboot -h
$1$dka0:[sys0.syscommon.][sysexe]sys$setboot.exe;1: illegal option -- h

Target specification required

This is the foreign-command SET BOOTBLOCK interface.
Available foreign command syntax options include:

  -a 0          bootblock for current architecture (SYI$K_ARCH_OTHER)
  -a 1          bootblock for OpenVMS VAX systems (SYI$K_ARCH_VAX)
  -a 2          bootblock for OpenVMS Alpha systems (SYI$K_ARCH_ALPHA)
  -a 3          bootblock for OpenVMS I64 systems (SYI$K_ARCH_IA64)
  -a 4          bootblock for OpenVMS x86-64 systems (SYI$K_ARCH_X86_64)
  -f filename   Select primary bootstrap device, or full-path filename
                   On -s, displays information from the specified device
                   If not specified, defaults to SYS$SYSDEVICE:
  -g            Preserve the Signature GUID (OpenVMS I64 & X86 only)
  -m            Ignore the existence, status and placement of GPT.SYS
                   On -s, bypass GPT.SYS processing
  -q lbn        Starting LBN (OpenVMS VAX bootblocks only)
  -r            Reset (overwrite) the bootblock and (if present) the GPT
  -s            show the bootblock (readonly; no changes performed)
                  specify target device with -f ddcu:
  -e            Extended GPT display format (I64 & X86 only); requires -s
  -x            Generate DCL symbols; requires -s
  -z loadaddr   Load Address (OpenVMS VAX bootblocks only)
  -2            Use 2KB blocks (OpenVMS I64 & X86 bootblocks only)
                   On -s, displays block offset values for optical disks

The default architecture for the bootblock is that of the current
system architecture.  The default bootstrap filename is selected
based on the target architecture for the bootblock.  The default
disk block (sector) size is 512-byte blocks, and is appropriate for
most disk bootstraps; 2KB block size can be required for certain CD
or DVD media bootstraps (only) on OpenVMS I64 & X86 systems.

Typical (and minimalist) usage:

    $ setboot :== $sys$setboot
    $ setboot -s

[hb]

Still, I'd like the system disk when expanded to fix the table, and when initializing a secondary disk, to have a valid table so standard tools will easily identify it by the name of the partition containing the Files-11 volume.

I'm not sure I fully understand what you're asking. A volume label/name is a filesystem thing. For VMS, the disk is the Files-11 volume. The GPT is part of the filesystem: [000000]GPT.SYS;1. For non-VMS systems, a VMS disk (currently only the system disk) has a GPT with one or more partitions covering the entire disk. None of the partitions contains a complete VMS file system.

I do not know how common partition names are. On my Linux system, the names are empty strings. And you have to go into fdisk's expert mode to set a name.

Maybe you want a new qualifier for INIT: /PARTITION_NAME[=name] (accepted only if /GPT is present), with the default being the volume-label argument. And an optional user-defined name. This should not be too hard to add for non-system disks. However, a SET VOLUME/LABEL will not and should not update the partition name. For system disks this should only affect the string [X86|IA64]_OPENVMS_SYSDISK, the suffixes _[LOW|HIGH|...] will/should not be settable. This seems like more work, especially since on fresh installations, setting up the GPT is done at installation time. If this is what you're looking for, you may want to submit a System Improvement Request to VSI.

[hb]

I see there are more options to setboot than I knew about..
I would like to see a SHOW BOOT command which does what the -s option does. It could have an option /FULL to do what -s -e does

Did you send a System Improvement Request to VSI? I think SHOW BOOT should do what the -s option does. Instead of a /FULL a /GPT seems more appropriate to me. Then SHOW BOOT should show, what the -s option shows plus what the -s -e options show. I would also ask for the wire format of the GUIDs output for -s and remove the hex octaword format for -s and for -s -e.