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
119540-03
120099-01
119858-01
120198-02
119582-01
119587-01
120469-01
120196-02
# 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
#
[1008 byte] By [
jwbledsoe] at [2007-11-26 6:03:23]

# 9
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 current.zip) 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
# 11
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.