Re: [pca] Three patches Using /var/tmp/patchdiag.xref from Nov/10/13 fail to install on a T2000

2013-11-12 Thread Martin Paul 
Strange - this patches are explicitely for the sun4v architecture (which 
the T2000 has), and they installed fine on my test T3 (which is sun4v as 
well).


Can you run these commands and send me the 3 output files:

  uname -a > uname.out
  showrev -p > showrev.out
  pkginfo -x > pkginfo.out

Martin.

Re: [pca] Three patches Using /var/tmp/patchdiag.xref from Nov/10/13 fail to install on a T2000

2013-11-12 Thread Martin Paul 

Am 12.11.2013 13:18, schrieb Richard Skelton:

This machine was built from a flash image which can install on Sun4u and
Sun4v


Maybe that's what's creating troubles here. After looking at the 
provided files, I found out that the affected system has multiple 
versions for different architectures installed for some of the packages.


E.g. patch 150109 patches SUNWcakr.v (which means it will only apply to 
sun4v systems). In your pkginfo output I see:


SUNWcakrCore Solaris Kernel Architecture (Root)
(sparc.sun4u) 11.10.0,REV=2005.01.21.15.53
SUNWcakr.2  Core Solaris Kernel Architecture (Root)
(sparc.sun4us) 11.10.0,REV=2005.01.20.17.25
SUNWcakr.3  Core Solaris Kernel Architecture (Root)
(sparc.sun4v) 11.10.0,REV=2005.08.25.02.12

So three instances of SUNWcakr are installed, for sun4u, sun4us and 
sun4v. That's no problem for PCA, it correctly identifies 150109 to 
apply to your system.


It seems as if patchadd has a problem with that situation, though. Even 
though the VERSION in  150109-01/SUNWcakr.v/pkginfo perfectly matches 
tht installed package (SUNWcakr.3, sparc.sun4v, 
11.10.0,REV=2005.08.25.02.12), it refuses to install the patch.


Try to remove SUNWcakr and SUNWcakr.2 and check whether PCA still shows 
the patch as missing and patchadd installs it. If so, you should 
probably adapt your installation procedure.


hth,
Martin.

Re: [pca] Three patches Using /var/tmp/patchdiag.xref from Nov/10/13 fail to install on a T2000

2013-11-12 Thread lastmiles . 
This is a perfectly valid bug report and service request to file via
MOS to Oracle. They will initially deny the problem but if you press a
little then the thing gets reported to Solaris guys in there and they
will look at it. I had to go through the same silly dance on a bug
with "zoneadm move" which fails when a zone has to go from one ZFS
filesystem to another on separate ZPools and there is a file or
directory entry with oddball characters in it.  Turns out that zoneadm
has to call cpio to do the copy and then cpio fails when it hits a
special character anywhere in the file pathnames.  So, push the
problem over onto the MOS folks because this looks like a valid bug in
patchadd.

Paul

On 11/12/13, Martin Paul  wrote:
> Am 12.11.2013 13:18, schrieb Richard Skelton:
>> This machine was built from a flash image which can install on Sun4u and
>> Sun4v
>
> Maybe that's what's creating troubles here. After looking at the
> provided files, I found out that the affected system has multiple
> versions for different architectures installed for some of the packages.
>
> E.g. patch 150109 patches SUNWcakr.v (which means it will only apply to
> sun4v systems). In your pkginfo output I see:
>
> SUNWcakrCore Solaris Kernel Architecture (Root)
>  (sparc.sun4u) 11.10.0,REV=2005.01.21.15.53
> SUNWcakr.2  Core Solaris Kernel Architecture (Root)
>  (sparc.sun4us) 11.10.0,REV=2005.01.20.17.25
> SUNWcakr.3  Core Solaris Kernel Architecture (Root)
>  (sparc.sun4v) 11.10.0,REV=2005.08.25.02.12
>
> So three instances of SUNWcakr are installed, for sun4u, sun4us and
> sun4v. That's no problem for PCA, it correctly identifies 150109 to
> apply to your system.
>
> It seems as if patchadd has a problem with that situation, though. Even
> though the VERSION in  150109-01/SUNWcakr.v/pkginfo perfectly matches
> tht installed package (SUNWcakr.3, sparc.sun4v,
> 11.10.0,REV=2005.08.25.02.12), it refuses to install the patch.
>
> Try to remove SUNWcakr and SUNWcakr.2 and check whether PCA still shows
> the patch as missing and patchadd installs it. If so, you should
> probably adapt your installation procedure.
>
> hth,
> Martin.
>
>