Is there any chance we can separate this case from a general archive recovery discussion?
In particular this case attempts to provide a method to configure the archive update behavior n uadmin invocation in light of very different requirements depending on deployment. This configuration is needed regardless of the level to which the system can recover itself. Some background to help clarify the motivation for this particular case: 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. -jan Darren J Moffat wrote: > I really think this case is solving the wrong problem. > > The problem is that we depend on the boot archive at all and that we > allow it to get out of date and even worse allow a system to stop very > early in boot because of that. > > I would much rather see we solve the root cause and rethink the whole > boot-archive issues - particularly in light of the fact that GRUB and > OBP can actually read ZFS. For network boot the boot-archive approach > is still desirable but the boot server can deal with the archive updates > in that case. > > However I see that this case is providing value as is so even given the > above I'm happy with the proposal and the release binding including the > intent to backport to S10. > > -- > Darren J Moffat
