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.
not clear when this will be included, today IPS allows you to update SUNWcsr
in the running system ( ie pkg update as opposed to pkg image-update which
alternate BE ), I have seen issues with compilers failing due to SUNWcsr and
getting out of sync, because user updated the live system.
Also IPS is not relevant to s10 users, who will be patching their systems for
some time to
come. ( i.e. many years )
I'd like to hear why fs/local being incorporated into single user milestone was
considered a good idea.
The patch milestone does sound interesting, as it would involve an agreed
> 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
>> -- 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 mailing list