[Info-vax] questions on initialize/gpt

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Tue Jun 23 10:24:41 EDT 2015


On 2015-06-23 13:43:47 +0000, Michael Moroney said:

> Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
> 
>> AIUI, (not actually having used IA-64 VMS) the GPT.SYS file is just a 
>> fake partition created by VMS $ init to allow the contents to be 
>> visible from the console.
> 
> Yes, there's just enough there for the Itanium console to find files 
> necessary to boot VMS.

FWIW / clarification...

The GPT.SYS overlays the GPT data structures, and provides enough 
information for EFI to find the separate FAT partition containing 
various tools including the OpenVMS primary bootstrap executable.  The 
FAT boot partition is overlaid by and protected by the ODS-2 / ODS-5 
file SYS$EFI.SYS.   If present, the diagnostic FAT partition is 
protected by the SYS$MAINTENANCE.SYS file.

> One partition covers the whole disk (other than what's covered by the 
> special boot files partition) to tell any other OS that those blocks 
> have been claimed.

All GPT-format disks do have what is known as a protective MBR, and 
that intentionally covers the whole disk.   The four partition records 
present in the standard MBR are configured within a protective MBR to 
use the type codes of (usually) EE and (less often, older) EF and those 
records are set to cover the whole disk.  The protective MBR is not 
specific to OpenVMS and to its implementation, either.  The protective 
MBR is only there to prevent pre-GPT MBR-based systems — old Windows 
versions, mostly — from clobbering the GPT structures and settings.   
That protective MBR is also not used for any GPT bootstraps.

At the GPT level, there is no partition which overlays the whole disk, 
and AFAIK overlapping partitions are not not be permissible within GPT. 
 An OpenVMS disk with a GPT typically includes from three to five 
partitions, which in aggregate cover the whole disk.   The number of 
partitions is based on the number and exact location of the FAT 
partitions on the disk.   It is possible to have an OpenVMS GPT disk 
with just one partition, if there are no FAT partitions present.  
That'll cover the range between the two GPT tables; almost all of the 
disk.  Two partitions can arise, if there's one FAT partition that's 
aligned exactly to the lowest or highest-available blocks within the 
available range of data blocks.

> BTW the funniest report I've heard in a while is that a thumb drive 
> formatted with bootable VMS will crash Windows if it's plugged into a 
> Windows system.  I just tried it; Windows 8.1 doesn't crash and sees 
> the files the Itanium console needs to see, but Windows XP crashes.

Bugs happen.  Trying to MOUNT a blank CD used to cause OpenVMS to loop 
at IPL, for instance.   Dealing with malformed or unexpected or 
malicious file structures is not an easy problem.

As for the crash, there wasn't support for GPT that far back with 
Windows XP (other than with the rarely-encountered Windows XP x64 
Edition), which could mean that something about the protective MBR 
handling is causing the error within Windows XP.    Interesting bug.  
Not one I've encountered, either.

Subsequent to the EFI specs that OpenVMS I64 is presently following, 
UEFI has apparently made some changes to the partition-identifying type 
codes used here too, including changing the file system type codes 
associated with the FAT partitions away from those associated with 
Microsoft FAT, too.  The FAT implementations have effectively been 
forked.


-- 
Pure Personal Opinion | HoffmanLabs LLC




More information about the Info-vax mailing list