Why is 118833-36 an interactive patch?
When I ran `smpatch update' today, it reported:
NOTICE: Patch 118833-36 cannot be installed because it is typed as "interactive" which is prohibited by policy.
After the `init 6', a whole bunch of other patches also didn't install because they
depended on this kernel patch. This patch is not really interactive! When I installed
it in single-user mode, it didn't ask me any questions.
I assume it's marked interactive because you need to read the README before
applying the patch. The README says that it must be applied in single-user mode,
and that the machine then requires a reconfiguration reboot before applying any
more patches.
Why can't smpatch do all of this? Couldn't it do the reboot after applying this patch
and then continue with the dependant patches? There's a similar issue with the new
kernel patch for Solaris 10 x86.
# 1
Garry,
Considering the amount of changes that are implemented by the current kernel patches, and the number of special instructions that are listed in the README (71 for sparc, 57 for x86), can you understand why it cannot be applied automagically by any patch tool? Here is an excerpt from the smpatch man page that gives it's definition of interactive:
interactive
An update that cannot be applied by running the usual
update management tools (pprosvc, smpatch, or patchadd).
Before this update is applied, the user must perform
special actions. Such actions might include checking the
serial number of a disk drive, stopping a critical dae-
mon, or reading the update's README file.
Thereby any patch that is deemed to require the administrator to read, and likely act upon the information in the README will be flagged as "interactive".
Of course, should you wish to totally isolate yourself from the patching process and risk breaking your system by applying patches that have been marked as "interactive" (for your safety), you can find the information on how to do this in the smpatch man page:
$ man smpatch
If you are unsure of how man works then I suggest you read the man page for man:
$ man man
Mod.
# 2
Please complain to the people who create patches that are this complicated.
In order to make Solaris a world-class operating system, we require automated
patch tools. There has to be a way to make this work. In this case, I was patching
a Solaris 10 11/06 system that was almost up to date on patches. Most of the
warnings in the README did not apply in this case. Smpatch could have checked
some of that information and then done automatically what I did by hand.
# 3
Dear Gary
While the need to mark this and similar patches as interactive may be frustrating in some cases. I hope you can see that not all possible combinations or permutations of environment coudl reasonably be made automatic.
Solaris is already a world class o/s and that is why it is so complicated in some respects due to the popularity and number of situations needing attention.
This aside , we hope that you find a way to handle this inconvenience to yourself and if we can help we will.
Mod.
# 4
Again, please inform the people responsible for creating patches that theyshould ensure that these patches can be applied by smpatch without furtheraction. This is especially important for kernel patches because these patchesare updated so frequently.
# 5
Dear Moderador,
I had a similar problem and ended up applying patch 118833-36 manually.
I understand that Sun needs to be conservative regarding kernel patches.
However, it would be nice to have an option allowing customers to make the final decision. I read in the smpatch man pages that say that an option is to specify interactive in the policy and patches similar to 118833-36 would be applyied automatically by smpatch. It did not work.
In my case, last time I counted, I am responsible for 50+ Solaris servers and the reason why I use smpatch and SunUC is to automate patching, one thing that we are doing almost every other month because of increasing demand to close security vulnerabilites in a shorter and shorter time. Applying even one patch manually in at least 50+ servers ...
Besides, companies like mine have test and/or QA servers that mirror production servers. Everything is tested in the QA environment before moved to production servers. So, I am one in favor of having an option in smpatch to automatically to install ALL patches with the possible exception of OBP (openboot) patches and updates.
shena at 2007-7-8 23:44:28 >
# 6
At the very lease the README notes should include the patch level that they were added.My dictionary defines interact:to act on one another; act reciprocallyLet's raise the bar for the world class O/S.
# 7
To me this was installed, although I was running in multiuser.
Seems to me that information about patches and how they are
classed always not work when using a proxy.
If a patch not is found in the fetched patch database, I think i should not
be installed right away. It could perhaps be queued.
# 8
> To me this was installed, although I was running in
> multiuser.
> Seems to me that information about patches and how
> they are
> classed always not work when using a proxy.
>
> If a patch not is found in the fetched patch
> database, I think i should not
> be installed right away. It could perhaps be queued.
The only circumstances I can think of which might cause this is if your proxy has cached an old patch DB (current.zip).
You can most likely rectify this by removing the current.zip files from /var/sadm/spool/patchsvr
I response to the posts requesting that kernel patches such as these be installable by smpatch, it is highly unlikely that this will be implemented. These patches are marked 'interactive' specifically to stop smpatch from installing them automatically.
It is imperative that the README is actually read before installing.
Mod.
# 9
Since 118833-36 can never be applied by smpatch, it's time to freeze that patch
and start building another one that can be applied by smpatch. That way, all of
us will only have to go through the pain of installing it once. Please request
your patch people to do this. Their goal should be to produce patches that can
be applied by Sun's patch tools.
# 10
Garry,
As clearly stated before the kernel patch, which can break many things as mentioned in the README, is marked as "interactive" to prevent the patch from being installed automatically by smpatch in it's default configuration.
I was certain that I had made clear that it is up to the end user to change their smpatch configuration if they so desire.
The reason that the kernel patch is so big and changes so many things at the same time is to prevent incompatible versions of software being installed in your system.
To be perfectly clear on this matter:
smpatch has the ability to install this (and any other) patch IF the user changes their "patchpro.install.types" to include "interactive", "reconfigimmediate", "singleuser", "rebootimmediate". See the man page for further info.
This is something that I would not recommend; as it is very likely that you will break your system by patching it in this manner - hence why it is not the default status of smpatch.
Mod.
# 11
So are you saying that you have no influence over the people who produce patches?Who do I talk to that does?
# 12
Can anybody tell me how to install this patch correctly?
# 13
Dear All
There is a bug related to 118833-36 presently being worked on (6522362). We have had a couple of customers showing smpatch DOES install it , when it ought not to, yourself wanting to know why it is interactive (because it is complex and has a huge README, and this in combination with many an varied environments), and trouble with the -G option when Zones are involved.
Effectively at present, download it from SunSolve and dont expect smpatch to do it, install using patchadd (and dont use the -G option)
We will be sure to update the forums when the issue(s) are resolved, and appreciate your patience in this matter.
Mod.
# 14
This is how it worked for me on my SPARC Solaris 10 3/05 servers.
After smpatch had downloaded the patch into /var/sadm/spool
# cd /var/sadm/spool
# smpatch add -i 118833-36
.... several messages about the patching ....
# touch /reconfigure
# init 6
After the reboot, the kernel should be Generic_118833-36
# uname -a
SunOS xxxxxxx 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-V89
#
shena at 2007-7-8 23:44:29 >
# 15
After unjarring the patch to /var/sadm/spool/118855-36 i did the following:
# chmod -R 755 118855-36
# smpatch add -i 118855-36
add patch 118855-36
Transition old-style patching.
Executing prePatch script...
Disabling kernel module unloading ...
Feb 10 10:40:18 unknown sendmail[769]: [ID 702911 mail.alert] unable to qualify my own domain name (unknown) -- using short name
Feb 10 10:40:18 unknown sendmail[768]: [ID 702911 mail.alert] unable to qualify my own domain name (unknown) -- using short name
Patch 118855-36 has been successfully installed.
Reboot client to install driver.
added profile to /etc/name_to_major
/var/sadm/pkg/SUNWppm/save/118855-36/undo: -- file unchanged
compress(1) returned error code 2
The SUNWppm backout package will not be compressed.
Continuing to process backout package.
#
seems i still haver to set my hostname, but that is an other issue.
# 16
I didn't have any issues installing 118833-36, smpatch installed everything up to and including it, then each of the following patches errored saying a reconfiguration reboot was necessary (not a surprise given the changes in that patch). I did the reboot, and applied the balance of the patches without issue.
If smpatch wasn't supposed to install 118833-36, then why did it? Is this another case of non-existent QA processes in the patching group?
I'm sorry if this stings a bit, but Sun employees have a responsibility to their customers to do proper QA testing of patches and patch tools just like any other Sun software product. When core functionality is broke by changes, then it's pretty clear QA testing wasn't done.
The patch tools have been so flaky since the third week of December that I went back to just installing the recommended patch cluster on all our Solaris 8/9 boxes.I had been using smpatch for somethng like 1.5 yrs but this is the third major tool breakage in the least year. All were because Sun made changes to the patch tools and didn't fully test for issues.
# 17
The issue affecting some systems causing patch 118855-36 to be scheduled for installation by smpatch or updatemanager has been reported as bug 6520882.
# 18
> Since 118833-36 can never be applied by smpatch, it's
> time to freeze that patch
> and start building another one that can be applied by
> smpatch. That way, all of
> us will only have to go through the pain of
> installing it once. Please request
> your patch people to do this. Their goal should be
> to produce patches that can
> be applied by Sun's patch tools.
I notice today that 118855-36 (the equivalent Solaris x86 patch) has been frozen,
with 125101-01 released as a new kernel patch. I hope that this will solve the
current problem, at least once the troublesome patch has been applied.
