Description of problem: i updated to autofs-1:5.0.1-26.x86_64 and everything died. Nothing would work no pids or lock files could be created. Desktop was stuck, couldnt change terminals... Lockup. Version-Release number of selected component (if applicable): autofs 1:5.0.1-26.x86_64 How reproducible: install autofs 1:5.0.1-26.x86_64 Steps to Reproduce: 1. use autofs 1:5.0.1-26.x86_64 2. 3. Actual results: nothing works, no logs /var got unmounted. /usr /proc /sys /dev /var all seemed to be remounted but / was the only listed mount in mount list. all my mounts in /etc/fstab seemed to be unmounted. no devs, sys was the only thing in /proc, nothing in /usr. /usr and /var are seperate partition on my machine /proc /sys /dev are not seperate partitions. Expected results: normal fs mounts wouldn't get unmounted or remounted. i use ldap for automounts these all got unmounted too Additional info: i rebooted to single user mode and `rpm -e autofs` then started networking and `yum install autofs` and everything was broke again. so i rebooted to single user mode again and `rpm -e autofs` and then `yum install autofs --disablerepo updates` now everything is working. There is a updates autofs package available to me but it is the same autofs-1:5.0.1-26.x86_64 version. I use ldap to get auth and automounts i dont know if not using ldap would cause the same results but when i update to the new autofs /etc/sysconfig/autofs gets replaced and all the ldap settings i need are commented out. i tried using the new autofs rpm with my ldap+autofs settings uncommented but it didnt help so i am assuming that this would cause the same problem if i was running with out ldap. I didnt try disabling selinux and i get no logs since /var gets unmounted. the new automount binary was still in /usr/sbin/automount. I will update again tomorrow and disable selinux and see if it is a problem with it. I was getting weird selinux logs but nothing that i can go back to since i had no /var. Time for bed...
(In reply to comment #0) > Description of problem: i updated to autofs-1:5.0.1-26.x86_64 and everything > died. Nothing would work no pids or lock files could be created. Desktop was > stuck, couldnt change terminals... Lockup. > > Version-Release number of selected component (if applicable): > autofs 1:5.0.1-26.x86_64 > > How reproducible: install autofs 1:5.0.1-26.x86_64 > > Steps to Reproduce: > 1. use autofs 1:5.0.1-26.x86_64 > 2. > 3. > > Actual results: nothing works, no logs /var got unmounted. /usr /proc /sys > /dev /var all seemed to be remounted but / was the only listed mount in mount > list. all my mounts in /etc/fstab seemed to be unmounted. no devs, sys was the > only thing in /proc, nothing in /usr. > > /usr and /var are seperate partition on my machine > > /proc /sys /dev are not seperate partitions. I don't see this on my F7 install. Can you post your maps please and /etc/nsswitch.conf. Ian
I run f7 i386 and had the same problem with the update. I had to downgrade autofs to get automaount working again. I also use ldap for automounts but, what I found was that autofs would not even start either on boot or manually and there was nothing logged in the messages file.
(In reply to comment #2) > I run f7 i386 and had the same problem with the update. I had to downgrade > autofs to get automaount working again. I also use ldap for automounts but, > what I found was that autofs would not even start either on boot or manually and > there was nothing logged in the messages file. How about trying to get a debug log. See http://people.redhat.com/jmoyer for information on how to setup to get appropriate logging. Ian
(In reply to comment #3) > (In reply to comment #2) > > I run f7 i386 and had the same problem with the update. I had to downgrade > > autofs to get automaount working again. I also use ldap for automounts but, > > what I found was that autofs would not even start either on boot or manually and > > there was nothing logged in the messages file. > > How about trying to get a debug log. > See http://people.redhat.com/jmoyer for information on > how to setup to get appropriate logging. > And what about an example of LDAP maps that don't work. Ian
Here is some information. After a restart of autofs [root@joe-laptop init.d]# /etc/init.d/autofs status automount is stopped debug log Aug 30 09:47:48 joe-laptop kernel: klogd 1.4.2, log source = /proc/kmsg started. Aug 30 09:48:27 joe-laptop automount[4595]: Starting automounter version 5.0.1-26, master map auto.master Aug 30 09:48:27 joe-laptop automount[4595]: using kernel protocol version 5.00 Aug 30 09:48:27 joe-laptop automount[4595]: master_notify: syntax error in map near [ /export/users/cvs ] example of mount map from ldap dn: cn=cvs,ou=auto.home,ou=Mounts,dc=vativ,dc=com objectClass: automount cn: cvs automountInformation: -fstype=nfs,tcp,hard,intr fs02:/export/users/cvs partial info from /etc/sysconfig/autofs MAP_OBJECT_CLASS="automountMap" ENTRY_OBJECT_CLASS="automount" MAP_ATTRIBUTE="ou" ENTRY_ATTRIBUTE="cn" VALUE_ATTRIBUTE="automountInformation"
(In reply to comment #5) > Here is some information. > > After a restart of autofs > [root@joe-laptop init.d]# /etc/init.d/autofs status > automount is stopped > > > debug log > > Aug 30 09:47:48 joe-laptop kernel: klogd 1.4.2, log source = /proc/kmsg started. > Aug 30 09:48:27 joe-laptop automount[4595]: Starting automounter version > 5.0.1-26, master map auto.master > Aug 30 09:48:27 joe-laptop automount[4595]: using kernel protocol version 5.00 > Aug 30 09:48:27 joe-laptop automount[4595]: master_notify: syntax error in map > near [ /export/users/cvs ] > > > example of mount map from ldap > > dn: cn=cvs,ou=auto.home,ou=Mounts,dc=vativ,dc=com > objectClass: automount > cn: cvs > automountInformation: -fstype=nfs,tcp,hard,intr fs02:/export/users/cvs > > > partial info from /etc/sysconfig/autofs > > MAP_OBJECT_CLASS="automountMap" > ENTRY_OBJECT_CLASS="automount" > MAP_ATTRIBUTE="ou" > ENTRY_ATTRIBUTE="cn" > VALUE_ATTRIBUTE="automountInformation" OK .. thanks for that, at least it's a starting point for me. Any more information that can be provided would be very much appreciated. I'm going to revert the change that I think is causing this and since I can't seem to duplicate it I won't have another chance to get the info. Ian
(In reply to comment #6) > > Aug 30 09:48:27 joe-laptop automount[4595]: master_notify: syntax error in map > > near [ /export/users/cvs ] > > > > > > example of mount map from ldap > > > > dn: cn=cvs,ou=auto.home,ou=Mounts,dc=vativ,dc=com > > objectClass: automount > > cn: cvs > > automountInformation: -fstype=nfs,tcp,hard,intr fs02:/export/users/cvs What are you using for a master map? What's it look like? Ian
Here is what I can show you. dn: dc=vativ,dc=com dc: vativ objectClass: top objectClass: domain dn: ou=Mounts,dc=vativ,dc=com ou: Mounts objectClass: top objectClass: organizationalUnit dn: ou=auto.home,ou=Mounts,dc=vativ,dc=com ou: auto.home objectClass: top objectClass: automountMap dn: cn=cvs,ou=auto.home,ou=Mounts,dc=vativ,dc=com objectClass: automount cn: cvs automountInformation: -fstype=nfs,tcp,hard,intr fs02:/export/users/cvs
(In reply to comment #8) > Here is what I can show you. All I want to know is what your master map looks like, an entry example with the names changed will be fine. Ian
(In reply to comment #9) > (In reply to comment #8) > > Here is what I can show you. > > All I want to know is what your master map looks > like, an entry example with the names changed will > be fine. > > Ian > > Ian I am not quite sure I understand what you need. If you want my auto.master it is unchanged from the default. # # $Id: auto.master,v 1.4 2005/01/04 14:36:54 raven Exp $ # # Sample auto.master file # This is an automounter map and it has the following format # key [ -mount-options-separated-by-comma ] location # For details of the format look at autofs(5). # /misc /etc/auto.misc /net -hosts # # Include central master map if it can be found using # nsswitch sources. # # Note that if there are entries for /net or /misc (as # above) in the included master map any keys that are the # same will not be seen as the first read key seen takes # precedence. # +auto.master info from nsswitch.conf automount: files ldap Everything works with autofs-5.0.1-9 Joe
I had a similar problem, I had to return to the previous version. The solution was to remove patch 18 from the 5.0.1-26 SRPM, and it works fine now. My previous output was this: Aug 30 17:11:37 litre automount[15587]: Starting automounter version 5.0.1-26, master map auto.master Aug 30 17:11:37 litre automount[15587]: using kernel protocol version 5.00 Aug 30 17:11:37 litre automount[15587]: lookup_nss_read_master: reading master files auto.master Aug 30 17:11:37 litre automount[15587]: parse_init: parse(sun): init gathered global options: (null) Aug 30 17:11:37 litre automount[15587]: mount_init: mount(bind): bind_works = 1 Aug 30 17:11:37 litre automount[15587]: lookup_read_master: lookup(file): read entry /misc Aug 30 17:11:37 litre automount[15587]: lookup_read_master: lookup(file): read entry /net Aug 30 17:11:37 litre automount[15587]: lookup_read_master: lookup(file): read entry +auto.master Aug 30 17:11:37 litre automount[15587]: lookup_nss_read_master: reading master files auto.master Aug 30 17:11:37 litre automount[15587]: parse_init: parse(sun): init gathered global options: (null) Aug 30 17:11:37 litre automount[15587]: lookup_nss_read_master: reading master ldap auto.master Aug 30 17:11:37 litre automount[15587]: parse_server_string: lookup(ldap): Attempting to parse LDAP information from string "auto.master". Aug 30 17:11:37 litre automount[15587]: parse_server_string: lookup(ldap): mapname auto.master Aug 30 17:11:37 litre automount[15587]: parse_ldap_config: ldap authentication configured with the following options: Aug 30 17:11:37 litre automount[15587]: parse_ldap_config: use_tls: 0, tls_required: 0, auth_required: 1, sasl_mech: (null) Aug 30 17:11:37 litre automount[15587]: parse_ldap_config: user: (null), secret: unspecified, client principal: (null) Aug 30 17:11:37 litre automount[15587]: do_connect: auth_required: 1, sasl_mech (null) Aug 30 17:11:37 litre automount[15587]: do_connect: lookup(ldap): ldap anonymous bind returned 0 Aug 30 17:11:37 litre automount[15587]: unbind_ldap_connection: use_tls: 0 Aug 30 17:11:37 litre automount[15587]: parse_init: parse(sun): init gathered global options: (null) Aug 30 17:11:37 litre automount[15587]: do_connect: auth_required: 1, sasl_mech (null) Aug 30 17:11:37 litre automount[15587]: do_connect: lookup(ldap): ldap anonymous bind returned 0 Aug 30 17:11:37 litre automount[15587]: lookup_read_master: lookup(ldap): searching for "(objectclass=automount)" under "(null)" Aug 30 17:11:37 litre automount[15587]: lookup_read_master: lookup(ldap): examining entries Aug 30 17:11:37 litre automount[15587]: master_notify: syntax error in map near [ /export/hecastil ] ... etc
Sorry, it was actually patch 35.
my ldap setup is the same as Joe's. Ill try removing patch35 tomorrow, time for bed again.
(In reply to comment #13) > my ldap setup is the same as Joe's. Ill try removing patch35 tomorrow, time for > bed again. Yep, I removed patch 35 yesterday. It should hit the mirrors soonish as well. Ian
(In reply to comment #14) > (In reply to comment #13) > > my ldap setup is the same as Joe's. Ill try removing patch35 tomorrow, time for > > bed again. > > Yep, I removed patch 35 yesterday. > It should hit the mirrors soonish as well. > > Ian > Ian, Tried to update again but still had the same problem. Did your fix rev the version number? Because when I update I still get 5.0.1-26. BTW -- I am not using x86_64 I am using i386. Joe
(In reply to comment #15) > (In reply to comment #14) > > (In reply to comment #13) > > > my ldap setup is the same as Joe's. Ill try removing patch35 tomorrow, time for > > > bed again. > > > > Yep, I removed patch 35 yesterday. > > It should hit the mirrors soonish as well. > > > > Ian > > > > Ian, > > Tried to update again but still had the same problem. Did your fix rev the > version number? Because when I update I still get 5.0.1-26. Yes, it's rev 27. It's been waiting to be pushed since the 30th. Lets give it a little more time and I'll see what I can do. Ian
autofs-5.0.1-27 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
autofs-5.0.1-28 should show up in updates testing soon. It should fix the schema discover failure identified in this bug. Please test it out for me. Ian
(In reply to comment #18) > autofs-5.0.1-28 should show up in updates testing soon. > It should fix the schema discover failure identified in this > bug. > > Please test it out for me. > > Ian > Ian, I did just update to autofs.i386 5.0.1-27 and it is working for me. What was changed with 28?
> Ian, > > I did just update to autofs.i386 5.0.1-27 and it is working for me. What was > changed with 28? We need to add automatic detection of the commonly used schema as well as the ability to specify this in the configuration. This is one of the most common sources of confusion with current autofs version 5 LDAP implementation. Revision 26 had a patch to do this but I made a mistake which got past without me catching it during testing, sorry. Revision 27 reverted this, as I wasn't sure how long it would take to fix, and 28 adds a corrected patch back in. Please give it a try. Ian
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.