Page 1 of 1
OpenVMS x86 doesn't create/update the GPT on disks correctly.
Posted: Sat Apr 20, 2024 12:10 am
by 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):
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
Posted: Sat Apr 20, 2024 8:56 am
by hb
pocketprobe wrote: ↑Sat Apr 20, 2024 12:10 am
- 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.
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
Posted: Sat Apr 20, 2024 10:36 am
by 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.
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
Posted: Sat Apr 20, 2024 4:49 pm
by hb
pocketprobe wrote: ↑Sat Apr 20, 2024 10:36 am
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.
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
Posted: Sat Apr 20, 2024 5:26 pm
by pocketprobe
hb wrote: ↑Sat Apr 20, 2024 4:49 pm
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.
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
Posted: Mon Apr 22, 2024 6:56 am
by 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
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
Posted: Tue Apr 23, 2024 5:22 am
by hb
pocketprobe wrote: ↑Sat Apr 20, 2024 5:26 pm
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.
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
Posted: Tue Apr 23, 2024 5:37 am
by hb
imiller wrote: ↑Mon Apr 22, 2024 6:56 am
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.