[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::decnis

Title: DEC Network Integration Server (DECNIS)
Notice:Please read note 1 to use this conference effectively
Moderator:MARVIN::WELCH
Created:Wed Sep 18 1991
Last Modified:Thu Jun 05 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:3660
Total number of notes:15082

3525.0. "Problems booting via MOP" by ALCALA::FLOPEZ (Where is the magic formula...?) Wed Jan 29 1997 10:16

    Trying to load a DECnis 600 via MOP we are experimenting the following:
    
    The DECnis displays the number 4, later the number 2 and this sequence
    is repeated for long time.
    
    Any suggestion about?
    
    Fernando L�pez
    NSIS-Spain
    
T.RTitleUserPersonal
Name
DateLines
3525.1The NIS can not find the Load HostMARVIN::MILLSWed Jan 29 1997 10:2925
    
>    The DECnis displays the number 4, later the number 2 and this sequence
>    is repeated for long time.
 
The number 4 indicates the the DECNIS is sending out a broadcast to any
Load hosts on all physical connections that it wishes to be serviced 
for a load.

When the DECNIS receives no reply via MOP, it will start to broadcast
BOOTP requests on all physical circuits for load.

If this fails the cycle repeats back to MOP.   


My guess is that you have not configured the load host, or the load 
host is unreachable.

How is the load host connected to the DECNIS?



Grant.
    

3525.2ALCALA::FLOPEZWhere is the magic formula...?Wed Jan 29 1997 12:5411
    Grant,
    
    Thanks a lot for your quick response, but the load host is configured
    and also the MOP circuit.
    
    The behaviour described in .0 happens when I execute the command:
    ncl load mop client <machinename>
    
    I could add that when I plug out the DECnis cable, the DECnis ask for
    loading and finishes this operation.
    
3525.32 = LOADING, 4 = STARTINGMARVIN::HARTTony Hart, InterNetworking Prod. Eng. GroupThu Jan 30 1997 03:2914
Actually 2 = LOADING and 4 = STARTING.

So it looks like your DECNIS is loading the image and then starting it OK but
for some reason the image fails to come up.  It maybe that the flash write
fails or that the image is corrupt.   Have you loaded this DECNIS before ?
Does BOOTP loading work ?  Can you try a different image or a different load
host ?

If you have an MPC-II then attach a terminal to the console port and see
what messages are output.  If you have an MPC-I then there is an *unsupported*
console thats hidden behind a piece of sticky plastic on the front bezel, as a
last resort you could connect a terminal to it.

Tony
3525.4ALCALA::FLOPEZWhere is the magic formula...?Thu Jan 30 1997 03:3912
    Thanks again,
    
    >>Have you loaded this DECNIS before ?
    Yes, in fact there are two DECnis with the same symptoms.
    >>Does BOOTP loading work ?
    I have never try to load by BOOTP.
    
    About the terminal console, the two DECnis are in South-America while I
    am working in Spain. Anyway I will contact with support people there.
    
    
    Fernando L�pez
3525.5The image you are loading must be brokenMARVIN::RIGBYNo such thing as an alpha betaThu Jan 30 1997 04:1610
the NCL command load mop client <machinename> should cause the DECNIS to load
from the machine on which the command is issued. Is that where the DECNIS
actually loads from when the operation is successful? (Look at HARDWARE LOADED
FILE IMAGE ALL).

As Tony says it would seem that the image that is being loaded is invalid in
some way. What does the LAST REBOOT REASON show on the first time a successful
load completes?

John
3525.6ALCALA::FLOPEZWhere is the magic formula...?Thu Jan 30 1997 09:2375
    .5 The server psrdf1 is providing the file and this node is from I
    executed the load mop client srdfp1 command.
    
    When I try the command: SH HARDWARE LOADED FILE IMAGE ALL I receive
    the answer:
    
    Node srdfp1 Hardware Loaded File Image
    AT 1997-01-30-07:14:01.398-05:00I-----
    
    Identifiers
    
        Name                              = Image
    
    Status
    
        Load Method                       = MOP V4
        Communications Port               = L602-3-0
        Line Protocol                     = CSMA/CD
        MOP Server Address                = aa-00-04-00-91-fd
    (LOCAL:.psrdf1)
        MOP Software ID                   = ""
        MOP Phase IV Client Name          = <Default value>
        MOP Phase IV Client Address       = 0.0
        MOP Phase IV Host Name            = <Default value>
        MOP Phase IV Host Address         = 0.0
        Client IP Address                 = 0.0.0.0
        BOOTP Server IP Address           = 0.0.0.0
        TFTP Server IP Address            = 0.0.0.0
        Gateway IP Address                = 0.0.0.0
        File Name                         =
        BOOTP Vendor Information          = ''H
        Load Started                      =
    1997-01-29-08:26:15.788-05:00I-----
        Load Completed                    =
    1997-01-29-08:26:15.788-05:00I-----
    
    Characteristics
    
        File Type                         = System Image
    
    
    
    and with: SH LAST REBOOT REASON
    
    Node srdfp1
    AT 1997-01-30-07:15:12.788-05:00I-----
    
    Status
    
        Last Reboot Reason                = Flash updated successfully
    
    
    
    Only in case it is a valid information, I could see with 
    the SH IMPLEMENTATION command is:
    
    Node srdfp1
    AT 1997-01-30-07:15:50.748-05:00I-----
    
    Characteristics
    
        Implementation                    =
            {
                [
                    Type ........  = DEC Network Integration Server 600 ,
                    Implementation = "V3.1.7"
                ]
            }
    
    
    Thanks,
    
    Fernando
    
    
3525.7unusual combination of symptomsMARVIN::RIGBYNo such thing as an alpha betaThu Jan 30 1997 11:4216
I don't understand what can be causing this.

The image file output clearly shows that the image was successfully loaded from
psrdf1 using MOP V4 for the execution that resulted in an active system. The
fact that the reboot reason is Flash updated successfully indicates that the
flash had to be written with the image that was loaded via MOP (otherwise it
would say MOP Trigger).

This leaves two possibilities:

1) the flash had been programmed with somthing else on the last load
2) the flash is broken and, although it verifies immediately it degrades such
    that it needs reprogramming on the next load.


The console output would help resolve this.
3525.8ALCALA::FLOPEZWhere is the magic formula...?Fri Jan 31 1997 11:555
    Thanks all,
    
    I will try to confirm that the local field service traces the problem
    
    Fernando