0   Clustering, Performance, Conversational Boot?   The Question is:    G I have a DS10 machine that I removed from a cluster to check standalone M  performance. The system password was not valid so I tried to change it using L  the uafalt method and then the "spawn" method in the web based FAQ. On both  occasions I had a graphics ter N minal in use and so neither method worked. The "spawn" method seemed to freezeK  the system. I had to power cycle the system many times before I realised I M  needed a serial console. I eventually changed it using the uafalt method but   confirmed that the "spaw , n" method worked too (using serial console).   N When I reset vaxcluster to 2 (or 1 which was its original setting) it fails toK  complete the boot with an error - %sysinit-e-error mounting system device, M  status=0072832C. This error occurs just after is says "Now a cluster member"   and is followed by a BUG 8 CHECK - code = 0000036C: PROCGONE, Process not in system+ Crash CPU:00  Primary CPU:00  Active CPUs:1  Current Process = sysinit  Current PSB ID = 1 Image Name = sysinit.exe etc    
 Any thoughts?     Cheers    Kevin   The Answer is :   )   The two common errors in this case are:      --    <  DIFVOLMNT,  different volume already mounted on this device   $   Facility:     MOUNT, Mount Utility   I   Explanation:  Previously, a different volume was mounted on this device J                 on another node in the cluster. The device may be in mountJ                 verification on the other node. Either the original volumeI                 was removed from the device and replaced with another, or :                 its volume identification was overwritten.   G   User Action:  Restore the previously mounted volume to the device. If K                 this is not possible, dismount the device on all nodes that J                 currently have it mounted. Then retry the mount operation.     --    9  VOLALRMNT,  another volume of same label already mounted    $   Facility:     MOUNT, Mount Utility   D   Explanation:  This message can occur under either of the following                 conditions:    H                 o A request was made to mount a volume that has the sameG                   label as a volume already mounted. Shared, group, and H                   system volumes that are mounted concurrently must have'                   unique volume labels.    F                 o A request was made to mount a volume that is already3                   mounted /GROUP for another group.       B   User Action:  Take one of the following actions, as appropriate:   M                 o Mount the volume as a private volume if it does not have to                    be shared.   K                 o Mount the volume as a private volume and change its label K                   using the DCL command SET VOLUME/LABEL. Then dismount the =                   volume and mount it as originally intended.    H                 o Wait until the conflicting volume has been dismounted.   M                 o If the volume is already mounted to another group, wait for >                   the volume to be dismounted from that group.   K                 You can determine the status and ownership of a conflicting J                 volume by using the DCL command SHOW DEVICES/FULL/MOUNTED.         --   F   When booting standalone, you are in effect partitioning the cluster,I   and will want to ensure correct values for VAXCLUSTER, NISCS_LOAD_PEA0, G   VOTES and EXPECTED_VOTES, as cited in the OpenVMS FAQ.  Do ensure you F   reset the local copies of both VAXCLUSTER and NISCS_LOAD_PEA0 on theG   host being removed from the cluster, as cited in the OpenVMS FAQ.  Do D   also ensure that the VOTES and EXPECTED_VOTES are set correctly onF   all nodes in the cluster, to avoid any potential incidence of severe   data corruptions.    G   In the typical case, an OpenVMS system will update the volume Storage D   Control Block (SCB) with the current mount time whenever it mountsG   a disk volume.  In the case of a volume that is shared with a cluster F   and particularly that is mounted locally on a partitioned node, thisG   SCB update will not be reflected in the SCB of a volume accessable to    any existing cluster members.    G   When the host system is eventually returned to the cluster, the other G   existing cluster members of the cluster can and often will still have H   an expectation around the mount time, and will refuse to allow anotherH   volume to be mounted with a conflicting value, producing the DIFVOLMNT   error.   G   If the volume is entirely local to the standalone host, then the disk E   data is probably still consistent as a correctly-configured cluster F   could not have written to the disk.  However, if the volume remainedJ   available to the other cluster members, then you may well have corruptedG   the volume, and will likely have to restore its contents from BACKUP.    H   To reboot this configuration, you will have to ensure all instances of<   this volume have been dismounted from all cluster members.   0  Answer written or last revised on  16-JUN-2004 