[Info-vax] OpenVMS Alpha V8.4 install from InfoServer-1000

Fri Oct 26 16:29:27 EDT 2012

In article <508aa73c$0$63192$815e3792 at news.qwest.net>, George Cornelius <cornelius at eisner.decus.org> writes:
>  VAXman-  @SendSpamHere.ORG wrote:
>
>> vaxman at Satellite:~$ cu -s 9600 -l /dev/KeySpan
>> Connected.
>> *** keyboard not plugged in...
>> 1024 Meg of system memory
>> probing hose 0, PCI
>> probing PCI-to-ISA bridge, bus 1
>> bus 0, slot 9 -- ewa -- DE500-BA Network Controller
>> bus 0, slot 11 -- ewb -- DE500-BA Network Controller
>> bus 0, slot 13 -- dqa -- Acer Labs M1543C IDE
>> bus 0, slot 13 -- dqb -- Acer Labs M1543C IDE
>> bus 0, slot 17 -- pka -- NCR 53C810
>> initializing GCT/FRU at 3ff40000
>> 
>> ewa0: link up : Negotiated  100BaseTX: full duplex
>> ......
>> ewb0: link failed : Using  100BaseTX: full duplex
>> Testing the System
>> Testing the Disks (read only)
>> Testing ew* devices.
>> System Temperature is 46 degrees C
>> 
>> AlphaServer DS10L 466 MHz Console V7.3-1, Feb 27 2007 13:17:58
>> 
>> CPU 0 booting
>> 
>> (boot ewa0.0.0.9.0 -file apb_084 -flags 0,0)
>> 
>> Trying MOP boot.
>> ...........
>> 
>> Network load complete.
>> 425 Packets, Max pkt size 1492, Retries 0
>> Loaded by: aa-00-04-00-fc-07
>> bootstrap code read in
>> base = 200000, image_start = 0, image_bytes = 99c00(629760)
>> initializing HWRPB at 2000
>> initializing page table at 3ff2a000
>> initializing machine state
>> setting affinity to the primary CPU
>> jumping to bootstrap code
>> %EWA-I-BOOTDRIVER, Console setting is Auto-Negotiate
>> %EWA-I-BOOTDRIVER, Found onboard DE500
>> %EWA-I-BOOTDRIVER, Starting internal auto-negotiation (DE500-BA, onboard
>> DE500)
>> %EWA-I-BOOTDRIVER, Internal auto-negotiation selected 100BaseTX FDX
>
>Interesting. So you have to load an apb image separately.  And, as
>you mentioned, I guess, it's from a VMS host - with a 1.xxxx DECnet
>IV address.

Save that the the Alpha is running DECnet Phase V but MOP is loaded on it.
I used the Alpha because it already is/was a MOP load server.

>So I'll assume you could have offered that service from the Infoserver
>as well but already had it on a host, and that the reason for the apb
>image is that it understands the DADn devices.
>
>[I don't believe I have updated Alpha VMS, at least in this century,
>from an Infoserver, so forgive me if I'm trying to get up to speed.]
>
>>  Network Initial System Load Function
>>  Version 1.2
>> 
>>   FUNCTION        FUNCTION
>>     ID
>>     1     -       Display Menu
>>     2     -       Help
>>     3     -       Choose Service
>>     4     -       Select Options
>>     5     -       Stop
>> 
>>  Enter a function ID value: 3
>> 
>> 
>>   OPTION          OPTION
>>     ID
>>     1     -       Find Services
>>     2     -       Enter known Service Name
>> 
>>  Enter an Option ID value: 1
>> 
>> 
>>  Working
>> 
>>  Servers found::    1
>> 
>>  Services offered by node INFOSERVER_1K_2, Address: 00-00-F8-43-6B-39
>> #   1  ALPHA084
>> #   2  IS1$DK0
>> #   3  IS1$DK1
>> #   4  IS1$DK2
>> #   5  IS1$DK3
>> #   6  IS1$DK7
>> #   7  TMESIS
>
>Service ALPHA084 is apparently the ALPHA084 CD loaded into an
>Infoserver drive?
>
>>  Enter a Service Number: 1
>> %EWA-I-BOOTDRIVER, Starting internal auto-negotiation (DE500-BA, onboard DE500)
>> %EWA-I-BOOTDRIVER, Internal auto-negotiation selected 100BaseTX FDX
>> %EWA-I-BOOTDRIVER, Starting internal auto-negotiation (DE500-BA, onboard DE500)
>> %EWA-I-BOOTDRIVER, Internal auto-negotiation selected 100BaseTX FDX
>> %EWA-I-BOOTDRIVER, Starting internal auto-negotiation (DE500-BA, onboard DE500)
>> %EWA-I-BOOTDRIVER, Internal auto-negotiation selected 100BaseTX FDX
>> 
>> 
>>     OpenVMS (TM) Alpha Operating System, Version V8.4
>>     ï¿½ Copyright 1976-2010 Hewlett-Packard Development Company, L.P.
>
>OK, so a VMS image has been loaded by the APB. Its job now, I suppose, is to
>connect to the CDROM again and start bringing in files (executive modules?).
>
>> %EWA-I-BOOTDRIVER, Starting internal auto-negotiation (DE500-BA, onboard DE500)
>> %EWA-I-BOOTDRIVER, Internal auto-negotiation selected 100BaseTX FDX
>
>OK. Doesn't say which ew device (assuming %EWA is generic), and no indication
>it found the Infoserver.  But it doesn't say it failed to get a path.
>
>> %EXECINIT-F-LOADERR, error loading SYS$UTC_SERVICES, status = 001380F4
>
>No indication that anything else has been accessed on the DAD device up
>to now, but I would be quite surprised if UTC Services is the first thing
>that gets loaded (although I suppose you will be asked early on to set
>the time). But I'm guessing it found various files before it got to the
>fatal error condition.

Quite a bit is loaded before SYS$UTC_SERVICES.

>Brian, there's not much point in me trying to give you advice on
>something like this, since you're a million miles ahead of me on
>understanding the boot process. But, just for completeness, I'll
>mention some things that come to mind:
>
> (a) setting the ewa device (and switch port) to static FastFD mode
>
> (b) turning on verbose output if there's a way to do that
>
> (c) checking to see if there's a conversational mode option,
>      like -fl 0,1 . Unfortunately that switch would probably
>      go to the apb_084 image and might not affect the loading
>      at the next level.
>
> (d) if the -fl x,y does work, trying x > 0 .  As I recall
>      there are multiple system roots on those CD's and if SYS0
>      has a problem maybe another, like SYS1, is OK.
>
> (e) I assume you have tried the same thing with an earlier
>     distribution, say 8.3, as a comparison?
>
> (f) since you mentioned trying to serve the CD from a host-
>     based Infoserver, I assume you made sure that was no
>     longer being offered when you booted to the 1000?
>
> (g) trying a different apb - if that is an option - preferably
>     one taken from the distribution CD
>
> (h) trying a different copy of the CD in case it is encountering
>     a read failure
>
> (i) Sniffing the traffic exchanged between the 10L and the
>     Infoserver in lieu of more direct monitoring of the boot
>     process.
>
>George

Strangely, the OpenVMS V8.3 media will boot the DS10L with all of the same
incantations as above.  I'm thinking that there may be files which are NOT
contiguous and many must be in order to boot although this seems not to be
necessary with the files being served.  Anyway, I've been derailed with an-
other issue, so I've put this whole update on the back burner for now.  I
do believe it's an issue in the mastering of the OpenVMS Alpha V8.4 media
but no time now to figure out just what that may be.  I may have to spend
some time Wireshark collecting the boot conversation to get to the bottom
of the issue. 

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

Well I speak to machines with the voice of humanity.