From ea691ecd980d2860f0b39e9e504de4da404806fd Mon Sep 17 00:00:00 2001 From: obrien Date: Wed, 5 Dec 2007 15:48:03 +0000 Subject: Virgin import of AMD (am-utils) v6.1.5 Sponsored by: Juniper Networks --- contrib/amd/BUGS | 115 ++++++++++++++++++++++++++++++++++++++++++++++++++----- 1 file changed, 106 insertions(+), 9 deletions(-) (limited to 'contrib/amd/BUGS') diff --git a/contrib/amd/BUGS b/contrib/amd/BUGS index fd52779..3a3ba6b 100644 --- a/contrib/amd/BUGS +++ b/contrib/amd/BUGS @@ -1,5 +1,8 @@ LIST OF KNOWN BUGS IN AM-UTILS OR OPERATING SYSTEMS +Note: report am-utils bugs via Bugzilla to https://bugzilla.am-utils.org/ or +by email to the am-utils@am-utils.org mailing list. + (1) mips-sgi-irix* @@ -163,12 +166,15 @@ kernel will panic. The Linux kernels don't support Amd's direct mounts very well, leading to erratic behavior: shares that don't get remounted after the first timeout, -inability to restart Amd because its mount points cannot be unmounted, -etc. There are some kernel patches on the am-utils Web site, which solve -these problems. See http://www.am-utils.org/patches/. +inability to restart Amd because its mount points cannot be unmounted, etc. +There are some kernel patches on the am-utils Web site, which solve these +problems. See http://www.am-utils.org/patches/. + +Later 2.4.x kernels completely disallow the hack amd was using for direct +mounts, so another solution will have to be found. -UPDATE: kernels 2.4.10 and later completely disallow the direct mount hack, -so direct mounts are simply not possible on those Linux kernels. +Note: the above is for the old-style amd mount_type = nfs. The autofs mounts +don't support direct mounts at all (due to lack of kernel support). (12) *-aix5.1.0.0 and *-hpux9* @@ -177,14 +183,24 @@ to use /bin/ksh instead. The buildall script will do it for you; if for some reason you need to run configure directly, run it using 'ksh configure' instead of just 'configure'. -[12A] *-aix5.1.* +[12A] *-aix5.2.* Apparently there is an NFS client side bug in vmount() which causes amd to hang when it starts (and tries to NFS-mount itself). According to IBM engineers, this has to do with partial support code for IPv6: the NFS kernel code doesn't appear to recognize the sin_family of the amd vmount(), -although amd does the right thing. The bug appears to have been fixed in -AIX 5.2. No known fix/patch is available for AIX 5.1 as of now (1/25/2003). +although amd does the right thing. The bug doesn't appear to be in 5.1 or +4.3.3. A fix from IBM is available, APAR number IY41417. + +A binary built on 4.3.3 will not work on 5.2, because the kernel ABIs have +changed. + +[12C] *-aix* + +It is important that you install bos.net.nfs.adt before configuring and +building am-utils. If you don't, you will get compile-time or +configure-time errors, especially when configure tries to find AIX's +definition of struct nfs_args. (13) *-linux and *-darwin6.0 @@ -201,6 +217,87 @@ default). Nonetheless, if a TCP connection breaks, under certain unclear circumstances the kernel might "forget" about that flag and start using unprivileged ports, causing the same EPERM error above. +(14) Solaris + +The line "%option" in *.l files may cause Solaris /usr/ccs/bin/lex to abort +with the error "missing translation value." This is a bug in Solaris lex. + +Moreover, both Solaris yacc and lex produce code that does not pass strict +compilation such as "gcc -Wall -Werror". + +Use GNU Flex and Bison instead. You can download ready-made binaries from +www.sunfreeware.com. Note, however, that sometimes the binaries on +sunfreeware.com don't seem to work, often because they are built against an +older revision of Solaris or build tools. In that case, build a fresh +version of GNU flex and/or bison from the latest stable sources. See +http://www.gnu.org/software/flex/ and http://www.gnu.org/software/bison/. + +(15) Solaris 8 + patch 10899[34]-xx (18 <= xx < 25) or patch 11260[56]-xx + +With this patch, Sun updated the autofs kernel module and automountd +userspace daemon from version 3 to version 4. They also updated the +/usr/include/rpcsvc/autofs_prot.x file, but forgot to regenerate the +autofs_prot.h file. Thus, when amd is compiled, it uses the old header and +thinks it should use autofs version 3, when in fact the kernel now supports +(and expects) only version 4. + +The workaround is to run 'rpcgen -C -h /usr/include/rpcsvc/autofs_prot.x > +/usr/include/rpcsvc/autofs_prot.h' and completely reconfigure and rebuild +am-utils (removing config.cache before running configure). + +The problem is fixed in patch revisions 10899[34]-25 and up. + + +(16) Linux kernel 2.4+ and lofs mounts + +Lofs mounts are not supported by the linux kernel, at all, but since 2.4.0 +the kernel supports a similar type of mount called a bind mount. Its +semantics are closer to those of a hardlink than to those of lofs, and one +of the results is that bind mounts ignore any mount options paseed to them. + +Amd uses bind mounts internally to emulate lofs mounts, which means that +lofs mounts on linux will effectively ignore their mount parameters and +inherit whatever options the original filesystem mounted upon had. + + +(17) autoconf 2.57 + +If you see configure warnings of the following kind: + +configure: WARNING: sys/proc.h: present but cannot be compiled +configure: WARNING: sys/proc.h: check for missing prerequisite headers? +configure: WARNING: sys/proc.h: proceeding with the preprocessor's result +configure: WARNING: ## ------------------------------------ ## +configure: WARNING: ## Report this to bug-autoconf@gnu.org. ## +configure: WARNING: ## ------------------------------------ ## + +please ignore them. They are not real errors, and neither +bug-autoconf@gnu.org nor the am-utils maintainers are interested in hearing +about them. Autoconf simply tries to do more than we need and attempts to +compile each header in isolation, which fails for many system headers. +That's ok, because we only need to know if a header file exists -- we know +how to use it properly ourselves. + +While autoconf does offer a way to specify other files to be included with +the tested header, in order to avoid these warnings, using it would enlarge +the resulting configure script by an order of magnitude, and for no real +gain. Configure is big enough as it is, we don't need any more useless +baggage in it. + +(18) NetBSD 2.0.2, FreeBSD 5.4, OpenBSD 3.7, and quite possibly most other + BSDs and other OSs (as of September 2005) -Erez & Ion. +Some BSD kernels don't have a way to turn off the NFS attribute cache. They +don't have a 'noac' mount flag, and setting various cache timeout fields in +struct nfs_args doesn't turn off the attribute cache; instead, it sets the +attribute cache timeout to some internal hard-coded default (usually +anywhere from 5-30 seconds). If Amd cannot turn off the NFS attribute +cache, under heavy Amd usage, users could get ESTALE errors from automounted +symlinks, or find that those symlinks point to the wrong place. One +workaround which would minimize this effect is to set auto_attrcache=1 in +your amd.conf, but it doesn't eliminate the problem! The best solutions are +(1) to use Amd in Autofs mode, if it's supported in your OS, and (2) talk to +your OS vendor to support a true "noac" flag. See README.attrcache for more +details. +Erez & the am-utils team. -- cgit v1.1