Patch Name: PHKL_6022 Patch Description: s700 10.00 LVM data corruption and read only activation Creation Date: 95/09/08 Post Date: 95/09/08 Hardware Platforms - OS Releases: s700: 10.00 Products: N/A Filesets: LVM.LVM-KRN Automatic Reboot?: Yes Status: General Release Critical: Yes PHKL_6022: CORRUPTION PANIC PHKL_5605: ABORT Path Name: /hp-ux_patches/s700/10.X/PHKL_6022 Symptoms: PHKL_6022: Running vgcreate on an LVM disc without re-running pvcreate before end could create an LVM disc where the start of user data overlaps the LVM header, as for example with the sequence: pvcreate /dev/rdsk/c0t0d0 vgcreate vg05 /dev/dsk/c0t0d0 vgremove vg05 vgcreate -s 1 -e 2033 -p 60 vg05 /dev/dsk/c0t0d0 Symptoms such as file system corruption or LVM header corruption, showing up as file system panics or LVM panics, could then be observed. PHKL_5605: The vgchange -a r command fails with the message: vgchange: Activation mode requested for the volume group conflicts with configured mode. Defect Description: PHKL_6022: Due to a defect in the SDS migration code, the kernel was computing the start of user data only when the data_psn field in the LVM record was 0 (which is the default value after running pvcreate). Not running pvcreate on an LVM disc before re-using it meant using the start of user data from previous disc usage, and thus causing data corruption if the new LVM header was bigger than in previous disc usage. Corruption can be prevented with the work-around of always running pvcreate before re-using an LVM disc. For 10.01, the patches PHKL_6024/s700 and PHKL_6025/s800 address also this defect. The patch will prevent from creating situation where the start of user data and the LVM header overlap. Also, a test was added to the activation code to detect discs which may have potential for data corruption, and a warning is printing on the system console: WARNING: The LVM header on the disc at 52.4.0 extends beyond the start of user data, which therefore has potential for data corruption. Please consult the documentation for patch PHKL_6025 (or any superceeding patch) for how to reconfigure to fix this. In the event you have a disk which is showing potential for this problem, as detected by the patched PV activation code, the procedure for correcting the problem (which must be repeated for each individual disk) is as follows. For this example, the disk which is showing problems is /dev/dsk/c1t6d0, which is part of vg01: If you have spare space available in your volume group (or can make it available by adding a new disk to the volume group), the procedure is simpler: - Add the new disk to the volume group if needed (c1t3d0 in this example): # pvcreate [-B] /dev/dsk/c1t3d0 # vgextend /dev/vg01 /dev/dsk/c1t3d0 - Move all logical extents to the new disk: # pvmove /dev/dsk/c1t6d0 /dev/dsk/c1t3d0 The second argument here is optional, and is only needed when you want to make sure all the extents go to the new disk. Without it, the extents will be moved to the first available free space elsewhere in the VG. - Remove the affected disk from the VG, run pvcreate to clear the data structures, then add it back to the VG. # vgreduce /dev/vg01 /dev/dsk/c1t6d0 # pvcreate [-B] /dev/dsk/c1t6d0 # vgextend /dev/vg01 /dev/dsk/c1t6d0 - If you want to remove the new disk from the VG again, you can do so now by reversing the pvmove process, and removing it: # pvmove /dev/dsk/c1t3d0 /dev/dsk/c1t6d0 # vgreduce /dev/vg01 /dev/dsk/c1t3d0 If you do not have spare disk space available, the procedure is slighly more complicated, as you will need to backup and restore all affected lvols: - determine which logical volumes are affected: # pvdisplay -v /dev/dsk/c1t6d0 | more - Under the heading "- Distribution of physical volume -", pvdisplay lists all of the logical volumes which are using this disk. Stop all activity to these logical volumes, shutting-down (or rebooting) to single-user mode, if necessary. - These lvols all need to be backed-up in their entirety, then removed. For example, if this disk contains file systems for the following: /dev/vg01/lvol1 mounted as /fs1 /dev/vg01/lvol2 mounted as /home and /dev/vg01/lvol3 mounted as /opt: # fbackup -i /fs1 -i /home -i /opt \ -vf /dev/rmt/c1t0d0BEST # lvremove /dev/vg01/lvol1 # lvremove /dev/vg01/lvol2 # lvremove /dev/vg01/lvol3 - Remove the affected disk from the VG, run pvcreate to clear the data structures, then add it back to the VG. # vgreduce /dev/vg01 /dev/dsk/c1t6d0 # pvcreate [-B] /dev/dsk/c1t6d0 # vgextend /dev/vg01 /dev/dsk/c1t6d0 - Recreate the logical volumes you removed previously, including the lvols and their fileysystems as needed (use SAM if you prefer). # lvcreate -L -n lvol1 /dev/vg01 # lvcreate -L -n lvol2 /dev/vg01 # lvcreate -L -n lvol3 /dev/vg01 # newfs /dev/vg01/rlvol1 # newfs /dev/vg01/rlvol2 # newfs /dev/vg01/rlvol3 # mount -a - Restore your data to these lvols, and you're back to where you started, without the problem of potential data corruption. # frecover -rvf /dev/rmt/c1t0d0BEST PHKL_5605: The vgchange -a r will fail when service guard cluster services are present in the system. The read only activation of the volume group fails when it has been activated in exclusive mode. There is no workaround for this problem. SR: 1653141945 4701293480 Patch Files: /usr/conf/lib/liblvm.a(lv_ioctls.o) what(1) Output: /usr/conf/lib/liblvm.a(lv_ioctls.o): lv_ioctls.c $Date: 95/09/08 13:34:31 $ $Revision: 1. 11.91.7 $ PATCH_10.0 (PHKL_6022) cksum(1) Output: 1014259841 19524 /usr/conf/lib/liblvm.a(lv_ioctls.o) Patch Conflicts: None Patch Dependencies: None Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_5605 Equivalent Patches: PHKL_6023: s800: 10.00 Patch Package Size: 80 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 PHKL_6022 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_6022.depot 5b. For a homogeneous NFS Diskless cluster run swcluster on the server to install the patch on the server and the clients: swcluster -i -b This will invoke swcluster in the interactive mode and force all clients to be shut down. WARNING: All cluster clients must be shut down prior to the patch installation. Installing the patch while the clients are booted is unsupported and can lead to serious problems. The swcluster command will invoke an swinstall session in which you must specify: alternate root path - default is /export/shared_root/OS_700 source depot path - /tmp/PHKL_6022.depot To complete the installation, select the patch by choosing "Actions -> Match What Target Has" and then "Actions -> Install" from the Menubar. 5c. For a heterogeneous NFS Diskless cluster: - run swinstall on the server as in step 5a to install the patch on the cluster server. - run swcluster on the server as in step 5b to install the patch on the cluster clients. The cluster clients must be shut down as described in step 5b. By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_6022. If you do not wish to retain a copy of the original software, you can create an empty file named /var/adm/sw/patch/PATCH_NOSAVE. Warning: If this file exists when a patch is installed, the patch cannot be deinstalled. Please be careful when using this feature. It is recommended that you move the PHKL_6022.text file to /var/adm/sw/patch for future reference. To put this patch on a magnetic tape and install from the tape drive, use the command: dd if=/tmp/PHKL_6022.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None