Enda O'Connor ( Sun Micro Systems Ireland) wrote On 10/17/06 14:43,: > Hi > There is also a seperate miniroot issues in that the KU cannot be > applied because the prepatch now checks if we ran a patchadd -C and if > so, then proceeds to test if a package SUNWicda which is only specific > to update 3 is in the miniroot. > > We need to either > 1 rip this dependency on SUNWicda out somehow ( not clear what is in the > KU that now requires the miniroot have an update 3 onwards package > SUNWicda ) > 2 if we cannto rip it out we need to investigate if we can somehow via > genesis add SUNWicda to the miniroot
So I assume this script was put in place for a reason.. As such, we need to follow this idea to genesis add SUNWicda to the miniroot - if that is possible... The script saying:- This patch requires the installation of the latest version of the SUNWicda package. The SUNWicda package can be found on the Solaris 10 Update 3 (12/2006) installation media or newer Solaris 10 updates. is not a good answer. Angela > Not clear what effect this will have on FCS,U1 or U2 > Genesis to a miniroot is highly undesirable as it hardly works in > live environments > Woudl strongly suggest avoiding this at all costs > > I'd ssuggest that we investigate option 1 above and see why SUNWicda is > now a hard requirement for patchadd -C in FCS through 6/06 > > The issue with SUNWsibi conflicting with generic patches can be solved > via modifications to the miniroot svc repository.db. > Not clear when that will happen though, but we can document it for now I > guess. > > Enda > > Angela Byrne - Solaris Sustaining wrote: > >>Hi All, >> >>I wanted to point out that we need to fix this issue now with the >>KU as we are about to rejuvenate the KU at the end of Update 3. >>This KU must be able to install in the miniroot since all future >>new KUs will require this old one. >> >>I am adding Peter Harvey to this thread as he has picked up a customer >>P1 bug on this >> - relating to the inability to install an SBD KU onto an update 2 >> miniroot. >> >>Peter, >> >>Please share the bugID with us. >> >>Also below is snippets from this thread which you will find useful >> >>Angela >> >> >>James Carlson wrote On 10/04/06 14:55,: >> >> >>>Enda O'Connor ( Sun Micro Systems Ireland) writes: >>> >>> >>> >>>>I was not aware of this particular mess. For now I'm not too convinced >>>>of how to fix this in the short term ( at least S10 time anyway ), ie >>>>customers applying patches such as the KU to their miniroot. >>>>I guess we could include some rev of SUNWsibi, but this is ugly and as >>>>SUNWsibi is different from FCS to 1/06 and again in U3, not clear what >>>>implications this would have. >>> >>> >>>I agree; it's not clear. We could add SUNWsibi to the releases >>>(putting it somewhere convenient, such as Solaris_10/Tools/SUNWsibi), >>>and include README notes for those patching the miniroot that >>>describes how to use it. >>> >>>An alternative might be to have a special form of the original patch >>>-- intended for miniroot use only -- that merely has those 'special' >>>files excised. >>> >>>Both have risks, and it'd be good to limit the amount of time we do >>>something like that. >>> >>> >>> >>> >>>>I suggest a bug/RFE to cover the whole implementation of SUNWsibi to >>>>cover the wider picture, I can log that, but we need to agree some short >>>>term fix/hack for now as well. ( either that or not miniroot patching >>>>for KU's, which is not good ) >>> >>> >>>Thanks for logging the bug. ;-} >>> >> >> >> http://monaco.sfbay/detail.jsf?cr=6478159 >> >>Sarah Jelinek wrote On 10/04/06 14:51,: >> >> >>>>Biut SUNWsibi has changed from FCS to u1 and again for U3, so what rev >>>>of SUNWsibi do we ship in say KU 118855-29 for instance? >>> >>>I don't know.. I hadn't realized this. >>> >>> >>> >>>>I should be able to patch my U2 miniroot with a KU that will also >>>>apply to my U3 miniroot ( at some point down the line ) >>>>But SUNWsibi is different in u2 to u3 miniroot. ( at least build 5 of >>>>u3 anyway ) >>> >>>Agreed. But, right now we cannot patch the miniroot with patches that >>>overwrite critical miniroot files. >>> >>>Please file an RFE to track this issue. I can add the appropriate Caiman >>>keywords so that we track it as part of this work. I don't think this is >>>a bug. It is the design of the existing miniroot that is causing this >>>limitation. The software is working as designed, perhaps badly, but it >>>is working as it has worked for a long time. The redesign of the >>>miniroot to not be special will take some work. >>> >>>thanks, >>>sarah >>>*** >> >> >>James Carlson wrote On 10/04/06 14:27,: >> >> >>>Casper.Dik at Sun.COM writes: >>> >>> >>> >>>>The miniroot is build by install the package SUNWsibi on top of >>>>the already installed packages. >>> >>>[...] >>> >>> >>> >>>>*OR* we need to restructure the miniroot such that it boots without >>>>having to replace any files. >>> >>> >>>That's the architecturally correct answer. The current design of >>>SUNWsibi violates the packaging standards (PSARC 1991/061), lacks the >>>required interface contracts for the private bits it modifies, and is >>>generally not well-designed. >>> >>>This particular accident is a direct result of not maintaining our own >>>standards, and that needs to be fixed, regardless of the possibility >>>of a workaround (shipping SUNWsibi to be forcibly installed after any >>>patch) for this one failure. >>> >>> >>>(Skeptics of the process sometimes ask me for examples of instances >>>where ARC review is both required and would help avoid expensive >>>problems down the road. I think this one would make a good entry.) >> >> >> >> >> >>Sarah Jelinek wrote On 10/04/06 14:12,: >> >> >>>Or... we don't make the miniroot 'special'. That would help this >>>situation a lot. >>> >>>sarah >>>**** >>>Sarah Jelinek wrote: >>> >>> >>> >>>>So, I have followed most of this patching in the minrroot thread. I >>>>have some comments to add: >>>> >>>>The miniroot is 'special' and owned by install. I agree that perhaps >>>>it shouldn't be special, but it is. >>>> >>>>If you read the man page for patchadd -C it says that you should only >>>>install patches that are recommended for the miniroot, such as >>>>install-related patches, like pkg commands, etc..this is a very >>>>limited set of patches. >>>> >>>>Now, I agree that this should include other patches. But, to fix this >>>>we have to do some engineering. There are a few choices I can see >>>>regarding patching the miniroot: >>>> >>>>1. patches must account for this *if* they want to be able to patch >>>>the miniroot. That is not to replace important, and required miniroot >>>>files that are necessary for booting and installing. And do the right >>>>thing to include these files as transfer files to the system during >>>>the install process. >>>> >>>>Or >>>> >>>>2. We provide tools that 'fix up' the miniroot after applying patches >>>>that may alter its environment in such a way that it is no longer the >>>>miniroot we need to install. >>>> >>>>Or ? other ideas welcome. >>>> >>>>thanks, >>>>sarah >>>>**** >> >> >
