- 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):
OpenVMS x86 doesn't create/update the GPT on disks correctly.
-
Topic author - Valued Contributor
- Posts: 76
- Joined: Sat Apr 15, 2023 11:53 pm
- Reputation: 0
- Status: Offline
OpenVMS x86 doesn't create/update the GPT on disks correctly.
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
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.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 ...
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.
-
Topic author - Valued Contributor
- Posts: 76
- Joined: Sat Apr 15, 2023 11:53 pm
- Reputation: 0
- Status: Offline
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
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.
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.
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.pocketprobe wrote: ↑Sat Apr 20, 2024 10:36 amTL;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.
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.
-
Topic author - Valued Contributor
- Posts: 76
- Joined: Sat Apr 15, 2023 11:53 pm
- Reputation: 0
- Status: Offline
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
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.
-
- Master
- Posts: 154
- Joined: Fri Jun 28, 2019 8:45 am
- Reputation: 0
- Location: South Tyneside, UK
- Status: Offline
- Contact:
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
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
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
Ian Miller
[ personal opinion only. usual disclaimers apply. Do not taunt happy fun ball ].
[ personal opinion only. usual disclaimers apply. Do not taunt happy fun ball ].
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
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.pocketprobe wrote: ↑Sat Apr 20, 2024 5:26 pmStill, 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 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.
Last edited by hb on Tue Apr 23, 2024 5:39 am, edited 1 time in total.
Re: OpenVMS x86 doesn't create/update the GPT on disks correctly.
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.