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_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 > > > > > -- Fred Chagnon fchag...@gmail.com
