On Sat, 22 Apr 2006, Tom Rhodes wrote:
BTW, turning on the multilabel flag in sysinstall is not an option offered
by the installer -- by setting it using sysinstall's "additional flags"
field, you're specifially doing something not part of the install path.
The MAC
Heh, exactly why I wanted to remove it. :)
Someone would need a reason to do it this way, I was hoping in this case
that someone would have a clue.
It's reverted in any case. ;)
Thanks. BTW, your concerns are not unwarranted -- the problem here is how to
deal with optional features that don't like being optional, and there's not
really a good way. The choice is really between having the system refuse to
run at all under those circumstances, and allowing it to run enough to allow
the administrator to recover. Neither works well. The trick, I think, is to
be as consistent as possible in presenting the results. The mount reporting
pieces are a bit confusing, as different file systems are configured in quite
different ways, etc.
What we'll need to do is be careful to document the difference between
requests and status, as mount accepts requests, but reports status. That and
provide a FAQ/debugging guide, with things like "If I set multilabel with
tunefs, but it doesn't appear in mount, what's going on?". The answer is:
check to see if it was properly set in the superblock using tunefs, and check
dmesg for warnings relating to MAC. If it's not set in the superblock, there
was either user error or an error at set time; if it is set, then most likely
MAC is not compiled in. Similar comments for ACL, but this will turn up less
since we compile UFS_ACL into GENERIC, so people are less likely to run into
it. One of the discussion topics for the dev summit will be what needs to
happen to MAC to get it compiled into GENERIC, but we have a ways to go on
that one.
Robert N M Watson
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
