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
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
>>>****
>
>
