pkg command: not found - Systems Maintenance(Archived)

I'm trying to install the necessary certificates so that I can use wget to fetch patches.
Starting here:
I'm on Step Two, obtaining the certificate. I click on the provided link, which takes me to:
where I downloaded the Opensolaris Standard Support key and certificate from
This is where I run into problems: step 3 on that page says:
$ pfexec pkg set-authority \
-k /var/pkg/ssl/OpenSolaris_standard_support.key.pem \
-c /var/pkg/ssl/OpenSolaris_standard_support.certificate.pem \
but when I try to run that command, I get:
pkg: Command not found
Apparently, there is supposed to be a /usr/bin/pkg, but no such command exists on either Solaris 10 system I have. Any ideas? 

well-sun wrote:
I'm trying to install the necessary certificates so that I can use wget to fetch patches.
Starting here:
I'm on Step Two, obtaining the certificate. I click on the provided link, which takes me to:
where I downloaded the Opensolaris Standard Support key and certificate from, there is supposed to be a /usr/bin/pkg, but no such command exists on either Solaris 10 system I have. Any ideas?"opensolaris" != "solaris"
/usr/bin/pkg and the Image packaging system are things in Opensolaris. They are not part of Solaris 10. As far as I can tell, that page you reference is only for OpenSolaris systems and not something useful for dealing with Solaris patches.

Okay, thanks. I guess the next question, then, is where is the equivalent download for Solaris? I want to be able to grab patches with wget, but all attempts to retrieve them that way end up with "Forbidden" or "Not authorized" messages, despite providing my login and password, having a software support contract, and supposedly being authorized to do so. 

Those are the commands to gain access to the "Extras" repository for OpenSolaris and will do you absolutely no good on regular Solaris.
For patches on Solaris 10 you need to register the machine and then follow the patching instructions to get the patches. Normal patches will require the registration number that you got when you registered the machine. If you need assistance on this it's probably easier to just deal with your rep.

In Solaris 10, 'smpatch' is the command-line tool for downloading/installing patches-something like 'yum' on Linux systems. You must have a support contract and have registered your system to use it. There is also a GUI interface. 

Okay, thanks all - I've got this bit licked now.


Attempt to install UpdateConnection on new Ultra 20 fails

I have a new Ultra 20 and when I try to install the update manager, I get a failure (see transcript below). I'm stuck.
Also, with this Sun Ultra 20 I purhcased a three-year support contract. However, nobody at Sun can find my support contract number and I can't sign up for SunSolve without one. How does one get past this barrier?
# ./installUpdateConnection
Adding patch 119575-02
Validating patches...
Loading patches installed on the system...
Loading patches requested to install.
Checking patches that you specified for installation.
Approved patches will be installed in this order:
Checking installed patches...
Verifying sufficient filesystem capacity (dry run method)...
Patch 119575-02 failed to install due to a failure produced by pkgadd.
See /var/sadm/patch/119575-02/log for details
Patchadd is terminating.
bash-3.00# cat /var/sadm/patch/119575-02/log
This appears to be an attempt to install the same architecture and
version of a package which is already installed. This installation
will attempt to overwrite this package.
/home/mel/Downloads/updateConnection/patches/119575-02/SUNWcsu/install/checkinstall: /home/mel/Downloads/updateConnection/patches/119575-02/SUNWcsu/install/checkinstall: cannot open
pkgadd: ERROR: checkinstall script did not complete successfully
Dryrun complete.
No changes were made to the system. 
The 'cannot open' is generally a permission problem.
pkgadd calls the checkinstall script as the user 'install'
(if present on the system) or 'nobody'.
If this user does not have permission to read the checkinstall
file, then there will be an error.
Can you provide the output of ls -l on these files. 
I ran the installer as root, so permissions would not be a probem, would it?
The error log from the patchadd command indicates the patch was missing the checkinstall file. The Sun Update Connect download version for the sparc platform does not include the patches for the x86 platform (but has an empty directory for the 119575-02 patch).
Could you download the x86 version of Sun Update Connection for your AMD Opteron based Ultra 20 and retry installing?
Note that the Sun Update Connection support team are unable to assist with contract issues. We can only assist with problems relating to registering a system with a known contract ID or subscription key. 
We did originally install the x86 version (the UpdateConnection dowload file is named But just to make sure I downloaded it again and reran updateConnectionInstall as root and got the same results.
This is a Sun Ultra 20, an Opteraon-based machine, so this should be the correct installer, no?
Going back to the original thought regarding permissions -
Although you run the installer as root it actually runs scripts as either the "install" user (if present) or "nobody". If the system has been hardened to tighten the security on "nobody" it could cause this error. Does "nobody" have appropriate permissions? 
How do I know what "appropriate permissions" are? Can you be more specific. Since I've not changed any of the permissions or reinstalled anything since the box was shipped, shouldn't it have the permissions originally delivered with the box?
Can I check the location where you extracted the software and are trying to install it software from?
Could you try extracting the software to the /var/tmp directory and installing it from there? 
That worked! It now says its installed and I will try using it.
Sun definitely needs to note this requirement in the instructions. There is no read-me file with the download, and the sole direction on the Update Manager Get Started page is:
"Step 2: Download the Sun Update Connection client software (the Sun Update Manager) then run the installer."
I wonder how many people encounter the same frustration I did because these instructions are too vague?
OK, new problem. How do you run the thing? There is zero documentation on running the updateManager, and it isn't named anything obvious that I can find, or located anywhere obvious, like /opt/SUNWspro.
I'm perhaps just not seeing this, but there appears to be no documentation online for UC. The UC Get Started page say:
he following Sun Update Connection services, System Edition documentation is available on the Sun Download Center (SDLC)[] Web site.
Sun Update Manager 1.0 Administration Guide
Sun Update Connection 1.0 Administration Guide
smpatch(1M) man page
patchsvr(1M) man page
Sun Update Connection, System Edition 1.0 Installation Guide and Release Notes
But I find nothing on that page but links to the binary installed. How do I run UC for the first time? How do I get the admin guide?
Can't tell you how to find the docs but I can tell you how to start it.
Any of 3 ways for JDS users:
JDS Launch menu: Launch->Applications->Utilities->Update Manager
clicking the Update Manager icon in the Notification tray residing in the Gnome panel.
For CDE users:
Update Manager icon in the CDE Application Mgr
You can get the documentation of UC from:
Sun Update Manager 1.0 Administration Guide
Sun Update Connection 1.0 Administration Guide
Sun Update Connection, Sytstem Edition 1.0 Release Notes
The documentation is also available by clicking 'Help and Support' on the Sun Update web site. 
OK, thanks for the pointers to the documentation.
I've encountered what appears to be a bug. After registering my machine with UpdateConnection, the UpdateManager application started its "Analyzing system" process. It has hung on that proces for several hours, with the progress bar at about the 50% point. The bar is not moving, and the Cancel button does not respond. Is there a graceful way to end this process, and how can I determine where it's gone wrong?
You may be able to determine the process that is running by grepping the output of ps for "updatemanager" and kill it with kill or some similar means. Obviously "xkill" or it's ilk will also kill it, but none of this would meet my standard for "graceful".
As for determining what is the problem... one thing to try is starting Update Manager from the command line with /usr/bin/updatemanager -debug and capturing that output.
Similarly running smpatch analyze from the command line may reveal some useful infromation, as Update Manager uses smpatch under the hood.
Finally you can get some useful registration information from ccr
Using the option to get the cns.assetid parameter will indicate if the registration process stored an assetid for your system, and may help check for backend errors as well...
/usr/lib/cc-ccr/bin/ccr -g cns.assetid

pkgadd misunderstanding

I have read all I can fine on pkgadd and still do not know how to install the kernel patch. I do know that I need to go to S (single user) and have done that. I then put this line at the prompt: pkgadd -d . 139556-08. I waited for over a half a hour but nothing. I had no internet interaction. What is the right command or, am I using the identification? 
Beware, patches look a lot like patches and pkgadd may actually try to do something (which would not be a good idea).
You want patchadd for patches, not pkgadd.
# patchadd 139556-08--
Here is what I got from using patchadd: Validating patches...
Loading patches installed on the system...
Loading patches requested to install.
Cannot locate 139556-08 to install.
I am guessing here but it seems I need to download the package first. I have no idea where to go to download the packages. Can you give me that info, if I am right?
I am new to solaris switching from linux. 
Neither pkgadd nor patchadd will attempt to contact remote servers. You have to have the patch or pkg locally. There is a third-party program called 'pca' that does that automation. You should be able to find it on the internet.
In either case, you must have a sunsolve account to access patches.
With the account, go to [], type in your patch number and get the patch.
Cannot locate 139556-08 to install.Assuming that patch 139556-08 is in a directory called somedir then use the absolute path along with patchadd. E.g.,
from man patchadd:
The absolute path name to patch_id or a URI pointing to
a signed patch. /var/sadm/spool/patch/104945-02 is an
example of a patch.
https://syrinx.eng:8887/patches/104945-02 is an example
of a URI pointing to a signed patch.
-M patch_location [patch_list]
Specifies the patches to be installed by directory loca-
tion or URL and, optionally, the name of a file contain-
ing a patch list.
The patchadd man page has plenty of examples in it.
Ok I understand all of that what I do not know is where to go to download the patchs to /var/sadm/spool. If I do not have to download them myself then how is it done? Yes I am newbie.
Thank all who have help so far and will Help in the future 
larka06 wrote:
Ok I understand all of that what I do not know is where to go to download the patchs to /var/sadm/spool. If I do not have to download them myself then how is it done? Yes I am newbie.As Darren has already mentioned you can get them directly from Sunsolve if you have an account. If you do not have an account then there are two options:
You can sign up for a free Sunsolve account which will give you access to critical patches and a small subset of other patches.
You can sign up for a support contract from Sun and then you use that support contract number to get any patches that you want.
As for tools,
You can use the GUI application, "Update Connecttion" to automatically get and install the patches for you.
You can download them yourself and use the patchadd utility to add the patch.
or you can use a third party utility such as Patch Check Advanced (PCA) to get and install the patches for you.
Yea, it's a lot easier on Linux.
My understanding about this update process is not good, to say the least. I finally goofed things up so bad that I am redoing the setup. I tried to save it with safe but was unable. Well I am just going to forget the kernel update this time till I read and understand more.
I thank all of you for all your help and patients.
God Bless 
If you're considering installing just a kernel patch, I would think about applying the solaris 10 recommended patch bundle. It will have the kernel patch, as well as a ton of other patches, some of which may be a pre-requisite of the kernel patch you're trying to install. The recommended patch cluster is also fairly easy to install- there's a wrapper script that does all the work for you. You can download that at the same place as the individual kernel patch at 
The Sun Bigadmin web site also has a patch hub full of information:

how to make x86 to select "Custom Jumpstart" by default  (continued)

hello all,
i have problems with the precedent response, here:
mAbrante said that he adds:
-m install w
to install without configuring X-server
i'm unable to get confirmation of this assertion in man pages!
"man boot" points to "man kernel" which point again to "man boot" without expliciting boot-args...?
In the past, i used to use "- install nowin" on sparc machines
i just want to force jumpstart without starting X11. If someone can point me to the correct documentation?
thanks in advance for help,
I can not vouch for x86 but I used to use boot net - install text on sparc 9 
Hmm, i doubt i found it documented, it was probably just the result of a trial-and-error process and perhaps i got some ideas from Sunsolve.
'install nowin' and 'install w' is the same thing, that is probably documented somewhere.
When you type 'boot net - install w' on a SPARC machine, the 'install w' argument will be used as argument by init (or at least to something that, in the end, starts the installatoin program rather than give you a plain shell).
According to 'man kernel' the -m flag instructs the kernel to pass the argument to -m on to SMF (and svc.startd), even though SMF itself doesn't understand it (i think it even prints an error for it), it will still be accessible by the program that determines what mode you want to boot to (aka if you wish to go to singleuser or into an CLI/GUI install).
Grub info:

Why doesn't Sunray Server patch show up?

Forum Moderator:
We use some of our SunFire X4100 M2 boxes as Sunray Servers which is, as you likely know, a Sun-supported product that has an annual license fee (that we pay ....). This is the set of 10-15 packages that are generally named SUNWut* and tend to be installed in /opt/SUNWut.
We are running Solaris 10u4 x86 on these machines.
It appears to me as if patch 127554-01 (for S10 x86 and 127553-01 for S10 SPARC) is applicable to this system. However, this patch does not show up on my list of applicable patches and, according to 'showrev', has not been installed.
My assumption would have been that UpdateManager would be checking and comparing all SUNW* installed packages to check them for applicable patches. However, as near as I can tell, this patch does not appear to be "on the radar".
1. Am I incorrect in thinking that UpdateManager should be checking for applicable patches for all installed SUNW* packages?
2. Is there anything "special" that needs to be done for a package like the SUNWut* set that has some sort of licensing requirement?
3. Is there something special on the Sun side that has to be done to add patches for the SUNWut* set of packages to those about which UpdateManager is aware or are there classes of SUNW packages for which UpdateManager is of no help?
I would also imagine that these patches should be recommended if the appropriate SUNWut* packages are installed, and both patches are listed in the expanded file.
Please try the following command:
# smpatch update -i 127553-01
If that fails then try using patchadd to collect a better explanation of the error:
# patchadd /var/sadm/spool/127553-01
If the patch does apply then we will need to look at why it is not being recommended. 
Forum Moderator:
Thanks for your quick response. Here's what I did:
1. First I did an "smpatch analyze" .... while it showed me a handful of new, available patches, it didn't show me that 127554-01 was needed.
2. However, I proceeded with "smpatch update -i 127554-01"
It responded with:
127554-01 has been validated
Installing patches from /var/sadm/spool...
127554-01 has been applied.
3. After that it, of course, "showrev -p | grep 127554" shows that
this patch has been applied.
Based on all of this, it appears to me as if something in the "smpatch analyze" step didn't realize that 127554-01 was either an available or a needed patch .... but that when I asked explicitly for it to be installed, things went just fine. In other words, it seems as if the patch actually installed just fine, but that the problem was that it was not being recommended.
Of course, since I've now installed that patch, I don't know how to try to go "backwards" to figure out why it was not being recommended.
Do you agree that it should have been recommended and, for some reason, that recommendation was not triggered? Is there a way do determine why it was not recommended?
You can remove patches using 'smpatch remove -i <patch-id>' or by using 'patchrm <patch-id>. You could then run another analysis on the system to see if anything had changed, although I doubt that the patch will be recommended.
As to why the patch was not recommended in the first instance I have forwarded this question on to our colleagues to see if they can shed some light on it.
In the mean time, do you (or anyone else for that matter) have any sparc systems showing the same problem? 
Forum Moderator:
Thanks for your suggestion. In terms of SPARC machines, I do have access to a SPARC machine that is running Solaris 9 that has the previous version of SRSS (Sun Ray Server Software) installed (3.1 rather than 4.0, I think). I can check to see if it has any patches recommended.
I also have another SPARC machine "sitting fallow" on which I've been meaning to install Solaris 10 and then SRSS to be able to use this machine as a part of a failover group. I'm about to leave for a few days of business travel, however, so it would likely be a week before I'd know the answer to this.
Upon investigation it appears that the realization for Sun Ray patches, where a realization is used by Update Connection to determine whether a patch is applicable to a system, is empty and hence will never be recommended by Update Connection.
We have raised bug 6649893 to have this corrected. 
Forum Moderator:
Thank your for delving into this problem, finding the cause, and for raising the bug to get it fixed. I'm confident that my fellow Sun Ray afficionados will appreciate having this resolved in the not-too-distant future.

smpatch order and patchpro_dnld_xxx are opposite, why?

I noticed that smpatch order output is just opposite of the install order that smpatch update uses and is listed in patchpro_dnld_xxx Obviously one is wrong and it seems smpatch order is wrong but I didn't check further. What's up with that?
# smpatch order -x idlist=analyze.lst > smpatch_order.out
# cat smpatch_order.out
# cat patchpro_dnld_2005.08.03#11:36:12:PDT.txt
This patch bundle was generated by PatchPro.
Please refer to the README file within each patch for installation
instructions. To properly patch your system, the following patches
should be installed in the listed order:
1) 120196-02 !!! REBOOT !!!
2) 120469-01 !!! REBOOT !!!
3) 119587-01
4) 119582-01 !!! REBOOT !!!
5) 120198-02 !!! REBOOT !!!
6) 119858-01 !!! REBOOT !!!
7) 120099-01
8) 119540-03
Can someone from Sun please look at this and comment. 
Thanks for bring this problem to our attention. The order of both lists should be the same. We are currently in the process of resolving this problem. 
ok, I believe I checked Solaris 8 and 9 for this but you might want to test for it on those as well, just to be sure they are correct. 
We are waiting on an update o nthis issue from our Engineering Team.
Once we have an update we shall post it. 
This is a known problem; it is described in Change Request 4975591 "smpatch remove and add reverse patch list"
We do not know when this change will be implemented 
Oh that's rich! 
So which is correct, smpatch order or the download log? When will this "feature" be fixed? 
As smpatch reorders based on dependencies in practice this should not be an issue.
As to when this will be fixed, our engineers have developed a fix but this has not yet been implemented. Currently we do not have a timescale. 
I believe the reversed order is actually because "smpatch update" reads the ordered download file top-down and "smpatch add" reads the idfile file bottom-up. At least that's what my testing showed (last year).
So if you do an smpatch download and intend to use smpatch add, then you need to read the ordered download list into smpatch order and use that resulting list for smpatch add idlist.
Since I have dev and prod environments that require the same patch set I only use smpatch (not updatemanager or updateconnection). This allows me to download all the patches for all systems the same day (e.g. same and use that resulting download file on each host as a key to assure all the hosts are getting the same patches but still getting any hardware specific ones on each host. I order the download file and use the resulting output as the idlist for smpatch add.
been doing this for about a year now, works great and only takes a few minutes prep per host a few days before I want to patch dev. I can post the actual process if folks want to see it, but this gives you the basic concepts.
JB, Yes I would be interested to see your process on this. I had also noticed the difference but what I see is not exectly the reverse order of patches. 
yes some are a bit different in order but that's probably because only some patches have pre-requisites. The main difference is that update reads from top down and add from bottom up. I never got a good answer from Sun on these differences, guess they have biger fish to fry.
here's what I use. It's a summarized version but you'll understand the process. I use update for all hosts that don't have prod/dev/qna/test type dependencies. The following process to assure prod gets the same patches as dev/qna hosts but any hardware specific patches are applied to each host. Works good, but I'm sure someone could make a more scripted version if they had hundreds of boxes. I only have about 35 that fall under this requirement.
note: we keep our own patch proxy with all the patches (~10k).
helps with speed and avoid potential download issues from Sun.
Steps a few days before you patch your dev/qna boxes (in case there are issues downloading)
Do this on all hosts you wish to have patches in sync (dev/qna/prod)
1. cd /var/sadm/spool
2. rm ./* (make sure you are in the correct dir! you can leave or delete the cache dir, don't delete cache dir on patch proxy server if it's Solaris 10 since that's where the registration is.)
3. smpatch analyze (I like to see the list)
4. smpatch download
5. update the date in the following line to reflect the date of the file from your download (above)
6. cd /var/sadm/spool; cat patchpro_dnld_2006.05.12*.txt | grep -- - | awk '{print $2}' > patches
7. smpatch order -x idlist=/var/sadm/spool/patches > patch_order
Steps on day of patching (either dev/qna or prod):
single user
1. smpatch add -x idlist=/var/sadm/spool/patch_order
immediate reboot (usually with reconfigure boot, depending...)
optional: use patchdiag to check for SUNWsan patches not caught by smpatch and disksuite/svm patches on any hosts running that.
Like I said, it's a pretty simple process. I know some just download to one OS version and copy the files to all the others. I find my method more complete (occasionally) and it's basically as fast. 
JB, Thanks for that. I'll have a close look and see how applicable it is to my situation.