I suspect this may be due to a combination of issues.  The first is that
/var/sadm/pkg resides on a large ZFS file system.  Could the Reporter please
provide details of the system in question including the output of "df -k
/var/sadm/pkg?"

In addition, I suspect the use of ksh93(1) for /usr/bin/ksh may also be playing
a part as /usr/lib/patch/patchadd is a ksh[93] script and it uses "typeset -i"
to declare numerous integers.  For ksh93, I believe these need to be "typeset
-il" in order to force these size parameters to be considered long integers.

I've cc'ed Roland to get his input on this particular issue.

(In reply to comment #1)
[snip]
> In addition, I suspect the use of ksh93(1) for /usr/bin/ksh may also be playing
> a part as /usr/lib/patch/patchadd is a ksh[93] script and it uses "typeset -i"
> to declare numerous integers.  For ksh93, I believe these need to be "typeset
> -il" in order to force these size parameters to be considered long integers.

Erm... I doubt this is an issue cause by ksh88/ksh93 differences since ksh88's
"typeset -i" creates integer variables which hold a 32bit value. ksh93's "-il"
means |long long integer|, e.g. a 64bit value (ksh88 didn't know 64bit values).
In general it's suggested to use "integer" instead of "typeset -i" since this
maps  to the lagest supported integer datatype of the shell interpreter (this
applies to ksh88, ksh93, bash, zsh).

Approved patches will be installed in this order:

124864-01 


Checking installed patches...
Verifying sufficient filesystem capacity (dry run method)...
Insufficient space in /var/sadm/pkg to save old files.
Space required in kilobytes:  221172
Space available in kilobytes:  132393330

Patchadd is terminating.


[1] +  Done(74)                <command unknown>

# df -k /var/sadm/pkg
Filesystem            kbytes    used   avail capacity  Mounted on
rpool/ROOT/opensolaris-1
                     138313728 2667651 132393619     2%    /

Where can I find the sources for this script ?

/usr/lib/patch/patchadd (and presumedly /usr/lib/patch/patchrm) on a 2008.05 or
Nevada system.

(In reply to comment #5)
> /usr/lib/patch/patchadd (and presumedly /usr/lib/patch/patchrm) on a 2008.05 or
> Nevada system.

Erm... I mean the location in the SCCS tree ... and which SCCS tree...

Roland: The patch source code is not available via OpenSolaris.  Please see the
email that I sent you for the internal location of the source code.

(In reply to comment #7)
> Roland: The patch source code is not available via OpenSolaris.  Please see the
> email that I sent you for the internal location of the source code.

Umpf... I assume I'm not even allowed to attach a patch for the script to this
bug then, right ?

David, you were right about the reported problem being the result of
a typeset -i integer wrapping around and actually ended up being a
negative number.  I modified /usr/lib/patch/patchadd and this problem
went away.  Here are the diffs:

    root@sqao42 # diff /usr/lib/patch/patchadd /usr/lib/patch/patchadd.orig
    4065c4065
    <       typeset -il DRBytesAvail=0
    ---
    >       typeset -i DRBytesAvail=0

Roland suggested using "integer", but I used "-il" instead because it
introduced
the minimal amount of changes and was consistent with the rest of the script.

----
Unfortunately I was still not able to patchadd 124873-01 to the
submitters system.  Now, I see the following errors:

    root@sqao42 # patchadd 124873-01 
    Validating patches...

    Loading patches installed on the system...

    Done!

    Loading patches requested to install.



    Checking for consistency of zone attributes
    between patch packages and installed packages
    Done!

    Checking patches that you specified for installation.

    Done!


    Approved patches will be installed in this order:

    124873-01


    Checking installed patches...
    Verifying sufficient filesystem capacity (dry run method)...
    Installing patch packages...
    /usr/bin/nawk: can't open file /pkginfo
     source line number 1
    /usr/lib/patch/patchadd[6408]: apply_diPatch: line 5148: pkg: is read only

    Patch packages installed:
              none

----
The problem that was documented in this bug was obviously a problem with
patchadd.  This new failure could either be an issue with patchadd or something
with that patch. 

Aparna, has this patch, 124873-01,  been verified as good on either S10 or
Nevada?

Moriah,
      Sun Studio 12 ML was released around Sept-Oct 2007. The patches have been
tested and are good.
I just installed Sun Studio 12 on a Solaris 10 system and the patch was
installed. 
# uname -a
SunOS sqao41 5.10 Generic_127128-11 i86pc i386 i86pc
# showrev -a |grep 124873
Patch: 124873-01 Obsoletes:  Requires:  Incompatibles:  Packages: SPROdbx,
SPROdbxx, SPROjdbx, SPROjdbxx
Patch: 124876-02 Obsoletes:  Requires: 124873-01 Incompatibles:  Packages:
SPROsvc, SPROdbxui
#

(In reply to comment #9)
> David, you were right about the reported problem being the result of
> a typeset -i integer wrapping around and actually ended up being a
> negative number.  I modified /usr/lib/patch/patchadd and this problem
> went away.  Here are the diffs:
> 
>     root@sqao42 # diff /usr/lib/patch/patchadd /usr/lib/patch/patchadd.orig
>     4065c4065
>     <       typeset -il DRBytesAvail=0
>     ---
>     >       typeset -i DRBytesAvail=0
> 
> Roland suggested using "integer", but I used "-il" instead because it
> introduced
> the minimal amount of changes and was consistent with the rest of the script.

Erm... my suggestion wasn't about consistency, it was about correctness. The
script assumes to use an integer datatype which can handle an file offset - and
that's "integer" (which points to the largest integer datatype supported by the
shell interpreter) and not "typeset -il" (which explicitly says "use long
integer").

> ----
> Unfortunately I was still not able to patchadd 124873-01 to the
> submitters system.  Now, I see the following errors:
> 
>     root@sqao42 # patchadd 124873-01 
>     Validating patches...
> 
>     Loading patches installed on the system...
> 
>     Done!
> 
>     Loading patches requested to install.
> 
> 
> 
>     Checking for consistency of zone attributes
>     between patch packages and installed packages
>     Done!
> 
>     Checking patches that you specified for installation.
> 
>     Done!
> 
> 
>     Approved patches will be installed in this order:
> 
>     124873-01
> 
> 
>     Checking installed patches...
>     Verifying sufficient filesystem capacity (dry run method)...
>     Installing patch packages...
>     /usr/bin/nawk: can't open file /pkginfo
>      source line number 1
>     /usr/lib/patch/patchadd[6408]: apply_diPatch: line 5148: pkg: is read only

Yep. If you look at the function it assumes to have local scope for variables
but uses Bourne-style foo() syntax to declare the function. The implosion is...
erm... pre-programmed... ;-(

Created an attachment (id=345) [details]
Prototype patch based on Solaris 11/B84's /usr/lib/patch/patchadd

The patch should AFAIK fix this problem and then cleans-up with some further
issues reported by shcomp -n/shlint (the changes should be compatible to
ksh88).

If the general direction of the patch is Ok I'll file a 2nd one which fixes the
remaining shcomp -n warnings...

*** Bug 3120 has been marked as a duplicate of this bug. ***

Current status:
We have patches but no way to get them into the upstream repository right
now... ;-(

If no progress can be made in the next two weeks I'll propose to mark this bug
as "WONTFIX" since we're running in circles since _four_ _months_ and I don't
see any light at the end of the tunnel.

This seems a prime candidate for opening a new bug in Sun's Bugster database
and closing this one as TRACKEDINBUGSTER. Is there any reason why this can't
be done?

(In reply to comment #15)
> This seems a prime candidate for opening a new bug in Sun's Bugster database
> and closing this one as TRACKEDINBUGSTER. Is there any reason why this can't
> be done?

How does it help the current "deadlock" situation ? I have a patch and need
someone to help me getting it tested&&commited (and maybe the scope should be
defined - a plain look at the script shows a lot more problems which can easily
be fixed, too) but right now there is no consolidation which can be targeted
nor can I get a sponsor to something which is completely Sun-internal right
now.

Bonnie:
Any suggestions how to proceed ?

(In reply to comment #16)
> (In reply to comment #15)
> > This seems a prime candidate for opening a new bug in Sun's Bugster database
> > and closing this one as TRACKEDINBUGSTER. Is there any reason why this can't
> > be done?
> 
> How does it help the current "deadlock" situation ? I have a patch and need
> someone to help me getting it tested&&commited (and maybe the scope should be
> defined - a plain look at the script shows a lot more problems which can easily
> be fixed, too) but right now there is no consolidation which can be targeted
> nor can I get a sponsor to something which is completely Sun-internal right
> now.

Here's my understanding of the problem. Please let me know
where I went wrong:

OpenSolaris currently uses Nevada SVR4 packages to generate it's
IPS packages. If it can, it will just try to use those SVR4
packages "as is", therefore, where possible, fixes should be done
to the Nevada source code and OpenSolaris will automatically 
pick it up when they are delivered to the OpenSolaris release dock.

We have found that not all engineering groups at Sun are tracking
bugs filed at defect.opensolaris.org and in order to get their
attention, we've been filing similar bugs in Bugster, and closing
the OpenSolaris one as TRACKEDINBUGSTER. It's not perfect, but hey,
you do what you can.

You've made modifications to patchadd which is delivered in the
SUNWswmt SVR4 package. Therefore, wouldn't it be best to get the
engineers that work on that package to take what you've done and
fix it "at the source"? Then we just pick up those changes when 
they are integrated into a future Nevada WOS build?

Actually, I believe the correct thing to do here is to change this bug into a
request to remove SUNWswmt from the repository (since we lack a proper way to
delete packaes at the moment, that means turning this into an empty package and
removing it from the slim_cluster cluster).  This is because although at the
moment we continue to support the legacy SVR4 package tools, there are no plans
at the moment to support the patch tools going forward.

(In reply to comment #18)
> Actually, I believe the correct thing to do here is to change this bug into a
> request to remove SUNWswmt from the repository (since we lack a proper way to
> delete packaes at the moment, that means turning this into an empty package and
> removing it from the slim_cluster cluster).  This is because although at the
> moment we continue to support the legacy SVR4 package tools, there are no plans
> at the moment to support the patch tools going forward.

Okay. So should I just change this bug Summary appropriately and move
it over to opensolaris/packaging (with an appropriate comment), or would 
you prefer to see a new bug opened for the SUNWswmt package removal?

Thanks.

Given that SVR4 patches will not be supported in future releases of
OpenSolaris, it's time to remove SUNWswmt from the repository.  Since there are
a few class-action scripts delivered by that packages, we will instead import
them into SUNWpkgcmds for legacy pkgadd(1M) use (this covers, for example, the
i.preserve class-action script).

Fixed in changeset 44a36244e83a68b8ecbfab35f28bf1d367ccf2e7.