Re: [pca] 137137-09
Allen Eastwood wrote: Really, Sun needs to update 137137-09 to have 126419 as a required patch. As far as I know, Sun won't publish new revisions of kernel patches which have been superseded by a new kernel patch. What they've done in the past is to publish a new revision of one of the patches required by the kernel patch which itself then requires 126419. No idea whether there are plans to do that. Martin.
Re: [pca] PCA not reporting on patches that may need to be re-installed
Norman Lyon wrote: Wait Can't we just drop the '.$ARCH' concern and look at the REV= part of the VERSION? From my initial checking, I'm seeing that the multiple package names are showing up with different versions... Seems as if we're getting to the very core of the problem. You are right, in your example one could ignore ARCH, as the VERSION is enough to differ between the packages; I had not noticed that yet. It's not valid for all packages, though. I looked up the problem reports I got back in 2008/09 when I had added recognition of partly installed patches to pca, and it was exactly the packages which have the same VERSION for all *.ARCH packages which caused problems. Unfortunately this mostly affected kernel patches, so pca started trying to re-install those which made me retract the code quickly. I've grep'ed for "VERSION" in Product/*.*/pkginfo now for Solaris 9 9/05 and 10 10/08 now on my jumpstart server. Here's a list of affected packages for Solaris 10 (the one for Solaris 9 is longer): FJSVvplr.u/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25 FJSVvplr.us/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25 FJSVvplu.u/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25 FJSVvplu.us/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25 SUNWiopc.u/pkginfo:VERSION=11.10.0,REV=2006.07.11.11.28 SUNWiopc.v/pkginfo:VERSION=11.10.0,REV=2006.07.11.11.28 SUNWnxge.u/pkginfo:VERSION=11.10.0,REV=2007.07.08.17.44 SUNWnxge.v/pkginfo:VERSION=11.10.0,REV=2007.07.08.17.44 There are no problems when a patch includes e.g. both SUNWnxge.u and SUNWnxge.v, as then on both sun4u and sun4v the package will be patched. The problem is e.g. 120011-14, which includes only SUNWiopc.v. So installing the patch on sun4u, SUNWiopc will not be patched, and the routine to find unpatched packages shows a false positive, as SUNWiopc:11.10.0,REV=2006.07.11.11.28 is installed but not listed in "showrev -p". It's too bad - at the end, it's only a handful of patches which will break the detection routine for partly installed patches, but for those there's no standard way to identify them from xref data. Some kind of hard-coded whitelist would be necessary to ignore certain patches and/or packages, but it will be nearly impossible to really test this with a reasonable amount of time and effort. Still - if you decide to implement and use your local check script, please let me know how it works out. Martin.
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 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 > >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 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. >>
Re: [pca] PCA not reporting on patches that may need to be re-installed
I see what you see in S9 and S10. I don't care about S8, but the story is a tad more complex with more than just 2 architectures (sun4[dmu]). BUT, what I'm seeing, at least in 9 and 10, is that (at least with the patches in the EIS bundles), if different architectures share a common package version and package name, the patches that apply to the package is updated for both architectures (I'm ignoring x86 here, since that has only 1 arch type, so I don't foresee an issue). Therefore if I have a particular version identifier for a package, and the patch patches that package:version, it'll patch it, regardless of architecture. So, my current question for you is, do you have any more info on the problems you had? Quoting Martin Paul : Norman Lyon wrote: Wait Can't we just drop the '.$ARCH' concern and look at the REV= part of the VERSION? From my initial checking, I'm seeing that the multiple package names are showing up with different versions... Seems as if we're getting to the very core of the problem. You are right, in your example one could ignore ARCH, as the VERSION is enough to differ between the packages; I had not noticed that yet. It's not valid for all packages, though. I looked up the problem reports I got back in 2008/09 when I had added recognition of partly installed patches to pca, and it was exactly the packages which have the same VERSION for all *.ARCH packages which caused problems. Unfortunately this mostly affected kernel patches, so pca started trying to re-install those which made me retract the code quickly. I've grep'ed for "VERSION" in Product/*.*/pkginfo now for Solaris 9 9/05 and 10 10/08 now on my jumpstart server. Here's a list of affected packages for Solaris 10 (the one for Solaris 9 is longer): FJSVvplr.u/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25 FJSVvplr.us/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25 FJSVvplu.u/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25 FJSVvplu.us/pkginfo:VERSION=11.10.0,REV=2005.01.20.17.25 SUNWiopc.u/pkginfo:VERSION=11.10.0,REV=2006.07.11.11.28 SUNWiopc.v/pkginfo:VERSION=11.10.0,REV=2006.07.11.11.28 SUNWnxge.u/pkginfo:VERSION=11.10.0,REV=2007.07.08.17.44 SUNWnxge.v/pkginfo:VERSION=11.10.0,REV=2007.07.08.17.44 There are no problems when a patch includes e.g. both SUNWnxge.u and SUNWnxge.v, as then on both sun4u and sun4v the package will be patched. The problem is e.g. 120011-14, which includes only SUNWiopc.v. So installing the patch on sun4u, SUNWiopc will not be patched, and the routine to find unpatched packages shows a false positive, as SUNWiopc:11.10.0,REV=2006.07.11.11.28 is installed but not listed in "showrev -p". It's too bad - at the end, it's only a handful of patches which will break the detection routine for partly installed patches, but for those there's no standard way to identify them from xref data. Some kind of hard-coded whitelist would be necessary to ignore certain patches and/or packages, but it will be nearly impossible to really test this with a reasonable amount of time and effort. Still - if you decide to implement and use your local check script, please let me know how it works out. Martin.
