Jan Setje-Eilers writes:
>   The previous users of uadmin(3c) that we had encountered were 
> clustering applications that require the ability to tear down a node as 
> quickly as possible. The current customer as an update/configuration 
> deployment framework that calls uadmin(3c) after applying the changes to 
> the system.

Haven't we always documented uadmin(2) as the wrong way to do that?
The current man page seems to be pretty clear that you're not supposed
to call it unless you really know what you're doing (which would
preclude calling it when the system is unstable).

Jan Setje-Eilers writes:
> > +1.  (I will also need to reproduce a similar problem with smf which also
> > needs to be fixed by the system)
> > 
> > Casper
> 
>   The risk there is that the system just identified itself as 
> potentially unstable. Prior to zfs root we were very careful to perform 
> this check before any fs is mounted rw, in order to avoid the 
> possibility of corrupting data if the system were to run into issues 
> with incompatible modules.
> 
>   If you all don't see a problem with this, I'm happy to implement the 
> automated re-build during boot, it's not like it's much code.

At least to me, one of the basic questions is: what the heck can the
administrator realistically do when the archive is out of date?

It is it at all plausible that someone might fix this problem by some
means that do not include just "bootadm update-archive"?  If so, then
what exactly is that scenario?  Or is it ever possible that someone
might want to continue running despite the obvious problem?  Again, if
so, why?

If there are no realistic cases where the user can do anything but
update the archive based on the current disk contents, then this looks
to me like the same sort of "please hang up and dial 1" annoyance
features that we ought to be avoiding.

Especially so given the annoying regularity of the problem ...

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

Reply via email to