Updating to net-fs/autofs-4.1.3-r6 breaks automounting on my box, downgrading back to net-fs/autofs-4.1.3-r4 and restarting autofs fixes this issue. I'm quite unsure how to debug this issue, I can run any commands or provide any information you ask for though. # emerge --info Portage 2.1_rc3-r1 (default-linux/amd64/2005.1, gcc-4.1.1, glibc-2.4-r3, 2.6.16-gentoo-r2 x86_64) ================================================================= System uname: 2.6.16-gentoo-r2 x86_64 AMD Athlon(tm) 64 Processor 3700+ Gentoo Base System version 1.12.0 ccache version 2.4 [enabled] dev-lang/python: 2.3.5, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: 2.4-r1 dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/env.d" CXXFLAGS="-march=athlon64 -O2 -pipe" DISTDIR="/mnt/distfiles" FEATURES="autoconfig buildpkg ccache distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_CA.UTF-8" LC_ALL="en_CA.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/gentopia" SYNC="rsync://mirror.iat.sfu.ca/gentoo-portage" USE="amd64 # #apps #services X a52 aac alsa audio avahi avi beagle bitmap-fonts bzip2 cairo canvas cdr cli codecs cracklib crypt cups dbus divx4linux dri dvd dvdr dvdread emboss faad fam firefox flac foomaticdb gif gmail gnome gpm gstreamer gtk gtk2 hal hddtemp howl-compat id3 imlib ipv6 isdnlog jpeg ldap lzw lzw-tiff mad matroska mono moznocompose moznoirc moznomail mp3 mpeg ncurses new-login nls nptl nptlonly nvidia ogg opengl pam pcre pdf pdflib perl png ppds pppd python qt quicktime rar readline reflection samba sdl session spell spl ssl svg tcpd theora truetype truetype-fonts type1-fonts usb userlocales utf8 v4l v4l2 video vorbis wxwindows xinerama xorg xpm xv xvid zeroconf zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_nvidia video_cards_vesa video_cards_fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
*** This bug has been marked as a duplicate of 120403 ***
Ok the bug you pointed to Jakub is marked as fixed, but it is not fixed. Manually editing the init script myself is not the correct way to go. When is the bug actually going to be fixed so I can safely emerge update world without masking out new version of autofs?
emerge sync in an hour or two and try w/ -r7 (don't forget to update config files as well, using etc-update/dispatch-conf).
hmmmm, unfortunately autofs-4.1.3-r7 produces the same failes results as r6. Any suggestions on how I can debug this?
Well, you unfortunately didn't describe your problem too well, so...
I would think it most likely has something to do with ldap. I have to comment out ldap in my /etc/nsswitch.conf file (before I reboot), otherwise it takes an incredibly long time to startup my computer as udev wants to access the ldap server before networking is up. When my computer is up, I add re-add ldap to nsswitch.conf and I restart nscd, autofs, and xdm. Then I can login fine but I don't have a home directory. My /etc/autofs/auto.master file looks like this: /home/users ldap:x.x.x.x:ou=home.users,ou=AutoFS,dc=iat,dc=sfu,dc=ca /home/projects ldap:x.x.x.x:ou=home.projects,ou=AutoFS,dc=iat,dc=sfu,dc=ca While using autofs-4.1.3-r7 and when restarting autofs, neither directory is setup properly, with the script giving a failure message.
Hmm, much better description now :=)
Just some clarification. autofs-4.1.3-r4 was installed with gcc 3.4 and openldap 2.2 (and worked perfectly) autofs-4.1.3-r7 was installed with gcc-4.1 and openldap 2.3 and didn't work. autofs-4.1.3-r4 was then installed on my upgraded system (not using the -K package option) it gave me a broken autofs-4.1.3-r4 I've found that now all autofs-4.1 packages segfault (in /var/log/messages) on my amd64 box, but autofs-4.0 does not segfault, it logs "cannot open lookup modules ldap (/usr/lib/autofs//lookup_ldap.so: cannot open shared object file: No such file or directory)"
Can you please tar up and email me the recent files from /var/log/portage showing the compiles of autofs-4.0 and autofs-4.1 with gcc-4.1.1? Also, include the output of 'locate lookup_ldap.so'
autofs-4.1 is fine when built with openldap-2.2, but when built and linked against openldap-2.3, it segfaults on startup, therefore I believe it's an openldap-2.3 issue.
*** Bug 149427 has been marked as a duplicate of this bug. ***
*** Bug 158228 has been marked as a duplicate of this bug. ***
This seems to be amd64 specific issue - I was experiencing a similar problem, google suggested http://www.openldap.org/lists/openldap-bugs/200511/msg00154.html. Merging autofs as: # CFLAGS="-DLDAP_DEPRECATED" emerge autofs Resolves the problem for me. Autofs 4.1.3 seems pretty old, 4.1.4 is the current 4.1 release and 5.0.1 is also available - neither of these are available as portage ebuilds though:(
18 months without a maintainer, ouch... I can confirm the problem still exists, and the same fix still works too.
New maintainer, net-fs/autofs-5.0.3-r1 is now in the tree.
Fixed in net-fs/autofs-4.1.3-r8
