Conference spezko::cluster

5243.0. "V7.1 fails to mount V6.2 served disk during boot" by TIMABS::FREPPEL (Mosquito ergo summm...) Thu Mar 06 1997 04:49

Hi all,

we've a Mixed Architecture 2 node NI based VMScluster for test purposes. 
Configuration information is appended at th end of this note.

Problem:
-------- 
- The VAX is up and running - fine.
- The Alpha boots and becomes a member of the cluster - fine.
- The Alpha's SYPAGSWPFILES.COM fails to mount a served (VAX) disk - not fine.

  o Command: 
    $ mount/noass/system $1$dka100: data_1 vol$data_1
    or
    $ mount/noass/cluster $1$dka100: data_1 vol$data_1 		!just to try

  o Message (after about 2 minutes):
    %MOUNT-F-DEVBUSY, mount or dismount in progress on device

  o Command: 
    $ mount/system $1$dka100: data_1 vol$data_1
    or
    $ mount/cluster $1$dka100: data_1 vol$data_1 		!just to try

  o Message (after about 2 minutes):
    %MOUNT-I-OPRQST, device _$1$DKA100: (RBAD93) is not available for mounting
    %MOUNT-F-BATCHNOOPR, no operator available to service batch request

- When the Alpha is booted without mounting $1$dka100: in SYPAGSWPFILES.COM,
  different sorts of MOUNT commands work fine, i.e.:
  o From the VAX:
    $ mount/cluster $1$dka100: data_1 vol$data_1 	! works fine
  o From the Alpha:
    $ mount/system $1$dka100: data_1 vol$data_1		! works fine

Questions:
----------
- What did I do wrong?
- Is there something wrong with the order the patches have been applied?
- Has anybody a similar configuration *without* the problem described above?
- What further information is needed to investigate the case?

As always: Thank you guys for your valuable support!
Raymond.
-------------------------configuration data------------------------------------
System Type 		OS		Patches in the order applied
-----------------------	---------------	-----------------------------
VAXstation 4000-90	OpenVMS V6.2	VAXDRIV04_070
VOTES=1					VAXMANA03_070
MSCP_LOAD=1				VAXMSCP01_070
MSCP_SERVE_ALL=2			VAXSHAD05_062
ALLOCLASS=1				VAXCOMPAT_062
					VAXCLUSIO01_062
			
DEC 3000 Model 400	OpenVMS V7.1	ALPMOUN01_071
VOTES=0					ALPSHAD01_071
MSCP_LOAD=1				ALPCPUC02_071
MSCP_SERVE_ALL=2
ALLOCLASS=2

Interconnect is NI only (ethernet).
Both systems have three local SCSI disks.
Both systems have their own system disk on one of the local SCSI disks.
    

    are you mounting the VAX disk within SYLOGICALS.COM? If yes, insert
    a 10 sec wait ($ wait 00:00:10) at the beginning of SYLOGICALS.COM
    
    This is a timing issue, because the CONFIGURE process is started just
    prior to executing the SYLOGICALS.COM and hasn't finished its
    initialization and is listening to incoming MSCP serving requests,
    hence does not see the device. Known problem, QARed twice etc. but
    there nothing is going to change.
    
    /cmos

    No, this is a problem with the MOUN01_071 kit.  This kit is now on
    hold and we are working to put out a MOUN02_071.
    
    The problem is, that early in the startup, there is no audit_server
    process to instantiate the ORB of the device.  A check that was added
    in MOUN01_071 incorrectly waits on the ORB instantiation even if the
    process has all privs, and eventually the DEVBUSY (for /NOASSIST) or
    operator retry messages (for /ASSIST) are displayed.
    
    Until MOUN02_071 is available, delete the MOUN01 MOUNTSHR.EXE (dated
    14-Feb-1997, I believe) and use the SSB V7.1.
    
    Cheers,
    jeff
    

    re .1:
    That's what I thought too at first glance, but after introducing a
    retry-loop I had to cancel this theory...
    
    re .2:
    Thanks. Will wait and see. Any ideas on dates? 
    
    Raymond.

    re: dates??  Very soon.  I know the kits are in the TIMA review 
    cycle now.
    
    Cheers,
    jeff