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 > firstname.lastname@example.org _______________________________________________ zones-discuss mailing list email@example.com