Add a new service "do-single-user-patch", make it depend on filesystem-local.
This service is typically disabled.  This service will add the patch(es)
and reboot.

In rcS.d/Swhatever, do:

        if (we want to do-single-user-patchs)
                assert(we are currently booting to single-user milestone)
                svcadm enable -tr do-single-user-patch
        fi

-Steve L.


On Tue, Aug 19, 2008 at 08:42:58AM -0700, Liane Praza wrote:
> I believe the original concern about making system/filesystem/local part 
> of single-user was that it changes the definition of single-user.  The 
> zones team was involved in that discussion, and I've just tried to 
> re-involve them in the resolution discussions.  (And have cc'ed them 
> here.  Apologies for the crosspost.)  It may just be morning, but I'm 
> currently having a hard time finding that argument too compelling on its 
> own -- it seems there must have been something more specific.
> 
> Creating a patch milestone has previously been my preferred direction 
> (as it requires actual definition and design of what the patching 
> frameworks need, rather than just hoping that single user is 
> appropriate), but I'm no longer certain this is a sensible investment, 
> as my understanding of IPS is that they're sticking to their guns and 
> there will be no live patching of the OS that leads us to these types of 
> scenarios.  Thankfully.
> 
> Given that, I wonder if a different option is to confirm that 
> system/filesystem/local is idempotent (and not already running), and 
> then have patchadd just run its method directly.  It leaves a bad taste 
> in my mouth, but then again so does the fact that we've got two 
> different patching systems which require the system to be in different 
> states when they run.
> 
> But, again, I think the zones team explored many of these options in the 
> first round and would like to make sure they have a chance to weigh in.
> 
> liane  (in theory, on vacation today.)
> 
> Renaud Manus wrote:
> > A solution could be to move system/filesystem/local in the single-user
> > milestone.
> > 
> > -- Renaud
> > 
> > Jordan Brown wrote:
> >> Could some SMFers please weigh in on 6725004 and give some opinions on 
> >> how best to address it?
> >>
> >> Here's a summary of the problem:
> >>
> >> Sun Update Connection Enterprise attempts to install "single-user" 
> >> patches using an rcS.d script.  This has historically been a problem, 
> >> since zone roots may not have been mounted yet.  Patchadd was recently 
> >> changed to partially work around this problem, by enabling 
> >> system/filesystem/local, but when that mechanism is triggered from an 
> >> rcS.d script (or, presumably, from a service on which 
> >> milestone/single-user depends), it yields a deadlock - 
> >> system/filesystem/local can't be run, because milestone/single-user 
> >> hasn't been reached.  (This is, I believe, in addition to the technical 
> >> issues surrounding performing SMF operations from an rcS.d script.)
> >>
> >> I believe that the most truly correct way to address this problem is to 
> >> have a deferred patching service that depends on 
> >> system/filesystem/local, and on which all other later services depend. 
> >> However, I think the only way to implement such a service would be to 
> >> modify the dependencies of those later services, and that seems awkward. 
> >>   (One could also rename system/filesystem/local, retain the original 
> >> name as something of a milestone, and insert the deferred patching 
> >> service as a new service between the renamed s/f/l and the original 
> >> s/f/l, but that  seems quite ugly.)
> >> _______________________________________________
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to