Patch Name: PHCO_29379 Patch Description: s700_800 11.11 LVM commands cumulative patch Creation Date: 04/02/05 Post Date: 04/03/05 Hardware Platforms - OS Releases: s700: 11.11 s800: 11.11 Products: N/A Filesets: LVM.LVM-ENG-A-MAN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP LVM.LVM-MIRROR-RUN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP LVM.LVM-RUN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP Automatic Reboot?: No Status: General Release Critical: Yes PHCO_29379: ABORT PANIC CORRUPTION HANG PHCO_27913: ABORT PANIC PHCO_27408: ABORT This fixes a problem in the vgimport(1M) command which results in a core dump. PHCO_24809: ABORT PHCO_23333: CORRUPTION Category Tags: defect_repair hardware_enablement enhancement general_release critical panic halts_system corruption manual_dependencies Path Name: /hp-ux_patches/s700_800/11.X/PHCO_29379 Symptoms: PHCO_29379: ( SR:8606217852 CR:JAGad87002 ) During system startup Volume Group activation, failure error messages can be seen when VGs comprising of iSCSI Physical Volumes are present. System hangs may also be seen. Hardware Enablement: This product update is a member of a set needed to enable the optional iSCSI support in LVM. The full list of product updates required for this feature are: PHKL_30552 and PHCO_29379. ( SR:8606279722 CR:JAGae43711 ) In certain cases, installation of an LVM commands patch could cause error messages similar to the following in the installation log files. ERROR: The swmodify command failed for PHCO_23333.LVM-RUN,l=/,r=1.0,a=HP-UX_B.11.11_32/64,v=HP. The configuration process will proceed. ERROR: Rebuilding the Installed Products Database has failed. You may need to retry this operation. ( SR:8606305556 CR:JAGae68604 ) I/O errors may be seen while executing the vgcfgrestore(1M) command on a disk which is smaller than the original disk. ( SR:8606305780 CR:JAGae68828 ) Upon activation of a VG with several mirrored lvols, when a synchronization failure occurs on an lvol, vgsync(1M) fails to continue synchronizing the remaining lvols beyond the first failure encountered. ( SR:8606305784 CR:JAGae68832 ) On a system with PHCO_24809 or any superseding patch, running the lvlnboot(1M) command with -b, -r, -s or -d on a bootable volume group on a configuration with alternate links can cause corruption. This corruption can cause a panic when booting from the affected volume group with messages similar to the following: Logical volume 64, 0x3 configured as ROOT LVM : Failure in attaching PV (8/8.1.0) to the root volume group. Cross device link. The disk is not a LVM disk. LVM : Failure in attaching PV (8/4.1.0) to the root volume group. Cross device link. The disk is not a LVM disk. LVM : Activation of root volume group failed Either no physical volumes are attached or no valid VGDAs were found on the physical volumes. Quorum not present, or some physical volume(s) are missing --------------------------------------------------- | SYSTEM HALTING during LVM Configuration | | | | Could not configure root VG | --------------------------------------------------- panic: LVM: Configuration failure ( SR:8606305787 CR:JAGae68835 ) In certain situations, vgimport(1M) fails to import the volume group and returns with the error message - vgimport: Unable to read the physical volume. ( SR:8606315175 CR:JAGae77907 ) PHCO_24809 introduced behavior that can result in incorrect physical volume information to remain in the /etc/lvmtab file when vgcreate(1M) or vgextend(1M) is invoked with more than one physical volume. For example, the following message can be displayed: vgextend: Physical volume "PV2" could not be deleted from the "/etc/lvmtab" file. There is now an inconsistency between the LVM device driver and the "/etc/lvmtab" file. vgextend: Couldn't install the physical volume "PV2". Too many links ( SR:8606315178 CR:JAGae77910 ) If the size of a physical volume is less than the size of one physical extent (as specified in a vgcreate(1M) command), then LVM can exhibit incorrect behavior. One such problem is that an LVM daemon will endlessly loop, using up CPU. ( SR:8606315186 CR:JAGae77918 ) The lvlnboot(1M) command gives a misleading message when it cannot get root configuration. The message displayed is: "Could find the root lv related information to create /stand/rootconf file." This message should be "Could not find..." ( SR:8606316260 CR:JAGae78977 ) If any duplicate pv path entries are provided to the vgimport(1M) command, no errors are reported and the command silently fails to complete. ( SR:8606320951 CR:JAGae83433 ) If a Volume Group has greater than 256 Physical Volumes (including alternate links), then vgscan(1M) fails with a meaningless message. For eg. vgscan(1M) on /dev/vg01 returns - vgscan: H Òè_ õ ò has no correspoding valid raw device file under /dev/rdsk. Verification of unique LVM disk id on each disk in the volume group /dev/vg01 failed. ( SR:8606344120 CR:JAGaf04972 ) vgcfgrestore(1M) can fail on a Physical Volume which is part of a currently active Volume Group, even when the path to the Physical Volume and the configuration file used for restore are correct. ( SR:8606323332 CR:JAGae85797 ) Exporting or creating (through the use of vgexport(1M) or vgcreate(1M) respectively) an LVM volume group can result in system panic at execution of subsequent LVM commands The stack trace is as follows - lock_write+0x14 lv_close+0x78 call_open_close+0x274 closed+0xb0 spec_close+0x54 vn_close+0x48 vno_close+0x20 closef+0x64 exit+0x1128 rexit+0x28 syscall+0x6f8 syscallinit+0x54c ( SR:8606352319 CR:JAGaf13124 ) The vgcreate(1M) and vgextend (1M)commands expect properly formatted PVs as parameters. PVs are formatted using pvcreate(1M). If a PV which is not properly formatted is passed to vgcreate(1M) or vgextend(1M), then the behavior will vary depending on the data on the PV. If a PV which has not been formatted with pvcreate(1M) is passed to vgcreate(1M) or vgextend(1M) then the command will abort with an I/O error. If a PV which has been formatted is unformatted with pvremove(1M) and then passed to vgcreate(1M) or vgextend(1M), then the PV will be skipped and any other PVs specified will be added to the VG. This behavior should not be inconsistent. Also, an unformatted PV should be treated the same a an unavailable PV. On finding that a PV is unformatted the command should abort with an appropriate error message PHCO_27913: ( SR:8606255308 CR:JAGae19635 ) When non unique minor numbers exist on the system, the vgimport(1M) command prints out one of the following messages: "Minor number of ___ is not unique. ___ has the same minor number." "Minor number of ___ is not unique. Conflicts with other volume group file." Instead of aborting, the vgimport(1M) command will incorrectly continue the import. This will make one of the volume groups inaccessible, and the user may have to reboot and reassign a unique minor number to the volume group in order to access both volume groups. ( SR:8606198887 CR:JAGad68076 ) When the vgchange(1M) command is used to activate a non- shared volume group which contains a disk previously used in a shared volume group, the volume group activation may fail. The following message may be displayed: vgchange: Activation mode requested for the volume group "/dev/vgtest" conflicts with configured mode. The following scenario can lead to the problem: - A disk was used in a shared volume group. - The same disk is reused in a non-shared volume group through the vgcreate(1M) command. - The volume group is deactivated. - The volume group is reactivated. ( SR:8606199556 CR:JAGad68743 ) When the lvremove(1M) command removes a logical volume in the root volume group, the following stack trace can result after a system panic: > panic+0x6c > report_trap_or_int_and_panic+0x94 > trap+0xf48 > nokgdb+0x8 > lv_rw_one_mirror+0xc0 > lv_schedule1+0x10c > lv_schedule+0x60 > lv_initiate+0x158 > lv_strategy+0x298 > lv_syncio+0xbc > lif_locate+0x130 > lv_readlabel+0xbc > lv_getpdisc+0xa4 > lv_lvswapmaint+0x78 > lv_swap_to_dump+0x60 > swap_to_dump+0x5c > dumpconf+0x164 > DoCalllist+0x3c > main+0x28 ( SR:8606223480 CR:JAGad92577 ) The vgscan(1M) command will not work correctly if vg00 does not appear first in /etc/lvmtab. If the user attempts to recreate the lvmtab with a vgscan, vg00 and all of the physical volumes associated with it will not be placed in the lvmtab. ( SR:8606266304 CR:JAGae30553 ) When lvlnboot(1M) is executed, the command may cause data corruption if a disk is missing or has failed. The wrong disk may also be marked as missing. These problems can only occur when one or more disks in an activated volume group are missing or have failed. ( SR:8606235481 CR:JAGae04635 ) The vgcfgbackup(1M) and pvremove(1M) commands may not return errors when there are partial failures of reads and writes. ( SR:8606230792 CR:JAGae00030 ) The vgchgid(1M) command can corrupt the Boot Data Reserved Area (BDRA), making the system unable to boot (except in maintenance mode). When lvlnboot(1M) is executed from maintenance mode, a flag is cleared which prevents LVM from recognizing the previous maintenance mode boot. This creates different data on mirrored copies, leading to silent data corruption in the root filesystem. ( SR:8606251163 CR:JAGae17229 ) Currently the vgremove(1M) command incorrectly allows a clustered volume group to be removed. This can lead to problems whose symptoms may include: - The inability to halt the cluster software. The command cmhaltcl(1M) will fail. - The inability to deactivate an unrelated volume group which may have been created at a later time. This volume group may appear to be activated in exclusive mode. ( SR:8606226992 CR:JAGad96054 ) The lvcreate(1M) command will core dump and create an lvol of size 0 when too large of a size is specified with the -L argument. The maximum size is determined by the extent size * number of extents (default 65535). PHCO_27408: ( SR:8606251225 CR:JAGae17291 ) This product update provides LVM support for the VA7405 and VA7410 disk arrays. Without this product update, there is a potential risk of data corruption when these disk arrays are used with LVM. ( SR:8606247046 CR:JAGae13486 ) The vgimport(1M) command may core dump when the number of physical volumes specified on the command line is less than the total number of physical volumes in the volume group. This happens with all of the LVM commands patches between PHCO_24809 and PHCO_25814. PHCO_27099: ( SR:8606262676 CR:JAGae27007 ) The VERITAS Volume Manager (VxVM) is not able to create workable root/boot disk on a system. PHCO_25814: ( SR:8606227294 CR:JAGad96355 ) PHCO_24809 Introduced an extra 10 seconds delay during LVM volume group activation, when all the disks in the volume group are present. PHCO_25390: ( SR:8606220106 CR:JAGad89247 ) PHCO_24809 introduced behavior that will cause the lvlnboot(1M) command to fail when executed in recovery mode. Executing 'lvlnboot -R' will fail to configure swap and dump volumes and messages similar to the following will be reported: lvlnboot: Unable to configure swap logical volume. Swap logical volume size beyond the IODC max address. lvlnboot: Unable to configure dump logical volume. Dump logical volume size beyond the IODC max address. PHCO_24809: ( SR:8606196725 CR:JAGad65923 ) A volume group (VG) which is activated shared (vgchange -a s), may be left with Physical volumes (PVs) still attached on de-activation. If the VG is then exported, it will not be possible to import and activate a different VG using the same group file minor number without rebooting. Typical activation error: vgchange: Couldn't set the unique id for volume group "XXX": File exists ( SR:8606204445 CR:JAGad73627 ) The pvdisplay -v command shows incorrect information about physical extent(s) and logical extent(s), if the number of the extent(s) is more than 9999. ( SR:8606195190 CR:JAGad64396 ) When the size of the file "/etc/lvmpvg" gets more than 8k bytes (characters), customers may encounter the following problems: lvcreate fails with: Error detected when reading from file "/etc/lvmpvg". pvdisplay reports a warning: Bad file "/etc/lvmpvg": Missing PVG keyword. ( SR:8606202819 CR:JAGad71993 ) The vgcfgbackup command gives incorrect information about the given file name. User might see the following error message: vgcfgback: Invalid filename: "XXX" specfied with -f. ( SR:8606214397 CR:JAGad83588 ) When more than one Volume Groups in LVM uses the same minor number they overstep on each others data structures in the kernel resulting in unpredictable behaviour with any of the operations with these volume groups. This problem will not go away even after removing both the volume groups. Any creation of a volume group with the same minor number (after removing all the Volume Groups using that minor number) would fail with the following message even though there is no volume group using that minor number at this time. vgcreate: Volume group "/dev/vgX" could not be created: A volume group is already using this major and minor number. Please check the minor number of the "group" device file. ( SR:8606198832 CR:JAGad68021 ) The lvlnboot -v command displays incorrect boot disk information when the boot disks order in the lvmtab file is reversed. ( SR:8606214419 CR:JAGad83610 ) LVM commands coredump. Due to stack size overflow. ( SR:8606186700 CR:JAGad55910 ) The pvcreate manual page does not document that pvcreate when invoked with the -f may overwrite disks under the control of the Veritas volume manager. ( SR:8606189090 CR:JAGad58306 ) The lvextend command could lead to data corruption, if the user enters the same physical volume more than once in the command line. ( SR:8606166168 CR:JAGad35455 ) The vgscan command puts a bogus entry in the lvmtab file, when a special file /dev/slvmvg is present with the same minor number as /dev/vg00. ( SR:8606213740 CR:JAGad82931 ) Very slow activation when physical volume links are down.If some of the links to physical volumes in a LVM volume group are not accessible then activation of volume group containing these physical links would take from several minutes to hours depending upon the number of unavailable links. ( SR:8606204444 CR:JAGad73626 ) When running lvdisplay simultaneously with the pvmove and the lvmerge commands, the lvdisplay command displays zeros extent information. PHCO_23333: ( SR:8606181365 CR:JAGad50582 ) Data loss and corruption can result from attempting to use LVM with "Virtual Array" disk arrays. Defect Description: PHCO_29379: ( SR:8606217852 CR:JAGad87002 ) Without the changes delivered by this patch, unrecognized errors will be returned by iSCSI PVs which will cause these PVs not to be attached to the Volume Group. Mounting filesystems residing on logical volumes comprising of iSCSI PVs will then result in error messages as the iSCSI PVs will not be accessible at the time filesystems are mounted during the boot-up sequence. This product update contains minor enhancements required to enable iSCSI support in LVM. Resolution: The code was modified to recognize the presence of iSCSI PVs at boot up time, and to allow the activation of these volume groups to be retried. Error messages which would have normally resulted from the failed activation have now been changed to notification messages for these cases. ( SR:8606279722 CR:JAGae43711 ) This error is the result of the configure script of LVM commands patches making an assumption that if the LVM-MIRROR-RUN fileset of the patch is installed the LVM-RUN fileset of the same patch is also installed. Resolution: The patch scripts were modified to remove any assumptions regarding the filesets installed. ( SR:8606305556 CR:JAGae68604 ) vgcfgrestore(1M) does not check that the new disk is at least as large as the old disk before restoring the configuration. Resolution: vgcfgrestore(1M) now verifies that the new disk is at least as large, or larger than the old disk. If the new disk is smaller than the old disk, then it displays an error message and aborts the operation. ( SR:8606305780 CR:JAGae68828 ) The vgsync(1M) command synchronizes the logical volumes serially inside a loop statement. The command exits this loop upon encountering the first error and it does not attempt to synchronize the remaining logical volumes. Resolution: Now the vgsync(1M) command continues with the synchronization of the remaining logical volumes even if it encounters an error with any logical volume, and it displays an error message, if required. ( SR:8606305784 CR:JAGae68832 ) The lvlnboot(1M) command will corrupt the Boot Data Reserved Area's portion in an alternate link configuration due to allocating an incorrect amount of memory. Resolution: The lvlnboot(1M) command has been modified to allocate the correct amount of memory to match the number of entries in the lvmtab file. ( SR:8606305787 CR:JAGae68835 ) On a physical volume, two copies of status information are maintained. During vgimport(1M), the best copy should be selected from the available copies. vgimport(1M) was incorrectly checking only the first copy of the status information and would fail if it was not valid even though the second copy was. Resolution: The vgimport(1M) code was modified to check for the second copy of the status area if the first copy is corrupt. ( SR:8606315175 CR:JAGae77907 ) When the vgextend(1M) or vgcreate(1M) commands are supplied with more than one physical volumes, and there is a failure in installing any of the PVs, then there is an incorrect initialization of a pointer in the code resulting in incorrect data remaining in the /etc/lvmtab file. Resolution: The code is modified to correctly initialize the pointers so that the /etc/lvmtab file contains correct data. ( SR:8606315178 CR:JAGae77910 ) If a physical volume is smaller than the physical extent size, then in some cases LVM will attempt to read beyond the end of the physical device. Resolution: The code was modified to prevent the situation where a physical volume can be smaller than the extent size. ( SR:8606315186 CR:JAGae77918 ) The word "not" is missing from the message. Resolution: The lvlnboot(1M) message has been modified to include the missing word. ( SR:8606316260 CR:JAGae78977 ) Although the duplicate entry is recognized by the code, the failure causes the command to abort in a way that the error is not reported to the user. Resolution: The code was modified to check for the duplicate physical volume and display an appropriate error message. ( SR:8606320951 CR:JAGae83433 ) The size allocated to the array containing the list of PVs is less that the possible number of PVs and alternate links to PVs in a VG. When a larger number of PVs are encountered, vgscan(1M) attempts to write beyond the array limits, and fails. Resolution: The size of the array for holding the PVs has now been correctly allocated. ( SR:8606344120 CR:JAGaf04972 ) During restoring of volume group configuration information on a Physical Volume(PV), the number of PVs in the backup file used for restore is verified against the number of PVs actually in the currently active VG. If the verification fails then the operation is aborted. This verification method is incorrect, since alternate links to a PV are considered whereas alternate links are not present in the backup file. Resolution: The validation of the number of PVs in the active VG against the number in the backup file is not required and is in some cases wrong, hence it is removed. ( SR:8606323332 CR:JAGae85797 ) This problem occurs when, unknowingly by the user, a volume group file is created with a vg index number already in use. The current LVM algorithm rejects any new minor number (0xMMMMMM) if it matches any pre-existing minor number. However, it fails to recognize that the vg index number (represented by 0xNN0000) could still be duplicated. (For example 0x123456 and 0x120000). Resolution: The fix for this is to restrict the vgcreate(1M) and vgimport(1M) commands to only accept group files with the format of 0xNN0000. ( SR:8606352319 CR:JAGaf13124 ) The code which opens, reads, and validates the metadata on a PV properly aborts if it cannot open or read the PV, but fails to abort when it finds invalid metadata. Resolution: The code now causes the command to abort when it finds corrupt metadata. PHCO_27913: ( SR:8606255308 CR:JAGae19635 ) When a function inside vgimport(1M) discovers that the volume group does not have a unique minor number, it prints out an error message and returns the wrong value to the calling function. So instead of aborting, vgimport(1M) continues to import a volume group with a duplicate minor number. This can result in kernel data structures being corrupted. Resolution: Change the value that the function in vgimport(1M) returns, so the command will abort an attempt to import a volume group with a duplicate minor number. ( SR:8606198887 CR:JAGad68076 ) When a disk is used in a shared volume group, it is assigned a cluster id. When this disk is reused, the cluster id is not removed properly. Resolution: A change was made to vgexport(1M) to clear the cluster id and configured activation mode upon export. When the vgcreate(1M) command is ran after vgexport(1M), the cluster id is then set to null and the activation mode is set to a standard configuration mode. ( SR:8606199556 CR:JAGad68743 ) When the lvremove(1M) command removes a logical volume in the root volume group, the lvlnboot(1M) command is invoked with the "-R" option. As a result, a "-1" is marked in two fields of the Boot Data Reserved Area (BDRA). This causes the subsequent activation to think the swap LV disk is itself an LV. This can eventually result in a system panic. Resolution: The lvlnboot(1M) command was modified to print out a warning message when lvlnboot(1M) fails. It also marks the swap device as not present, preventing any confusion upon next boot. ( SR:8606223480 CR:JAGad92577 ) The vgscan(1M) command was dependent on the order of volume groups in /etc/lvmtab. When the first volume group in /etc/lvmtab is not vg00, the physical volumes associated with vg00 will not be added to the /etc/lvmtab file. Resolution: Modified the vgscan(1M) command so that it no longer depends on the order of the volume groups in the /etc/lvmtab file. ( SR:8606266304 CR:JAGae30553 ) The wrong array index was used when setting the error flag of a physical volume. This will only occur when the lvlnboot(1M) command is executed and a disk is missing or has failed. Resolution: A one line code change was made to correct the index used to mark the bad disk. ( SR:8606235481 CR:JAGae04635 ) The vgcfgbackup(1M) and pvremove(1M) commands have some read and write calls which do not properly check the amount of data read or written. They currently just check that at least one byte of data was written. Although it is rare, there are some cases in which only a part of the data was read or written. Resolution: The read and write calls in both the vgcfgbackup(1M) and pvremove(1M) commands now check to ensure that all data was read or written correctly. ( SR:8606230792 CR:JAGae00030 ) The vgchgid(1M) command replaces the volume group id fields correctly, but does not recalculate the checksum with the new volume group ids. This causes the validation of the Boot Data Reserved Area (BDRA) to fail, making the system using this BDRA not bootable (except in maintenance mode). Resolution: The vgchgid(1M) command now recalculates the checksum with the new volume group ids. ( SR:8606251163 CR:JAGae17229 ) Before removing a volume group, vgremove(1M) does not check to see if a volume group is part of a cluster. When an active clustered volume group is removed in this manner, other nodes in the cluster are not notified of the volume group's removal. Because the other nodes do not know that the volume group has been removed, the cmhaltcl (1M) command will fail. The vgremove command also does not completely remove an active clustered volume group, so there will be residual data which may interfere with a volume group created in the future. Resolution: The code has been modified to prevent the vgremove (1M) command from removing an active volume group which is part of a cluster. The volume group should first be made non- clustered and then removed. The correct procedure to remove a clustered volume group is described below: 1. Deactivate the volume group on all nodes in the cluster. 2. Export the volume group on all nodes except one. 3. Make the volume group non-clustered on the remaining node. 4. Activate the volume group locally on the remaining node. 5. Remove the volume group. ( SR:8606226992 CR:JAGad96054 ) The problem is that the lvcreate(1M) command doesn't check the parameters against the maximum limit when -L is used. The bad parameter eventually causes a memory fault. Resolution: A check was added to lvcreate(1M) which checks that logical_volume_size/physical_extent_size < LVM_maximum_extents when the L option is used. If a size specified with the -L option results in too many extents (based on the extent size of the VG) then an error message will be displayed. PHCO_27408: ( SR:8606251225 CR:JAGae17291 ) This product update contains minor enhancements required to enable the VA7405 and VA7410 disk arrays to be used with LVM. Resolution: Changes were made in LVM to use a unique identifier for each LUN belonging to the VA7405 and VA7410 disk arrays. With these changes the VA7405 and VA7410 disk arrays can be used with LVM. ( SR:8606247046 CR:JAGae13486 ) This problem was exposed when a statically allocated array was changed to a dynamically allocated array. During the execution of the vgimport(1M) command, a function was still assuming the array to be static, and was trying to access elements past the end of the dynamically allocated array. Stepping past the end of the array is what caused the vgimport(1M) command to core dump. Resolution: The function no longer assumes the array to be a specific size. The function now looks at a variable which contains the number of elements in the array instead of relying on a maximum constant variable. PHCO_27099: ( SR:8606262676 CR:JAGae27007 ) The LVM library was not able to identify VxVM disks that contain Cross platform Data Sharing (CDS) identifier labels. Resolution: Enhance the LVM library to be able to identify VxVM disks that contain CDS identifier labels. PHCO_25814: ( SR:8606227294 CR:JAGad96355 ) Patch PHCO_24809 contained fixes to improve the volume group activation time of a volume group containing unavailable physical volumes. However, this fix introduced a 10 second delay during activation of a volume group with all the physical volumes are present. In all other cases the fix improves the activation time. According to the fix in patch PHCO_24809, during attaching of physical volumes, LVM will try opening all the physical volumes and if some opens fail, it will retry one more time after a delay of 10 seconds before giving up on the failed physical volumes. So the delay of 10 seconds should happen only upon retry, but instead it is happening for every try. Resolution: Corrected the retry loop to invoke delay only during retry and not every time. PHCO_25390: ( SR:8606220106 CR:JAGad89247 ) LVM dump and swap logical volumes should not extend beyond the maximum IODC block address of the device on which these contiguous logical volumes reside. To enforce this, lvlnboot(1M) verifies that logical volume size for dump and swap device is less than the maximum IODC block address of the device, which is obtained by doing an ioctl to the kernel with raw device id of the underlying device as an argument. In PHCO_24809, as part of a code cleaup a typo error was made where block device id was set for the ioctl instead of raw device id. As a result, the ioctl call was failing and it caused the lvlnboot(1M) command to fail. Resolution: Corrected the problem in the ioctl argument, now it gets the maximum IODC block address from the raw device. PHCO_24809: ( SR:8606196725 CR:JAGad65923 ) When a shared volume group is deactivated and then exported, the volume group ID (vgid) is not cleared from the volgrp structure. If the shared volume group is imported later on with a different minor number, there will be two different volgrp structures in the array with the same vgid - one is a leftover, another one is created at the time of vg activation. When the new VG is de-activated the previously used (no longer active) volgrp slot may be incorrectly used. This will result in the new volgrp being de-activated but with the PVs pvol structures still attached. The latest volgrp cannot be re-used with a different vgid without a system reboot. If this process is repeated the finite number of volgrp structures may be exhausted. Resolution: Vgexport will clear the volume group id while exporting the volume group. ( SR:8606204445 CR:JAGad73627 ) LVM only allows 4 digits for displaying the number of logical and physical extent(s). Resolution: Changed the LVM code to now allow 5 digits fields. ( SR:8606195190 CR:JAGad64396 ) The LVM library code used a C library "ungetc" which has a 8k boundary which caused problem when the length of the ungetted strings is more than 8k. Resolution: The LVM library code has been modified to fix the problem. ( SR:8606202819 CR:JAGad71993 ) The vgcfgbackup command did not check the file name correctly. Resolution: Modified the vgcfgbackup command to fix the problem. ( SR:8606214397 CR:JAGad83588 ) For every volume group configured, has an element in the volume group data strures array in the kernel which contains information specific to the volume group in the kernel. This entry is indexed by the group id (minor number) created during creation of the volume group. Since each entry contains information specific to a volume group, every volume group should have a unique group id. If more than one volume groups are created with the same group id, then they all map to the same element in the kernel data structure, resulting in corruption of the data structure. This causes unpredictable results with operations on all these volume groups and even the export of these volume groups does not happen cleanly resulting in prohibiting any further use of these minor numbers even after removing these volume groups. Resolution: Added a new check in vgcreate and vgimport to verify for the unique group id, so that an entry in the kernel data structure for the volume group is used only by this volume group. The check verifies that the group id file is unique in the /dev directory and is not used by any volume group. ( SR:8606198832 CR:JAGad68021 ) The lvlnboot command does not pick up the correct boot disk information when the boot disk order was reversed. Resolution: The lvlnboot command was modified to pick up the refreshed boot disk information. ( SR:8606214419 CR:JAGad83610 ) In LVM commands, some of the large size arrays are statically allocated resulting in stack size overflow, which causes the commands to coredump when run. Resolution: All the arrays and data stuctures are dynamically allocated resulting in less stack size usage. ( SR:8606186700 CR:JAGad55910 ) The manual page is incomplete. It should warn of the possible pitfalls of using the -f option. Resolution: The document was corrected to fully describe the behavior of the pvcreate -f option. ( SR:8606189090 CR:JAGad58306 ) A list of unique Physical Volumes is not properly built during lvextend, and it leads to a case where multiple entries of a same physical volume could be present list. Resolution: Added a new check during mapping of logical extents to physical extent to verify that no physical extent is mapped more than once. ( SR:8606166168 CR:JAGad35455 ) vgscan looks for all special files with major number 0x64 under /dev and assumes that the directory in which it is present is a volume group name. Resolution: The vgscan command is modified to check the group file under each volume group directory. ( SR:8606213740 CR:JAGad82931 ) During Volume Group activation, LVM opens each physical link associated with the volume group. If the link is unavailable i.e. open returns ENXIO error, LVM retries opening the physical link for a maximum of 10 retries with a sleep of one second between each retry. Opening of physical links is a serial operation with commands issuing one open at a time. Since opening a physical link would take tens of seconds and total time of opening links is a cummulative of these times it would take several minutes to hours depending upon number of unavailable links in the volume group. Resolution: Fixing this defect requires corresponding kernel and commands patch. Since most of the time is spent in the one second sleeps between the retries and actual time opening the device being negligible chainging the retry per device to retry per opening of all devices reduces the sleep time from (number of unavailable links * 10 seconds) to 10 seconds. Hence the total time will be a fraction more than the 10 seconds. For this kernel provides interface to open a device with no retries and the commands opens all the devices and then retries again all the unavailable devices after the retry sleep time. ( SR:8606204444 CR:JAGad73626 ) LVM commands are not designed to have multiple command running at the same time. Incorrect information was displayed due to the problem. Resolution: Fix the lvdisplay command to display more meaningful error message. PHCO_23333: ( SR:8606181365 CR:JAGad50582 ) "Virtual Array" family of disks support splitting a LUN. Since this results in a new disk with identical data to the original disk, verifying the pvid and vgid information on disk is no longer sufficient in determining which links are alternate links to a LUN. This could result in data loss or corruption by LVM using what it believes is an alternate link to the original LUN when it is actually using a link to the new LUN created by the split. Resolution: "Virtual Array" specific functionality to LVM was added by using the array specific LUN id as a unique identifier when we are attempting to identify alternate links and disks with duplicate LVM metadata. Enhancement: No (superseded patches contained enhancements) PHCO_27913: Enhancements were delivered in a patch this one has superseded. Please review the Defect Description text for more information. SR: 8606166168 8606181365 8606186700 8606189090 8606195190 8606196725 8606198832 8606198887 8606199556 8606202819 8606204444 8606204445 8606213740 8606214397 8606214419 8606217852 8606220106 8606223480 8606226992 8606227294 8606230792 8606235481 8606247046 8606251163 8606251225 8606255308 8606262676 8606266304 8606279722 8606305556 8606305780 8606305784 8606305787 8606315175 8606315178 8606315186 8606316260 8606320951 8606323332 8606344120 8606352319 Patch Files: LVM.LVM-ENG-A-MAN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: /usr/share/man/man1m.Z/pvcreate.1m LVM.LVM-MIRROR-RUN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: /usr/newconfig/sbin/lvchange.mir /usr/newconfig/usr/sbin/lvchange.mir LVM.LVM-RUN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: /sbin/lvchange /sbin/lvcreate /sbin/lvdisplay /sbin/lvextend /sbin/lvlnboot /sbin/lvreduce /sbin/lvremove /sbin/lvrmboot /sbin/pvchange /sbin/pvck /sbin/pvcreate /sbin/pvdisplay /sbin/pvmove /sbin/pvremove /sbin/vgcfgbackup /sbin/vgcfgrestore /sbin/vgchange /sbin/vgchgid /sbin/vgcreate /sbin/vgdisplay /sbin/vgexport /sbin/vgextend /sbin/vgimport /sbin/vgreduce /sbin/vgremove /sbin/vgscan /usr/lib/nls/msg/C/lvm.cat /usr/newconfig/sl /usr/newconfig/usl /usr/sbin/lvchange /usr/sbin/lvcreate /usr/sbin/lvdisplay /usr/sbin/lvextend /usr/sbin/lvlnboot /usr/sbin/lvreduce /usr/sbin/lvremove /usr/sbin/lvrmboot /usr/sbin/pvchange /usr/sbin/pvck /usr/sbin/pvcreate /usr/sbin/pvdisplay /usr/sbin/pvmove /usr/sbin/pvremove /usr/sbin/vgcfgbackup /usr/sbin/vgcfgrestore /usr/sbin/vgchange /usr/sbin/vgchgid /usr/sbin/vgcreate /usr/sbin/vgdisplay /usr/sbin/vgexport /usr/sbin/vgextend /usr/sbin/vgimport /usr/sbin/vgreduce /usr/sbin/vgremove /usr/sbin/vgscan what(1) Output: LVM.LVM-ENG-A-MAN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: /usr/share/man/man1m.Z/pvcreate.1m: None LVM.LVM-MIRROR-RUN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: /usr/newconfig/sbin/lvchange.mir: None /usr/newconfig/usr/sbin/lvchange.mir: None LVM.LVM-RUN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: /sbin/lvchange: None /sbin/lvcreate: None /sbin/lvdisplay: None /sbin/lvextend: None /sbin/lvlnboot: None /sbin/lvreduce: None /sbin/lvremove: None /sbin/lvrmboot: None /sbin/pvchange: None /sbin/pvck: None /sbin/pvcreate: None /sbin/pvdisplay: None /sbin/pvmove: None /sbin/pvremove: None /sbin/vgcfgbackup: None /sbin/vgcfgrestore: None /sbin/vgchange: None /sbin/vgchgid: None /sbin/vgcreate: None /sbin/vgdisplay: None /sbin/vgexport: None /sbin/vgextend: None /sbin/vgimport: None /sbin/vgreduce: None /sbin/vgremove: None /sbin/vgscan: None /usr/lib/nls/msg/C/lvm.cat: None /usr/newconfig/sl: None /usr/newconfig/usl: None /usr/sbin/lvchange: None /usr/sbin/lvcreate: None /usr/sbin/lvdisplay: None /usr/sbin/lvextend: None /usr/sbin/lvlnboot: None /usr/sbin/lvreduce: None /usr/sbin/lvremove: None /usr/sbin/lvrmboot: None /usr/sbin/pvchange: None /usr/sbin/pvck: None /usr/sbin/pvcreate: None /usr/sbin/pvdisplay: None /usr/sbin/pvmove: None /usr/sbin/pvremove: None /usr/sbin/vgcfgbackup: None /usr/sbin/vgcfgrestore: None /usr/sbin/vgchange: None /usr/sbin/vgchgid: None /usr/sbin/vgcreate: None /usr/sbin/vgdisplay: None /usr/sbin/vgexport: None /usr/sbin/vgextend: None /usr/sbin/vgimport: None /usr/sbin/vgreduce: None /usr/sbin/vgremove: None /usr/sbin/vgscan: None cksum(1) Output: LVM.LVM-ENG-A-MAN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: 2326987365 2986 /usr/share/man/man1m.Z/pvcreate.1m LVM.LVM-MIRROR-RUN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: 3859099433 851968 /usr/newconfig/sbin/lvchange.mir 2552010680 565248 /usr/newconfig/usr/sbin/lvchange.mir LVM.LVM-RUN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP: 4119461593 831488 /sbin/lvchange 4119461593 831488 /sbin/lvcreate 4119461593 831488 /sbin/lvdisplay 4119461593 831488 /sbin/lvextend 4119461593 831488 /sbin/lvlnboot 4119461593 831488 /sbin/lvreduce 4119461593 831488 /sbin/lvremove 4119461593 831488 /sbin/lvrmboot 4119461593 831488 /sbin/pvchange 4119461593 831488 /sbin/pvck 4119461593 831488 /sbin/pvcreate 4119461593 831488 /sbin/pvdisplay 4119461593 831488 /sbin/pvmove 4119461593 831488 /sbin/pvremove 4119461593 831488 /sbin/vgcfgbackup 4119461593 831488 /sbin/vgcfgrestore 4119461593 831488 /sbin/vgchange 4119461593 831488 /sbin/vgchgid 4119461593 831488 /sbin/vgcreate 4119461593 831488 /sbin/vgdisplay 4119461593 831488 /sbin/vgexport 4119461593 831488 /sbin/vgextend 4119461593 831488 /sbin/vgimport 4119461593 831488 /sbin/vgreduce 4119461593 831488 /sbin/vgremove 4119461593 831488 /sbin/vgscan 1799784090 46768 /usr/lib/nls/msg/C/lvm.cat 3859099433 851968 /usr/newconfig/sl 2552010680 565248 /usr/newconfig/usl 3262709266 540672 /usr/sbin/lvchange 3262709266 540672 /usr/sbin/lvcreate 3262709266 540672 /usr/sbin/lvdisplay 3262709266 540672 /usr/sbin/lvextend 3262709266 540672 /usr/sbin/lvlnboot 3262709266 540672 /usr/sbin/lvreduce 3262709266 540672 /usr/sbin/lvremove 3262709266 540672 /usr/sbin/lvrmboot 3262709266 540672 /usr/sbin/pvchange 3262709266 540672 /usr/sbin/pvck 3262709266 540672 /usr/sbin/pvcreate 3262709266 540672 /usr/sbin/pvdisplay 3262709266 540672 /usr/sbin/pvmove 3262709266 540672 /usr/sbin/pvremove 3262709266 540672 /usr/sbin/vgcfgbackup 3262709266 540672 /usr/sbin/vgcfgrestore 3262709266 540672 /usr/sbin/vgchange 3262709266 540672 /usr/sbin/vgchgid 3262709266 540672 /usr/sbin/vgcreate 3262709266 540672 /usr/sbin/vgdisplay 3262709266 540672 /usr/sbin/vgexport 3262709266 540672 /usr/sbin/vgextend 3262709266 540672 /usr/sbin/vgimport 3262709266 540672 /usr/sbin/vgreduce 3262709266 540672 /usr/sbin/vgremove 3262709266 540672 /usr/sbin/vgscan Patch Conflicts: None Patch Dependencies: s700: 11.11: PHKL_24779 s800: 11.11: PHKL_24779 Hardware Dependencies: None Other Dependencies: PHCO_29379: To enable iSCSI support in LVM, the following must be installed: PHKL_30552 and PHCO_29379. These product updates may be installed in any order. This patch is a member of a set of patches needed to enable VxVM rootability on HP-UX 11i. The patch set includes PHKL_27096, PHCO_27099, PHCO_27100, PHCO_27101, PHCO_27103, and PHCO_27209. If any of the patches belonging to this set is not installed on the system, then the VxVM rootability feature will not function. When the HP-UX 11i 0902 OEUR is installed, it will install the full set of required patches for VxVM, including this patch. Supersedes: PHCO_27913 PHCO_27408 PHCO_27099 PHCO_25814 PHCO_25390 PHCO_24809 PHCO_23333 Equivalent Patches: None Patch Package Size: 1840 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_29379 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHCO_29379.depot By default swinstall will archive the original software in /var/adm/sw/save/PHCO_29379. 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_29379.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHCO_29379.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHCO_29379.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None