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_rebootimmediat 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 >> Update to install patches in an inactive boot environment. >> >> Martin. >> >> > > >-- >Fred Chagnon >fchag...@gmail.com >
