On 04/21/10 09:01, Evan Layton wrote:
On 4/21/10 8:23 AM, Dave Miner wrote:
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:
I agree that based on the comments and what you've put here that
these are the requirements.
- 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).
This is what I was thinking when I coded the fix and this is what
the fix handles. However as you point out this really isn't enough
for the activate case.
- 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.
I agree that activate should be treated differently and that we should
do the extra checking in this instance. I also think that this check
should have it's own error message to more clearly state that the BE may
not be bootable. However I think that this check should only be done if
this BE passes the cheaper check so that we're not running the more
time-consuming check for a BE that we already know isn't valid.
Wait, don't you mean, "that this check should only be done if
this BE *fails* the cheaper check" ? Otherwise, it'd seem you're
considering the cheaper check failure as meaning a definitive
invalid BE. That doesn't sound right.
Also I think the "cheaper" check should be done for the rest of the
subcommands to limit users attempting to act on invalid BE's without
impacting those commands as much.
But the "cheaper" check, by itself, does not tell us anything definitive.
So why would we base any decisions on that data alone, for any of
the other subcommands?
Or is "cheaper" check something other than uuid now?
-ethan
Thanks!
-evan
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
