1*a53f50b9Schristos Am-utils Frequently Asked Questions 2*a53f50b9Schristos 3*a53f50b9SchristosNote: we started this FAQ only on March 15, 2005; so it's not long or 4*a53f50b9Schristoscomprehensive, yet. Amd is much older than that, and so there's a lot of 5*a53f50b9Schristosinformation that's already available in other forms. If this FAQ doesn't 6*a53f50b9Schristosanswer your questions, see information in the following sources: 7*a53f50b9Schristos 8*a53f50b9Schristos1. The Am-utils book: http://www.am-utils.org/docs/amd-book/ 9*a53f50b9Schristos 10*a53f50b9Schristos2. The Am-utils user manual, which is part of the distribution and is also 11*a53f50b9Schristos available from www.am-utils.org. 12*a53f50b9Schristos 13*a53f50b9Schristos3. The www.am-utils.org Web site resources, especially the "am-utils" mailing 14*a53f50b9Schristos list (and its archives). 15*a53f50b9Schristos 16*a53f50b9Schristos4. In the am-utils distribution (always use the latest ones), see all of the 17*a53f50b9Schristos various README files (README, README.autofs, README.ldap, README.osx, and 18*a53f50b9Schristos README.y2k). The "BUGS" file also lists useful information about bugs 19*a53f50b9Schristos and problems with specific OSs which affect Amd. All of these text files 20*a53f50b9Schristos are also available from www.am-utils.org. 21*a53f50b9Schristos 22*a53f50b9Schristos5. Some FAQ questions (including newbie questions) are available here: 23*a53f50b9Schristos http://www.kernelcorp.com/resources_faqs.html 24*a53f50b9Schristos 25*a53f50b9Schristos6. Some problems are known bugs but have not been fixed yet: this are 26*a53f50b9Schristos listed in bugzilla in https://bugzilla.am-utils.org/ 27*a53f50b9Schristos 28*a53f50b9SchristosIf you have additions to this FAQ, please let us know at 29*a53f50b9Schristosthe am-utils list (see www.am-utils.org). 30*a53f50b9Schristos 31*a53f50b9SchristosThank you, 32*a53f50b9SchristosThe Am-utils development team. 33*a53f50b9Schristos 34*a53f50b9Schristos<FAQ> 35*a53f50b9Schristos 36*a53f50b9Schristos*** Linux Questions 37*a53f50b9Schristos 38*a53f50b9SchristosQ1. When I use Amd with Autofs and I restart Amd, how come it cannot remount 39*a53f50b9Schristos the Autofs partitions? 40*a53f50b9Schristos 41*a53f50b9SchristosA1. This is a limitation of the Linux Autofs kernel module (for both autofs 42*a53f50b9Schristos v2. and v3). The Linux Autofs does not allow restarting automounted 43*a53f50b9Schristos points. There's nothing Amd can do about this. In fact, the same 44*a53f50b9Schristos problem exists if you use the userland "automount" daemon instead of 45*a53f50b9Schristos Amd. Hopefully Autofs-v4 or the separate effort of Autofs-NG will 46*a53f50b9Schristos address this serious problem. 47*a53f50b9Schristos 48*a53f50b9Schristos Note that Amd itself can restart autofs automounted points just fine on 49*a53f50b9Schristos OSs that support it, for example Solaris. 50*a53f50b9Schristos 51*a53f50b9Schristos 52*a53f50b9SchristosQ2. When I use Amd, I get this console message frequently: "mount version 53*a53f50b9Schristos older than kernel." Is it a problem? 54*a53f50b9Schristos 55*a53f50b9SchristosA2. No, it's a harmless warning message that the Linux kernel prints for NFS 56*a53f50b9Schristos mounts. The intent was to alert administrators that the kernel has 57*a53f50b9Schristos supposedly a different version of the mount(2) code than a userland 58*a53f50b9Schristos program used. This happens if you compile Amd against kernel headers 59*a53f50b9Schristos that are different than the kernel you're running. If the message 60*a53f50b9Schristos really bothers you, then one way to "fix" the problem is to recompile 61*a53f50b9Schristos Amd against the same kernel headers as the running kernel. 62*a53f50b9Schristos 63*a53f50b9Schristos Nevertheless, it is a relatively useless message because as far as we 64*a53f50b9Schristos know, the NFS v2 and v3 mount codes have been in perfect sync between 65*a53f50b9Schristos the userland and kernel sides, and were "standardized" for years 66*a53f50b9Schristos already. This warning message caused more unnecessary worry among 67*a53f50b9Schristos administrators than helping alert them to legitimate problems. 68*a53f50b9Schristos 69*a53f50b9Schristos</FAQ> 70