This patch is very bad.
It turned my V20z server (Solaris 10 3/05 plus
all patches) un-bootable.
Blue screen from Solaris primary boot system
just state "Cannot find boot.bin"
I suspect this patch should only be applied
to S10U1 1/06 systems. But UpdateManager
happily applied it anyway to my 3/05 patched server.
At home I have a 1/06 system where 118844-27
worked just fine though.
This forum is only used for the discussion of Sun Update Connection application.
The problem which you are having relates to compatabilty issues with patch 118844-2.
We are not responsible for the design or support of individual patches.
As such we recommend that you use a different discussion group.
Patch 118844-27 is a kernal patch for x86, please find below 2 discussion groups, which may be able to assist you with your enquiry:
Solaris[tm] (x86 Platform Edition)
http://forum.sun.com/forum.jspa?forumID=11
General Solaris 10 Discussion
http://forum.sun.com/forum.jspa?forumID=271
See ticket 64876010
I think there is more to it than whats in the Sun Alert
which I just read. I believe the main points of the alert was taken care of (except the fact that the Alert talks about how to apply the patch manually with a reboot
at certain times, now I did it using the UpdateManager that did NOT do that, so I still think this issue is partially at least an issue with UpdateManager)
The resolution will be that I intend to manually install GRUB on the disk, but before I can do that, I must download and burn at least CD1 of the 1/06 update.
Can I check if you specifically refgerring to the instructions for applying patch 117435-02 "SunOS 5.10_x86: biosdev patch" and rebooting prior to applying patch 118844-27 "SunOS 5.10_x86: kernel Patch"?
In other words, had Sun Update Connection had applied both patches on the same shutdown on your system?
Yes, all requirements as noted in the Sun alert
were satisfied, including the reboot requirement after
117435 (which was installed back in Oct really, many reboots since then). Currently trying on other systems to see if I can reproduce it. First server has been recovered by manually installing GRUB stage1 and stage 2, fixing active partition, manually writing
a grub menu.lst file.
