Bart Smaalders writes: > This means either we cannot use a boot archive, or that we need to > eliminate the existence of the uadmin command. The former means we need
I'd be willing to go for a middle ground: just make it so that the user doesn't have to know that the archive exists. It rebuilds when it needs to, and doesn't when it doesn't. > systems and there is an unavoidable window of vulnerability here. Note > that the "panic during patching problem" isn't solved by getting rid of > boot archives, since the components in the filesystem may not form > a coherent bootable set anyway. The boot archive merely expands the > WoV, and according to Roger, such windows are either open or closed. Yep; understood. If the system happens to go down with inconsistent bits on disk, then you're in a very sad place. I hope you either backed the system first, or you take it as an object lesson in the goodness of tools such as Live Upgrade, so that at least some good comes of it. In the other cases, though, the current behavior is just plain annoying. It doesn't help, and it hurts in all the cases where the bits on the disk are "right" but just don't happen to match what was last stored in the archive. > If you're going to stand on architectural principle, then fix the entire > underlying problem, rather than going off on boot archives. Otherwise > you're just arguing about what constitutes a more serious problem > for the customer - interesting and useful perhaps, but not really > architectural. The architectural matters here are that (a) the bits natively on the disk [not in the archive] are the real ones and (b) nothing but inconsistency or corruption in the *real* bits should stop the system from coming up. The boot archive is just supposed to be a cache. If it's inconsistent, that shouldn't turn the system into a warm brick as it does today. It should cause the system to come up more slowly. Stopping the system because archive doesn't match disk just seems like confusing map for terrain to me. -- 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
