Patch Name: PHCO_28378 Patch Description: s700_800 11.11 VxVM B.03.20.1 Command Cumulative Patch 02 Creation Date: 03/09/16 Post Date: 03/10/17 Hardware Platforms - OS Releases: s700: 11.11 s800: 11.11 Products: HP VxVM B.03.20.1 Filesets: HPvxvm.VXVM-RUN,fr=B.03.20.1,fa=HP-UX_B.11.11_32/64,v=HP HPvxvm.VXVM-ENG-A-MAN,fr=B.03.20.1,fa=HP-UX_B.11.11_32/64,v=HP Automatic Reboot?: No Status: General Release Critical: Yes PHCO_28378: ABORT MEMORY_LEAK PANIC CORRUPTION HANG PHCO_27724: ABORT PHCO_26420: ABORT PHCO_27977: ABORT PHCO_25837: ABORT Category Tags: defect_repair general_release critical panic halts_system corruption memory_leak Path Name: /hp-ux_patches/s700_800/11.X/PHCO_28378 Symptoms: PHCO_28378: ( SR:8606310931 CR:JAGae73789 ) Panic and file system corruption after doing "rm *" during a raid5 sd move operation. ( SR:8606282335 CR:JAGae46287 ) Replacement disk may have a different publen created by vold. ( SR:8606310939 CR:JAGae73797 ) Possibility of stack corruption in vxconfigd is due to a bug in make_deinfo_list(). ( SR:8606310938 CR:JAGae73796 ) Memory leak exists in vxconfigd priv_scan() during diskgroup import if an LVM disk is present. ( SR:8606310936 CR:JAGae73794 ) Memory leak exists in vxconfigd:vold_thread_create(). ( SR:8606310933 CR:JAGae73791 ) Mirrored volume is not disabled when it lost the last ACTIVE plex during resync. ( SR:8606310934 CR:JAGae73792 ) vxpfto bug in Usage ( SR:8606310935 CR:JAGae73793 ) Memory leaks exist in vxconfigd (using MLScanner). ( SR:8606310432 CR:JAGae73304) HPASL install:Impossible to build static vxconfigd - various problems ( SR:8606302684 CR:JAGae66043 ) (1) SRL failure may result in inconsistent data. (2) Replication hung while running autosync_rlinks test case. ( SR:8606272213 CR:JAGae36353 ) If there are duplicate diskid and if there is no match for the vendor selection criteria, the first da found in the stack, was always returned. This would be a problem if there are duplicate disk ids, since a wrong disk can be made online. ( SR:8606302668 CR:JAGae66027 ) Wrong Enclosure Name assigned to VA7X00 arrays. During QA testing of the VA7X00 array, HP discovered that the enclosure name is gotten from the wrong SCSI buffer field. ( SR:8606302676 CR:JAGae66035 ) Plexes with SNAPDONE state are not detached on i/o error. Plexes in SNAPDONE state do not get detached on write errors. This can be re-produced by as follows: #> vxassist make vol0 102400 nmirrors=1 #> vxassist snapstart vol0 set ted error on plex vol0-02 #> dd if=/dev/zero of=/dev/vx/rdsk/dg/vol0 count=1 The plex vol0-02 (in SNAPDONE state) remains in the active state. ( SR:8606284763 CR:JAGae48706 ) Panic occurs from dmp_migrate_node() routine. trap panic in VxVM DMP code panic+0x6c report_trap_or_int_and_panic+0x94 trap+0xedc nokgdb+0x8 dmp_migrate_node+0x64 dmp_migrate_dmpnode_to_devlist+0x70 dmp_migrate_dmpnode+0x148 dmp_migrate_devices+0x74 dmp_load_path_map+0x168 gendmpioctl+0x3b0 dmpioctl+0x8c spec_ioctl+0xac vno_ioctl+0x98 ioctl+0x120 syscall+0x204 $syscallrtn+0x0 ( SR:8606302666 CR:JAGae66025 ) DISK-SUBSYSTEM entries on XP array shows up in "vxdisk list". ( SR:8606302674 CR:JAGae66033 ) The zkill test case hung (looping forever) while trying to start vxconfigd. The test was stuck looping trying to start vxconfigd, but it could not. ( SR:8606302675 CR:JAGae66034 ) /etc/vx/array.info file is set @ 555 permissions The permissions should be set to 0644. Normal user should not be able to tamper with array.info file. ( SR:8606282303 CR:JAGae46255 ) (1)During boot time, one of the VxVM boot-up script /etc/rcS.d/S85vxvm-startup2 calls vxreattach to recover all failed disks. Since vxreattach is a shell script it does not know about the routines in daselect.c (which has been modified to take care of the scenario in JAGae36353). As a result it may recover the wrong disk if two or more disks in the disk group have the same diskid. (2)vxvm-startup2/vxreattach performance degradation on boot for large configurations. This was due to a "rm" statement inside a loop. Solution is to check for the existence of the file before trying to remove it. ( SR:8606288162 CR:JAGae52095 ) The commands dgcfgbackup(1M) and dgcfgrestore(1M) are inconsistent in the way they treat configuration file if "-f" depending whether "-f" option is specified or not. ( SR:8606302681 CR:JAGae66040 ) Memory leak in (vxconfigd) priv_scan() during diskgroup import if an LVM disk is present. PHCO_27724: ( SR:8606219607 CR:JAGad88747 ) On a cluster, a VxVM disk that is shared from a different machine appears as "FS_Wholedisk" under 'STATUS' in the output. The system querying the shared disk doesn't recognize that the disk contains a VxVM volume or show it as "online" but not in a disk group. ( SR:8606255740 CR:JAGae20057 ) After using vxassist to create a stripe-mirror layout volume with: vxassist -g datadg make test 100m \ layout=stripe-mirror mirror=ctlr nstripe=9 vxprint incorrectly shows the volume layout. Not all plexes have a related subdisk, or not all subdisks belong to a plex. ( SR:8606255749 CR:JAGae20066 ) When choosing option 17 from the vxdiskadm main menu to prevent multipathing/Suppress devices from VxVM's view, and then choosing option 7 of the submenu to prevent multipathing of disks by specifying a VID:PID combination While rebooting the system as the application recommends vxconfigd gets a segmentation violation core dump. ( SR:8606255768 CR:JAGae20085 ) The vxddladm command doesn't handle invalid commands, i.e. first argument or argv[1]. The worst case is when vxddladm is executed with two args and the first (the command) is invalid. The file, /etc/vx/vxddl.exclude, is reinitialized via vxddl_initialize_ddlfiles() since argc = 3. $ rm /etc/vx/vxddl.exclude $ ls -al /etc/vx/vxddl.exclude /etc/vx/vxddl.exclude: No such file or directory $ vxddladm invalidcommand anything with only 1 invalid arg, listexclude will be executed, since argc=2. Segmentation violations and bus errors are seen, as well: $ vxddladm 1 2 3 4 Segmentation fault ( SR:8606255778 CR:JAGae20095 ) vxconfigd core dumps when running the command: vxdmpadm setattr enclosure SENA0 name=PHOTON ( SR:8606255780 CR:JAGae20097 ) A Hitachi HDS 5700 array may not be recognized by DMP. The output should look like: # vxdmpadm listctlr all CTLR-NAME ENCLR-TYPE STATE ENCLR-NAME ===================================================== c0 OTHER_DISKS ENABLED OTHER_DISKS c3 HITACHI ENABLED HITACHI0 c4 HITACHI ENABLED HITACHI0 however, it comes out like: # vxdmpadm listctlr all CTLR-NAME ENCLR-TYPE STATE ENCLR-NAME ===================================================== c0 OTHER_DISKS ENABLED OTHER_DISKS c3 OTHER_DISKS ENABLED OTHER_DISKS c4 OTHER_DISKS ENABLED OTHER_DISKS ( SR:8606255788 CR:JAGae20105 ) The vxdmpdis utility can disable DMP even though it is required for VxVM operation. ( SR:8606255807 CR:JAGae20124 ) I/O's to VxVM with size greater than 64K are broken into 64K chunks. ( SR:8606255819 CR:JAGae20136 ) Create subdisk or volumes in single-user mode without /usr mounted using vxmake and gives the following error: # vxmake -g vxgd -U gen vol vol1 crt0: ERROR couldn't open /usr/lib/dld.sl errno:000000002 ( SR:8606268328 CR:JAGae32567 ) FS error when snapshot is taken on VxVM volume with VxFS file system: # vxassist -g testdg snapstart tvol3 # vxassist -g testdg snapshot tvol3 SNAP-tvol3 vxvm:vxsync: INFO: VX_FREEZE_ALL ioctl failed ( SR:8606274833 CR:JAGae38910 ) While taking an FMR snapshot of a volume, there is a window of time during which any I/O's coming on the original volume could cause data corruption during snapback. ( SR:8606274849 CR:JAGae38926 ) Switching to enclosure based DA names is creating duplicate records for DA names. ( SR:8606275725 CR:JAGae39801 ) When installing an Array Support Library package, the Unsatisfied symbols errors for: shl_load, shl_unload, and shl_findsym are seen. PHCO_26420: ( SR:8606242622 CR:JAGae09857 ) Either HP Performance measurement tools products, GlancePlus or MeasureWare, does not produce VxVM volume statistics when used with VxVM 3.2 (AR1201). PHCO_26053: ( SR:8606232419 CR:JAGae01654 ) FusionIC3:PHCO_25895 should restart the dgcfgdaemon or reboot the system. PHCO_25895: ( SR:8606228040 CR:JAGad97098 ) Glance and MeasureWare will core dump with VxVM 3.2 or VxVM 3.2 Lite installed and configured on a system. PHCO_27977: ( SR:8606290914 CR:JAGae54757) vxvmconvert: analysis problem with enclosure based names ( SR:8606221522 CR:JAGad90656 ) vxvmconvert: vxlvmencap Memory fault (coredump) from vxhpcap. ( SR:8606279193 CR:JAGae43249 ) The get_vg_pvols routine can't handle physical VG's. ( SR:8606275881 CR:JAGae39956 ) vxvmconvert can't handle LARGE extent based STRIPED volumes. ( SR:8606279194 CR:JAGae43250 ) The get_vg_pvols routine has problem with DMP alternate links. ( SR:8606279207 CR:JAGae43263 ) The vxhpcap utility cores when 255 lvols are in VG. ( SR:8606279196 CR:JAGae43252 ) The vxhpcap utility cores on large "extent based" striped LVM volumes. ( SR:8606267273 CR:JAGae31516 ) The vxvmconvert utility doesn't save LVM config record if one already exists. ( SR:8606267552 CR:JAGae31794 ) The vxvmconvert utility passes analysis phase but then fails if disk has ISL header. ( SR:8606275674 CR:JAGae39750 ) The vxhpcap utility dumps core on systems with more than 256 disks. ( SR:8606278842 CR:JAGae42899 ) The dogi_get_group_pvlist() and get_vg_pvols() are not handling Physical Volume Groups correctly. ( SR:8606289449 CR:JAGae53380 ) Conversion problem with pvlinks and EMC Powerpath. ( SR:8606289441 CR:JAGae53372 ) Rollback failed on physical Volume Groups. PHCO_25837: ( SR:8606237753 CR:JAGae06796 ) Error messages at system boot time with VVR objects at the time the vxvm-startup script is executed from inittab. Defect Description: PHCO_28378: ( SR:8606310931 CR:JAGae73789 ) Panic and file system corruption after doing "rm *" during a raid5 sd move operation Reproduction scenario: o i have 2 paths to a disk o create a ufs partition on a disk o mount the partition using 2 different paths (say mnt1, and mnt2) o now you have one disk has 2 mount points. o i copied a 2 huge vmcore file using 1 path each. o it took long time to complete so i removed the copied files, o when i do ls before remove i got the following message vmesc3# ls -l /kir1 /kir1/vmcore.17.Z: I/O error o the machine then paniced The culprit code is in volsd.c. The fix was to make the destination plex write-only during sd-move operation. ( SR:8606282335 CR:JAGae46287 ) Replacement disk may have a different publen created by vold. vold (vxconfigd) is responsible for building the private region on a disk. Part of the information is the size of the public region. The public region will be sited shortly after the private region. However the length of the public region (publen) is not simply the the size of the disk minus the start of the public region. sliced_init_internal (vold) function uses the disk's geometry rather than the size. Therefore disks of the same size, but with different geometry will probably have different publens. This is a particular problem for HP as the disks supplied by the repair line may not have the same geometry. But will return the same size if an inquiry for the size is made (HP has the manufacturers set the mode page where the size is held to return a specific size). With the current design it is possible that a replacement disk will have vold calculate a smaller publen and therefore insufficient space to hold all the data. Request is to have vold use the disk size rather than the geometry. We are not planning to change the policy of calculating disk size based on disk geometry. Instead, we will give an "override" option to the CDS reservation scheme. So, the customer can now mirror his pre3.2 disks onto disks of different geometry without any problem in one of the following ways(Of course, after restarting vxconfigd): 1. Use vxmirror to mirror volumes from one disk onto any other disk. 2. Use vxdiskadm option 5. 3. Manually, by initializing the disk so that the public region expands from, after the private region, till the end of the disk. And then using "vxassist mirror". ( SR:8606310939 CR:JAGae73797 ) possibility of stack corruption in vxconfigd due to a bug in make_devinfo_list() routine. The reason for the invalid free is that we are FREE'ing an address which was on the stack. ( SR:8606310938 CR:JAGae73796 ) Memory leak exists in (vxconfigd) priv_scan () during diskgroup import if an LVM disk is present. We don't free up the header (private region) if priv_scan_offset() fails. In the current scenario we try to scan for the private region at 2 offsets, so the mem leak is 880 bytes in all. The customer ran "vxdg import/deport" in a loop and ultimately vxconfigd crashed. ( SR:8606310936 CR:JAGae73794 ) Memory leak exists in vxconfigd:vold_thread_create(). test: start vxconfigd and do a import/deport of a diskgroup in a loopp. a> if vxconfigd is started with "-xnothreads" option, then there are no mem-leaks b> but running a multi-threaded version of vxconfigd, the heap size starts increasing appreciably. pthread_attr_init internally allocates memory (80 bytes) and pthread_attr_destroy should be called after the thread is created. fixed mem leaks by adding pthread_attr_destroy () in the code path ( SR:8606310933 CR:JAGae73791 ) Mirrored volume is not disabled when it lost the last ACTIVE plex during resync. I/Os go to the STALE plex and corrupt the data due to a mirror volume is not disabled when it lost the last ACTIVE plex during resync. During resync, if the last ACTIVE plex got failed, we should disable the volume immediately, so application can not access volume any more. It will reduce the possibility of data loss. Though in this situation, there is no guarantee of data consistency. But in case of path failure, we still have chances to recover the whole data by utilizing functions of other applications. ( SR:8606310934 CR:JAGae73792 ) vxpfto bug in Usage This is due to the missing message-id in the usage funtion ( SR:8606310935 CR:JAGae73793 ) Fix memory leaks in vxconfigd (using MLScanner). In function set_cached_asl: we currently do nv_free(cached) for a particular condition. Instead we need to do free as malloc and not nv_alloc is used for this. And we should free for all cases where ret > 0. in ddl_vendor_info(): in this function for multiple pids we allocate an array of strings. This is not freed by the caller ddl_build_property_list which does not use the last argument to the call to ddl_vendor_info at all. The fix is to free the pid field of the last argument for each call of ddl_vendor_info in ddl_build_property_list In the function request_loop in request.c we call dmp_get_events to get a list of events. The argument note is allocated by dmp_get_events and needs to be freed by the caller. This is not done. Note this needs to be freed in case of 0 events also. In the function ddl_make_dll_info we allocate and fill the structure dll_handler_t which is freed by the caller. This structure has a field library_name which is separately allocated but the callers never free it. The fix is to allocate the memory for this structure and the field in a single malloc so that none of the callers need to separately free this field. In the function get_da_lic local variables temp and list are used and are repeatedly allocated and freed in a loop which calls ddl_get_asso. While allocating ddl_get_asso uses malloc but we free using nv_free. This causes the leak to be shown. We should free using free. This is because nv_free checks for a header and the free is done to a different address than malloc returned. ( SR:8606310432 CR:JAGae73304) HPASL install:Impossible to build static vxconfigd. Customer applied HPXPasl library from Veritas and cannot build the static version of vxconfigd on VxVM 3.2. Several dependencies are missing; there is a mixture of 32-bit and 64-bit objects, etc. The problem is that HPXPasl shared library shipped by Veritas is PA1.1 while archived version of the same library is PA2.0. At the same time vold.o module is PA1.1 even on 64bit OS. Errors from installation of HPXPasl package on 64-bit system for VM 3.2: ld: (Warning) At least one PA 2.0 object file (ddlarrays.o) was detected. The li nked output may not run on a PA 1.x system. ld: Unsatisfied symbols: shl_load (code) shl_unload (code) shl_findsym (code) *** Error exit code 1 Resolution: 1. repackage HPXPasl patch with 1.1 archive library (check other ASL patches - VA74xx ??) 2. change /etc/vx/static.d/default/makevold.sh to make sure correct CFLAGS specified. 3. Remove checksums for /etc/vx/type/static/vxconfigd in all commands patches; check for /etc/vx/static.d/build/vold.o only - this should be delivered file. Run the build script makevold.sh as part of commands patch installation process. Otherwise subsequent installation of commands patches will overwrite static vxconfigd compiled with ASLs. ( SR:8606302684 CR:JAGae66043 ) (1) SRL failure may result in inconsistent data Consider following configuration on Primary: There are 2 data volumes on Primary. datavol1 is on a I/o device which is very slow; whereas SRL, datavol2 are on much faster io device. Application does a write W1 on Primary datavol1. This update gets written to SRL and then we start async write to datavol1 and return to the application. Application starts write W2 (which is dependent on write W1) on datavol2. Update for W2 goes to the SRL; then async write to datavol2 is started. If write to datavol2 gets completed before write to datavol1 and at that point system crashes and destroys SRL volume; then on the system recovery data on the volumes becomes inconsistent (W2 has completed; but not W1). Resolution: All writes from a previous generation must finish before any writes from the next generation can start. (2) Replication hung while running autosync_rlinks.tc Following sequence of events happening because of which vxrlink -f det command is failing. 1.Command starts a transaction to det the rlink. path is do_det() --> trans() --> tans_det(). 2. Before transaction could finish, asynchronous signal (SIGIO) from kernel is received by vxconfigd (in request_loop function). vxconfigd now calls "dg_check_kernel()". This starts a internal vold transaction and aborts all pending clients with the reason VE_RESTART. Path is (request_loop() --> dg_check_kernel() --> dg_trans_start() --> client_abort_reason(). 3. Now when det transaction proceeds and try to get rlinks for rvg using getreplicas(), kernel aborts the transaction and set "vol_errno" to VE_RESTART and getreplicas() returns -1. On getting the error value -1, trans_det prints error message and return VEX_NOENT(11) to trans function. Since the return value is +ve (11) trans function also cannot retry the transaction, though the vol_errno set to VR_RESTART, because it expects return value as -1 and vol_errno == VE_RESTART to retry. Code was added in getreplicas() function to retry the transaction if the error code is VE_RETRY. Same applies to getdatavols() function also. ( SR:8606272213 CR:JAGae36353 ) If there are duplicate diskid and if there is no match for the vendor selection criteria, the first da found in the stack, was always returned. This would be a problem if there are duplicate disk ids, since a wrong disk can be made online. Resolution: All duplicate array policies are made within array_da_select. This function contains the vendor specific policy. If no vendor specific policy is found, then no disk will be selected. The functions da_select_diskid and da_find_diskid will honor ( SR:8606302668 CR:JAGae66027 ) Wrong Enclosure Name assigned to VA7X00 arrays. During QA testing of the VA7X00 array, HP discovered that the enclosure name is gotten from the wrong SCSI buffer field. ( SR:8606302676 CR:JAGae66035 ) Volume manager does not detach a plex if it is write only mode. When a plex is set to be write only using setplex_rdwr(), PL_PFLAG_NOERROR is set on the plex. This flag gets loaded as VOLKV_ASFLAG_NOERROR in the kernel. While detaching a plex in kernel, vol_mv_det_errmirs() skips plexes marked with VOLKV_ASFLAG_NOERROR. SNAPDONE plexes are write only plexes and hence don't get detached on error. Resolution: This problem is fixed by resetting the PL_PFLAG_NOERROR on the SNAPDONE plex. ( SR:8606302666 CR:JAGae66025 ) DISK-SUBSYSTEM entries on XP array shows up in "vxdisk list". On HP 11.11 AR1201, when XP512 array is attached all the LUN 0 entries show up as DISK-SUBSYSTEM placeholder and not actual disks with OPEN-X in ioscan. While installing through vxinstall, it shows up as an error that those disks can't be claimed. Resolution: Removed the exclude message issued. ( SR:8606284763 CR:JAGae48706 ) Bug is that dmp_migrate_dmpnode(k) passes down to dmp_migrate_dmpnode_to_devlist(k)a dmpnode_t which contains a list of node_t's with possibly several having state & NODE_TOBE_MIGRATED. It also passes a dev_list_t which contains the devno it has found to be migrated. dmp_migrate_dmpnode_to_devlist(k) checks all the node_t's on the list, not just the first on it that is state & NODE_TOBE_MIGRATED which dmp_migrate_dmpnode(k) found. Therefore if we have more than one node_t off of the dmpnode_t list that is state & NODE_TOBE_MIGRATED and any of these are on a different dev_list_t in the enclr_list_head then we will trap panic. This is what happened. To check if you are seeing this problem obtain the vxvm_mem output (version which shows enclr_list_head required). If you have more than one node_t with a state & NODE_TOBE_MIGRATED (0x40) off the same dmpnode_t in the dev_list_headp then check the enclr_list_head for the node_t's devno. If the devno's are linked off the same dev_list_t then this is fine and will not cause a problem. If however one of the devno's that is state & NODE_TOBE_MIGRATED in a specific dmpnode in the dev_list_headp is in one dev_list_t in the enclr_list_head and another devno that is state & NODE_TOBE_MIGRATED in the same dmpnode appears in a different dev_list_t in the enclr_list_head then this will result in a trap panic in dmp_migrate_node(k). Resolution: Solution is to ensure that arrays are only claimed when all procedures are successful. Meaning if any SCSI command fails, the array will be excluded. This should prevent DMP for getting confused panicing. ( SR:8606302674 CR:JAGae66033 ) Record fragmentation can potentially lead to missing of configuration database records. We had a bug in the way we allocated blocks in the database, if the record splits. If a record spanned across multiple blocks, we try to allocate first available free block from ddb_next.'ddb_create_record' allowed to allocate fragmented part of the record at a lower block number than that of first part of the record. While extracting a record from database, there was an assumption that fragmented record block will exist at a block number higher than that of the first block of the record. As a result, if a record spans across block numbers such that the fragmented part lies at a lower block number than that of first block of the record, we skip the record marking it as fragment missing. Resolution: Changes the logic in ddb_create_record(), not to create records with the wrap-around policy. ( SR:8606302675 CR:JAGae66034 ) /etc/vx/array.info file is set @ 555 permissions The permissions should be set to 0644. Normal user should not be able to tamper with array.info file. ( SR:8606282303 CR:JAGae46255 ) During boot time, one of the VxVM boot-up script /etc/rcS.d/S85vxvm-startup2 calls vxreattach to recover all failed disks. Since vxreattach is a shell script it does not know about the routines in daselect.c(which has been modified to take care of the scenario in JAGae36353). As a result it may recover the wrong disk if two or more disks in the disk group have the same diskid. This problem can be avoided if all disks in a given disk group have duplicate disk ids and the disk group is not imported. vxreattach will ONLY recover failed disks if the disk group is imported. Resolution: vxrecover will not try to recover disks having duplicate diskids. It will display an appropriate error. ( SR:8606288162 CR:JAGae52095 ) The commands dgcfgbackup(1M) and dgcfgrestore(1M) are inconsistent in the way they treat configuration file if "-f" depending whether "-f" option is specified or not. Resolution: The information string "VxVM_DG_Config_Backup_File: $DG" will always be in the config file. (regardless how it was created). ( SR:8606302681 CR:JAGae66040 ) Memory leak in (vxconfigd) priv_scan() during diskgroup import if an LVM disk is present. The LVM disk is scanned on every re-online of the disks [say fired from vxdg import/deport], and this exposes the memory leak. In the current scenario we try to scan for the private region at 2 offsets, so the memory leak is 880 bytes in all. The customer ran "vxdg import/deport" in a loop and ultimately vxconfigd crashed. PHCO_27724: ( SR:8606219607 CR:JAGad88747 ) The was that the DA_TFLAG_FOREIGN2 DA record flag was not being reset when the disk was initialized. Since there was nothing to reset it unless we ran through an entire scan and reset all the DA tflags, merely doing a vxdctl enable did not change the flag therefore it was still set. Resolution: The fix is to reset both the DA_TFLAG_FOREIGN1 and DA_TFLAG_FOREIGN2 tflags when we load the DA record in the kernel and set the DA_TFLAG_DEV_OPEN flag in kernel_disk_load(). ( SR:8606255740 CR:JAGae20057 ) In large configurations the number of returns from nodecmp() which is called when looking up plexes was incorrect. This in turn caused entries to appear in the binary search tree that were not supposed to be there causing other entries to be missed. The root of the problem was that the comparison routine attempted to sort numbers using their numeric value and on this configuration the number was too large to represent as an integer: 'encA_c11t20000020371438E4d0s-02'. Resolution: Use 'strcmp()' to compare the strings. ( SR:8606255749 CR:JAGae20066 ) The problem is due to calls to free(vid); free(pid) in function ddl_exclude_vidpid_from_dmp(). vid/pid is passed to this function from ddl_final_claim_devices(), and have local scope, i.e. allocated on stack. Freeing these leads to corruption of data structures managed by malloc/free and will cause a coredump in either routine. Resolution: Remove the offending calls to free() -- allow the stack allocation routines to free them from the calling function. ( SR:8606255768 CR:JAGae20085 ) The call to parse vxddladm arguments has the unfortunate effect of setting 'num' to 'argc' if the strcmp() of argv[1] doesn't produce a valid match (e.g., listsupport, listexclude, includearray, ...). As long as argv[1] is a valid command, the command variable is set appropriately and returned, so 'num' is set correctly. 'command' isn't initialized at the beginning of the vxddl_parseargs() function, nor is it set if it isn't a valid command, thus an uninitialized variable is returned. Resolution: Initialize the 'command' variable in vxddl_parseargs() and set it to return an invalid 'num'. ( SR:8606255778 CR:JAGae20095 ) Because the system doesn't have a multipathing license (vxlicense -p doesn't show feature '95') vxconfigd can see both active as well as passive paths. Also the array is in AP/F mode (i.e. explicit failover mode). Because of this an inquiry on passive paths will return a status of "not ready". Also, even though there are 4 luns (with 2 paths each), the DMP structures in the kernel list 8 devices out of which 4 are passive devices. But, because of the way the code is structured, DMP first multipaths the devices (even though license is not present). The devices are then retrieved by vxconfigd. Since at that time the devices are multipathed, vxconfigd knows about only 4 devices. Later on the license is checked and once it is confirmed that the license is absent, the devices are split inside DMP. Now, DMP in the kernel lists 8 devices. (Note that vxconfigd, as of now knows only about 4 devices). When name of an enclosure is changed, discovery of no new devices is attempted or expected i.e. DMP reconfiguration is not done. But already existing devices are again retrieved by vold from DMP in the kernel. Unfortunately we end up discovering new devices here (since there are more devices in DMP kernel than vold knows about them, because of splitting). devintf_add_autoconfig() is called after this to change the names. We don't do onlining of these newly added devices (since no new devices are expected). Hence we end up getting some DA records with incomplete information. Doing 'vxdctl enable' before any name change makes sure that there are all 8 devices visible to vold so that there is no discrepancy between vold's view of devices and DMP's view. Hence the problem is not seen after that. Hence, a possible workaround for the problem is to do 'vxdctl enable' before any name change is attempted under such a situation. (Even restart of vold i.e. 'vxdctl stop' and 'vxconfigd' will do). Resolution: Add code in req_array_setattr() in to deal with the newly added devices. The fix is to call da_rootdg_setup() after devintf_add_autoconfig() is called. ( SR:8606255780 CR:JAGae20097 ) There was an assumption that all arrays follow the documented standard of serial numbers starting with "D3, D4,D5". This is not true as the HDS 5700 uses "00", HDS 5800 uses "DF", and HDS 9200 uses "D5". Resolution: Don't validate serial number, because not all arrays follow the documented standard of "D3, D4,D5". 5700 uses "00", 5800 uses "DF", 9200 uses "D5". ( SR:8606255788 CR:JAGae20105 ) Commands from VxVM 3.1 to manipulate the state of DMP were left over in VxVM 3.2. If the vxdmpdis command is run it will actually diable DMP causing all VxVM-managed data to become unavailable. Resolution: Change 'vxdmpdis' and 'vxdmpen' to scripts that just print an error message and do not changed DMP's state. ( SR:8606255807 CR:JAGae20124 ) VxVM is maximum I/O size is hard-coded to be 64K. Resolution: Hard code the size to be 256K for maximum I/O size. ( SR:8606255819 CR:JAGae20136 ) The reason for the failure is due to the vxmake cmd in /etc/vx/type/gen; this is currently not built statically. Resolution: Build /etc/vx/type/gen/vxmake as a statically linked binary. ( SR:8606268328 CR:JAGae32567 ) The ioctl definition is declared wrong in VxVM. The correct definition from VxFS should be used. Resolution: Correct the ioctl definition and rebuild. ( SR:8606274833 CR:JAGae38910 ) Two steps of snapshotting are: (1) det_sync_volumes() calls "vxsync" utility which does the following. A. Freezes the file system. B. Detaches the snapshot plexes(from the original vol) that are passed to it. C. Unfreezes the file system. (2) The actual transaction which takes the plex from original to the snapshot. If there is a write on the original volume between (1) and (2), it would not be reflected in the snapshot plex (since it is was detached in step1). This "missed" write will not be tracked and hence won't be synced by FMR while snapback'ing the snapshot volume. This could result in data corruption after snapback. Resolution: The PLEX_DETACH ioctl will be changed so that FMR is enabled in the ioctl. A null will be used from this ioctl to indicate that we don't know what the plex will be (snapshot, detach) after the ioctl. So, the call to volfmr_update_info() is deferred until the actual transaction when it is set to the snapshot as needed. ( SR:8606274849 CR:JAGae38926 ) The problem is because of the persistent DA records, which aren't handled properly while changing the naming scheme. Resolution: vxdiskadm/vxinstall no longer creates these persistent records and code to avoid duplicate entries in 'vxdisk list' output was added. Also, a filter to remove spurious DA records which may appear when changing naming scheme from CnTnDn to enclosure-based was also added. ( SR:8606275725 CR:JAGae39801 ) The executable: /etc/vx/static.d/build/vold.o was dynamically linked which causes build errors. Resolution: Re-link 'vold.o' statically PHCO_26420: ( SR:8606242622 CR:JAGae09857 ) GlancePlus and MeasureWare were built with VxVM 3.1 header files. The volkdisk structure increased in size for VxVM 3.2 in AR1201 which caused an incompatibility with Glance since the application did not allocate enough memory. Resolution: Glance-specific ioctl() was added to VxVM to make it compatible with the VxVM 3.1 headers used to build GlancePlus and MeasureWare. This new ioctl() impacted not only VxVM kernel objects, but also the utilities vxconfigd (static and dynamic) and vxkprint. Also, the /sbin/vxconfigd released with AR1201 was incorrectly packaged. In VxVM 3.2 this utility is a switchout command. It will execute the dynamic version in /usr/sbin if it is available; otherwise, it will execute the static version from /etc/vx/type/static. PHCO_26053: ( SR:8606232419 CR:JAGae01654 ) Patch PHCO_25895 which provided a fix for JAGae01654 Installing this patch removes the old /etc/vxvmconf/.confchanged if any, however, if the system is not rebooted after installing the patch, still the old copy of /usr/sbin/dgcfgdaemon is running which causes the creation of .confchanged file in response to any VXVM changes which results into the glance core dump. PHCO_25895: ( SR:8606228040 CR:JAGad97098 ) The header file for VxVM 3.2 causes memory corruption in the midaemon module. Both Glance and MeasureWare use this module when they monitor VxVM, and will eventually core dump when the memory corruption occurs. This behavior breaks backwards compatibility with all version of Glance and MeasureWare. Resolution: A superseding patch is being providing the same fix but forcing the machine to reboot after the patch is installed. PHCO_27977: ( SR:8606290914 CR:JAGae54757) Problem in conversion found during testing if enclosure based names are used. We now handle enclosure based names during the conversion. ( SR:8606221522 CR:JAGad90656 ) The fault is due to the input file to vxhpcap from vxlvmencap does not contain the %vgname string marker. The core dump is from strncpy. This is because the VG has PVs which have multiple paths but not all paths are specified for the VG. Change vxvmconvert to cope with this type of set-up and convert the VG. It is valid for a VG to not have all paths to the VG specified. ( SR:8606279193 CR:JAGae43249 ) The get_vg_pvols does not work with Volume Groups using Physical Volume Groups. Changed get_vg_pvols() to just use vxhpcap instead. ( SR:8606275881 CR:JAGae39956 ) The problem is that extent based striping on HP, when converted, results in hundreds of subdisks when the volume size is large. This causes vxhpcap to have a buffer overrun when generating the "vxmake plex" command which follows with each and every subdisk in the plex. vxhpcap can currently handle only about 50 subdisks. So, if the volume using extent based striping is using the default 4MB partitions, this would translate to only being able to convert a VG up to about 200MB. Of course, if the partitions were 256MB, then we could handle up to about 12 Gig. Increased buffer size to allow for large amount of subdisks in a plex. ( SR:8606279194 CR:JAGae43250 ) The get_vg_pvols does not work with Physical Volume Groups. Changed get_vg_pvols() to be able to handle physical VGs. ( SR:8606279207 CR:JAGae43263 ) vxhpcap utility is trying to access the 256th entry in the VG_entry.lv structure. So this is an "array index out of bounds" problem. The array for logical volume information was set to 255 items and it needed to be 256. ( SR:8606279196 CR:JAGae43252 ) The vxmake command will fail if the vxmake command line is too long. Since the large extent based volumes, result in thousands of subdisks being created, the vxmake plex sd="list of 4000+ subdisks" causes the vxmake command to fail. Added code to handle many thousands of disks. ( SR:8606267273 CR:JAGae31516 ) When vxvmconvert is used to convert LVM volume groups to VxVM disk groups, for some reason conversion fails, the next time customer run vxvmconvert on the same volume group, vxvmconvert doesn't save lvm configuration records and do not proceed with updating rollback information. As a result rollback of the disk group is unavailable. This because if the config file used by the commands already exists(created on the failed attempt) then vgcfgbackup fails. Added check for config file before attempting backup. ( SR:8606267552 CR:JAGae31794 ) The problem with this disk was that it had ISL directory header in the first block (block zero). This disk was probably a boot disk at some point (configured with pvcreate -B and mkboot) and then recreated with pvcreate -f. Added extra lifls checks to examine the disks. ( SR:8606275674 CR:JAGae39750 ) vxhpcap dumps core and aborts with SIGSEGV on systems with more than 256 disks. Changed the structure definition from char to uint to support large number of disks. ( SR:8606278842 CR:JAGae42899 ) The routines dogi_get_group_pvlist() and get_vg_pvols() are not handling Physical Volume Groups correctly. Updated get_vg_pvols() and dogi_get_group_pvlist() to handle physical volume groups correctly. ( SR:8606289449 CR:JAGae53380 ) Conversion problem with pvlinks and EMC Powerpath. Primary problem was that get_vg_pvols could not handle the case where LVM uses a non-primary path to a disk as the VG's only known path to the disk. Fix so that LVM can use non-primary path to a disk as the VG's only known path to the disk. ( SR:8606289441 CR:JAGae53372 ) Rollback failed on physical Volume Groups. vxvm:vxdisk: ERROR: Failed to obtain locks: c0t10d0: no such object in the configuration vxvm:vxdisk: ERROR: Failed to obtain locks: c0t11d0: no such object in the configuration vgdisplay: Volume group "/dev/vg01" does not exist in the "/etc/lvmtab" file. vgdisplay: Cannot display volume group "vg01". Fix so that Rollback of physical Volume Groups works. PHCO_25837: ( SR:8606237753 CR:JAGae06796 ) Error messages at system boot time with VVR objects at the time the vxvm-startup script is executed. Resolution: Use a new usetype of "static" for VVR recovery. The fix for VVR 3.2 on HP (AR1201) will have to just revert the use-type specified in vxrecover to the earlier DFLT_USE_TYPE. Enhancement: No SR: 8606219607 8606228040 8606232419 8606242622 8606255740 8606255749 8606255768 8606255778 8606255780 8606255788 8606255807 8606255819 8606268328 8606274833 8606274849 8606275725 8606272213 8606302668 8606284763 8606302666 8606302674 8606302675 8606282303 8606288162 8606302684 8606302681 8606302676 8606310931 8606282335 8606310939 8606310938 8606310936 8606310933 8606282303 8606310934 8606221522 8606279193 8606275881 8606279194 8606279207 8606279196 8606267273 8606267552 8606275674 8606278842 8606310935 8606310432 8606289449 8606289441 8606237753 Patch Files: HPvxvm.VXVM-RUN,fr=B.03.20.1,fa=HP-UX_B.11.11_32/64,v=HP: /etc/vx/aslkey.d/libvxhitachi.key /etc/vx/aslkey.d/libvxautoraid.key /etc/vx/aslkey.d/libvxhds.key /etc/vx/aslkey.d/libvxfc60.key /etc/vx/aslkey.d/libvxdgc.key /etc/vx/aslkey.d/libvxva.key /etc/vx/aslkey.d/libvxxp256.key /etc/vx/static.d/build/vold.o /usr/lib/vxvm/lib/discovery.d/libvxhitachi.sl /usr/lib/vxvm/lib/discovery.d/libvxautoraid.sl /usr/lib/vxvm/lib/discovery.d/libvxhds.sl /usr/lib/vxvm/lib/discovery.d/libvxfc60.sl /usr/lib/vxvm/lib/discovery.d/libvxdgc.sl /usr/lib/vxvm/lib/discovery.d/libvxva.sl /usr/lib/vxvm/lib/discovery.d/libvxxp256.sl /etc/vx/static.d/default/libvxarrays.a /etc/vx/type/fsgen/fs.d/vxfs/vxsync /etc/vx/type/gen/vxmake_static /etc/vx/type/static/vxmake /etc/vx/type/raid5/vxvol /etc/vx/type/raid5/vxsd /etc/vx/type/gen/vxvol /usr/sbin/vxmake /etc/vx/type/fsgen/vxplex /etc/vx/type/gen/vxplex /etc/vx/type/static/vxconfigd /etc/vx/type/static/vxprint /etc/vx/type/static/vxedit /etc/vx/type/gen/vxrlink /etc/vx/type/gen/vxrvg /sbin/vxedit /sbin/vxrecover /sbin/vxmake /sbin/vxprint /sbin/vxconfigd /usr/lib/vxvm/bin/nulldisk /usr/lib/vxvm/diag.d/vxkprint /usr/lib/vxvm/diag.d/vxconfigdump /usr/lib/vxvm/diag.d/vxprivutil /usr/sbin/dgcfgrestore /usr/sbin/dgcfgdaemon /usr/sbin/dgcfgbackup /usr/sbin/vxconfigd /usr/sbin/vxddladm /usr/sbin/vxrvg /usr/sbin/vxedit /usr/sbin/vxrlink /usr/sbin/vxassist /usr/sbin/vxprint /usr/lib/vxvm/bin/vxdmpen /usr/lib/vxvm/bin/vxreattach /usr/lib/vxvm/bin/vxdmpdis /usr/lib/vxvm/bin/vxpfto /usr/lib/vxvm/bin/vxmirror /usr/lib/vxvm/bin/vxdisksetup /usr/lib/vxvm/bin/vxhpcap /usr/lib/vxvm/bin/vxlvmencap /usr/lib/vxvm/voladm.d/bin/disk.mirror /usr/lib/vxvm/voladm.d/bin/disk.repl /usr/lib/vxvm/voladm.d/bin/disk.anal.ckinit /usr/lib/vxvm/voladm.d/bin/disk.lvm.ckinit /usr/lib/vxvm/voladm.d/bin/disk.convert /usr/lib/vxvm/voladm.d/bin/vxsave_lvmrecs /usr/lib/vxvm/voladm.d/bin/minor_numchk /usr/lib/vxvm/voladm.d/lib/vxadm_lib.sh /usr/lib/vxvm/voladm.d/lib/vxadm_syslib.sh /usr/lib/vxvm/voladm.d/lib/vxadm_lvmlib.sh HPvxvm.VXVM-ENG-A-MAN,fr=B.03.20.1,fa=HP-UX_B.11.11_32/64, v=HP: /usr/share/man/man1m.Z/vxdisksetup.1m what(1) Output: HPvxvm.VXVM-RUN,fr=B.03.20.1,fa=HP-UX_B.11.11_32/64,v=HP: /etc/vx/aslkey.d/libvxhitachi.key: No what(1) output available /etc/vx/aslkey.d/libvxautoraid.key: No what(1) output available /etc/vx/aslkey.d/libvxhds.key: No what(1) output available /etc/vx/aslkey.d/libvxfc60.key: No what(1) output available /etc/vx/aslkey.d/libvxdgc.key: No what(1) output available /etc/vx/aslkey.d/libvxva.key: No what(1) output available /etc/vx/aslkey.d/libvxxp256.key: No what(1) output available /etc/vx/static.d/build/vold.o: coredb.c $Date: 2003/05/11 21:45:00 $Revision: 32.3 PATCH_11.11 (PHCO_28378) da.c $Date: 2003/02/03 23:27:33 $Revision: 32.4 PATC H_11.11 (PHCO_28378) daselect.c $Date: 2003/02/04 00:02:31 $Revision: 32. 3 PATCH_11.11 (PHCO_28378) dbase.c $Date: 2003/02/04 03:34:42 $Revision: 32.3 P ATCH_11.11 (PHCO_28378) devintf.c $Date: 2002/08/23 09:13:43 $Revision: 32.3 PATCH_11.11 (PHCO_27724) kernel.c $Date: 2003/05/11 21:48:55 $Revision: 32.5 PATCH_11.11 (PHCO_28378) krecover.c $Date: 2002/03/06 12:32:28 $Revision: r11 .11/1 PATCH_11.11 (PHCO_26420) libelm.a $Date: 2002/05/29 21:25:21 $Revision: r11.1 1/1 PATCH_11.11 (UNOF_libelm.a) mode.c $Date: 2002/08/23 09:13:44 $Revision: 32.3 PA TCH_11.11 (PHCO_27724) naming.c $Date: 2003/01/21 23:59:06 $Revision: 32.4 PATCH_11.11 (PHCO_28378) priv.c $Date: 2003/03/25 22:35:46 $Revision: 32.3 PA TCH_11.11 (PHCO_28378) request.c $Date: 2003/05/11 21:51:26 $Revision: 32.3 PATCH_11.11 (PHCO_28378) sliced_sys.c $Date: 2003/05/11 23:05:49 $Revision: 3 2.4 PATCH_11.11 (PHCO_28378) voldb.c $Date: 2002/08/23 09:13:44 $Revision: 32.3 P ATCH_11.11 (PHCO_27724) voldbsup.c $Date: 2002/12/31 06:50:19 $Revision: 32. 3 PATCH_11.11 (PHCO_28378) voldthreads.c $Date: 2003/05/11 21:53:29 $Revision: 32.3 PATCH_11.11 (PHCO_28378) volddl_pack.c $Date: 2003/05/11 22:37:31 $Revision: 1.2 PATCH_11.11 (PHCO_28378) volddl_claim.c $Date: 2003/06/02 20:33:47 $Revision: 1.4 PATCH_11.11 (PHCO_28378) volddl_dmplic.c $Date: 2003/05/11 22:39:32 $Revision : 1.2 PATCH_11.11 (PHCO_28378) volddl_sys.c $Date: 2003/05/11 22:32:46 $Revision: 1 .2 PATCH_11.11 (PHCO_28378) volddl_vendor_lib.c $Date: 2003/05/11 22:34:50 $Revi sion: 1.2 PATCH_11.11 (PHCO_28378) ddlskiplist.c $Date: 2003/05/11 22:29:00 $Revision: 1.2 PATCH_11.11 (PHCO_28378) $ Version_11.11 Mar 17 2002 22:35:46 $ /etc/vx/static.d/default/libvxarrays.a: ddlhds.c $Date: 2003/02/14 00:04:15 $Revision: 1.3 P ATCH_11.11 (PHCO_28378) ddlautoraid.c $Date: 2003/02/14 01:02:44 $Revision: 1.3 PATCH_11.11 (PHCO_28378) ddlxp256.c $Date: 2003/02/14 00:09:26 $Revision: 1.2 PATCH_11.11 (PHCO_28378) ddlhitachi.c $Date: 2003/02/07 02:59:32 $Revision: 1 .2 PATCH_11.11 (PHCO_28378) ddlva.c $Date: 2003/02/14 00:06:18 $Revision: 1.4 PA TCH_11.11 (PHCO_28378) ddlfc60.c $Date: 2003/02/13 23:07:09 $Revision: 1.2 PATCH_11.11 (PHCO_28378) ddldgc.c $Date: 2003/02/14 01:05:15 $Revision: 1.3 P ATCH_11.11 (PHCO_28378) /usr/lib/vxvm/lib/discovery.d/libvxautoraid.sl: ddlautoraid.c $Date: 2003/02/14 01:02:44 $Revision: 1.3 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/lib/discovery.d/libvxdgc.sl: ddldgc.c $Date: 2003/02/14 01:05:15 $Revision: 1.3 P ATCH_11.11 (PHCO_28378) /usr/lib/vxvm/lib/discovery.d/libvxfc60.sl: ddlfc60.c $Date: 2003/02/13 23:07:09 $Revision: 1.2 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/lib/discovery.d/libvxhds.sl: ddlhds.c $Date: 2003/02/14 00:04:15 $Revision: 1.3 P ATCH_11.11 (PHCO_28378) /usr/lib/vxvm/lib/discovery.d/libvxhitachi.sl: ddlhitachi.c $Date: 2003/02/07 02:59:32 $Revision: 1 .2 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/lib/discovery.d/libvxva.sl: ddlva.c $Date: 2003/02/14 00:06:18 $Revision: 1.4 PA TCH_11.11 (PHCO_28378) /usr/lib/vxvm/lib/discovery.d/libvxxp256.sl: ddlxp256.c $Date: 2003/02/14 00:09:26 $Revision: 1.2 PATCH_11.11 (PHCO_28378) /etc/vx/type/fsgen/fs.d/vxfs/vxsync: volsync.c $Date: 2002/08/23 09:13:39 $Revision: 32.2 PATCH_11.11 (PHCO_27724) $ Version_11.11 Mar 17 2002 22:35:46 $ /etc/vx/type/gen/vxmake_static: unixvm:src/common/cmd/vxvm/gen/volmake.c 1.17.45.1 unixvm:src/common/cmd/vxvm/gen/genextern.c 1.4 $ Version_11.11 Mar 17 2002 22:35:46 $ /etc/vx/type/static/vxmake: unixvm:src/hp/cmd/vxvm/switchout/vxswitchout.h 1.4 volmake.c $Date: 2002/08/23 09:13:41 $Revision: 32.2 PATCH_11.11 (PHCO_27724) $ Version_11.11 Mar 17 2002 22:35:46 $ /usr/sbin/vxmake: unixvm:src/hp/cmd/vxvm/switchout/vxswitchout.h 1.4 volmake.c $Date: 2002/08/23 09:13:41 $Revision: 32.2 PATCH_11.11 (PHCO_27724) /usr/sbin/vxrvg: volrvg.c $Date: 2002/12/30 23:21:39 $Revision: 32.3 PATCH_11.11 (PHCO_28378) getrec.c $Date: 2002/12/31 03:51:19 $Revision: 32.2 PATCH_11.11 (PHCO_28378) /usr/sbin/vxrlink: volrlink.c $Date: 2002/02/01 14:39:44 $Revision: r11 .11/1 PATCH_11.11 (PHCO_25837) getrec.c $Date: 2002/12/31 03:51:19 $Revision: 32.2 PATCH_11.11 (PHCO_28378) /usr/sbin/vxedit: getrec.c $Date: 2002/12/31 03:51:19 $Revision: 32.2 PATCH_11.11 (PHCO_28378) /etc/vx/type/gen/vxplex: volplex.c $Date: 2003/02/12 06:10:19 $Revision: 32.3 PATCH_11.11 (PHCO_28378) $ Version_11.11 Mar 17 2002 22:35:46 $ /etc/vx/type/fsgen/vxplex: volplex.c $Date: 2003/02/12 06:10:19 $Revision: 32.3 PATCH_11.11 (PHCO_28378) /etc/vx/type/static/vxedit: getrec.c $Date: 2002/12/31 03:51:19 $Revision: 32.2 PATCH_11.11 (PHCO_28378) /etc/vx/type/gen/vxrlink: volrlink.c $Date: 2002/02/01 14:39:44 $Revision: r11 .11/1 PATCH_11.11 (PHCO_25837) getrec.c $Date: 2002/12/31 03:51:19 $Revision: 32.2 PATCH_11.11 (PHCO_28378) /etc/vx/type/gen/vxrvg: volrvg.c $Date: 2002/12/30 23:21:39 $Revision: 32.3 PATCH_11.11 (PHCO_28378) getrec.c $Date: 2002/12/31 03:51:19 $Revision: 32.2 PATCH_11.11 (PHCO_28378) /etc/vx/type/static/vxconfigd: coredb.c $Date: 2003/05/11 21:45:00 $Revision: 32.3 PATCH_11.11 (PHCO_28378) da.c $Date: 2003/02/03 23:27:33 $Revision: 32.4 PATC H_11.11 (PHCO_28378) daselect.c $Date: 2003/02/04 00:02:31 $Revision: 32. 3 PATCH_11.11 (PHCO_28378) dbase.c $Date: 2003/02/04 03:34:42 $Revision: 32.3 P ATCH_11.11 (PHCO_28378) devintf.c $Date: 2002/08/23 09:13:43 $Revision: 32.3 PATCH_11.11 (PHCO_27724) kernel.c $Date: 2003/05/11 21:48:55 $Revision: 32.5 PATCH_11.11 (PHCO_28378) krecover.c $Date: 2002/03/06 12:32:28 $Revision: r11 .11/1 PATCH_11.11 (PHCO_26420) libelm.a $Date: 2002/05/29 21:25:21 $Revision: r11.1 1/1 PATCH_11.11 (UNOF_libelm.a) mode.c $Date: 2002/08/23 09:13:44 $Revision: 32.3 PA TCH_11.11 (PHCO_27724) naming.c $Date: 2003/01/21 23:59:06 $Revision: 32.4 PATCH_11.11 (PHCO_28378) priv.c $Date: 2003/03/25 22:35:46 $Revision: 32.3 PA TCH_11.11 (PHCO_28378) request.c $Date: 2003/05/11 21:51:26 $Revision: 32.3 PATCH_11.11 (PHCO_28378) sliced_sys.c $Date: 2003/05/11 23:05:49 $Revision: 3 2.4 PATCH_11.11 (PHCO_28378) voldb.c $Date: 2002/08/23 09:13:44 $Revision: 32.3 P ATCH_11.11 (PHCO_27724) voldbsup.c $Date: 2002/12/31 06:50:19 $Revision: 32. 3 PATCH_11.11 (PHCO_28378) voldthreads.c $Date: 2003/05/11 21:53:29 $Revision: 32.3 PATCH_11.11 (PHCO_28378) volddl_pack.c $Date: 2003/05/11 22:37:31 $Revision: 1.2 PATCH_11.11 (PHCO_28378) volddl_claim.c $Date: 2003/06/02 20:33:47 $Revision: 1.4 PATCH_11.11 (PHCO_28378) volddl_dmplic.c $Date: 2003/05/11 22:39:32 $Revision : 1.2 PATCH_11.11 (PHCO_28378) volddl_sys.c $Date: 2003/05/11 22:32:46 $Revision: 1 .2 PATCH_11.11 (PHCO_28378) volddl_vendor_lib.c $Date: 2003/05/11 22:34:50 $Revi sion: 1.2 PATCH_11.11 (PHCO_28378) ddlskiplist.c $Date: 2003/05/11 22:29:00 $Revision: 1.2 PATCH_11.11 (PHCO_28378) ddlhds.c $Date: 2003/02/14 00:04:15 $Revision: 1.3 P ATCH_11.11 (PHCO_28378) ddlautoraid.c $Date: 2003/02/14 01:02:44 $Revision: 1.3 PATCH_11.11 (PHCO_28378) ddlxp256.c $Date: 2003/02/14 00:09:26 $Revision: 1.2 PATCH_11.11 (PHCO_28378) ddlhitachi.c $Date: 2003/02/07 02:59:32 $Revision: 1 .2 PATCH_11.11 (PHCO_28378) ddlva.c $Date: 2003/02/14 00:06:18 $Revision: 1.4 PA TCH_11.11 (PHCO_28378) ddlfc60.c $Date: 2003/02/13 23:07:09 $Revision: 1.2 PATCH_11.11 (PHCO_28378) ddldgc.c $Date: 2003/02/14 01:05:15 $Revision: 1.3 P ATCH_11.11 (PHCO_28378) HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O ILP 32) $Revision: 75.02 $ $ Version_11.11 Mar 17 2002 22:35:46 $ /etc/vx/type/gen/vxvol: volume.c $Date: 2002/12/31 01:03:06 $Revision: 32.2 PATCH_11.11 (PHCO_28378) comstart.c $Date: 2003/02/12 05:59:00 $Revision: 32. 2 PATCH_11.11 (PHCO_28378) comklog.c $Date: 2003/02/12 06:17:42 $Revision: 32.3 PATCH_11.11 (PHCO_28378) $ Version_11.11 Mar 17 2002 22:35:46 $ /etc/vx/type/raid5/vxvol: comklog.c $Date: 2003/02/12 06:17:42 $Revision: 32.3 PATCH_11.11 (PHCO_28378) $ Version_11.11 Mar 17 2002 22:35:46 $ /etc/vx/type/raid5/vxsd: volsd.c $Date: 2003/05/11 22:07:13 $Revision: 32.2 P ATCH_11.11 (PHCO_28378) getrec.c $Date: 2002/12/31 03:51:19 $Revision: 32.2 PATCH_11.11 (PHCO_28378) $ Version_11.11 Mar 17 2002 22:35:46 $ /etc/vx/type/static/vxprint: volprint.c $Date: 2002/12/30 22:58:49 $Revision: 32. 4 PATCH_11.11 (PHCO_28378) unixvm:src/hp/cmd/vxvm/admin/volpfto_sup.c 1.7 $ Version_11.11 Mar 17 2002 22:35:46 $ /sbin/vxrecover: volrecover.c $Date: 2002/02/01 14:39:44 $Revision: r 11.11/1 PATCH_11.11 (PHCO_25837) getrec.c $Date: 2002/12/31 03:51:19 $Revision: 32.2 PATCH_11.11 (PHCO_28378) $ Version_11.11 Mar 17 2002 22:35:46 $ /sbin/vxedit: volstaticsw.c $Date: 2002/03/04 12:30:23 $Revision: r11.11/1 PATCH_11.11 (PHCO_26420) $ Version_11.11 Mar 17 2002 22:35:46 $ /sbin/vxmake: volstaticsw.c $Date: 2002/03/04 12:30:23 $Revision: r11.11/1 PATCH_11.11 (PHCO_26420) $ Version_11.11 Mar 17 2002 22:35:46 $ /sbin/vxconfigd: volstaticsw.c $Date: 2002/03/04 12:30:23 $Revision: r11.11/1 PATCH_11.11 (PHCO_26420) $ Version_11.11 Mar 17 2002 22:35:46 $ /sbin/vxprint: volstaticsw.c $Date: 2002/03/04 12:30:23 $Revision: r11.11/1 PATCH_11.11 (PHCO_26420) $ Version_11.11 Mar 17 2002 22:35:46 $ /usr/lib/vxvm/bin/nulldisk: nulldisk.c $Date: 2002/08/23 09:13:41 $Revision: 32. 2 PATCH_11.11 (PHCO_27724) /usr/lib/vxvm/diag.d/vxkprint: volkprint.c $Date: 2003/01/01 03:10:27 $Revision: 32 .3 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/diag.d/vxconfigdump: dbase.c $Date: 2003/02/04 03:34:42 $Revision: 32.3 P ATCH_11.11 (PHCO_28378) voldbsup.c $Date: 2002/12/31 06:50:19 $Revision: 32. 3 PATCH_11.11 (PHCO_28378) voldthreads.c $Date: 2003/05/11 21:53:29 $Revision: 32.3 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/diag.d/vxprivutil: def_sys.h $Date: 2002/08/23 09:13:43 $Revision: 32.3 PATCH_11.11 (PHCO_27724) voldthreads.c $Date: 2003/05/11 21:53:29 $Revision: 32.3 PATCH_11.11 (PHCO_28378) priv.c $Date: 2003/03/25 22:35:46 $Revision: 32.3 PA TCH_11.11 (PHCO_28378) /usr/sbin/dgcfgdaemon: dgcfgdaemon.sh $Date: 2002/03/05 12:49:42 $Revision: r11.11/1 PATCH_11.11 (PHCO_26420) /usr/sbin/dgcfgbackup: dgcfgbackup.sh $Date: 2003/02/12 06:41:32 $Revision: 32.3 PATCH_11.11 (PHCO_28378) /usr/sbin/dgcfgrestore: dgcfgrestore.sh $Date: 2003/02/12 06:46:27 $Revision : 32.3 PATCH_11.11 (PHCO_28378) /usr/sbin/vxassist: snap.c $Date: 2003/02/12 05:53:48 $Revision: 32.2 PA TCH_11.11 (PHCO_28378) /usr/sbin/vxconfigd: coredb.c $Date: 2003/05/11 21:45:00 $Revision: 32.3 PATCH_11.11 (PHCO_28378) da.c $Date: 2003/02/03 23:27:33 $Revision: 32.4 PATC H_11.11 (PHCO_28378) daselect.c $Date: 2003/02/04 00:02:31 $Revision: 32. 3 PATCH_11.11 (PHCO_28378) dbase.c $Date: 2003/02/04 03:34:42 $Revision: 32.3 P ATCH_11.11 (PHCO_28378) devintf.c $Date: 2002/08/23 09:13:43 $Revision: 32.3 PATCH_11.11 (PHCO_27724) kernel.c $Date: 2003/05/11 21:48:55 $Revision: 32.5 PATCH_11.11 (PHCO_28378) krecover.c $Date: 2002/03/06 12:32:28 $Revision: r11 .11/1 PATCH_11.11 (PHCO_26420) libelm.a $Date: 2002/05/29 21:25:21 $Revision: r11.1 1/1 PATCH_11.11 (UNOF_libelm.a) mode.c $Date: 2002/08/23 09:13:44 $Revision: 32.3 PA TCH_11.11 (PHCO_27724) naming.c $Date: 2003/01/21 23:59:06 $Revision: 32.4 PATCH_11.11 (PHCO_28378) priv.c $Date: 2003/03/25 22:35:46 $Revision: 32.3 PA TCH_11.11 (PHCO_28378) request.c $Date: 2003/05/11 21:51:26 $Revision: 32.3 PATCH_11.11 (PHCO_28378) sliced_sys.c $Date: 2003/05/11 23:05:49 $Revision: 3 2.4 PATCH_11.11 (PHCO_28378) voldb.c $Date: 2002/08/23 09:13:44 $Revision: 32.3 P ATCH_11.11 (PHCO_27724) voldbsup.c $Date: 2002/12/31 06:50:19 $Revision: 32. 3 PATCH_11.11 (PHCO_28378) voldthreads.c $Date: 2003/05/11 21:53:29 $Revision: 32.3 PATCH_11.11 (PHCO_28378) volddl_pack.c $Date: 2003/05/11 22:37:31 $Revision: 1.2 PATCH_11.11 (PHCO_28378) volddl_claim.c $Date: 2003/06/02 20:33:47 $Revision: 1.4 PATCH_11.11 (PHCO_28378) volddl_dmplic.c $Date: 2003/05/11 22:39:32 $Revision : 1.2 PATCH_11.11 (PHCO_28378) volddl_sys.c $Date: 2003/05/11 22:32:46 $Revision: 1 .2 PATCH_11.11 (PHCO_28378) volddl_vendor_lib.c $Date: 2003/05/11 22:34:50 $Revi sion: 1.2 PATCH_11.11 (PHCO_28378) ddlskiplist.c $Date: 2003/05/11 22:29:00 $Revision: 1.2 PATCH_11.11 (PHCO_28378) HP92453-02A.11.00 HP-UX SYMBOLIC DEBUGGER (END.O ILP 32) $Revision: 75.02 $ $ Version_11.11 Mar 17 2002 22:35:46 $ /usr/sbin/vxddladm: volddladm.c $Date: 2002/08/23 09:13:39 $Revision: 32 .2 PATCH_11.11 (PHCO_27724) unixvm:src/hp/cmd/vxvm/admin/ddlsys.c 1.1.45.3 $ Version_11.11 Mar 17 2002 22:35:46 $ /usr/sbin/vxprint: volprint.c $Date: 2002/12/30 22:58:49 $Revision: 32. 4 PATCH_11.11 (PHCO_28378) unixvm:src/hp/cmd/vxvm/admin/volpfto_sup.c 1.7 /usr/lib/vxvm/bin/vxdmpen: src/hp/cmd/vxvm/support/vxdmpen.sh 1.5.52.1 08/28/02 07:34:30 - unixvm:src/hp/cmd/vxvm/support/vxdmpen.sh 1.5.52.1 vxdmpen.sh $Date: 2002/09/04 08:47:35 $Revision: 32. 3 PATCH_11.11 (PHCO_27724) /usr/lib/vxvm/bin/vxdmpdis: src/hp/cmd/vxvm/support/vxdmpdis.sh 1.5.52.1 08/28/0 2 07:35:16 - unixvm:src/hp/cmd/vxvm/support/vxdmpdis.sh 1.5.52.1 vxdmpdis.sh $Date: 2002/09/04 08:47:54 $Revision: 32 .3 PATCH_11.11 (PHCO_27724) /usr/lib/vxvm/bin/vxreattach: vxreattach.sh $Date: 2003/04/05 03:41:26 $Revision: 32.4 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/bin/vxmirror: vxmirror.sh $Date: 2003/05/11 22:15:25 $Revision: 32 .2 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/bin/vxpfto: vxpfto.sh $Date: 2003/05/11 22:17:56 $Revision: 32.2 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/bin/vxdisksetup: vxdisksetup.sh $Date: 2003/05/11 22:13:00 $Revision: 32.3 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/voladm.d/bin/disk.mirror: disk.mirror.sh $Date: 2003/05/11 22:20:34 $Revision: 32.2 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/voladm.d/bin/disk.repl: disk.repl.sh $Date: 2003/05/11 22:23:07 $Revision: 3 2.2 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/voladm.d/lib/vxadm_lib.sh: vxadm_lib.sh $Date: 2003/05/11 22:26:04 $Revision: 3 2.3 PATCH_11.11 (PHCO_28378) /usr/lib/vxvm/bin/vxhpcap: vxhpcap.c $Date: 2003/01/07 08:34:28 $Revision: 32.7 PATCH_11.11 (PHCO_27977) /usr/lib/vxvm/voladm.d/bin/disk.anal.ckinit: disk.anal.ckinit.sh $Date: 2002/12/23 07:45:59 $Revi sion: 32.3 PATCH_11.11 (PHCO_27977) /usr/lib/vxvm/voladm.d/bin/disk.convert: disk.convert.sh $Date: 2002/12/11 08:14:29 $Revision : 32.3 PATCH_11.11 (PHCO_27977) /usr/lib/vxvm/voladm.d/bin/disk.lvm.ckinit: disk.lvm.ckinit.sh $Date: 2002/12/23 07:56:58 $Revis ion: 32.3 PATCH_11.11 (PHCO_27977) src/hp/cmd/vxvm/voladm/disk.lvm.ckinit.sh 1.18 .52.5 12/22/02 13:20:48 - Copyright (c) 1999 VERITAS Software Corp. unixvm:src/hp/cmd/vxvm/voladm/disk.lvm.ckinit.sh 1.1 8.52.5 /usr/lib/vxvm/voladm.d/lib/vxadm_syslib.sh: vxadm_syslib.sh $Date: 2002/12/12 08:07:20 $Revision : 32.6 PATCH_11.11 (PHCO_27977) /usr/lib/vxvm/voladm.d/bin/minor_numchk: minor_numchk.sh $Date: 2002/12/09 09:36:40 $Revision : 32.2 PATCH_11.11 (PHCO_27977) /usr/lib/vxvm/voladm.d/lib/vxadm_lvmlib.sh: vxadm_lvmlib.sh $Date: 2003/01/07 08:42:31 $Revision : 32.7 PATCH_11.11 (PHCO_27977) /usr/lib/vxvm/voladm.d/bin/vxsave_lvmrecs: vxsave_lvmrecs.sh $Date: 2002/12/30 13:27:11 $Revisi on: 32.7 PATCH_11.11 (PHCO_27977) /usr/lib/vxvm/bin/vxlvmencap: vxlvmencap.sh $Date: 2003/01/07 08:39:42 $Revision: 32.3 PATCH_11.11 (PHCO_27977) HPvxvm.VXVM-ENG-A-MAN,fr=B.03.20.1,fa=HP-UX_B.11.11_32/64, v=HP: /usr/share/man/man1m.Z/vxdisksetup.1m: No What output available. cksum(1) Output: HPvxvm.VXVM-RUN,fr=B.03.20.1,fa=HP-UX_B.11.11_32/64,v=HP: 2992764985 128 /etc/vx/aslkey.d/libvxautoraid.key 3685883292 112 /etc/vx/aslkey.d/libvxdgc.key 1990146669 96 /etc/vx/aslkey.d/libvxfc60.key 4170483542 96 /etc/vx/aslkey.d/libvxhds.key 1539490976 128 /etc/vx/aslkey.d/libvxhitachi.key 916595955 96 /etc/vx/aslkey.d/libvxva.key 1808911557 112 /etc/vx/aslkey.d/libvxxp256.key 3744732955 2003076 /etc/vx/static.d/build/vold.o 3960215777 258048 /etc/vx/type/fsgen/fs.d/vxfs/vxsync 568120953 376832 /etc/vx/type/gen/vxmake_static 1308203851 479232 /etc/vx/type/static/vxmake 1878087964 475136 /etc/vx/type/raid5/vxvol 2942594104 446464 /etc/vx/type/raid5/vxsd 1073714606 471040 /etc/vx/type/gen/vxvol 830131567 491520 /etc/vx/type/fsgen/vxplex 406998604 475136 /etc/vx/type/gen/vxplex 1200521007 233472 /usr/sbin/vxmake 2802863409 1743384 /etc/vx/type/static/vxconfigd 3007530923 512000 /etc/vx/type/static/vxedit 2908857097 397312 /etc/vx/type/gen/vxrlink 2734584531 380928 /etc/vx/type/gen/vxrvg 4050067658 544768 /etc/vx/type/static/vxprint 4288813713 196608 /sbin/vxedit 4288813713 196608 /sbin/vxmake 4288813713 196608 /sbin/vxprint 4288813713 196608 /sbin/vxconfigd 471731967 380928 /sbin/vxrecover 3018366254 24576 /usr/lib/vxvm/bin/nulldisk 2665512452 7668 /usr/lib/vxvm/bin/vxreattach 699894625 10922 /usr/lib/vxvm/bin/vxdisksetup 2056100391 6326 /usr/lib/vxvm/bin/vxpfto 2082657299 7159 /usr/lib/vxvm/bin/vxmirror 3301564663 65536 /usr/lib/vxvm/diag.d/vxkprint 747581344 98304 /usr/lib/vxvm/diag.d/vxprivutil 3756529508 176128 /usr/lib/vxvm/diag.d/vxconfigdump 1228314427 46688 /etc/vx/static.d/default/libvxarrays.a 343892325 24576 /usr/lib/vxvm/lib/discovery.d/ libvxautoraid.sl 206740176 24576 /usr/lib/vxvm/lib/discovery.d/libvxdgc.sl 402874898 24576 /usr/lib/vxvm/lib/discovery.d/libvxfc60.sl 3016527809 24576 /usr/lib/vxvm/lib/discovery.d/libvxhds.sl 2850087078 28672 /usr/lib/vxvm/lib/discovery.d/ libvxhitachi.sl 4164395082 24576 /usr/lib/vxvm/lib/discovery.d/libvxva.sl 2419910610 24576 /usr/lib/vxvm/lib/discovery.d/libvxxp256.sl 186951600 1799 /usr/sbin/dgcfgdaemon 1262692930 2688 /usr/sbin/dgcfgbackup 4050558649 7625 /usr/sbin/dgcfgrestore 2229177686 167936 /usr/sbin/vxrvg 2131800295 184320 /usr/sbin/vxrlink 2467092895 241664 /usr/sbin/vxedit 4165148866 475136 /usr/sbin/vxassist 2284968049 1556480 /usr/sbin/vxconfigd 2771431016 315392 /usr/sbin/vxddladm 519632791 282624 /usr/sbin/vxprint 3925430768 1174 /usr/lib/vxvm/bin/vxdmpen 3324169698 1175 /usr/lib/vxvm/bin/vxdmpdis 946904818 5487 /usr/lib/vxvm/voladm.d/bin/disk.mirror 3426750274 13741 /usr/lib/vxvm/voladm.d/bin/disk.repl 1671188177 64571 /usr/lib/vxvm/voladm.d/lib/vxadm_lib.sh 1141997224 102400 /usr/lib/vxvm/bin/vxhpcap 2390587215 43552 /usr/lib/vxvm/voladm.d/bin/disk.anal.ckinit 1638225708 14229 /usr/lib/vxvm/voladm.d/bin/disk.convert 673530599 46838 /usr/lib/vxvm/voladm.d/bin/disk.lvm.ckinit 888070867 2104 /usr/lib/vxvm/voladm.d/bin/minor_numchk 3769750491 42156 /usr/lib/vxvm/voladm.d/lib/vxadm_lvmlib.sh 491862189 47456 /usr/lib/vxvm/voladm.d/lib/vxadm_syslib.sh 1840944733 8487 /usr/lib/vxvm/voladm.d/bin/vxsave_lvmrecs 2196129147 11092 /usr/lib/vxvm/bin/vxlvmencap HPvxvm.VXVM-ENG-A-MAN,fr=B.03.20.1,fa=HP-UX_B.11.11_32/64, v=HP: 3966899384 3965 /usr/share/man/man1m.Z/vxdisksetup.1m Patch Conflicts: None Patch Dependencies: s700: 11.11: PHKL_28379 s800: 11.11: PHKL_28379 Hardware Dependencies: None Other Dependencies: None Supersedes: PHCO_25837 PHCO_27977 PHCO_25895 PHCO_26053 PHCO_26420 PHCO_27724 Equivalent Patches: None Patch Package Size: 6640 KBytes Installation Instructions: Please review all instructions and the Hewlett-Packard SupportLine User Guide or your Hewlett-Packard support terms and conditions for precautions, scope of license, restrictions, and, limitation of liability and warranties, before installing this patch. ------------------------------------------------------------ 1. Back up your system before installing a patch. 2. Login as root. 3. Copy the patch to the /tmp directory. 4. Move to the /tmp directory and unshar the patch: cd /tmp sh PHCO_28378 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHCO_28378.depot By default swinstall will archive the original software in /var/adm/sw/save/PHCO_28378. If you do not wish to retain a copy of the original software, include the patch_save_files option in the swinstall command above: -x patch_save_files=false WARNING: If patch_save_files is false when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. For future reference, the contents of the PHCO_28378.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHCO_28378.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHCO_28378.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None