On 04/21/10 12:45 AM, Evan Layton wrote:
On 4/20/10 10:18 PM, Seth Goldberg wrote:
Quoting Evan Layton, who wrote the following on Tue, 20 Apr 2010:
On 4/20/10 10:10 PM, Seth Goldberg wrote:
Quoting Seth Goldberg, who wrote the following on Tue, 20 Apr 2010:
Well, I was just suggesting the minimum set of files needed to at
least show a boot panic :). unix, genunix and the boot archive are
that set, I believe.
I should say that genunix will be loaded from the boot archive, so
testing the validity of genunix in the boot archive (i.e. via loopback
mounting it and running `file' or elfdump on genunix (admittedly, both
are not great tests, but they're something -- other suggestions are
welcomed :))) might be a better idea.
Ick, that's really not something I really want to be doing from a C
library if I can avoid it...
I hear ya. I'm just suggesting checks that would made validation more
airtight. Most of them are just calls to system() and checking the
return values.
I don't think we can really get to "airtight". ;-)
I'd really rather not add this kind of check that requires running
something like elfdump. It doesn't really "ensure" that genunix is
valid only that it is more likely to be valid. However that "more
likely to be valid" check may be something we should do anyway. If
folks feel that we should do this check I'll add that as well.
I think you have two possible requirements, which likely lead to
different solutions:
- don't list datasets in "beadm list" that really aren't BE's. Any
checks here need to be cheap, as systems with a few dozen BE's are known
to exist in the wild and having a listing take many seconds on such a
system would be disagreeable (beadm list on a system with 50 BE's takes
.25s with the existing implementation).
- don't activate BE's that aren't bootable. Activation can be
reasonably expected to take a few seconds, so more time-consuming tests
are allowable, and you're only acting on one BE. I don't think there's
any scenario in which "airtight" is possible, though; you'd be into
running things like "pkg verify" to get very close, and even that would
be problematic in the face of developer use of (cap-I) Install for
kernel work.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
