
PROBLEM: (89942) (PATCH ID: OSF520-105)
********
Enabler for Enterprise Volume Manager product.

PROBLEM: (90910, FR_G02528) (PATCH ID: OSF520-226)
********
This patch prevents a vold from core dumping when removing a disk from
rootdg using voldiskadm or voldg.
An example of the stack trace from an unstriped vold:

  10 raise(0x3ff801229d8, 0x100000006, 0x3ff801869b4, 0x0,
0x3ff801a9c44) [0x3ff
801869b0]
  11 abort(0x12007f66c, 0x17a4, 0x3ff80577ae0, 0x0, 0x600000000)
[0x3ff801a9c40]
  12 clsm_update_devs(dg = 0x140019d00, pending = 1)
["../../../../../../src/usr
/sbin/lsm/clsm/vold/clsmintf.c":3711, 0x12007f668]
  13 vold_dm_dis_da(dm = 0x1400ae400, clnt = 0x140018f80, remove = 1)
["../../..
/../../../src/usr/sbin/lsm/common/vold/da.c":1763, 0x120024288]
  14 req_dm_dis_da(clnt = 0x140018f80, req = 0x3ffc0641170)
["../../../../../../
src/usr/sbin/lsm/common/vold/da.c":1582, 0x120023d24]
More (n if no)?
  15 request_loop()
["../../../../../../src/usr/sbin/lsm/common/vold/request.c":
568, 0x120061d50]
  16 main(argc = 2, argv = 0x11fffc018)
["../../../../../../src/usr/sbin/lsm/com
mon/vold/main.c":708, 0x120050420]


PROBLEM: (90665, GB_G02495) (PATCH ID: OSF520-331)
********
This patch prevents a KMF (kernel memory fault) panic, in voldiskiostart(), 
when an I/O is attempted on an lsm device that is not accessible.
A typical stack trace follows:

     14 panic         
     15 trap         
     16 _XentMM   
     17 voldiskiostart      
     18 volkiostart    
     19 spec_strategy       
     20 read_raw_page   
     21 get_raw_vd_attrs   
     22 bs_bfdmn_tbl_activate  
     23 bs_bfset_activate_int 
     24 bs_bfset_activate    
     25 advfs_mountfs        
     26 msfs_mount           
     27 cfs_do_pfs_mount 
     28 cfs_fo_handle_pfs_mounting 
     29 cfs_fo_handle_bid_accept 
     30 cfs_fo_thread


PROBLEM: (83901) (PATCH ID: OSF520-318)
********
This patch fixes a situation in which when a cluster member fails, mirrored
volumes are left in a state such that recovery is always necessary when members
boot, even if no additional recovery should be necessary.
The problem is that without this fix a node booting does not clear its own
recovery flags after recovery has completed.  This results in volumes being
recovered at every node boot, even if the volume was never marked dirty on
the node being booted.


PROBLEM: (86483, 92796, 90530, 91558,
          92215, 92229) (PATCH ID: OSF520-447)
********
PROBLEM: Cannot create new diskgroups when vold is in noloadbalance mode.
 LSM appears to have a problem creating diskgroups when vold is in 
 "noloadbalance" mode.

 # volsetup dsk2 dsk3
 Checking for an existing LSM configuration

 Initialize vold and the root disk group: 
 Add disk dsk2 to the root disk group as dsk2:
 Addition of disk dsk2 as dsk2 succeeded.
 Add disk dsk3 to the root disk group as dsk3:
 Addition of disk dsk3 as dsk3 succeeded.
 Initialization of vold and the root disk group was successful.
 # vold -k -r reset -d ; voldctl stop
 # vold -x noloadbalance
 # voldisksetup -i dsk4
 # voldg init tstdg dsk4
 lsm:voldg: ERROR: Disk group tstdg: cannot create: 
 Disk group has no valid configuration copies

 Problem appears to be that NOLOADBALANCE code disables config/log allocation.  
 This needs to be special cased to allow for DG creation.


PROBLEM: LSM does not work correctly with third-party disks.

 # ls /dev/qb
 qa15a   qa15c   qa15e   qa15g   rqa15a  rqa15c  rqa15e  rqa15g  temp
 qa15b   qa15d   qa15f   qa15h   rqa15b  rqa15d  rqa15f  rqa15h
 # voldiskadd qa15

   No matching disks were returned.
 # disklabel -rwn /dev/qb/rqa15c
 # disklabel -r /dev/qb/rqa15c
 # /dev/qb/rqa15c:
 type: unknown
 disk: qd
 label: 
 flags:
 bytes/sector: 512
 sectors/track: 64
 tracks/cylinder: 256
 sectors/cylinder: 16384
 cylinders: 128
 sectors/unit: 2097152
 rpm: 3600
 interleave: 1
 trackskew: 0
 cylinderskew: 0
 headswitch: 0           # milliseconds
 track-to-track seek: 0  # milliseconds
 drivedata: 0 

 8 partitions:
  .
  .
  .
 # voldiskadd qa15
 No matching disks were returned.

PROBLEM: Cluster nodes can panic during boot trying to enable a non-existent
         klog object.
   
   Node 1:
   ______
   malloc: zero-size request from: ffffffff0008ea8c

            trap: invalid memory read access from kernel mode

                faulting virtual address:     0xfffffe04fe417f30
                pc of faulting instruction:   0xffffffff00042ef0
                ra contents at time of fault: 0xffffffff00042ef0
                sp contents at time of fault: 0xfffffe072bfef800

            panic (cpu 0): kernel memory fault

    Node 2:
    ______
            ics_mct: Node 1 is now down
            clsm_sync_peer_disks: failure sending sync data
            clsm: sync dumpDisks() failed!
            clsm: failed to sync peer

PROBLEM: Vold can dump core if an old configuration database exists on a disk.

PROBLEM: When cluster_root is under lsm control, minimal information is
         available prior to cluster root being mounted.  Error messages were 
         being printed for devices which are under lsm control, but not part 
         of rootdg.

PROBLEM: It is possible on a large configuration for lsm to start before the
         kernel to kernel sync has completed.  This is very bad as it can cause
         panics, proposal collisions, and other unexpected behavior.  The fix 
         blocks LSM from starting in user mode until the sync has been 
         completed, or an attempt that failed due to a lack of peer 
         configurations that were capable of syncing had also completed.


PROBLEM: (90741, 90746, 90759, 90809,
          90830, 90875, 91002, 91353, 91497,
          92735, 92870, 93570, 91688, 92773) (PATCH ID: OSF520-542)
********
PROBLEM: Vold autoconfiguration problem in a cluster
If LSM discovers new LSM disks, each cluster member will create a 
separate record for each disk, resulting in multiple records for the 
same disk.   The new disks are discovered via the "voldctl enable" 
command.

If an LSM disk is cloned in hardware, for example, and made available 
to Tru64 UNIX, and then to LSM by running the "voldctl enable" command, 
the following output will appear, assuming dsk10 is a new disk and 
this is a 3-node cluster.

# voldctl enable
# voldisk list
DEVICE       TYPE      DISK         GROUP        STATUS
dsk0         sliced    -            -            unknown
dsk1         sliced    -            -            unknown
dsk2         sliced    dsk2         rootdg       online
dsk3         sliced    -            -            unknown
dsk4         sliced    -            -            unknown
dsk5         sliced    -            -            unknown
dsk6         sliced    -            -            unknown
dsk7         sliced    -            -            unknown
dsk8         sliced    dsk8         dg1          online
dsk9         sliced    dsk9         dg1          online
dsk10        sliced    -  	    -            online
dsk10        sliced    -            -            online
dsk10        sliced    -            -            online

The autoconfiguration functionality in vold was not being distributed 
properly.
With this fix, newly discovered disks will be treated as a configuration 
change and other cluster members will then get up to date, not treat the 
disk as newly discovered even if another member has already found it.

PROBLEM:  Loss of LSM volume special device files after a "voldctl enable" 
call

The "voldctl enable" command was not being distributed properly in a 
cluster such that newly discovered LSM volumes could be ignored by other 
cluster members and their corresponding special devices files could be 
removed.  With this fix, all disk groups should be up to date before 
processing a "voldctl enable" call, thus accounting for newly discovered 
volumes.

PROBLEM:  volsave problem saving LSM disk flags

The volsave command was not saving the "reserved" or "spare" LSM disk flags,
meaning they could not be restored automatically.    

With this fix, volsave will save the "reserved" and "spare" disk flags 
if appropriate.   The volrestore command will restore them if appropriate.

As a result, the volclonedg command was updated to take advantage of this
new functionality, so if the parent disk group has these flags set on any
of its disks, the clone disk group will as well.   Note that this 
functionality is necessary to ensure the disk group clone has the same 
configuration as its parent.

PROBLEM: cannot run volsave from one cluster member and volrestore from 
another

If the volsave command is run from one cluster member, and then volrestore 
is run from another, the following volrestore error will occur.

# volrestore

  LSM configuration was saved on host tender.zk3.dec.com
         Use -f option to override this warning and 
         restore configuration on host track.zk3.dec.com

The volsave and volrestore commands were using local host information
in a cluster, rather than clusterwide information.   
With this fix, they will use the information in the /etc/vol/volboot 
file, not the local hostname, so if in a cluster, the cluster alias 
will be used.

PROBLEM:  volsave command not displaying variables when I18N turned on

If i18n is turned on, meaning the message catalog is being used to output
messages, the volsave command is not displaying variables, as shown in the
following example.

# volsave

  LSM configuration being saved to 

  LSM Configuration saved successfully to 

The volsave command is not displaying the directory name.   With this 
fix, the variables are exported properly.    Therefore, commands such as
volclonedg, which parse the output of volsave, will be able to run 
properly.

PROBLEM:  The volclonedg command has an option, -r, that allows users 
to specify "no recovery" for mirored volumes.   If any plexes were 
detached from a volume in the parent disk group, they should be detached 
in the clone disk group to avoid data integrity issues.   This ensures 
future recovery of that volume uses the most up-to-date data plex.    
This fix checks the parent disk group for volumes with detached plexes 
and makes sure they are detached in the clone disk group.  

Volclonedg uses the volrestore command to get information about 
the parent disk group from it's associated volsave metadata.    This 
fix also makes sure the volrestore command is run minimally, thus 
keeping the time it will take to run volclonedg reasonable and avoid 
scalability issues.

PROBLEM:  The volclonedg command will not set up the disk group clone 
configuration properly if the disk clones were created on a different 
host or cluster.    The volclonedg command uses the volrestore command 
to restore the configuration.  With this fix, it uses the "-f" option 
to volrestore to ignore host or cluster name checks.   Without this fix, 
the volclonedg command will not be able to create the disk group clone 
configuration.

PROBLEM:  The volclonedg command does not work if any disks in the 
disk group to clone has a nopriv disk.  That is correct behavior.  
However, the command is also failing if ANY disk group has a nopriv 
disk, not just the disk group to clone.   This fix enables volclonedg 
to use the volsave metadata saved from the parent disk group to 
determine if it has any nopriv disks, thus using the appropriate LSM 
configuration information.


PROBLEM: (92566, 90844, ORNG-617, DK_G02609) (PATCH ID: OSF520-589)
********
This patch allows the proper synchronization of disk errors and failures
in a cluster under CLSM control.
Before the patch the command: "voldisk list" will not be consistent on
all nodes after a voldisk rm is executed on a failing or failed disk.
The output on the node where the disk was removed will remove it.
However all other nodes will still show the disk with 'error' as its
status.

On one of the nodes where the voldisk rm command was not executed:

dsk103       sliced    -            -            error
-            -         orange02     orange       removed was:dsk103

On node where voldisk rm was executed only the disk media information
was displayed, as expected.

-            -         orange02     orange       removed was:dsk103


PROBLEM: (88526, 88541, 88562, wc.sec.002.ssrt) (PATCH ID: OSF520-791)
********
A potential security vulnerability has been discovered, where under
certain circumstances, system integrity may be compromised. This may
be in the form of improper file access. HP has corrected this
potential vulnerability.


PROBLEM: (DSATM0D2R, 93380, HPAQ50CLP) (PATCH ID: OSF520-747)
********
This patch corrects performance issues on starting of Cluster Logical
Storage Manager with large configurations.


PROBLEM: (88488) (PATCH ID: OSF520-790)
********
A potential security vulnerability has been discovered, where under
certain circumstances, system integrity may be compromised. This may
be in the form of improper file access. HP has corrected this
potential vulnerability.


PROBLEM: (89390, HPAQK1D53, HPAQ51LNHH, TKT360311, DE_G04616, SE_G04994)
         (PATCH ID: OSF520-754)
********
This patch is to prevent vold from core dumping on booting with the
message:

   commit: not holding dg lock <diskgroup>
PROBLEM: (93135) (PATCH ID: OSF520-837)
********
This code change to the volreconfig command will prevent inconsistent
LSM volumes when the name of a volume is the same as that created by
a volencap of a disk partition.  An example would be to have as an
existing volume "vol-dsk2b", and to later conduct a "volencap dsk2b"
to encapsulate that partition, which creates a default name for the
volume of "vol-dsk2b".


PROBLEM: (95147, 95058) (PATCH ID: OSF520-843)
********
When using LSM's volclonedg command to clone a LSM disk group whose 
underlying disks have been snapped or cloned in hardware, a new disk group
is created.  If there was a filesystem on one of the LSM volumes in the
parent disk group, we now have a copy of that data.   When trying to mount
the filesystem on the new volume, the vold on another cluster member was
dumping core and the new disk group was deported. This only occurred when 
smsd was running. The problem is smsd queries cluster members for
information and may do so from each cluster member. If the cluster member
is out of date with respect to the LSM configuration, we may get LSM
configuration errors.

PROBLEM: (SSRT2275) (PATCH ID: OSF520-922)
********
This patch provides protection against a class of  potential security
vulnerabilities called buffer overflows. Buffer overflows are sometimes
exploited in an attempt to subvert the function of a privileged program
and possibly execute commands at the elevated privileges if the program
file has the setuid privilege. This patch allows a system administrator
to enable memory management protections that limit potential buffer
overflow vulnerabilities.

PROBLEM: (DE_G05778) (PATCH ID: OSF520-941)

This patch corrects an I/O performance issue seen when CLSM is
configured and one member of a cluster goes down unexpectedly.

PROBLEM: (95739, BCGMD29X1, BE_G06019) (PATCH ID: OSF520-1058)

This patch corrects an issue of a cluster node hanging on boot while
the other member recovers the cluster root file systems.

PROBLEM: (94351, 95504) (PATCH ID: OSF520-926)
********
Additional checks were included in the volencap command to insure
that cluster_root can not be encapsulated, and that swap partitions
cannot be placed into a non-rootdg diskgroup.  Encapsulation of these
can result in an unbootable system.

PROBLEM: (95635, 95970) (PATCH ID: OSF520-993)
********
A potential security vulnerability has been discovered, where under
certain circumstances, system integrity may be compromised.  This may be
in the form of improper file access.  HP has corrected this potential
vulnerability.

PROBLEM: (89621, 95897) (PATCH ID: OSF520-1087)
********
This change will allow volsave and volrestore to save nconfig/nlog policies for
diskgroups and restore them appropriately.  This fix also corrects awk errors
for invalid "quit" statements.

PROBLEM: (89300, BCGM70HRD) (PATCH ID: OSF520-165)
********
This patch corrects the problem with a mirrored LSM volume with dirty
region logging (DRL) enabled still doing a full resynchronization
during a recovery after an unclean shutdown.
This full resynchronization will only occur the first time and then DRL
will be properly enabled.  To determine if any current volumes will need
to have the DRL replaced to avoid this, execute the following command:

volprint -v -a

Check the field recover_checkpoint.  If this field is 0, then a
new DRL for the volume will need to be done if you wish to avoid this
full resynchronization.  NOTE:  Ignore RAID5 volumes
as this problem doesn't apply to them.

Example of creating a new DRL for the volume after the patch is applied
is:

# volplex -o force dis vol01-03
# voledit -r rm vol01-03
# volassist addlog vol01 dsk6
# volprint -av
 
The volume will now have the recover_checkpoint enabled.


PROBLEM: (90754) (PATCH ID: OSF520-1046)
********
The volassist command was previously unable to create a mirror of
an existing striped plex with a new plex with a specified
layout of CONCAT.  An attempt to create one would either have volassist
exit with an error (not enough space), or a new striped plex would be
created instead of the desired concatenated plex to mirror the existing
striped plex.


PROBLEM: (85978) (PATCH ID: OSF520-1225)
********
Code that inspected the disklabel for overlapping partitions
did not skip over null partitions as expected.


PROBLEM: (96192, SE_G06858) (PATCH ID: OSF520-1236)
********
This patch fixes issues with I/O failures seen on non rootdg
diskgroups.   One symptom is that the reimport of the diskgroup
may fail under certain conditions.  Another is that vold may core dump
when failing a non rootdg disk.
This patch also fixes a performance issue seen during plex detach
operations.


PROBLEM: (94676) (PATCH ID: OSF520-1230)
********
An invalid recovery magic number was clearing the map but not setting the
BADLOGS bit, this results in NO resync when a volume resync may be required.


PROBLEM: (96408) (PATCH ID: OSF520-1224)
********
Modified the volassist command to correctly output a warning
message for its grow and shrink operations.    The "-f"
option must be used to grow or shrink a LSM volume, signifying
that an associated filesystem may not be able to take
advantage of the change.    If the "-f" option is not used,
a warning message appears.   That message included extraneous
output and was not included in LSM's message catalog for
internationalization support.


PROBLEM: (89516) (PATCH ID: OSF520-1208)
********
Corrected an internationalization problem affecting LSM's voldiskadm.
An instructional message output when choosing voldiskadm's list option
was incorrect.   It had not been entered properly in the message catalog.



