Initial OpenVMS 9.2-1 Installation and PuTTy problems

[rjolbrich]

Hello,
I'm attempting my first x86 installation with VirtualBox and PuTTy.
I can get past the first boot before installation with PuTTy.
From the docs:


The TELNET prompt will now show:

VMS Software, Inc. OpenVMS (TM) x86_64 Operating System, E9.2-1
Copyright 2023 VMS Software, Inc.

[...]

You can install or upgrade the OpenVMS X86-64 operating system
or you can install or upgrade layered products that are included
on the OpenVMS X86-64 distribution media.

You can also execute DCL commands and procedures to perform
"standalone" tasks, such as backing up the system disk.

Please choose one of the following:

1) Upgrade, install or reconfigure OpenVMS X86-64 Version E9.2-1
2) Display layered products that this procedure can install
3) Install or upgrade layered products
4) Show installed products
5) Reconfigure installed products
6) Remove installed products
7) Find, Install or Undo patches; Show or Delete Recovery Data
8) Execute DCL commands and procedures
9) Shut down this system

Press and hold CTRL, then press ]. The prompt changes to telnet>. You need to enter the command:

unset crlf

Press CTRL+] again and enter another command:

mode char

If you don't do this, you cannot enter a SYSTEM account password later on.


-----------------------------------------------

I cannot get ctrl-] to give me a telnet prompt.
So I cannot enter the given commands.

I'm new to PuTTy and am not familiar with its settings.
Can someone help me.

Thanks

[hb]

On my bare metal machine at the BOOTMGR> prompt, I was able to tell it
BOOTMGR> AUTO B DKA0

Code: Select all

BOOTMGR> HELP

shows

Code: Select all

AUTOACTION        - HALT, BOOT or n  - Automatic action to take when BootManager is invoked.
                    The value of n is a delay in seconds (1 to 30) before executing the action.

Setting AUTOACTION should do what you want/need to do.

Don't try to boot what the BootManager shows in the "BOOTABLE DEVICES" list as

Code: Select all

DKA300     (DVD) = FS1    UEFI: UEFI_SHELL   VMS: None         2     MB  SATA DVD

Other than hitting <ESC> several times while the "temporary windows" are displayed ...

You may want to try the EFI$CP tool

Code: Select all

$ mc efi$cp
EFI$CP> mount/over=id/dev=efi: sys$sysdevice:[vms$common.sys$ldr]sys$efi.sys
EFI$CP> dir efi:\efi\boot\

Directory EFI:\EFI\BOOT\

 8-NOV-2023 14:36:00.08  <DIR>         UPDATE
 8-NOV-2023 14:36:01.08       2052320  BOOTX64.EFI
 8-NOV-2023 14:36:01.04       2052320  VMS_BOOTMGR.EFI
 8-NOV-2023 14:36:00.04       6220856  VMS_IMG.BMP
 8-NOV-2023 14:36:01.07        955648  VMS_KITBOOT.EFI
EFI$CP>

You can use the copy command to copy file from and to the EFI partition. Have a look at

Code: Select all

$ mc efi$cp help copy description

If the host OS is Linux and the type of the your VMS system disk is "raw", you should be able to create a loop device for the EFI partition and mount it.

[rjolbrich]

OK, I think I found it,

You need to use both <cr> AND <esc> !

After typing EXIT if I hit the first <esc> at about the same time as <cr>
and continue with more <cr>s I can get a new screen with
a manager menu. Selecting Boot Manager displays a menu
where I can choose the internal shell and eventually
get the shell prompt. The timing of the <cr> and <esc>s
is critical.

[sms]

Code: Select all

> You need to use both <cr> AND <esc> !

   I thought that 'put in an "EXIT" command' was clear enough, but
apparently not.  "Put in a command" includes hitting the <CR> key after
typing the printable characters.  (Until you hit <CR>, you haven't put
in the command.)

> [...] The timing of the <cr> and <esc>s is critical.

   I wouldn't say that.

   The key to understanding what to do may be realizing that a key like
<CR> or <ESC> sends a character, so you don't want to try to hit
multiple such keys simultaneously.  In this case, within a few seconds
should be soon enough.  ("Immediately" and "simultaneously" are spelled
differently for a reason.)

   Another class of keys includes <SHIFT>, <CTRL>, and so on.  Such
"shifting" keys alter the action of other, character-sending keys, and
need to be held down while some other (character-sending) key is
pressed.  But you still don't want to try to hit one of these keys
simultaneously with some other key.  (Press shifting key, press and
release character-sending key(s), release shifting key.)

   But see also: https://en.wikipedia.org/wiki/Key_rollover

   Everything's complicated.

[rjolbrich]

The timing is critical in my system!
If I wait for longer than a second the <ctrl> key is useless.
Under the bridge as they say......

Auto- boot : complete
Networking: complete and tested successfully with ping.
SSH: installed, but...

Can anyone point me to docs regarding PuTTY and SSH for OpenVMS.
I'm using 192.168.2.x for my DHCP connection and port 22 for SSH.
The connection is not refused but frozen.
This time I remembered to change the serial port setting to 22,
so I think I have that right. There seem to be quite a few settings
in PuTTy > Connections for SSH. Can anyone share their success?

[sms]

Code: Select all

> If I wait for longer than a second the <ctrl> key is useless.

   "the <ctrl> key"?  After an "EXIT<CR>" command, you should hit the
Escape key (sending some <ESC> characters).


> [...] This time I remembered to change the serial port setting to 22,
> so I think I have that right. [...]

   At least one of us is confused.  The VM (pseudo-)serial console
connection is independent of the SSH network service on the VMS system.

   If you had the console stuff working at port 2023. then I'd restore
that configuration.  Using port 22 for SSH (on your LAN) should be fine.

> Networking: complete and tested successfully with ping.

   "tested" how, exactly?  As usual, showing actual actions (commands)
with their actual results (behavior, error messages, ...) can be more
helpful than vague descriptions or interpretations.  "I'm happy" is not
as good as a detailed description of the network configuration.

> I'm using 192.168.2.x for my DHCP connection [...]

   What are the actual IP addresses (and so on) of all the relevant
network interfaces in this stuff?  That is, the Windows Ethernet
interface, and the emulated VMS-system Ethernet interface (and anything
else which might matter).

   Around here, for example, using VMware Fusion on a Mac, the console
stuff in the ".vmx" (configuration) file looks like:

serial0.fileType = "network"
serial0.fileName = "telnet://10.0.0.174:2023"
serial0.present = "TRUE"

where "10.0.0.174" is the address of the Mac's "Ethernet 2" interface. 
(I gave my virtual machine its own Ethernet interface.  "Ethernet 1" is
at "10.0.0.173", which is what the Mac uses.  If your VM shares the
network interface with Windows, then I'd expect you to use one address
which is shared by Windows and your VM (for its "serial" console).

   The VMS network interface is elsewhere:

V87 $ tcpip show interface
                                                           Packets
Interface   IP_Addr         Network mask          Receive          Send     MTU
 
 IE0        10.0.0.184      255.255.255.0         1313116        105350    1500
 LO0        127.0.0.1       255.0.0.0                 293           293    4096

   So, from an xterm (or Terminal) window on the Mac (or anyplace else),
SSH is done using the IP address of the IE0 interface on the virtual VMS
system:

proe% ssh -l system 10.0.0.184


      I'm V87.  Who are you?

[...]
V87 $ 


   The notable fact here is that the VM console connection is made using
Telnet to 10.0.0.174:2023 (per the VM config), and the SSH connection to
the VMS system is made to 10.0.0.184:22 (per the VMS network config).

> Can anyone point me to docs regarding PuTTY and SSH for OpenVMS.

   I suspect that the problem lies with your network configuration, not
with the way you're using PuTTY.

[rjolbrich]

Thanks for the help.

I fired up the Termius app on my Android tablet,
entered the terminals selection, and connected to
the desired IP address and port for VMS (192.168.2.xxx and 22).
No problem. I got the $ prompt and was happy.

Regarding the <ctrl> and <esc> confusion:
I apologize. I had a brain fart when composing the
post to this forum. I was exclusively using the <esc>
key, but somehow posted <ctrl>. You've got to
believe me sms!

Onto the transfer of the license file. Hopefully, that will be simple.

[sms]

Code: Select all

> [...] (192.168.2.xxx [...]

   There's no good reason to hide details of such private addresses
(unless there are people you don't trust who have access to your LAN).

> No problem. I got the $ prompt and was happy.

   Glad to hear it.  (But what could go wrong?)

> Onto the transfer of the license file. Hopefully, that will be simple.

   If SSH access works, then I'd expect SCP to do the job with little or
no additional trouble.  (And, if you're doing networky things like SSH,
then I'd also guess that you already registered enough PAKs manually to
allow that.)  In any case, if all the easy network file-transfer methods
did fail, there's also a host of messier, more complicated schemes which
ought to be explained elsewhere in these forums and/or the Web more
generally. 

> [...] You've got to believe me sms!

   I don't _have_ to, but a clerical error in the posting seemed to me
to be the most likely explanation.

[rjolbrich]

Hello,
I got my licenses to "install" and installed Webui.
That's the last of the tasks from the 3-part series on raymii.org.
I believe its time to end this thread. Thank you.
I might make a new thread on DECwindows, x86, and SSH.

[tomwade]

I found with Putty, you had to make sure you had the following settings:

Under Terminal (left pane) make sure both Local Echo and Local Line Editing are set to Force off.

[sodjan]

Note that this is not something unique for console work on an x86 VM VMS session.
It is the same when connection to an Alpha COM console port over some old terminal server.

This is due to that the console does not have a full telnet implementation and it will not
reply correctly (or as expected) when Putty tries to negotiate the settings. Putty then
falls back to "Local echo: ON", and that is not what you want.

When connecting to the TCP/Services telnet server, this works as expected and
"Local echo" is correctly negotiated to "OFF".

So here for the console, you need to force "Local echo: OFF".

And b.t.w., this is not unique for Putty, you need to do this setting in most terminal emulators.