The most significant change in the boot process is the use of a new "MemoryDisk" boot method.

This small disk image is contained in the file SYS$COMMON:[SYS$LDR]SYS$MD.DSK. During boot, this device is represented as DMM0:; when connected as a logical disk at runtime, it is also represented as LDM1:.

The minimum bootable VSI OpenVMS kernel is presented by approximately 180 files.

On prior architectures, during a network installation, the OS loader (an EFI application) constructed a memory-resident, pseudo system disk containing a set of the essential directories found on a system disk. It then parsed a list of files, downloading and copying each file into its proper directory. The boot process ran from files in this memory-resident disk, eventually reaching a point where it could mount the real system disk and use runtime drivers for ongoing file access. The initial memory-resident disk was then dissolved.

This relatively slow and complex process resulted in an OS loader that needed to understand VSI OpenVMS disk and file structures and was tied to the specific device and version of VSI OpenVMS being booted. It also required special primitive boot drivers for every supported boot device.

The new MemoryDisk boot method eliminates most of this complexity and decouples the OS loader (Boot Manager) from a specific device or instance of x86-64 VSI OpenVMS. Instead of downloading a list of files and constructing a pseudo system disk image in memory at boot time, a single pre-packaged MemoryDisk container file (SYS$MD.DSK) is provided on distribution media (the installation kit) and on every bootable VSI OpenVMS system device.

The MemoryDisk contains all of the files that are required to boot the minimum VSI OpenVMS kernel. The Boot Manager loads the MemoryDisk into memory and transfers control to the secondary bootstrap program (SYSBOOT.EXE). It can do this using the physical block I/O and file I/O drivers provided by UEFI, eliminating the need for VSI OpenVMS boot drivers and knowledge of VSI OpenVMS file systems. All of the files required by the dump kernel also reside in the MemoryDisk, allowing the dump kernel to directly boot from the pre-loaded MemoryDisk.

As the Boot Manager loads the MemoryDisk, it performs several security and integrity checks before transferring control to SYSBOOT.EXE. Errors in these checks are deemed fatal and result in clearing memory and performing a system reset.

An important concept to keep in mind is that the MemoryDisk is a container file that is structured as a bootable system disk, having its own (inner) boot blocks and GUID Partition Table (GPT), but containing only those files which are required by the early boot process; hence, a mini-kernel. When the system is running, the OS uses symlinks to direct file references to their actual location for any files that reside inside the MemoryDisk.

The contents of the MemoryDisk must be kept up to date. Any changes to these MemoryDisk-resident files through parameter file modifications, PCSI kit or patch installation, and so on, require the operating system to execute a procedure to update the MemoryDisk container. This ensures that the next boot will use the new images. This is handled by system utilities and is largely transparent to end users. The command procedure SYS$UPDATE:SYS$MD.COM handles updating the MemoryDisk container.

As the MemoryDisk is an actual bootable disk image, it implements its own (inner) boot blocks consisting of a Protective Master Boot Record (PMBR), a GPT, and multiple disk partition table entries (GPTEs).

The MemoryDisk image contains two ODS-5 structured partitions (signatures: X86VMS_SYSDISK_LOW and X86VMS_SYSDISK_HIGH) and one FAT-structured UEFI partition (signature: X86_EFI).

An installed system disk also has its own (outer) boot blocks consisting of GPT structures and three partitions, similar to the MemoryDisk. The outer boot blocks contain a pointer to the MemoryDisk. Therefore, we can boot a system disk, extracting the MemoryDisk from it, or we can directly boot a MemoryDisk. Direct boot of a MemoryDisk is primarily a development feature with some future uses.

During a normal boot from an installed system disk, the Boot Manager uses the outer boot blocks to locate and extract the MemoryDisk (SYS$MD.DSK) from the system disk. The MemoryDisk image is loaded into memory, represented as disk DMM0:, and once the logical disk is connected (as LDA1:), it becomes the system device until the boot process reaches a point where it can mount the full, physical system disk. At that point, DMM0: is set offline but is retained in case the dump kernel needs to boot.

During a network installation, the entire installation kit image is downloaded into memory as DMM1: and (using the outer boot blocks) the embedded MemoryDisk DMM0: is extracted from the kit. In this one special case and only for the duration of the installation procedure, we have two memory-resident disk images: the installation kit (DMM1:) and the MemoryDisk contained within the installation kit (DMM0:). Both of these memory-resident disks are serviced by the new MemoryDisk driver: SYS$DMDRIVER.EXE.

VSI OpenVMS is a three-partition system. Of the three disk partitions, the UEFI FAT-structured partition is the only partition that is recognized as a bootable partition by UEFI. Thus, during pre-boot execution, UEFI only sees this one partition and the files contained therein. This is where the VSI OpenVMS Boot Manager and any other UEFI executables reside. The other two ODS-5 structured partitions (and the files they contain) remain invisible to UEFI.

Shell> MAP -B

A bootable VSI OpenVMS disk will have four device mappings associated with it; one file system (fsx:) device, where the Boot Manager resides, and three block I/O (blkx:) devices, representing the three partitions (one FAT and two ODS-5 partitions). Looking at these device paths, you will note that they contain, among other things, a PCI device path, a storage device type (Sata, Fibre, etc.), and a hard disk identifier (HD1, HD2, CDROM, etc.). The bootable partition will always be shown as HD1. HD2 and HD3 are the ODS-5 partitions where the majority of VSI OpenVMS files reside.

If you want to launch a specific instance of the Boot Manager, then you will need to identify the UEFI fsx: device that is assigned to your desired boot disk (as you always had to do in IA-64 systems). You can then switch to that fsx: device and to the \EFI\VMS folder where you will find and launch VMS_BOOTMGR.EFI. It is not always easy to sift through the UEFI device paths to locate your desired disk, so it helps to familiarize yourself with device path nomenclature.

For x86-64, the Boot Manager can be run from any fsx: disk and boot any other (bootable) fsx: disk. Thus, you can simply launch the Boot Manager directly from shell as follows:

Shell> fs0:\EFI\VMS\VMS_BOOTMGR.EFI

BOOTMGR> BOOT DKA0

BOOTMGR> BOOT fs2

When a BOOT command has been issued, the Boot Manager locates an extent map contained in the boot blocks of the target disk. The extent map contains the information required to locate and load the MemoryDisk and the secondary bootstrap image SYSBOOT.EXE which resides in one of the ODS partitions.

The Boot Manager loads the MemoryDisk and SYSBOOT.EXE using the UEFI block I/O protocol, the LBA (Logical Block Address, or LBN), and the size specified in the extent map. Since UEFI contains block I/O protocols for every supported type of boot device, we no longer need VMS-specific boot drivers. During early boot, while running memory-resident, SYSBOOT.EXE loads and uses the new VSI OpenVMS MemoryDisk driver (SYS$DMDRIVER). Later, during SYSINIT, device-specific runtime drivers are loaded for access to the full physical system disk.

The UEFI partition is implemented as a logical disk container file named [SYSEXE]SYS$EFI.SYS. This is a full implementation of the UEFI partition; the folders and files are visible from the UEFI shell including \EFI\BOOT, \EFI\VMS, \EFI\UPDATE, and \EFI\TOOLS.

In order to allow the MemoryDisk itself to be a bootable entity, the MemoryDisk container file [SYSEXE]SYS$MD.DSK contains a reduced-functionality UEFI partition implemented as another logical disk container file named: [SYSEXE]MEM$EFI.SYS. Although there are no UEFI utilities in this boot-only UEFI partition, its inner boot blocks contain just enough information to locate and load SYSBOOT.EXE when the MemoryDisk is directly booted.

To be technically complete, the installation files and kit must adhere to ISO 9660 structure and boot method. Per ISO specification, yet another copy of the UEFI partition exists as the ISO boot file. Per UEFI specification, the ISO boot file must be a UEFI partition instead of an executable image. Therefore, when an ISO DVD is detected by UEFI firmware, UEFI treats the ISO boot file as a file system partition. Subsequently, if the partition contains a UEFI application named \EFI\BOOT\BOOTX64.EFI, then UEFI firmware automatically launches the application. In our case, this is a copy of the VSI OpenVMS Boot Manager. The net result is that the Boot Manager executes automatically when the installation kit file is assigned to an optical device or an installation kit DVD is inserted into the DVD drive.

Due to the automatic launch feature of optical discs that contain fsx:\EFI\BOOT\BOOTX64.EFI, VMS Software strongly suggests that you disconnect these devices after installation to prevent unwanted launching from the write-locked DVD device. After installation, you will want to launch the Boot Manager from fsx:\EFI\VMS\VMS_BOOTMGR.EFI on the installed disc.

There are several folders in the UEFI partition:

The following files may be found in the \EFI\VMS and \EFI\BOOT folders:

Additional files may appear as development continues.

When the Boot Manager is launched, it scans the system hardware to locate all bootable devices. A bootable device is one that contains a GPT and, minimally, a UEFI partition. If the GPT contains structures indicating the presence of VSI OpenVMS partitions, the volume details (labels, size, etc.) will be displayed as a bootable VSI OpenVMS device by the DEVICE command. Network devices that support the UNDI (Universal Network Device Interface) protocol are also considered bootable.

When a BOOT command is issued, the Boot Manager attempts to locate the MemoryDisk inside the boot source device. It does this by scanning the boot block structures for a specific signature. If found, additional extent records in the boot block indicate the LBA (Logical Block Address) and size of the MemoryDisk. Up to twenty-four extent records can describe the full MemoryDisk image. Because all device access at this early stage uses physical block references, the Boot Manager can use the built-in block I/O drivers provided by UEFI to load the MemoryDisk into system memory. This same method is used regardless of whether we are booting an installed system disk or an installation kit from an optical drive or over a network.

When booting from a virtual or physical device, the boot source device's (outer) boot block contains the location (Logical Block Address) and size of the MemoryDisk and the relative location and size of SYSBOOT.EXE within the MemoryDisk. SYSBOOT.EXE is the initial VSI OpenVMS bootstrap program to be loaded and executed.

When booting the installation kit over a network, the VMS_KITBOOT.EFI utility downloads the entire installation kit image. It then launches the Boot Manager. The Boot Manager, using the outer boot blocks, locates, extracts, validates, and loads the MemoryDisk from within the memory-resident installation kit image and then, using the inner boot blocks, locates, extracts, validates, loads, and executes SYSBOOT.EXE.

Before transferring control to SYSBOOT.EXE, the Boot Manager performs a variety of other tasks required to prepare the system for execution, including allocation and initialization of boot-related data structures, such as the Hardware Restart Parameter Block (HWRPB), enumeration of devices, and establishing the memory maps. It does this for both the primary kernel and the dump kernel.

If a bugcheck occurs at any point after VSI OpenVMS is booted, the dump kernel is already resident in system memory (this includes the MemoryDisk and a separate copy of SYSBOOT.EXE). The crashing primary kernel passes control to the dump kernel, which will rapidly boot, perform its tasks, and reset the system. This independent dump kernel provides for faster crash dump and shutdown processing using runtime device drivers.

The operating system procedures that build and maintain the MemoryDisk must also maintain the inner boot blocks of the MemoryDisk and the outer boot blocks of the system disk's UEFI partition. If system files that reside within the MemoryDisk are updated, by installation of a patch kit for example, the involved utilities will invoke a command procedure (SYS$MD.COM) to create a new MemoryDisk image so that any changes will be preserved for the next system boot. The system files that reside within the MemoryDisk are not files that a user or system manager would typically need to modify unless you need to add customer-developed execlets to be loaded during boot.

There are several ways to set up a system to automatically launch the VSI OpenVMS Boot Manager. As a standalone UEFI application, it can be launched from one disk and boot another. This can lead to confusion when several bootable disks are present, so the user needs to be careful about how this is set up.

Most UEFI implementations maintain a path-like list of all file system devices. UEFI can use this path to search for specific files among multiple disks. Such searches begin with fs0: and continue incrementally for the remaining fsx: devices.

The subsequent sections describe the two most common methods for setting up automatic launch.

Using a Startup File

If a file STARTUP.NSH is found on any disk that is contained in UEFI’s path, it will be executed by the UEFI shell, after a brief countdown. The STARTUP.NSH file is a simple, optional text file containing UEFI shell commands. You can create this file using the shell edit command or other method of placing the file in an fsx:\EFI folder.

The file should contain one shell command per line. In its simplest form, a single line containing VMS_BOOTMGR will launch the VSI OpenVMS Boot Manager, but because no specific fsx: device was specified, UEFI will search its path for the first instance of VMS_BOOTMGR.EFI available to it.

fs2:
CD EFI\VMS
VMS_BOOTMGR

By specifying the fsx: device first, you have identified the root device that UEFI will use. This is important because it helps to locate other files (such as environment variable files).

Any combination of shell commands can be placed in the STARTUP.NSH script. It is often used to configure low-level network and adapter details.

Typically, STARTUP.NSH is found in the fsx:\EFI folder. If multiple disks contain STARTUP.NSH files, UEFI will execute the first one it finds. You can place this file on fs0: (making it the first one found), or you can adjust the boot options and boot order in your platform firmware to point to the desired disk. Some systems allow STARTUP.NSH to be located on a network.

Setting Up Boot Options and Boot Order in the Platform Firmware

This is performed to point to the disk that you wish to automatically boot. Entering the platform boot manager screens typically involves pressing a function key during system power-on or exiting from the Shell> prompt. Your boot options are a list of bootable devices that can be edited. The boot order specifies the order in which the boot options are processed.

Typical platform firmware implementations may provide some pre-defined boot options, one of which might be the "Internal UEFI Shell." Often the shell option says it is unsupported, meaning that it is not actually a boot device. You can still use this option if you want the UEFI shell to be launched by default.

You can add new boot options and adjust the boot order as needed to place your desired default device at the top of the list. When adding a new boot option, if you specify only a boot device, UEFI will expect to find the default boot file at fsx:\EFI\BOOT\BOOTX64.EFI. It is better to specify the full folder and file (fsx:\EFI\VMS\VMS_BOOTMGR.EFI) to avoid ambiguity. Failing to be precise means that if the default boot file is not found, the next boot option will be tried, which is likely to be a different disk.

Precise boot options can be entered using the Boot from a file function or careful construction of a new boot option entry. Unfortunately, the syntax and functions vary among platforms.

BOOTMGR> AUTO BOOT

BOOTMGR> AUTO n

BOOTMGR> EXIT

Depending on the capabilities of the current system, the Boot Manager will operate in one of the four distinct modes. The Boot Manager evaluates and selects the most capable mode in the following order:

When using the VSI OpenVMS Boot Manager, you can usually connect a remote terminal session to use in parallel with the graphical display. You will need a remote connection anyway for OPA0: interaction when the system boots.

The remote serial connection always uses the architectural COM1 port (port address 0x3F8). Currently, only COM1 is supported. Use any terminal emulator that supports serial port communication, such as PuTTY. You can also set up a console connection via network (TCP port 2023, etc.) or named pipes (i.e., \\.\pipe\pipe_name, typically limited to a common host system unless a proxy server is used).

Unfortunately, the number and variety of utilities and remote access methods, along with specific differences between the various hypervisors, make console port setup exceedingly difficult to describe. Individual users will likely have to experiment and refer to relevant documentation to find what works for them.

Some platform firmware and hypervisors do not support remote connections to the UEFI shell. Others may support output-only (no keyboard input) until VSI OpenVMS is booted. In all cases, the VSI OpenVMS Boot Manager will suspend keyboard input after a BOOT command has been issued. This is because the UEFI keyboard drivers terminate once the boot has begun, and keyboard input will not resume until the VSI OpenVMS runtime drivers take over (just in time to support a conversational boot dialog).

When booted, VSI OpenVMS always assumes the use of COM1 for OPA0: interaction, except in specific instances where hardware does not support legacy COM ports.

On systems that provide a graphical display, the Boot Manager will attempt to load an optional background image file that may be customized by the user. A default background image has been provided by VMS Software.

The background image file must adhere to certain guidelines pertaining to format, dimensions, color depth, location, and name.

The file location and name must be fsx:\EFI\VMS\VMS_IMG.BMP. If this file is found and it meets the specified guidelines, it will be used by the Boot Manager.

The background bitmap image must be non-compressed, BMP format, with 24-bit color depth. Image dimensions must be a minimum of 1024 × 768 pixels and, ideally, 1920 × 1080 pixels to support most Full HD resolution monitors. If the image is smaller than the current display, it will be tiled as needed to fill the display. If the image is larger than the current display, it will be cropped. Image scaling and rotation are not supported.

A region in the upper-left corner of the image, measuring 900 × 144 pixels, is reserved for overlaying the various buttons and the VMS Software logo. The user cannot alter the placement or color of the graphical controls, so any custom image should provide adequate contrast in this region to assure that the controls remain visible. Selected controls are highlighted in red, so this too should be considered when selecting a custom image. A VMS Software copyright statement will be overlayed along the lower edge of the image. The text output area will be overlayed on top of the provided image.

If no suitable background image is found, the Boot Manager will fall back to the rendered text mode. In this mode, the full display dimensions will be used for output. If this full-size display mode is desirable, the user may rename or delete the bitmap image file. This effectively prevents the Boot Manager from entering graphical modes.

Some remote server management utilities and hypervisors will run the Boot Manager within a child window that is smaller than the physical monitor. Without having specific interfaces to these various utilities, the Boot Manager is unaware of the size of its containing window and will attempt to size its display according to the physical monitor size. This results in the need to scroll the window to see the complete Boot Manager display.

To improve usability when confined to a child window, do the following:

This will cause the Boot Manager to recalculate its display height to fit the window. This can also be handy if you would like to shrink the Boot Manager to save screen space. Changes to the display size are preserved in response to a BOOT, EXIT, or SAVE command. If you wish to restore the full display size, issue the LINES command specifying an excessively large number of lines. The Boot Manager will then determine the maximum number of lines it can use with the current monitor.

Note that the Boot Manager does not currently support display width adjustment.

The Boot Manager supports a limited form of text scrolling. The Page Up/Page Down keys will redisplay prior pages of text output. The number of pages that can be recalled depends on the density of text on each page, but in typical use, six or more pages can usually be recalled, which is sufficient for most users. Page numbers at the bottom-left corner will indicate which page is currently displayed.

Commands that produce more than a single page of output will automatically pause as each full page has been displayed, and the user may enter Q to quit the current command output.

Although the Boot Manager is able to automatically control multiple-page output, the PAGE command can be issued to enter "Page Mode." This will cause the display to pause at the end of each page and wait for the user to press a key to continue. The display will be cleared as each subsequent page is displayed. Page mode greatly improves the display performance when using remote server management utilities, particularly when the display is being sent to a web browser interface. You can disable page mode using the NOPAGE command.

Occasionally, it is useful to capture boot process output for presentation or problem reporting. End-to-end logging of the boot process can be difficult to accomplish due to the many transitions that occur during the boot process. For example, the graphical or text mode Boot Manager runs within UEFI boot context. It transitions into UEFI Runtime context as it transfers control to VSI OpenVMS.

In UEFI runtime context and beyond, the Boot Manager has no access to UEFI file protocols, thus precluding UEFI file-based logging. When VSI OpenVMS is able to initialize its operator terminal driver, it can commence logging to a VSI OpenVMS file. Seamless logging of output across these complex transitions is best accomplished by routing Boot Manager and operator output to a terminal session where logging of session output is possible.

When booting VSI OpenVMS as a VM guest, the hypervisor will often provide a means of logging a session. You may also define a serial port for your Virtual Machine that can be directed to a TCP port and address. In this case, you can route the output to a terminal emulator to provide both scrolling and logging capability.

The Boot Manager COM x command, where x is the x86-64 architecturally defined COM Port number (1 through 4), will cause Boot Manager output to be echoed to the specified serial port. COM 0 disables this function. You may route output to multiple ports by issuing additional COM x commands.

COM1 (0x3F8) will become the default port for OPA0: terminal communications once VSI OpenVMS has booted, even if Boot Manager output was disabled via a COM 0 command.

Your selected COM port routing is preserved when you issue a BOOT, EXIT, or SAVE command.

Occasionally, it is useful to project the display to a larger screen for demonstration or training purposes. This can be problematic due to the number of display resolution changes upon transferring control between BIOS, UEFI, Boot Manager, and VSI OpenVMS. Experience has shown that most modern projectors will synchronize to the resolution used by UEFI. This is fine for projecting the initial power-on sequence. Once you launch the Boot Manager, the resolution will almost certainly increase, and some projectors are not able to recognize the change. To accommodate this, we recommend that you avoid enabling output to your projector until you have launched the Boot Manager. This allows the projector to synchronize to the active resolution used by the Boot Manager.

User input on x86-64 systems is typically provided by a locally attached keyboard. This may be a standard keyboard, a USB keyboard, a local or remote serial terminal, or a terminal emulator. Some systems require that the console keyboard be plugged into a specific port in order to recognize it as a boot keyboard. This is particularly true for USB keyboards on systems with firmware that does not yet support USB 3.x speeds. Refer to the documentation for your specific hardware.

Many x86-64 systems, particularly modern middle- to low-end class, do not provide traditional (RS-232/454) serial ports. Vendors tend to get rid of serial ports in home desktop environments and, in many cases, in server/enterprise-grade systems as well.

USB input devices have their own set of issues. USB operation requires an active system timer interrupt and more system resources to be available than required by a simple RS-232 serial port. Developers that need to work in the early boot stages should use traditional serial port input in order to avoid temporary loss of console input during boot.

As the system boots, the various input devices must transition to a runtime driver environment. During this transition, there may be a brief period of time (typically a second or two) when these devices become unavailable. For developers using the XDelta debugger, this problem is avoided by using a traditional serial port keyboard or special serial debug port device instead of the USB keyboard.

The Boot Manager and system firmware support a minimum subset of keyboard functionality as required to boot the system. Special function keys and languages other than English are not currently supported by the Boot Manager. Systems that provide a mouse, touchpad, or touchscreen input device should function as expected, but special features of these devices, such as gesture recognition or specialized buttons, are not supported in the boot environment. Some hypervisors, such as VirtualBox, do not report mouse movement at all in the UEFI environment.

The keyboard Up and Down arrows operate a command recall buffer. The Right and Left arrow keys move input focus to the next or previous button in a circular chain of buttons. Whenever the arrow keys highlight a button, the Escape or Enter keys will activate the highlighted button. If the user presses any key other than the arrow keys, input focus is returned to the Boot Manager command line. The Page Up and Page Down keys display previous output pages. Pay attention to the page numbers in the lower-left corner of the display. The number of pages that can be redisplayed depends on the density of text in each page, but typically up to six pages of output can be redisplayed.

VSI OpenVMS has traditionally been dependent on UEFI environment variables to control certain aspects of the boot procedures. However, there is some inconsistency among the behaviors of some hypervisors with regards to how they handle UEFI environment variables.

While most hypervisors support interfaces for managing environment variables, some fail to provide persistence of these values across power cycles. Worse yet, some hypervisors fail to provide the fundamental interfaces and also fail to report errors when these standard UEFI features are not available.

In order to address this problem, the Boot Manager maintains an internal structure containing the required variables and attempts to store or retrieve these variables from both environment variable (if present) and a UEFI binary file, fsx:\EFI\VMS\VMS_ENV.DAT.

Using a binary file to store environment variables works with the hypervisors that preserve such files across power cycles, although there remain some persistence issues. The VMS_ENV.DAT file should not be edited. Nothing in the file is critical, and the file is deleted if it fails various validity checks.

In order to manage the number of messages that VSI OpenVMS can produce during boot, the operating system provides a defined subset of boot flags to control messages from specific phases of the boot procedures. The Boot Manager provides commands and buttons to control each of these phase-specific messaging features.

The boot phases having their own boot message flags include: BOOTMGR, SYSBOOT, EXECINIT, SYSINIT, ACPI, HWCONFIG, and DRIVER. Both graphical mode check buttons and commands are provided for each of these flags.

In addition to each phase-specific message flag, the [NO]VERBOSE command (or its associated push button) controls the extent of message detail.

%SYSBOOT-I-PARAM, Loaded Parameter File

If the VERBOSE mode flag is set, extended debug information will be provided. These messages are not formalized, and their display depends on specific developers' requirements for extensive troubleshooting.

Boot flags are a 32-bit mask of numeric constants that enable or disable specific boot-related features. These features include boot modes, boot messages, and a variety of less common features.

The definition of boot flags were changed for VSI OpenVMS x86-64. Many of the earlier flags no longer applied to the x86-64 architecture, or else served functions that were unrelated to booting.

For VSI OpenVMS on x86-64, we have reorganized the flags into three categories:

The Boot Manager presents graphical check buttons for the most commonly used flags and commands to set and clear individual flags by name. Note, however, that most hypervisors do not support mouse movement under UEFI, so if you wish to use the graphical buttons, you will need to press the arrow keys to select a button, then press Enter to toggle the state of the button. As an alternative, you can use commands to control the flag states. Refer to FLAGS and Message Check Buttons for more information on the FLAGS command and message check buttons.

Each boot flag has a corresponding command to set or clear the flag. All such Boot Manager commands can be prefixed with NO to clear the flag. For example: PROGRESS sets the progress message flag and NOPROGRESS clears the flag. Most commands can be abbreviated to a minimum number of unique characters.

A FLAGS command is also available for managing the full set of available flags. Entering the FLAGS command without an additional value will display and interpret the current boot flag settings, as follows (in graphical modes, a chart of flag bits will also be displayed):

BOOTMGR> FLAGS
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
  X               X X X X X X             X X           X
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0

Bit  Hex         Type      Command         Description
<00>(00000001) = BOOTMODE: CONVERSE  Conversational Boot : SYSBOOT>
<01>(00000002) = BOOTMODE: XDELTA    Enable Early XDELTA Debugger
<02>(00000004) = BOOTMODE: BREAK     Take Early XDELTA breakpoint
<03>(00000008) = Reserved
<04>(00000010) = MESSAGES: PROGRESS  Display Boot Progress Messages
<05>(00000020) = MESSAGES: SYSBOOT   Display Detailed SYSBOOT  Messages
<06>(00000040) = MESSAGES: EXECINIT  Display Detailed EXECINIT Messages
<07>(00000080) = MESSAGES: SYSINIT   Display Detailed SYSINIT  Messages
<08>(00000100) = MESSAGES: DRIVER    Display Device DRIVER Messages
<09:10>        = Reserved
<11>(00000800) = BOOTMODE: SYSDBG    Enable System Execlet XDELTA Debugger
<12>(00001000) = MESSAGES: ACPI      Display ACPI Messages
<13>(00002000) = MESSAGES: CONFIG    Display Hardware Configuration Messages
<14>(00004000) = Reserved
<15>(00008000) = BOOTMODE: HALT      Halt before transfer of control to SYSBOOT
<16>(00010000) = BOOTMODE: NoCommand Dump Kernel runs without a System disk
<17:19>        = Reserved
<20:22>        = Reserved
<23>(00800000) = BOOTMODE: OPA0      Use Guest Console OPA0 Terminal
                                     (rather than serial port).
<24>(01000000) = BOOTMODE: BOOTMGR   Interactive Boot Manager Dialog: BOOTMGR>
<25>(02000000) = DIAG MSG: MEMCHECK  Enable Memory Assignment Diagnostics
<26>(04000000) = DIAG MSG: DEVCHECK  Enable Device Enumeration Diagnostics
<27>(08000000) = DIAG MSG: DEVELOP   Enable Special Functions (subject to change)
<28>(10000000) = DIAG MSG: MDCHECK   Enable Memory Disk Diagnostics
<29>(20000000) = DIAG MSG: CPUCHECK  Enable CPU Startup Diagnostics
<30>(40000000) = Reserved
<31>(80000000) = MESSAGES: VERBOSE   Enable Verbose Messages

  BOOTFLAGS:   0x00000010, DUMPFLAGS: 0x00000000
  MESSAGES:    PROGRESS
  MODES:

To set or clear boot flags, the desired hexadecimal value can be provided following the FLAGS command. For example, FLAGS 1070 would set boot flag bits <4>, <5>, <6>, and <12>, enabling general boot PROGRESS messages and additional messages from SYSBOOT, EXEC_INIT, and ACPI facilities.

When setting new flag values, be aware that the value you enter will supersede flags that had been set previously. For this reason, you may want to use the FLAGS command first to see the current value, then adjust the value to enable or disable the flag bit(s) you are interested in.

The Boot Manager saves your boot flags value in response to a BOOT, EXIT, or SAVE command. Flag values that were set during a BOOT command will also be preserved as the default BOOT command string to be used on subsequent boots.

Boot Manager commands use a very simple syntax.

A command verb is followed by an optional parameter separated by a space.

Command verbs can be abbreviated to the smallest number of characters required to assure uniqueness. Certain commands having significant effect must be entered in full as a means of verifying user intent.

Commands that set a flag or enable a feature are typically cleared by prefixing the verb NO in front of the original command. For example, the PROGRESS command enables a flag to produce boot progress messages. The NOPROGRESS command clears the flag. In other words, the Boot Manager does not use SET, CLEAR, ENABLE, or DISABLE command precursors.

The Boot Manager provides a limited command recall buffer that can be accessed with the Up or Down arrow keys. The Boot Manager supports a limited form of scrolled output using the Page Up and Page Down keyboard keys.

It is unusual for the early boot process to produce large amounts of text prior to transfer to VSI OpenVMS, at which point the operator terminal and logging are available. In cases where Boot Manager commands produce more lines of output than will fit on a single screen, the Boot Manager may pause the output as text exceeds each visible display page.

In cases where a permanent log of Boot Manager output is desired, output can be directed to a COM port and terminal emulator. These features are described in their respective command descriptions.

When operating in graphical mode, common commands are represented by rows of push buttons (see the figure below). If a pointing device (mouse or touchpad) is active, the push buttons can be activated as you would expect from a GUI-based application.

If no pointing device is active, the push buttons can be selected using the Right or Left arrow keys. The selected button will be outlined in red. To activate the selected button, press the Enter or Escape key. If you press any other keys, input focus will return to the command line.

The Boot Manager provides a bridge between the UEFI pre-boot environment and the early phase of system boot (SYSBOOT). Once control is transferred to SYSBOOT, the Boot Manager keyboard is no longer available for input (due to limited USB support in VSI OpenVMS V9.2-2 or higher) and the Boot Manager display shows only XDELTA and operator terminal output. Normal interaction with VSI OpenVMS must occur through remote terminal session connection for both keyboard input and display output.

A variety of terminal utilities can be used with VSI OpenVMS. Telnet, SSH, named pipes, and TCP are the most commonly used methods. It would be impractical to document every known terminal utility, so this document focuses on Telnet and assumes that the user can translate the methods to the terminal utility of their choice.

As a general guideline, VSI OpenVMS assumes control over command processing, so you should enable character command mode (as opposed to line mode) and disable any functions that would modify the command-line terminators (carriage returns and line feeds). Terminal utilities that attempt to negotiate connection details should be set up to avoid doing so.

In the serial port setup of your VM guest and in your terminal utility, define your named pipe as \\.\pipe\pipe_name, where pipe_name is simply a unique name you provide. Using named pipes requires that your terminal utility reside on your VM host system. To use named pipes over a different network host, you will need to use a named pipe proxy server.

BOOTMGR> COM 1

The Boot Manager and UEFI use 115200 baud, 8 bit, 1 stop bit, no parity. It will auto-negotiage other baud rates.

Refer to the Chapter 7, "Troubleshooting" section if you have problems establishing a terminal session.

VMSBOX gn$ telnet 10.10.XX.XX XXXX
Trying 10.10.XX.XX..
Will send carriage returns as telnet <CR><LF>.
Connected to 10.10.XX.XX.
Escape character is '^]'.


  ENABLED:  Console output to COM1

BOOTMGR>

BOOTMGR> PROGRESS

BOOTMGR> BOOT

If you are performing a web server installation, the default device will always be the MemoryDisk DMM0:.

BOOTMGR> DEVICE

Below is an example of the installation output (output may differ slightly from that shown depending on various factors):

Booting...
%VMS_BOOTMGR-I-MAIN,    Allocating Kernel Memory.
%VMS_BOOTMGR-I-SMP,     Enumerating Processors.
%VMS_BOOTMGR-I-MEMDISK, [BLOCKIO] Booting a local ISO/DVD disk.
%VMS_BOOTMGR-I-INSTALL, Booting an OpenVMS Installation Kit...

%VMS_BOOTMGR-I-MEMDISK, Loading ISO image into DMM1. This may take a few minutes...
100%

%VMS_BOOTMGR-I-MEMDISK, Extracting DMM0 from DMM1...
%VMS_BOOTMGR-I-MEMDISK, Extracting SYSBOOT from DMM0...
%VMS_BOOTMGR-I-HWRPB,   Initializing Kernel Data Structures.
%VMS_BOOTMGR-I-HWRPB,   Initializing HWRPB for Primary Kernel.
%VMS_BOOTMGR-I-HWRPB,   Configuring System Clocks... (~3 second delay)
%VMS_BOOTMGR-I-HWRPB,   Initializing HWRPB for Dump Kernel.


%VMS_BOOTMGR-I-TRANSFER: Starting VSI OpenVMS


%%%%%%%%%%% VSI OpenVMS (tm) x86-64 Console %%%%%%%%%%%

Welcome to VSI OpenVMS SYSBOOT, Baselevel XGS4, built on Oct  7 2024 15:29:35

_______________________________________________

      THE GUEST CONSOLE HAS BEEN SUSPENDED
     USE A TERMINAL UTILITY FOR OPA0 ACCESS
_______________________________________________

VSI Primary Kernel SYSBOOT

%SYSBOOT-I-VMTYPE, Booting as a VMware (tm) Guest

%SYSBOOT-I-MEMDISKMNT, Boot memory disk mounted
%SYSBOOT-I-LOADFILE, Loaded file [SYS0.SYSEXE]X86_64VMSSYS.PAR

%SYSBOOT-I-MEMDISKDISMNT, Boot memory disk dismounted
%SYSBOOT-I-ALLOCMAPBLT, Allocation bitmap built
%SYSBOOT-I-MAP_MD, Boot MemoryDisk remapped to S2 space
%SYSBOOT-I-MAP_SYSMD, System MemoryDisk remapped to S2 space

%SYSBOOT-I-MEMDISKMNT, Boot memory disk mounted
%SYSBOOT-I-ALLOCPGS, Loader huge pages allocated
%SYSBOOT-I-LOADFILE, Loaded file [VMS$COMMON.SYSLIB]SYS$PUBLIC_VECTORS.EXE
%SYSBOOT-I-LOADFILE, Loaded file [VMS$COMMON.SYS$LDR]SYS$BASE_IMAGE.EXE
%SYSBOOT-I-LOADSYSIMGS, Base system images loaded
%SYSBOOT-I-INITDATA, Key system data cells initialized
%SYSBOOT-I-ALLOCERL, Allocated Error Log Buffers
%SYSBOOT-I-POOLINIT, Created Paged and Nonpaged Pools
%SYSBOOT-I-PXMLCOPY, Copied PXML Database to S2 space
%SYSBOOT-I-CREATECPUDB, Created the CPU Database
%SYSBOOT-I-REMAP, Moved HWRPB and SWRPB to system space
%SYSBOOT-I-CPUID, Gathered CPUID information
%SYSBOOT-I-REMAPIDT, Remapped IDT to system space
%SYSBOOT-I-INITCPUDB, Initialized Primary CPU Database
%SYSBOOT-I-INITGPT, Initialized Global Page Table
%SYSBOOT-I-PFNMAP, Created PFN Memory Map
%SYSBOOT-I-CREATEPFNDB, Created PFN Database

%SYSBOOT-I-UEFIREMAP, Remapping UEFI Services...
%SYSBOOT-I-UEFIRUNVIRT, Enabling Virtual Runtime Services.
%SYSBOOT-I-LOADFILE, Loaded file [VMS$COMMON.SYS$LDR]SYS$PLATFORM_SUPPORT.EXE
%SYSBOOT-I-LOADFILE, Loaded file [VMS$COMMON.SYS$LDR]ERRORLOG.EXE
%SYSBOOT-I-LOADFILE, Loaded file [VMS$COMMON.SYS$LDR]SYS$ACPI.EXE
%SYSBOOT-I-LOADFILE, Loaded file [VMS$COMMON.SYS$LDR]SYSTEM_PRIMITIVES_MIN.EXE
%SYSBOOT-I-LOADFILE, Loaded file [VMS$COMMON.SYS$LDR]SYSTEM_SYNCHRONIZATION.EXE
%SYSBOOT-I-LOADFILE, Loaded file [VMS$COMMON.SYS$LDR]SYS$OPDRIVER.EXE
%SYSBOOT-I-LOADFILE, Loaded file [VMS$COMMON.SYS$LDR]EXEC_INIT.EXE
%SYSBOOT-I-LOADEXEC, Execlets loaded
%SYSBOOT-I-PARMSCOPIED, System parameters copied to the base image
%SYSBOOT-I-TRANSFER, Transferring to EXEC_INIT at: ffff8300.64b50f00
EXE$INIT_RAD_INFO: Start
    SGN$GL_RAD_SUPPORT = 00000000


VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, V9.2-3
                    Copyright 2024 VMS Software, Inc.

  MDS Mitigation active, variant verw(MD_CLEAR)

%SYSBOOT-I-MEMDISKMNT, Boot memory disk mounted

                                               %SYSBOOT-I-MEMDISKMNT, Boot memory disk mounted

              %SYSBOOT-I-MEMDISKMNT, Boot memory disk mounted
                                                             %GPS-I-ACPI_SUPPORT,  Initializing ACPI Operating System Layer...
%GPS-I-ACPI_SUPPORT,  Configuring IOAPICs...
%GPS-I-ACPI_SUPPORT,  Configuring ACPI Devices...

%SYSBOOT-I-MEMDISKMNT, Boot memory disk mounted
                                               %GPS-I-ACPI_SUPPORT,  Configuring GPE Blocks...
%GPS-I-ACPI_SUPPORT,  Configuring ACPI CPUs...

%SYSBOOT-I-MEMDISKDISMNT, Boot memory disk dismounted

%SRDRIVER-I-INITDRV, Serial Port Console owns OPA0 keyboard & display.
EXE$INIT_RAD_DATA: Start

Refer to Section A.4, ''Progress Messages on Guest Display After BOOT'' for an alternative example of installation output.

As the boot proceeds, you will eventually reach the VSI OpenVMS installation menu. At this point, the installation procedures are similar to a traditional installation. You will be prompted to select your target device to install to and any optional kits you wish to install.

The dump kernel is a limited-functionality VSI OpenVMS kernel designed to handle crash dump data collection, compression and storage.

During boot, the dump kernel is created in parallel with the primary kernel. It resides in a separate memory space and shares the MemoryDisk. The dump kernel requires only 512 MB of memory.

The MemoryDisk remains in memory after the primary kernel is booted and the device associated with the MemoryDisk (DMM0:) is set offline and write-protected. A logical disk device LDMn: (where n is a device number) is created during boot, to allow access to files residing in the MemoryDisk using symlinks.

Having a second kernel for crash dump processing reduces the dependency on the crashing system and allows for greater flexibility in collecting, compressing, and writing to the dump device(s) using runtime drivers. VSI OpenVMS x86-64 does not use the traditional boot drivers.

The dump kernel is loaded, but does not boot until the primary kernel encounters a bugcheck. The bugcheck process prepares the crashing system (halting processors, identifying important areas of memory, etc.), transfers control to the dump kernel's SYSBOOT image, and then the dump kernel boots.

The dump kernel, being resident in memory, boots quickly. A dump kernel-specific startup procedure ([SYSEXE]SYS$DUMP_STARTUP.COM) executes the dump kernel's main image ([SYSEXE]SYS$DUMP_KERNEL.EXE). The dump kernel maps and collects the important areas of memory, compresses and writes the data to the dump file SYSDUMP.DMP for later analysis.

Once the crash dump has been processed and the dump file has been written, the dump kernel will invoke a power off or system reset to restart the primary kernel and re-arm a new instance of the dump kernel.

The dump kernel has a few new system parameters to control its operation. These are described in following sections.

To create a dump file on your system disk, use SYS$UPDATE:SWAPFILES.COM. When the command procedure requests a file size, start with 200,000 blocks (extend as needed).

To create a dump file on a different disk, use the following procedure. In this example, we will use DKA100: and system root 0 (SYS0):

$ CREATE/DIRECTORY DKA100:[SYS0.SYSEXE]
$ MCR SYSGEN
SYSGEN> CREATE DKA100:[SYS0.SYSEXE]SYSDUMP.DMP/SIZE=200000
SYSGEN> EXIT

$ SET DUMP_OPTIONS/DEVICE=DKA100:

The changes are effective immediately. A reboot is not necessary.

The SYSGEN parameter DUMPSTYLE must be set. VSI OpenVMS V9.2-x supports only selective (bit 0) and compressed bit (3) dump features. Setting DUMPSTYLE to 9 enables these features for a dump to the system disk. Dumping to a non-system disk is always enabled, and there is no need to set bit 2 in DUMPSTYLE.

$ MCR SYSGEN
USE CURRENT
SET DUMPSTYLE 9
WRITE ACTIVE
WRITE CURRENT
EXIT

No reboot is required after changing dump control parameters if WRITE ACTIVE is included in the SYSGEN dialogue.

When the dump kernel completes its tasks, it will execute a user-specified automatic action to restart or power off the system. Several parameters are involved in defining this behavior. The following is a description of how these parameters interact.

The flags OPC$REBOOT and OPC$POWER_OFF are set or cleared in response to SHUTDOWN parameters (or answers to SHUTDOWN prompts).

Additional failure modes are handled by performing a system reset to the UEFI shell and any specified automatic actions that follow. These failure modes include:

Crash analysis is beyond the scope of this guide. The traditional VSI OpenVMS crash analysis tools are available. For more information, refer to the VSI OpenVMS System Analysis Tools Manual (in particular, the ANALYZE/CRASH_DUMP [filespec] command).

Some terminal emulators will attempt to take ownership of a serial port if it is not already in use. If this happens, the VMS_KITBOOT procedure or the VMS_BOOTMGR utility may consider the port as unavailable and fail to make a connection.

If this occurs, you need to follow a specific sequence when connecting:

If you wish to direct console I/O to a system running Microsoft Windows, VSI recommends using the PuTTY terminal emulator. You can download PuTTY from http://putty.org. While VMS Software tests with PuTTY, other terminal utilities are also available.

Depending on how the system you are running your terminal emulator on is connected to the target system, you should select a Raw or Telnet session. The Raw option works well with VSI OpenVMS. If using Telnet, you will need to adjust various settings described below to avoid duplicate output and line termination issues.

PuTTY has several features that allow for control of your session. If you are working remotely using a SSH connection through your VPN, make sure that the IP address forwarding option is enabled (typically it is by default).

Set up your PuTTY session as follows: ?

telnet> mode char

telnet> mode line