Patch Name: PHCO_27653 Patch Description: s700_800 11.04 (VVOS) LVM commands cumulative patch Creation Date: 02/08/05 Post Date: 02/09/17 Hardware Platforms - OS Releases: s700: 11.04 s800: 11.04 Products: N/A Filesets: LVM.LVM-ENG-A-MAN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP LVM.LVM-MIRROR-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP LVM.LVM-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP Automatic Reboot?: No Status: General Release Critical: Yes PHCO_27653: ABORT PANIC CORRUPTION Based on HP-UX Patch PHCO_27369: ABORT CORRUPTION Based on HP-UX Patch PHCO_24645: ABORT CORRUPTION Based on HP-UX Patch PHCO_24437: CORRUPTION Based on HP-UX Patch PHCO_23791: CORRUPTION Based on HP-UX Patch PHCO_23499: PANIC Category Tags: defect_repair hardware_enablement enhancement general_release critical panic halts_system corruption Path Name: /hp-ux_patches/s700_800/11.X/PHCO_27653 Symptoms: PHCO_27653: Ported HP-UX patch PHCO_27369 to VVOS Note: VA7405 and VA7410 disk arrays are not supported on VVOS 11.04. Based on HP-UX patch PHCO_27369: (SR: 8606251224 CR: JAGae17290) Enhancement: 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: 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 following: - 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: 8606266310 CR:JAGae30559) 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. Based on HP-UX patch PHCO_24645: ( SR: 8606189031 CR: JAGad58247 ) lvcreate(1M) core dumps when logical volume size specified results in more than the maximum extents allowed for the volume. ( SR: 8606185504 CR: JAGad54697 ) 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: 8606196637 CR: JAGad65840 ) LVM commands with -A n (no auto backup) could potentially core dump. ( SR: 8606218155 CR: JAGad87305 ) LVM commands can be killed through SIGPIPE signal and leave the LVM data structures in unusable state. ( SR: 8606159704 CR: JAGad29030 ) 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 behavior 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: 8606218794 CR: JAGad87942 ) vgextend(1M) command core dumps when adding an alternate link to a volume group which has over 256 links attached. ( SR: 8606220972 CR: JAGad90108 ) LVM commands coredump. Due to stack size overflow. ( SR: 8606207075 CR: JAGad76248 ) lvlnboot -v displays "PV Name" instead of "Boot" if LANG=C is set. Based on HP-UX patch PHCO_24437: ( SR: 1653162065 CR: JAGaa10504 ) When running lvdisplay simultaneously with the pvmove and the lvmerge commands, the lvdisplay command displays zeros extent information. ( SR: 8606198826 CR: JAGad68015 ) The lvlnboot -v command displays incorrect boot disk information when the boot disks order in the lvmtab file is reversed. ( SR: 5003432500 CR: JAGaa52059 ) 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: 8606161148 CR: JAGad30464 ) The vgimport command will fail with the following error message, if the imported volume group has a logical volume with the minor number of 255. Warning: Logical Volume number "nn" found on physical volume not found in "xxxxx". where "nn" is the logical volume number, and "xxxxx" is the mapfile name. ( SR: 8606111918 CR: JAGab84052 ) 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: 8606199183 CR: JAGad68371 ) The lvextend command could lead to data corruption, if the user enters the same physical volume more than once in the command line. Based on HP-UX patch PHCO_23791: (CR: JAGad55191 SR: 8606185986) 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. (CR:JAGad50582 SR:8606181365) Data loss and corruption can result from attempting to use LVM with "Virtual Array" disk arrays. Based on HP-UX patch PHCO_23499: (CR: JAGad46538 SR: 8606177306) When a volume group is deactivated and exported, there is a leftover kernel data structure with the volume group ID. If the volume group is imported later with a different minor number, there will be two different data structures with the same volume group ID - one left over, another created at the time the volume group was activated. In the case of a shared volume group, this can eventually cause the LVM minor number to become unusable until the system is rebooted. (CR: JAGad05245 SR: 8606136115) System panic when CPU0 was doing "vgdisplay -v" on a cluster volume group. This panic occurred when user was activating and deactivating a cluster volume group. Data page fault at lv_querylvmap. The stack trace looks like: panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 nokgdb+0x8 lv_querylvmap+0x11c lv_ioctl+0xff8 spec_ioctl+0xac vno_ioctl+0x90 ioctl+0x1e4 syscall+0x200 $syscallrtn+0x0 Based on HP-UX patch PHCO_23076: (CR: JAGad50461 SR: 8606181244) New functionality in LVM to support "Virtual Array" disk arrays. PHCO_26299: When patch PHCO_25061 is installed after MirrorDisk is installed, a user may be unable to see commands in the /usr/bin directory.Also, running 'swverify \*' will indicate numerous errors in the swagent.log file regarding the /usr/bin directory permissions. After the system is rebooted, or 'setfiles' is run, both problems go away. PHCO_25061: Ported HP-UX patch PHCO_24437 to VVOS Based on HP-UX patch PHCO_24437: ( SR: 1653162065 CR: JAGaa10504 ) When running lvdisplay simultaneously with the pvmove and the lvmerge commands, the lvdisplay command displays zeros extent information. ( SR: 8606198826 CR: JAGad68015 ) The lvlnboot -v command displays incorrect boot disk information when the boot disks order in the lvmtab file is reversed. ( SR: 5003432500 CR: JAGaa52059 ) 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: 8606161148 CR: JAGad30464 ) The vgimport command will fail with the following error message, if the imported volume group has a logical volume with the minor number of 255. Warning: Logical Volume number "nn" found on physical volume not found in "xxxxx". where "nn" is the logical volume number, and "xxxxx" is the mapfile name. ( SR: 8606111918 CR: JAGab84052 ) 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: 8606199183 CR: JAGad68371 ) The lvextend command could lead to data corruption, if the user enters the same physical volume more than once in the command line. Based on HP-UX patch PHCO_23791: (CR: JAGad55191 SR: 8606185986) 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. (CR:JAGad50582 SR:8606181365) Data loss and corruption can result from attempting to use LVM with "Virtual Array" disk arrays. Based on HP-UX patch PHCO_23499: (CR: JAGad46538 SR: 8606177306) LVM pvol structure is not getting released which prevents creating/importing volume groups on the system. Customer may eventually come up to the situation when all minor numbers are exhausted and this would require the system reboot. It is not possible to modify volume group minor id and name in shared mode. (CR: JAGad05245 SR: 8606136115) System panic when CPU0 was doing "vgdisplay -v" on a cluster volume group. This panic occurred when user was activating and deactivating a cluster volume group. Data page fault at lv_querylvmap. The stack trace looks like: panic+0x14 report_trap_or_int_and_panic+0x80 trap+0xdb8 nokgdb+0x8 lv_querylvmap+0x11c lv_ioctl+0xff8 spec_ioctl+0xac vno_ioctl+0x90 ioctl+0x1e4 syscall+0x200 $syscallrtn+0x0 Based on HP-UX patch PHCO_23076: (CR: JAGad50461 SR: 8606181244) New functionality in LVM to support "Virtual Array" disk arrays. PHCO_22866: Ported HP-UX patch PHCO_22839 to VVOS Based on HP-UX patch PHCO_22839: (CR: JAGad38961 SR: 8606169686) Currently, LVM commands recognize XP disk arrays such as XP256 and XP512. LVM commands do not recognize XP48 as part of the XP disk array family. Based on HP-UX patch PHCO_21630: (CR: JAGac78496 SR: 8606127694) When two VGs created with the same name, one with an extra alash ("/") at the end of the group file, many LVM commands will fail to recognize they are different VGs and get confused. This situation leads to LVM command failing and sometimes system panics. (CR: JAGad06173 SR: 8606137055) The vgchgid command currently only changes the VGID on EMC and XP256 devices. Even though the XP512 came from the same family as XP256, but they have different product-id. In this case, vgchgid will not recognize XP512, and it will fail to modify the VGID on the split-off mirror copy when it is needed. Based on HP-UX patch PHCO_21269: Customer needs new functionality in the LVM command vgchgid to support XP256 disk array. Based on HP-UX patch PHCO_20870: (CR: JAGaa46006 SR: 1653288878) Various LVM commands coredump on systems where any PV has more than 4 PVlinks (one primary and 3 alternates). (CR: JAGab83482 SR: 8606110734) The pvdisplay command displays "PV Status" as available when a disk is powerfailed. (JAGab83482) (CR: JAGab83470 SR: 8606110722) vgimport needs a method to specify disk list in a file. (CR: JAGad02854 SR: 8606133710) Need method to remove an unattached path without using vgexport/import. (CR: JAGad02856 SR: 8606133712) Need a method to see the pvchange(1m) autoswitch setting. Based on HP-UX patch PHCO_20054: 1. vgcreate with a disk having more than 64K extents sets up the VG incorrectly. 2. vgreduce deletes PV entries from /etc/lvmtab for a read-only Volume Group 3. vgreduce deletes a PV from /etc/lvmtab even when the PV has some extents in use under certain circumstances. 4. When a VG has one PV and multiple links vgremove still removes the VG, but doesn't cleanup /etc/lvmtab. Based on HP-UX patch PHCO_19631: 1. vgextend doesn't print a proper error message when supplied with a character device name rather than a block device name. 2. Enhancement to identify VxFS version 4 filesystem. Based on HP-UX patch PHCO_19479: 1. vgdisplay used to show wrong number of free extents, if the total number of free extents exceeded 64K in number. 2. lvcreate -I would not allow stripe sizes more than 64 K. Based on HP-UX patch PHCO_19205: 1. lvlnboot -R used to corrupt BDRA data under certain circumstances. 2. "vgchange -a r; vgchange -a y" doesn't print error message. 3. lvdisplay incorectly displays extents larger than 4 digits. 4. pvremove command is disabled. PHCO_19255: Ported HP-UX patch PHCO_18485 to VVOS Based on HP-UX patch PHCO_18485: This patch does not include the pvremove(1M) command. PHCO_17453 introduced this new functionality mistakenly, and has been recalled. This patch fix the problem for vgcfgbackup and vgextend. vgcfgbackup - invalid lvmrecord was backup due to lack of sanity check in this command. vgextend - users are limited to create volume group with maximum physical extents of 65535. This is incorrect. Based on HP-UX patch PHCO_17453: The introduction of the VERITAS Volume Manager (VxVM) requires several enhancements for LVM coexistence with VxVM. Based on HP-UX patch PHCO_18292: This patch has the following fixes : 1. This patch fix the data corruption problem when mirrored logical volumes are created on PVGs which has PVs with alternate links. 2. LVM allows creation of stripes greater than the total size of physical volumes in the volume group. 3. Limit for Stripe size is 64K currently where as it can go upto 32MB. Based on HP-UX patch PHCO_16851: This patch has the following fixes : 1. LVM scripts which lvextend one extent at a time (where the next logical extent added is always placed on a different physical volume from the preceding logical extent) can take hours to run for large logical volumes (i.e. 50gb). The goal of this kind of configuration is to create "extent-based mirrored stripes". LVM provides no alternate method for creating "extent-based mirrored stripes". 2. The SG stress suite is unable to shutdown the cluster after 24 hours or so because it can't shutdown the LVM daemon. 3. lvremove occasionally fails to remove logical volumes with an error message saying that it is a swap device, when it is not. Based on HP-UX patch PHCO_16248: If any of the PVs which belong to a VG are involved in any LVM commands operation, is not available after the device is opened. The system hangs on subsequent read/write since it is doing a blocking operatin. Eg: vgcfgbackup hangs when a PV is unavailable after opening it. Based on HP-UX patch PHCO_16090: vgextend prohibits even partial use of disks larger than the defined Max_PE_per_PV. Based on HP-UX patch PHCO_15237: lvcreate was dumping core when given out-of-range LogicalVolumeSize with the -L option (-L 0, for e.g.). Man page documentation was specifying incorrect range for LogicalVolumeSize in lvcreate, lvextend and lvreduce. Error message on extending a volume group with a disk that is too large was getting mangled with normal informative messages. SAM was not able to interpret the messages properly. vgcreate was not recalculating max_pe properly if the -s option was used. lvreduce -k was allowing only one pvkey to be selected. Based on HP-UX patch PHCO_15087: lvmtab_read error message added to lvlnboot,lvrmboot, pvcreate, vgchgid, vgimport and vgscan commands. sleep() is added in vgchgid while creating new vgids , Interrupts are disabled and check for valid no. of PVs added. Checks for SCSI disks added when verifying the disks in vgchgid,vgimport,vgscan and vgextend commands. Based on HP-UX patch PHCO_14562: The pvmove command does not support physical volume groups as a destination path as documented. Based on HP-UX patch PHCO_14124: This patch contains the following hotsite fixes: 1. PV links don't switch in a shared cluster environment. 2. Cannot import a cluster aware volume group after migrating to 11.00. vgimport failed. 3. EMC provides the option to split a hardware mirror without hpux knowning. This causes the system to see another set of disks with duplicate VGIDS. LVM needs to come up with a solution to allow customer import the split-off disk(s) to another system for backup purpose without causing problems. Defect Description: PHCO_27653: Ported HP-UX patch PHCO_27369 to VVOS Based on HP-UX patch PHCO_27369: (SR: 8606251224 CR:JAGae17290) 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 identify each LUN belonging to the VA7405 and VA7410 disk arrays, using a unique identifier associated with each LUN. With these changes, the VA7405 and VA7410 disk arrays can be used with LVM. (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, 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(1M) 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: 8606266310 CR: JAGae30559) 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. Based on HP-UX patch PHCO_24645: ( SR: 8606189031 CR: JAGad58247 ) If the result of the logical volume size (specified in the lvcreate command), divided by the volume group physical extent size is greater than the "maximum allowed", the lvcreate will core dump. Resolution: Added a new check in lvcreate(1M) to ensure that the number of extents in the logical volume stays in bounds. If it is out of bounds then a new error message is printed and the command is aborted. ( SR: 8606185504 CR: JAGad54697 ) 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 could take tens of seconds and the total time for opening links is the sum of these times, it could take several minutes to hours depending upon number of unavailable links in the volume group. Resolution: The new code eliminates retries each time the open of a physical link fails. Instead, an attempt is made to open all links. If any opens failed then there is a pause and a retry of all unavailable links. This significantly reduces the number of retries. As part of the resolution, we are providing a new kernel interface which opens a device with no retries. LVM commands will open all devices and then retry all the unavailable devices at one time. This patch contains the commands part of the fix. ( SR: 8606196637 CR: JAGad65840 ) In the LVM main routine, the argument list is initialized to NULL during a call to auto backup. However, if the call to auto backup is bypassed, the argument list will not be initialized to NULL. This results in subsequent operations passing an uninitialized argument list leading to potential data corruption. Resolution: Added initialization of argument list if the backup is not done. ( SR: 8606218155 CR: JAGad87305 ) LVM commands can be killed through SIGPIPE signal and leave the LVM data structures in unusable state since SIGPIPE is not part of the list of signals that are disabled and enabled when LVM commands are run. Resolution: Added SIGPIPE to list of signals that are to be disabled and enabled when LVM commands are run. ( SR: 8606159704 CR: JAGad29030 ) Every volume group configured has an element in the volume group data structure array in the kernel. This contains information specific to the volume group in the kernel. Each 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 group are created with the same group id, then they all map to the same element in the kernel data structure. This results in corruption of the data structure. 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: 8606218794 CR: JAGad87942 ) vgextend(1M) command core dumps when adding an alternate link to a volume group attached with 256 links. This happens because, current size of the array containing the link information is 256, since there could be more than 256 elements this array will overflow when adding more than 256 links. Resolution: Replaced the static array used to store all the links in the volume group into a dynamically allocated array, based on the number of links in the volume group. ( SR: 8606220972 CR: JAGad90108 ) 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: Modified LVM code to dynamically allocate arrays and data structures. ( SR: 8606207075 CR: JAGad76248 ) Setting the LANG variable causes the output of lvlnboot(1M) command to be translated using the lvm message catalog. When printing the "Boot" the wrong section of the message catalog is referenced resulting in an incorrect message, "PV Name". Resolution: "Boot" message is in section 3, so changed the message definition file to call section 3 instead of section 2 to display this message. Based on HP-UX patch PHCO_24437: ( SR: 1653162065 CR: JAGaa10504 ) 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. ( SR: 8606198826 CR: JAGad68015 ) 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: 5003432500 CR: JAGaa52059 ) 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: 8606161148 CR: JAGad30464 ) The vgimport command only checks the logical volume number up to 254. Resolution: The vgimport command was modified to fix the problem. ( SR: 8606111918 CR: JAGab84052 ) 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: 8606199183 CR:JAGad68371 ) 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. Based on HP-UX patch PHCO_23791: (CR: JAGad55191 SR: 8606185986) 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. Resoultion: The LVM library code has been modified to fix the problem. (CR:JAGad50582 SR:8606181365) "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. Based on HP-UX patch PHCO_23499: (CR: JAGad46538 SR: 8606177306) When a volume group is deactivated and then exported, there is a leftover in volgrp structure with the volume group id. If the 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. Resolution: Vgexport will Clear the volume group id while exporting the volume group. (CR: JAGad05245 SR: 8606136115) The panic occurred when lv_querylvmap tried to dereference (vg->pvols[ext->e_pvnum])->pv_flags on a volume group whose vg->pvols was null. Resoultion: Add attach_pvs() inside vgchange_main() which will call notify_clvmd_deactivn() to fail on an exclusively activated volume group. Based on HP-UX patch PHCO_23076: (CR: JAGad50461 SR: 8606181244) "Virtual Array" family of disks support splitting a LUN. Therefore, for determining alternate links to a LUN it is not sufficient to verify the pvid and vgid information on disk from each link because LVM can be easily misled in case of split LUNs where the data may be same on two links but they are paths to two different disks after the split. Resoultion : Added "Virtual Array" specific functionality to LVM, where we identify alternate links and disks with duplicate LVM metadata by using the array specific unique LUN id. PHCO_26299: Supersedes VVOS patch PHCO_25061 When the postinstall script for PHCO_25061 runs on a MirrorDisk installation, the /usr/bin directory is set to with permissions 2111 (--x--s--x). This is due to a misstated 'chmod' command that attempts to set the permissions on the /sbin/lvchange and /usr/sbin/lvchange commands installed by the patch. The command should read 'chmog' instead of 'chmod'. The 'chmog' function is provided in /usr/lbin/sw/control_utils for sw control scripts to use to set all permissions on a file using one command line. Resolution: Update the postinstall script to use 'chmog' instead of 'chmod' to set the permissions on the MirrorDisk version of the shipped files. PHCO_25061: Ported HP-UX patch PHCO_24437 to VVOS Based on HP-UX patch PHCO_24437: ( SR: 1653162065 CR: JAGaa10504 ) 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. ( SR: 8606198826 CR: JAGad68015 ) 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: 5003432500 CR: JAGaa52059 ) 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: 8606161148 CR: JAGad30464 ) The vgimport command only checks the logical volume number up to 254. Resolution: The vgimport command was modified to fix the problem. ( SR: 8606111918 CR: JAGab84052 ) 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: 8606199183 CR:JAGad68371 ) 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. Based on HP-UX patch PHCO_23791: (CR: JAGad55191 SR: 8606185986) 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. Resoultion: The LVM library code has been modified to fix the problem. (CR:JAGad50582 SR:8606181365) "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. Based on HP-UX patch PHCO_23499: (CR: JAGad46538 SR: 8606177306) When a volume group is deactivated and then exported, there is a leftover in volgrp structure with the volume group id. If the 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. Resolution: Vgexport will Clear the volume group id while exporting the volume group. (CR: JAGad05245 SR: 8606136115) The panic occurred when lv_querylvmap tried to dereference (vg->pvols[ext->e_pvnum])->pv_flags on a volume group whose vg->pvols was null. Resoultion: Add attach_pvs() inside vgchange_main() which will call notify_clvmd_deactivn() to fail on an exclusively activated volume group. Based on HP-UX patch PHCO_23076: (CR: JAGad50461 SR: 8606181244) "Virtual Array" family of disks support splitting a LUN. Therefore, for determining alternate links to a LUN it is not sufficient to verify the pvid and vgid information on disk from each link because LVM can be easily misled in case of split LUNs where the data may be same on two links but they are paths to two different disks after the split. Resoultion : Added "Virtual Array" specific functionality to LVM, where we identify alternate links and disks with duplicate LVM metadata by using the array specific unique LUN id. PHCO_22866: Ported HP-UX patch PHCO_22839 to VVOS Based on HP-UX patch PHCO_22839: (CR: JAGad38961 SR: 8606169686) Currently, LVM commands recognize XP256 and XP512 by checking the unique identifier on the disk. Need to modify LVM commands to recognize XP48 as part of the XP disk array family. Resolution: Modify LVM commands to recognize XP disk array family by means of product id, instead of using the unique identifier on the firmware. Based on HP-UX patch PHCO_21630: (CR: JAGac78496 SR: 8606127694) Several problems caused by having the same VG appearing in the lvmtab more than once. Because LVM commands failed to check if the PVs in those VGS are indeed valid, by comparing the VGID on the disk and on the lvmtab file. Resolution: Modified LVM commands to validate each PVs in the VG to make sure they belong. (CR: JAGad06173 SR: 8606137055) Currently, LVM commands recognize XP256 disk array by checking the product id. But XP512 have a different product id. Need to modify LVM commands to recognize XP512 as well. Resolution: Modified LVM commands to recognized XP256 as well as XP512 disk arrays. Based on HP-UX patch PHCO_21269: The LVM command vgchgid only modifies the VGID on EMC BCV or EMC RDF2 devices. Customers need the same functionality to support XP256 disks, such that the vgchgid command would also modify the VGID on the XP256 devices. Rssolution: Modified the LVM command vgchgid to add new functionality to support XP256 disk array. Other LVM commands are also modified in order to support both EMC and XP256 devices in the same volume group. Based on HP-UX patch PHCO_20870: (CR: JAGaa46006 SR: 1653288878) The maximum number of physical volume which LVM can support was used incorrectly in the code. (CR: JAGab83482 SR: 8606110734) The pvdisplay command failed to report correct status when a disk is powerfailed. (CR: JAGab83470 SR: 8606110722) The vgimport command and vgexport command lack of an option which allow users to specify device names in a file. (CR: JAGad02854 SR: 8606133710) The vgreduce command failed to remove any unattached physical volume in the lvmtab file. And the vgreduce command "-f" option insists that all physical volume in the lvmtab are attached. (CR: JAGad02856 SR: 8606133712) The "autoswitch" option was not implemented on the vgdisplay and the pvdisplay command. Resolution: (CR: JAGaa46006 SR: 1653288878) Modified LVM commands to handle maximum physical volume configuration. With the fix in this patch, LVM can handle a volume group up to 255 physical volumes, and 8 paths (one primary, 7 alternate) to each physical volume. (CR: JAGab83482 SR: 8606110734) Modified the pvdisplay command to report correct status when a disk is powerfailed. (CR: JAGab83470 SR: 8606110722) Add a new option "-f" to the vgimport and vgexport command to allow user to specify all devices in a file. (CR: JAGad02854 SR: 8606133710) Add a new option "-l" to the vgreduce command, so that the unattached physical volume can be removed Modified the vgreduce command "-f" option to remove any unattached physical volume in the lvmtab file. (CR: JAGad02856 SR: 8606133712) Modified the vgdisplay and the pvdisplay command to have a display on whether the "autoswitch" option is on for each physical volume. Based on HP-UX patch PHCO_20054: 1. Modified vgcreate to create VG with disks more than 64K extents correctly. Only 64K extents from the PV will be used. 2. Modified vgreduce to not delete /etc/lvmtab entries for a read-only Volume Group. 3. Modified vgreduce to not delete PV entries from /etc/lvmtab if the PV has extnets in use. 4. Modified vgremove to not delete the VG if there are more than one entry (multiple links for PV) in the /etc/lvmtab even though the VG contains only one PV. Based on HP-UX patch PHCO_19631: 1. Modified vgextend and vgcreate commands to print proper error messages when supplied with character device pathname. 2. Multiple VxFS products are available on HPUX 11.00. The VxFS product (JFS3.1) installed with 11.00 does not have version 4 filesystem capability. Later VxFS products (JFS3.3) include a version 4 filesystem. Therefore, libc routines have been updated to identify and verify version 4 filesystems. The lvm commands call these modified libc routines. To allow for multiple VxFS versions the following patches are required: PHCO_19491 libc PHCO_18462 diskusg_vxfs PHCO_18463 fscat PHCO_18464 getext PHCO_18465 setext PHCO_18466 vxdump PHCO_18467 vxrestore PHCO_18468 vxupgrade PHCO_18470 df PHCO_18471 fstyp PHCO_18472 fs_wrapper PHCO_18473 mount_wrapper PHCO_19673 fsck_hfs PHCO_19623 mount_hfs PHCO_19624 mount_cdfs PHCO_19656 mkboot Please note that PHCO_19631 can be used without the above patch dependencies if multiple VxFS version support is not required. Resolution: Re-issue lvm commands to use updatad libc routines. Based on HP-UX patch PHCO_19479: 1. In lv_queryvg structure, freepxs has been defined as a short. This caused the vgdisplay command to not show the right number of free extents if it exceeds the 64K (which is what a short can hold). Modified the total_px and free_px from 'int' to 'ulong_t' and now using free_px to print the number of free extents instead of using lv_queryvg.freepxs 2. Modified code in lvcreate to allow stripe size of more than 64 K. Based on HP-UX patch PHCO_19205: 1. In recover_boot_info() function, to search for alternate paths, for boot, root & swap volumes we use the total number of primary links in VG instead of total number of all links. Modified the code to use the total number of all links (primary + alternate) in VG to fix BDRA corruption 2. Added a new check in vgchange not to activate VG if it is already activated in read-only mode. 3. Modified lvdisplay to accomodate the 5 digit extent numbers. 4. Enabled the pvremove command. PHCO_19255: Ported HP-UX patch PHCO_18485 to VVOS Based on HP-UX patch PHCO_18485: This patch does not include the pvremove(1M) command. PHCO_17453 introduced this new functionality mistakenly, and has been recalled. The pvremove(1m) command may not be included in subsequent patches. Also, please note that if pvremove(1M) is reintroduced in the future, it may or may not be compatible with the version in PHCO_17453. Therefore, HP recommends removing PHCO_17453. New checks are added to the vgcfgbackup command to make sure the information in the lvmrecord is correct before backing it up. Corrections are made to the vgextend command to allow user create volume group with maximum physical extents of 255 * 65535. Based on HP-UX patch PHCO_17453: Enhancements to LVM commands for coexistence with the VERITAS Volume Manager (VxVM). Enhancements include: 1. Introduction of the pvremove command to free disk media from under the control of LVM. 2. Enhancements to the pvcreate and vgcfgrestore commands to be VxVM aware. Resolution: This is an enhancement for LVM to coexist with VxVM. Based on HP-UX patch PHCO_18292: 1. Add new checks in LVM library to make sure all LEs are mapped to unique PEs; Another new checks are added to check for alternate links in PV to make sure the same PV would not be selected again. 2. In lvcreate we were not checking for total number of stripes to be less than or equal to total number of PVs in the VG, hence it was possible to create a VG with Stripes more than the total number of PVs in the VG, added a new check to dissallow this. 3. Earlier the max StripeSize that can be specified was 64 whereas it can go upto 32K since that is the max power of two value that can be stored in a ushort_t. Based on HP-UX patch PHCO_16851: 1. The solution is to create a new LVM allocation policy for creating "extent-based mirrored stripes". By reducing the configuration sequence to a single step, the time for the configuration to complete has been reduced from hours to minutes (i.e. for a 50gb logical volume). The new policy is called the distributed allocation policy and is described in the new lvcreate(1M) man page provided with this patch. There are new lvchange(1M) and lvdisplay(1M) man pages also. There is new command line option in both lvcreate and lvchange: -D y. There is a new logical volume flag in the kernel (see dependent kernel patch). 2. The SG stress suite is unable to shutdown the cluster after 24 hours or so, because LVM leaves clvmd and LVM kernel in an inconsistent state. This patch fixes vgchange to include recovery schemes if that happens and to prevent such a state, in general. 3. Lvremove fails to remove logical volumes occasionally, because it thinks that the volume is a swap device, when it is not. This is caused by not checking error return and this patch fixes it. Based on HP-UX patch PHCO_16248: The problem of blocking on an not available PV and hence causing the called process to hang is overcome by converting all the blocking read/write operations to non-blocking read/write operations and a wrapper is put arround the read/write operations to retry a definite number of times. To make non-blocking O_NDELAY flag is set while opening the raw PVs. Based on HP-UX patch PHCO_16090: The fix for PHCO_15237 prohibits even partial use of disks larger than Max_PE_per_PV. The command should print a warning message (on stdout) and proceed, instead of printing an error message and aborting. Based on HP-UX patch PHCO_15237: lvcreate, lvextend and lvreduce were not performing range check for LogicalVolumeSize with the -L option. The man pages for these commands were indicating wrong range for LogicalVolumeSize. The vgcreate/vgextend defect on error message was due to an earlier fix that changed a few stderr prints to stdouts. Also, on this particular case, after sending error message to stderr, vgcreate/vgextend commands needed to fail which they were not doing. The adjustment of max_pe was not being done by vgcreate even if one of -s or -e option was supplied. The correct fix is to report failure only if both the options are given and the required number of PE's exceed the supplied value. lvreduce allows reduction of missing PV by specifying the pvkey rather than the pvpath but it was accepting a single key only. The fix was made such that -k no longer accepts any arguments and the pvkey is now derived from the pvpath list. Based on HP-UX patch PHCO_15087: lvmtab_read() call did have any error message printed if the call was a failure in lvlnboot.c,lvrmboot.c pvcreate.c,vgchgid.c, vgimport.c and vgscan.c vgchgid generated same vgids if the vgchgid is called in a shell srcipt. So added 1 second delay and disabled all interrupts. Check for max. no. of Arguments added. Check for SCSI disk added when the devices are verified for vgchgid,vgscan,vgimport,vgextend commands. Based on HP-UX patch PHCO_14562: Modified pvmove to allow a physical volume group as a destination path. Based on HP-UX patch PHCO_14124: 1. Implemented a new ioctl to fix the problem of links not switching in a shared cluster environment. 2. The vgimport failed was caused by a bad checksum on 10.20 disks. Temporary turn off checksum in LVM command for the same reason that kernel has turned off the checksum until a proper versioning mechanism is implemented. 3. A new command (vgchgid) is created to modify the VGIDs on the split-off EMC Symmetrix disk(s). LVM commands vgscan, vgextend and vgimport are also modified to support EMC Symmetrix disk(s). SR: 1653282301 1653292375 1653325484 5003385989 4701374967 1653252874 1653252759 1653252734 1653199265 5003320606 1653196428 5003325340 1653271833 1653264887 4701368670 5003408633 1653297630 5003429829 1653282301 4701427328 1653286518 1653288878 8606110734 8606110722 8606133710 8606133712 8606131752 8606127694 8606137055 8606169686 8606181244 8606177306 8606136115 8606185986 8606181365 1653162065 8606198826 5003432500 8606161148 8606111918 8606199183 8606189031 8606185504 8606196637 8606218155 8606159704 8606218794 8606220972 8606207075 8606251224 8606251163 8606266310 8606266556 8606237938 1653232785 8606101328 8606101603 8606102640 8606104191 8606105028 Patch Files: LVM.LVM-ENG-A-MAN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/share/man/man1m.Z/lvchange.1m /usr/share/man/man1m.Z/lvcreate.1m /usr/share/man/man1m.Z/lvdisplay.1m /usr/share/man/man1m.Z/lvextend.1m /usr/share/man/man1m.Z/lvreduce.1m /usr/share/man/man1m.Z/pvcreate.1m /usr/share/man/man1m.Z/pvremove.1m /usr/share/man/man1m.Z/vgchgid.1m /usr/share/man/man1m.Z/vgcreate.1m /usr/share/man/man1m.Z/vgexport.1m /usr/share/man/man1m.Z/vgextend.1m /usr/share/man/man1m.Z/vgimport.1m /usr/share/man/man1m.Z/vgreduce.1m /usr/share/man/man1m.Z/vgscan.1m LVM.LVM-MIRROR-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/newconfig/sbin/lvchange.mir /usr/newconfig/usr/sbin/lvchange.mir LVM.LVM-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/lib/nls/msg/C/lvm.cat /sbin/lvchange /usr/sbin/lvchange what(1) Output: LVM.LVM-ENG-A-MAN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/share/man/man1m.Z/lvchange.1m: None /usr/share/man/man1m.Z/lvcreate.1m: None /usr/share/man/man1m.Z/lvdisplay.1m: None /usr/share/man/man1m.Z/lvextend.1m: None /usr/share/man/man1m.Z/lvreduce.1m: None /usr/share/man/man1m.Z/pvcreate.1m: None /usr/share/man/man1m.Z/pvremove.1m: None /usr/share/man/man1m.Z/vgchgid.1m: None /usr/share/man/man1m.Z/vgcreate.1m: None /usr/share/man/man1m.Z/vgexport.1m: None /usr/share/man/man1m.Z/vgextend.1m: None /usr/share/man/man1m.Z/vgimport.1m: None /usr/share/man/man1m.Z/vgreduce.1m: None /usr/share/man/man1m.Z/vgscan.1m: None LVM.LVM-MIRROR-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/newconfig/sbin/lvchange.mir: $Revision: Hewlett-Packard ISSL Level vvos_rose42 $ $Header: Hewlett-Packard ISSL Release vvos_r ose $ $Date: Thu Aug 29 02:38:24 EDT 2002 $ $Revision: 80.6 $ $Date: 97/04/28 18:00:45 $ $Source: cmd/lvm/vgcfgbackup.c, hpuxcmdlvm, vvos_ros e, rose0287 $ $Date: 02/08/23 05:33:13 $ $Re vision: 1.7.1.7 PATCH_11.04 (PHCO_27653) $ $Revision: 70.5 $ $Revision: 82.26.1.9.1.118 $ MIRROR PRODUCT $Source: cmd/lvm/hpux_rel.c, hpuxcmds, vvos_rose, ro se0287 $ $Date: 02/08/23 05:26:17 $ $Revisio n: 1.8 PATCH_11.04 (PHCO_27653) $ $Source: lib/libsecurity/auditdb.c, libsecurity_audi t, vvos_rose, rose0270 $ $Date: 01/08/23 16: 33:10 $ $Revision: 1.14.2.2 PATCH_11.04 (PHC O_24852) $ $ PATCH/11.00:PHCO_24148 May 25 2001 08:04:43 $ /usr/newconfig/usr/sbin/lvchange.mir: $Revision: Hewlett-Packard ISSL Level vvos_rose42 $ $Header: Hewlett-Packard ISSL Release vvos_r ose $ $Date: Thu Aug 29 02:38:24 EDT 2002 $ $Revision: 80.6 $ $Date: 97/04/28 18:00:45 $ $Source: cmd/lvm/vgcfgbackup.c, hpuxcmdlvm, vvos_ros e, rose0287 $ $Date: 02/08/23 05:33:13 $ $Re vision: 1.7.1.7 PATCH_11.04 (PHCO_27653) $ $Revision: 70.5 $ $Revision: 82.26.1.9.1.118 $ MIRROR PRODUCT $Source: cmd/lvm/hpux_rel.c, hpuxcmds, vvos_rose, ro se0287 $ $Date: 02/08/23 05:26:17 $ $Revisio n: 1.8 PATCH_11.04 (PHCO_27653) $ LVM.LVM-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: /usr/lib/nls/msg/C/lvm.cat: None /sbin/lvchange: $Revision: Hewlett-Packard ISSL Level vvos_rose42 $ $Header: Hewlett-Packard ISSL Release vvos_r ose $ $Date: Thu Aug 29 02:38:24 EDT 2002 $ $Revision: 80.6 $ $Date: 97/04/28 18:00:45 $ $Source: cmd/lvm/vgcfgbackup.c, hpuxcmdlvm, vvos_ros e, rose0287 $ $Date: 02/08/23 05:33:13 $ $Re vision: 1.7.1.7 PATCH_11.04 (PHCO_27653) $ $Revision: 70.5 $ $Revision: 82.26.1.9.1.118 $ $Source: cmd/lvm/hpux_rel.c, hpuxcmds, vvos_rose, ro se0287 $ $Date: 02/08/23 05:26:17 $ $Revisio n: 1.8 PATCH_11.04 (PHCO_27653) $ $Source: lib/libsecurity/auditdb.c, libsecurity_audi t, vvos_rose, rose0270 $ $Date: 01/08/23 16: 33:10 $ $Revision: 1.14.2.2 PATCH_11.04 (PHC O_24852) $ $ PATCH/11.00:PHCO_24148 May 25 2001 08:04:43 $ /usr/sbin/lvchange: $Revision: Hewlett-Packard ISSL Level vvos_rose42 $ $Header: Hewlett-Packard ISSL Release vvos_r ose $ $Date: Thu Aug 29 02:38:24 EDT 2002 $ $Revision: 80.6 $ $Date: 97/04/28 18:00:45 $ $Source: cmd/lvm/vgcfgbackup.c, hpuxcmdlvm, vvos_ros e, rose0287 $ $Date: 02/08/23 05:33:13 $ $Re vision: 1.7.1.7 PATCH_11.04 (PHCO_27653) $ $Revision: 70.5 $ $Revision: 82.26.1.9.1.118 $ $Source: cmd/lvm/hpux_rel.c, hpuxcmds, vvos_rose, ro se0287 $ $Date: 02/08/23 05:26:17 $ $Revisio n: 1.8 PATCH_11.04 (PHCO_27653) $ cksum(1) Output: LVM.LVM-ENG-A-MAN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: 158505942 7638 /usr/share/man/man1m.Z/lvchange.1m 1235186861 8478 /usr/share/man/man1m.Z/lvcreate.1m 3374447163 5559 /usr/share/man/man1m.Z/lvdisplay.1m 1537195080 5024 /usr/share/man/man1m.Z/lvextend.1m 1202649665 5035 /usr/share/man/man1m.Z/lvreduce.1m 2478289008 4327 /usr/share/man/man1m.Z/pvcreate.1m 2308744220 2941 /usr/share/man/man1m.Z/pvremove.1m 1508629017 4432 /usr/share/man/man1m.Z/vgchgid.1m 1355037792 5801 /usr/share/man/man1m.Z/vgcreate.1m 2288109274 4315 /usr/share/man/man1m.Z/vgexport.1m 831864614 5805 /usr/share/man/man1m.Z/vgextend.1m 2570997169 5564 /usr/share/man/man1m.Z/vgimport.1m 1426672620 4888 /usr/share/man/man1m.Z/vgreduce.1m 617237061 4949 /usr/share/man/man1m.Z/vgscan.1m LVM.LVM-MIRROR-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: 1890637441 1089536 /usr/newconfig/sbin/lvchange.mir 390130785 561152 /usr/newconfig/usr/sbin/lvchange.mir LVM.LVM-RUN,fr=B.11.04,fa=HP-UX_B.11.04_32/64,v=HP: 2606802694 44823 /usr/lib/nls/msg/C/lvm.cat 3294936829 1064960 /sbin/lvchange 2703384908 544768 /usr/sbin/lvchange Patch Conflicts: None Patch Dependencies: s700: 11.04: PHKL_27711 s800: 11.04: PHKL_27711 Hardware Dependencies: None Other Dependencies: None Supersedes: PHCO_19255 PHCO_22866 PHCO_25061 PHCO_26299 Equivalent Patches: PHCO_27369: s700: 11.00 s800: 11.00 Patch Package Size: 3410 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_27653 5. Run swinstall to install the patch: swinstall -x autoreboot=true -x patch_match_target=true \ -s /tmp/PHCO_27653.depot By default swinstall will archive the original software in /var/adm/sw/save/PHCO_27653. 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_27653.text file is available in the product readme: swlist -l product -a readme -d @ /tmp/PHCO_27653.depot To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHCO_27653.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None