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 at opensolaris.org
