Patch Name: PHKL_11733 Patch Description: s700 10.20 JFS panic, mount, umount cumulative patch Creation Date: 97/07/25 Post Date: 97/07/30 Hardware Platforms - OS Releases: s700: 10.20 Products: N/A Filesets: JournalFS.VXFS-BASE-KRN Automatic Reboot?: Yes Status: General Superseded Critical: Yes PHKL_11733: OTHER Unmountable VxFS (JFS) file system. PHKL_11860: PANIC PHKL_9370: OTHER Unmountable VxFS (JFS) file system. PHKL_7776: OTHER Unmountable VxFS (JFS) file system. Path Name: /hp-ux_patches/s700/10.X/PHKL_11733 Symptoms: PHKL_11733: After a hard failure (panic/hang/TOC), a JFS file system may not mount and will return the following error message: vxfs mount: %s is not a vxfs file system. This could even happen with patches PHKL_9370 and PHCO_11223 installed. A full fsck does not clean the file system; a newfs/mkfs is the only solution. PHKL_11860: The PHKL_9370 installed system panic's during reboot, if reboot command is used. This patch fixes this problem. PHKL_9370: If a customer upgrades from 10.01 or 10.10 to 10.20, and tries to increase their VxFS file systems via SAM, the file system will not mount after completion of extending the volume and file system. The typical approach for SAM is: 1) unmount the file system 2) lvextend the volume 3) extendfs the file system 4) mount the file system The mount will always fail in this case. PHKL_7776: It's possible for a JFS file system to get into a state where it can't be mounted (except read-only), but fsck(1M) does not report any problem with it. At mount time, the kernel prints the following warning on the console: vxfs: mesg 012: vx_iget - file system invalid inode number XXX and mount(1M) fails with the following message: vxfs mount: /dev/XXX is not a vxfs file system. Once a file system has gotten into this state, it remains unmountable, even after running fsck(1M). Defect Description: PHKL_11733: After a hard system failure, a JFS file system may not mount even if PHKL_9370 and PHCO_11223 are installed. If the VX_IETRUNC flag is set for a file, then vx_trunc() is called and returns without clearing the ip->i_eopflags field. Since VX_IETRUNC alone is still set after vx_trunc(), the error return is set to EINVAL (reason why the mount fails). Prior to returning, if error is non-zero, vxfs sets the VX_FULLFSCK flag and returns. Patch PHKL_9370 added the setting of the VX_FULLFSCK flag; the bug leaving the ip->i_eopflags set to VX_IETRUNC still existed prior to PHKL_9370, however after the first failed mount, a second mount would have been successful. PHKL_11860: It is assumed that there is one active reference to a disk quota at vx_quotaoff(), which enables to free vx_dquota blocks in vx_dqlist. This assumption is not true during vx_replay() since there is still a VX_MLDQUOT mlink in the file system mlink chain waiting to be flushed. Hence, flushing the file system's mlink queue before calling vx_quotaoff will fix the problem. PHKL_9370: The inode summary fields in the new allocation unit added by extendfs were not properly initialized, so whatever happened to be in the block wound up being treated as inode summary data. The vxfs fsck command never detected this, and the mount command was failing in the kernel due to a file system validation error. The problem is easily reproduced by executing the following: # lvcreate -L 40 -n testvol /dev/vg00 # mkfs -Fvxfs -oversion=2 /dev/vg00/rtestvol # mount -Fvxfs /dev/vg00/testvol /tmp_mnt # umount /tmp_mnt # lvextend -L 80 /dev/vg00/testvol # extendfs -Fvxfs /dev/vg00/rtestvol # mount -Fvxfs /dev/vg00/testvol /tmp_mnt PHKL_7776: At mount time, the kernel completes any pending "extended operations" for a JFS file system. (These might include, for example, removing a file that has no links but couldn't be removed when the last link went away because some process had the file open.) We maintain a bitmap on disk with one bit per inode indicating whether the inode has any extended operations pending, to avoid having to inspect every single inode at mount time. However, the calculation of an inode number from a bit in the bitmap is done incorrectly. This means, first of all, that some extended operations are never completed. More seriously, the inode number we calculate could be out of range, causing the mount to fail. Running fsck(1M) will not help, since there's nothing wrong with the file system. Although the file system can't be mounted in read/write mode, it can be mounted read-only. If a file system gets into this unmountable state, the only recourse is to mount it read-only and to copy the files from it to another (replacement) file system. SR: 1653220079 4701327544 4701341479 4701361444 Patch Files: /usr/conf/lib/libvxfs_base.a(vx_itrunc.o) /usr/conf/lib/libvxfs_base.a(vx_replay.o) what(1) Output: /usr/conf/lib/libvxfs_base.a(vx_itrunc.o): vx_itrunc.c $Date: 97/07/24 09:06:54 $ $Revision: 1. 7.98.17 $ PATCH_10.20 (PHKL_11733) /usr/conf/lib/libvxfs_base.a(vx_replay.o): vx_replay.c $Date: 97/07/24 14:49:32 $ $Revision: 1. 2.98.12 $ PATCH_10.20 (PHKL_11733) cksum(1) Output: 3239474659 15120 /usr/conf/lib/libvxfs_base.a(vx_itrunc.o) 1579530169 7048 /usr/conf/lib/libvxfs_base.a(vx_replay.o) Patch Conflicts: None Patch Dependencies: s700: 10.20: PHCO_9396 Hardware Dependencies: None Other Dependencies: None Supersedes: PHKL_7776 PHKL_9370 PHKL_11860 Equivalent Patches: PHKL_11734: s800: 10.20 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_11733 5a. For a standalone system, run swinstall to install the patch: swinstall -x autoreboot=true -x match_target=true \ -s /tmp/PHKL_11733.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_11733.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. By default swinstall will archive the original software in /var/adm/sw/patch/PHKL_11733. 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_11733.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_11733.depot of=/dev/rmt/0m bs=2k Special Installation Instructions: None