Date: Sat, 22 Apr 2006 13:45:35 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Tom Rhodes <trhodes@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org, John Baldwin <jhb@FreeBSD.org> Subject: Re: cvs commit: src/sys/ufs/ffs ffs_vfsops.c Message-ID: <20060422133933.A56433@fledge.watson.org> In-Reply-To: <20060422001635.247a8b88.trhodes@FreeBSD.org> References: <200604210714.k3L7EQhD046878@repoman.freebsd.org> <20060421161321.J44089@fledge.watson.org> <20060421212322.2f5b3fa8.trhodes@FreeBSD.org> <1A949C80-E65D-4349-8028-8B0EB1A91D27@FreeBSD.org> <20060422001635.247a8b88.trhodes@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 22 Apr 2006, Tom Rhodes wrote: > Which is why I suggested that, similar to Linux, we make everything an > option instead of either Warning before you build/install the new kernel or > add the addition headache of turning it on later. Thus, I'm still of the > opinion that one does not blindly add a newfs option during the install > without understanding what's going on. The problem you're diagnosing is booting a kernel that doesn't support features requested by the administrator. When this happens, there are really only two things you can do: (1) Generate warnings and continue. (2) Generate warnings and stop. We opt for (1) because it makes recovery easier. Deleting the warnings helps neither case. Booting an SELinux system without an SELinux kernel will fail in many spectacular ways, but I'm not sure if they generate a warning equivilent to the one you deleted. 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 instructions I've provided always involve completing the normal install, building MAC support, etc, not turning it on in sysinstall and expecting it to work. The only instructions I've distributed that involve setting multilabel in sysinstall relate to the SEBSD install ISOs, which explicitly support flagging multilabel support during the install. >>> I'll revert it if you feel strongly about it; however, I want it >>> to be known what my opinion is. And I find the warnings >>> extremely annoying and have answered at least one question as >>> to why "mount don't show me correct output." Yes, real quote. :) >> >> mount != tunefs. tunefs will tell you what options are enabled in the > > Yes. > >> filesystem, but I think mount should only tell you the options that are >> actually in force. > > Once they're enabled does that not mean they are in force? I'm not sure what you mean by "enabled" here. Flags only have an effect if the kernel code to support them is compiled in. The way the code was before you modified it, the flags could not be shown in mount if the kernel didn't implement them -- i.e., if you type in "mount" and don't see ACLs, then they are not implemented, and if you do see ACLs, then they are implemented. With your change, they can now be set but not implemented. I.e., you can look at mount, see "acls" set, but ACLs won't actually be in force, which I consider a more confusing failure mode. If you mean, can they be enabled in tunefs but not in force -- yes, if you are running a kernel that can't support them. In which case, before your change, a warning was generated, but not now. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060422133933.A56433>