[pca] Reboot recommended / required behaviour

[Ateeq Altaf]

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.altaf at talis.com

 

 

 

From: pca-bounces at lists.univie.ac.at
[mailto:pca-bounces at 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.Satchell at 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 <fchagnon at 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 <martin at 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
>> Update to install patches in an inactive boot environment.
>>
>> Martin.
>>
>>
>
>
>--
>Fred Chagnon
>fchagnon at gmail.com
>






-- 
Fred Chagnon
fchagnon at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.univie.ac.at/mailman/private/pca/attachments/20090324/6e888df3/attachment.html