Re: [pca] Reboot recommended / required behaviour

[Don O'Malley]

Hi, Just catching up on some old mail and came across this one. I asked a colleague familiar with Live Upgrade about the issues with the boot archive after using LU to patch and here's what he had to say: Hi If they install the latest LU patches ( 121430/121431 SPARC/x86 ), then they can install KU's using patchadd -R/luupgrade -t, and luactivate will take case of the boot archive bit on bootign into the new BE. So essentially if they use latest Lu they should be fine  ( if there are problems using latest LU patcehs, then it's a bug most likely ) But if they use say patchadd -R, then use an older LU patch ( pre u6 ) then yes the system will fail to boot if the boot archive was modified after installing 137137-09. Or if they use non-standard technologies like ufsrestore to create BE's then it is up to the user to run create_ramdisk manually, note it has to be create_ramdisk from the ABE that is run. Enda HTH, -Don Ateeq Altaf wrote: 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_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   Please consider the environment before printing this email. Find out more about Talis at www.talis.com shared innovationTM Any views or personal opinions expressed within this email may not be those of Talis Information Ltd or its employees. The content of this email message and any files that may be attached are confidential, and for the usage of the intended recipient only. If you are not the intended recipient, then please return this message to the sender and delete it. Any use of this e-mail by an unauthorised recipient is prohibited. Talis Information Ltd is a member of the Talis Group of companies and is registered in England No 3638278 with its registered office at Knights Court, Solihull Parkway, Birmingham Business Park, B37 7YB.