Re: [pca] Oracle removed support from patchdiag.xref for --minimal option in pca?
Could we approach this a different way by first getting a list of missing patches relevant to a patchdiag slightly *newer* than the CPU, then filter that list with the list of patches on the CPU? e.g., pca missing patches.missing.full for patch in `cat cpu_patches.lst | cut -d- -f1`; do patch_id=`echo $patch | cut -d- -f1` grep ^$patch_id patches.missing.full echo $patch cpu_patches_check.lst done; pca -l $(chkmin $(cat cpu_patches_check.lst)) The chkmin is to avoid re-installing the same release of a patch if the patchdiag.xref contains a newer release than the CPU. I haven't tried any of the above to see if it produces a list as I'm dreading trying to navigate Oracle support to see if there's a way to get the recent CPU patch_order file without downloading the 2GB zip file. Ateeq -Original Message- From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Martin Paul Sent: 15 June 2011 10:07 To: PCA (Patch Check Advanced) Discussion Subject: Re: [pca] Oracle removed support from patchdiag.xref for --minimal option in pca? Jeff wrote: It does reduce the number of patches to 100, but the problem still exists that pca doesn't verify the packages are installed that the patches applies to if a specific revision is requested. So in the case of the server I'm testing, it was built with the SUNWCrnet cluster, so it has minimal packages and the actual number that would be applied is around 10. I see, you're right. It only makes sense if you stick to the Entire Distribution cluster. I really think the best solution is to either convince Oracle to package a patchdiag.xref that cooresponds with the revisions in the CPU within the CPU bundle, or for me to grab patchdiag.xrefs around the release date until I find one that cooresponds with the bundle. Agreed, it would be best if Oracle provided a matching patchdiag.xref with each CPU. Chances for that are pretty low, I guess. Same for finding an xref file from a certain date which matches the CPU exactly. As Don already mentioned, the ultimate solution would be to create a new patchdiag.xref from scratch with the data from the patches in the CPU. All the required information should be in patchinfo (PATCHID, PATCH_ARCH, PATCH_REQUIRES), the README (Synopsis, Date) and the SUNW*/pkginfo files (VERSION). The R/S flags aren't in there, but they won't matter. Anybody want to try it? :) I guess I could come up with a rough script, it's the fine-tuning and testing which scares me off, as it will take a lot of time. All I have to say is keep up the good work Martin, you are keeping a lot of Solaris shops afloat. Thanks for that! Martin. This email and any attachment to it are confidential. Unless you are the intended recipient, you may not use, copy or disclose either the message or any information contained in the message. If you are not the intended recipient, you should delete this email and notify the sender immediately. Any views or opinions expressed in this email are those of the sender only, unless otherwise stated. All copyright in any Capita material in this email is reserved. All emails, incoming and outgoing, may be recorded by Capita and monitored for legitimate business purposes. Capita exclude all liability for any loss or damage arising or resulting from the receipt, use or transmission of this email to the fullest extent permitted by law.
[pca] chkmin ignoring obsoletions if an older version of the patch is installed
On my system I have the following patches related to 'providing' 124204:
bash-3.00# patchadd -p | grep 124204
Patch: 120473-12 Obsoletes: 117463-05 118890-03 119985-02 120469-07 121006-02
121278-01 121294-01 122535-01 123330-01 123350-01 123356-02 123911-01 124204-04
124280-01 125795-01 Requires: 118833-36 122640-05 123839-01 Incompatibles:
Packages: SUNWcsr SUNWcsl SUNWkvm SUNWtecla SUNWperl584core SUNWperl584usr
SUNWkrbu SUNWopenssl-libraries SUNWvolu SUNWscpu SUNWzfskr SUNWzfsr SUNWsmapi
SUNWzfsu SUNWcslr SUNWfmd SUNWdtrc SUNWsndmu
Patch: 124204-03 Obsoletes: Requires: 123839-01 122640-05 118833-25
Incompatibles: Packages: SUNWzfskr SUNWzfsr SUNWzfsu SUNWfmd
Running chkmin on this system tells me I need to install patch 124204-04 when
that obviously isn't the case:
bash-3.00# ./chkmin 124204-04
124204-04
I've made the following addition to not overwrite a higher patch rev with a
lower one in the code, which I think should address the problem but not sure if
it's too simple and I've missed something:
bash-3.00# diff -u chkmin.orig chkmin
--- chkmin.orig Fri May 13 18:42:26 2011
+++ chkmin Fri May 13 18:53:46 2011
@@ -10,6 +10,7 @@
chomp; $_ =~ s/Requires:.*$//;
foreach my $i (split (/[, ]+/, $_)) {
next unless ($i =~ /^(\d{6})-(\d{2})$/);
+next if (exists $p{$1} and $p{$1} ge $2);
$p{$1}=$2;
}
}
Has anyone else come across this issue?
Thanks
Ateeq
Ateeq A Altaf
Technical Consultant, Capita Software Services
Knights Court, Solihull Parkway
Birmingham Business Park B37 7YB
Office: 0870 400 5440
Fax: 0870 400 5001
email: ateeq.al...@capita.co.ukmailto:firstname.surn...@capita.co.uk
Part of The Capita Group plc www.capita.co.ukhttp://www.capita.co.uk
This email and any attachment to it are confidential. Unless you are the
intended recipient, you may not use, copy or disclose either the message or any
information contained in the message. If you are not the intended recipient,
you should delete this email and notify the sender immediately.
Any views or opinions expressed in this email are those of the sender only,
unless otherwise stated. All copyright in any Capita material in this email is
reserved.
All emails, incoming and outgoing, may be recorded by Capita and monitored for
legitimate business purposes.
Capita exclude all liability for any loss or damage arising or resulting from
the receipt, use or transmission of this email to the fullest extent permitted
by law.
Re: [pca] Reboot recommended / required behaviour
I usually use Live Upgrade with PCA but LU isn't quite there with the new boot archive. Quite often you need to run bootadm update-archive against the alternate LU root manually in order to have a bootable environment and put up with a spurious update-archive in the live environment because some patch puts the update-needed flag in the wrong place. Ateeq Ateeq A Altaf Technical Consultant, Talis 0870 400 5440 ateeq.al...@talis.com From: pca-boun...@lists.univie.ac.at [mailto:pca-boun...@lists.univie.ac.at] On Behalf Of Fred Chagnon Sent: 23 March 2009 15:50 To: Glenn Satchell; PCA (Patch Check Advanced) Discussion Subject: Re: [pca] Reboot recommended / required behaviour Indeed Glenn, that's exactly what I had to do (well, I booted from the network to get a shell, but same difference). And that's also why I am now trying to ensure that all my Solaris 10 servers reboot immediately after any kernel patch. Yes it slows things down if a server is multiple revs behind but I think this is a good trade-off. Besides, our jumpstart environment is now installing Update 6 on new systems, and as you all know, this comes with kernel version 137137-09 already so this patch modification really only adds complexity for much older installs. Speaking of Live Upgrade, I was reading an article this morning where PCA is once again mentioned as a good tool to do the analysis phase of a patch installation using this method. I don't think the author is completely familliar with the tool (otherwise he would probably talk more about how it kicks the crap out of all the others he mentions) but it's always nice to see it get mentioned alongside all the other official solutions. http://blogs.sun.com/bobn/entry/dr_live_upgrade_or_how Fred On Mon, Mar 23, 2009 at 9:51 AM, Glenn Satchell glenn.satch...@uniq.com.au wrote: If you install kernel patch 137137-09 without rebooting then there will be trouble. This patch installs boot archive, just like x86. Subsequent kernel patches expect this to be in place. The result is a system that will not boot. I had to boot from DVD then mount / and /var and patchrm the kernel patches and their dependancies. From my experience I would recomend using --stopafter each kernel patch and reboot. Yes it's time consuming, but still quicker than restoring from backup, etc. Of course, if you patch regularly (say more than every few months) then you typically don't get this problem as you would only be installing one kernel patch in each run. regards, -glenn Date: Mon, 23 Mar 2009 09:08:37 -0400 From: Fred Chagnon fchag...@gmail.com I appreciate the answer Martin. In my case I will continue to trust pca's behaviour, however given my horrible past experience with kernel patches I will likely add them to a 'stop after' line in my config file. Thanks again for your.feedback. Always informative. Fred On 3/23/09, Martin Paul mar...@par.univie.ac.at wrote: Hi Fred, My understanding it is that the logic between patchinfo and what PCA spits out works like this: reconfigimmediate -- Reconfig required rebootimmediate -- Reboot required reconfiglater -- Reconfig recommended rebootlater -- Reboot Recommended Correct. Correct me if I'm wrong, but when pca comes across a 'reconfig immediate' patch, for example *137137-09*, shouldn't it stop dead in it's path and prompt the user to reboot before proceeding with further patches? I think it just keeps on trucking until all the patches in it's list are done, doesn't it? You're right, a patch with *immediate will not make pca stop installing patches, it will go on. There are three reasons for that behaviour: After years of patching like this, I haven't seen a problem with it. Ok, that's a weak argument, I know :) pca uses patchadd to install patches, and assumes its behaviour to be a kind of base standard. As you might guess, patchadd doesn't refuse to install further patches (for exceptions, see below), so pca follows this behaviour. The third and strongest reason is this statement by Sun: http://blogs.sun.com/patch/entry/definitive_interpretation_of_the_reboot immediat e (or see InfoDoc 249046). It says: reconfigimmediate: the system is in a potentially inconsistent state until the system is rebooted ... However, since the footprint of the patch utilities is relatively small, it is normally OK to continue to apply further patches before initiating the reboot. In cases where this is not OK, the patch in question will typically contain additional code to prevent further patches from being applied until the reboot takes place (e.g. 118833-36/118855-36, whose patch scripts replace 'patchadd' with a no-op telling the user to reboot the system). All this convinced me that pca's behaviour is OK, especially as you probably would need more than one reboot during a regular patch session, slowing down things a lot. For 100% safety, I guess Sun's (and my) answer would be to use Live
