Bob Netherton wrote:
> And further
> refinement would only impact patching rather than the booting process
> as a whole.
Hmm. I don't know how to have a service that runs when a particular
milestone is selected, that *doesn't* run when "all" is selected.
(Other than by dynamically enabling and disabling it.)
> rc scripts doing things with SMF seem a permanent solution to a
> temporary problem. In my virtual universe there are no rc scripts :)
> And then the alarm clock goes off and I return to reality. But it does
> promote rc hackery rather than fixing the problem in SMF where it
Agreed. Besides, I believe that SMF is locked while rc scripts are
running, and that any attempt to manipulate it deadlocks.
There are related schemes that could work, but the problem is getting
them properly sequenced into system startup.
> reboot -- -m milestone=patchinstall seems elegantly simple.
Plausible, though it doesn't exactly fit the current application usage
model. At the moment, the reboot might or might not be triggered by the
patching application. The patching application leaves the system set up
to do the patching at the next shutdown/reboot, whenever that might be.
(For SunUC-S's shutdown-time processing, it's require that that reboot
be via the "clean" mechanisms - init, shutdown - so that the processing
This scheme would require either
1) having the patch application set the default milestone, and then
having the startup-time processing set it back, or
2) having the patch application do the reboot.
There's still the issue with how to keep this service from running when
you boot to "all".
Hmm. How does single-user-mode login work? What stops it from running
on a normal boot? Is it a special case?
BTW: I'm not in a position to commit the patch applications. I'm in
the middle here because I'm relatively familiar with all of the players
and the issues, but in my day job I'm not responsible for *any* of them.
zones-discuss mailing list