Special Install Instructions:
-----------------------------

Reboot the system after patch installation.

If possible, perform patch installation in single user mode.
If this can not be done, we recommend having the system in as
quiet a state as possible: no users logged on, no user jobs
running.

***************************************************************************
If an incompatible patch has previously been installed on the system, the
following error message will be displayed by patchadd when an attempt is
made to install this patch:

    ERROR: This patch is incompatible with patch <PatchID>
    which has already been applied to the system.

In such circumstances, the incompatible patch needs to be removed using
patchrm before this patch can be applied.
***************************************************************************
A new UFS internal consistency check may be falsely triggered by a
legitimate condition, resulting in the production of a misleading and
scary kernel warning.  Two messages are possible: if the filesystem is
not logging, ``WARNING: /example: unexpected free inode <Number>, run
fsck(1M)'', and if it is logging, ``WARNING: /example: unexpected
free inode <Number>, run fsck(1M) -o f''.

The condition that can cause these messages to be reported is the
deletion of the parent of a process' current working directory, and
subsequently having that process attempt to chdir to ``..''.  This is
more easily explained with a simple demonstration shell script:

        #!/bin/sh

        if [ $# -ne 1 ]; then
                echo usage: cwd-eio /writable/ufs/directory
                exit 1
        fi

        dirbase=$1
        subdirbase=$dirbase/cwd-eio.$$
        subdirfull=$subdirbase/bar
        mkdir -p $subdirfull
        (cd $subdirfull; sleep 2; cd ..) &
        rm -r $subdirbase
        sync
        wait

When the sleep completes, and the backgrounded shell attempts to
execute the ``cd ..'', the shell will complain ``./cwd-eio: ..: bad
directory'', and the kernel will report one of the messages described
above.  Correct behavior would be for the shell to complain, but the
kernel to remain silent.  The correct error return (and hence
complaint from the shell) is open to discussion.  ENOENT would be
technically correct, but EIO possibly more likely to be understood by
random applications.