Upgrading firmware on an A1000 through the RM6 GUI fails with the 
        following message, although it appears that nothing is accessing the 
        A1000.
      
        "I/O going to controller or there are mounted file systems"
      
                                 

        If Solstice DiskSuite[TM] (SDS) or Solstice Logical Volume Manager is 
        being used to manage any of the LUNs on the array, follow procedure C, 
        below.
      

        If Veritas Volume Manager (VxVM) is being used to manage any of the 
        LUNs on the array, there are two procedures that can workaround this 
        problem. Follow procedure B (below), and if that does not help, follow 
        procedure A.
      
        Procedure A:
      
        1. Unmount all filesystems made from LUNs on the A1000.
      
        2. Deport the disk group(s) where LUNs are located.
      
        3. Run "vxdiskadm" and run option #11 for each LUN in the disk 
        group(s).
      
        4. Run through the firmware upgrade as documented.
      
        5. Run "vxdiskadm" and run option #10 for each LUN.
      
        6. Import the disk group(s).
      
        7. Start volumes manually using "vxvol -g <disk_group> startall".
     

        Procedure B:
     
        1. Unmount all filesystems made from LUNs on the A1000.
      
        2. Deport the disk group(s) where LUNs are located.
      
        3. Run "vxdisk rm c#t#d#s2" on all LUNs in the deported disk group(s).

        4. Run "vxdctl stop" to kill the 'vxconfigd' daemon. This will not 
        affect other running volumes.
     
        5. Run through the firmware upgrade as documented.
     
        6. Run "vxconfigd". This will restart the vxconfigd and pull back the 
        LUNs that were removed above.
     
        7. Import the disk group(s).
      
        8. Start volumes manually using "vxvol -g <disk_group> startall".

        Procedure C:
      
        1. Unmount all filesystems made from LUNs on the A1000.
      
        2. Check to see if any metadevices are using any of the LUNS in the 
        array. If any metadevice(s) is using any of the LUNs, the 
        metadevice(s) must be removed. You can save the definition of the 
        metadevice in the "md.tab" file. For example, if you determine that 
        "d3" contains LUNS on the array, save the configuration of "d3" into 
        the "md.tab" file:
      
        # metastat -p d3 >> <path>/md.tab
      
        and then remove the metadevice:
      
        # metaclear -r d3
      
        Do this for all metadevices containing LUNS on the array.
      
        NOTE: The "md.tab" file exists either in the /etc/opt/SUNWmd or 
        /etc/lvm directory, depending on the version of DiskSuite you are 
        running.
      
        3. Check to see if any database replicas are on any of the LUNs in the 
        array. To list all replicas, run "metadb". Use the "metadb -d" command 
        to delete any replicas on any of the LUNS. For example:
      
        # metadb -d c3t1d0s7 c3t2d0s7
      
        4. Run through the firmware upgrade as documented.
      
        5. Recreate the replicas you deleted above using the "metadb -a" 
        command. For example:
      
        # metadb -a c3t1d0s7 c3t2d0s7
     
        6. Recreate the metadevices you deleted above using the 'metainit' 
        command. The definitions which you stored in the 'md.tab' file will be 
        read automatically. Simply enter "metainit d###" for each metadevice 
        to be recreated.
      
  -------------------------------------------------------------------------------
        
        Alternatives Ways to Stop I/O to the controller.      

        Because they have only a single controller, A1000 arrays tend to be 
        more difficult to perform firmware upgrades on than A3500s or A3000s. 
        In particular, it is frequently harder to stop I/O streams to the 
        controller, especially if Veritas Volume Manager exists on the host as 
        well. If RM6 LUNs are under VxVM control, the latter tends to spawn 
        processes which periodically poll the devices it knows about, in 
        effect creating a permanent bond to the array.
      

        Listed below are several ways to try and halt I/O to an A1000. Sets of 
        steps should be tried sequentially.
      

        **NOTE**: This document also assumes an unencapsulated boot disk is 
        present, i.e. that the system comes up on partitions (/dev/dsk) versus 
        VxVM (/dev/vx) devices. If unsure, obtain a vxprint -ht or 
        check the /etc/vfstab; you may also look for the file 
        /etc/vx/reconfig.d/state.d/root-done.
      

       I:

    1. Try and unmount any UFS/VXFS filesystems.
                        
    2. Use the RM6 GUI to try and upgrade the firmware.
 
        II:
        
    1. Deport all VxVM diskgroups that are built on any A1000 LUNs.
        
    2. Use the RM6 GUI to try and upgrade the firmware.
        
          **NOTE**: If rootdg contains volumes that are built on RM6 LUNs, 
        you will not be able to stop I/O in this way as this diskgroup cannot 
        be deported.
      

        III:
                            
          Stop and/or kill all VxVM processes. This can be achieved by doing a
          'ps -eaf |grep vx', or by issuing an 'fuser' command on the device(s)
          in question, then viewing and killing the processes as needed.
        
          Use the RM6 GUI to try and upgrade the firmware.
       
        IV:
       
          If there are no vx processes and an 'fuser' command returns nothing, 
          touch /etc/vx/reconfig.d/state.d/install-db and then reboot; 
          this file will prevent VxVM from starting up at all.
        
          Use the RM6 GUI to try and upgrade firmware.
        
        V:      
     
          If for whatever reason touching install-db does not work the way it 
          should, try moving the VxVM startup scripts (located in /etc/rcS.d 
          and /etc/rc2.d) out of the way. An effective method for achieving 
          this and not losing track of where they are is to simply rename them 
          with a lowercase versus uppercase 'S': S25vxvm-sysboot would 
          become s25vxvm-sysboot, S35vxvm-startup1 would become s35vxvm-startup1 
          and so forth. For a complete list, do an 'ls | grep vx'in the rcS and 
          rc2 directories.
       
          Use the RM6 GUI to try and upgrade firmware.
        
        VI:      
      
          If all attempts fail, use the 'fwutil' command to upgrade 
          firmware outside of the GUI. Do this from single-user mode if 
          possible, and make sure to do bootware before appware:
        
	  Update Bootware for the universal controller FRU: # fwutil 
          /usr/lib/osa/fw/03xxxxxx.bwd cxtxdxs0

          Update Appware for the universal controller FRU: # fwutil 
          /usr/lib/osa/fw/03xxxxxx.apd cxtxdxs0
        
          
      
                     

                
                                                                   
      R.B. Khleif, Storage TSE