Bug 266101 - updated to autofs 1:5.0.1-26.x86_64
updated to autofs 1:5.0.1-26.x86_64
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: autofs (Show other bugs)
7
x86_64 Linux
medium Severity urgent
: ---
: ---
Assigned To: Ian Kent
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-29 22:39 EDT by shane
Modified: 2008-06-16 22:16 EDT (History)
4 users (show)

See Also:
Fixed In Version: 5.0.1-27
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 22:16:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description shane 2007-08-29 22:39:03 EDT
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...
Comment 1 Ian Kent 2007-08-30 01:19:22 EDT
(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
Comment 2 Joe Harb 2007-08-30 11:53:05 EDT
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.
Comment 3 Ian Kent 2007-08-30 12:19:42 EDT
(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
Comment 4 Ian Kent 2007-08-30 12:22:21 EDT
(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
Comment 5 Joe Harb 2007-08-30 13:10:09 EDT
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"


Comment 6 Ian Kent 2007-08-30 13:34:09 EDT
(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
Comment 7 Ian Kent 2007-08-30 13:35:44 EDT
(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
Comment 8 Joe Harb 2007-08-30 13:53:47 EDT
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
Comment 9 Ian Kent 2007-08-30 14:27:35 EDT
(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

Comment 10 Joe Harb 2007-08-30 15:11:32 EDT
(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
Comment 11 Jaime Oyarzun Knittel 2007-08-30 19:20:41 EDT
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
Comment 12 Jaime Oyarzun Knittel 2007-08-30 21:12:42 EDT
Sorry, it was actually patch 35.
Comment 13 shane 2007-08-30 21:20:08 EDT
my ldap setup is the same as Joe's.  Ill try removing patch35 tomorrow, time for
bed again.
Comment 14 Ian Kent 2007-08-30 22:52:58 EDT
(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
Comment 15 Joe Harb 2007-09-04 11:52:55 EDT
(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
Comment 16 Ian Kent 2007-09-04 12:24:42 EDT
(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
Comment 17 Fedora Update System 2007-09-04 18:13:54 EDT
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.
Comment 18 Ian Kent 2007-09-05 01:54:05 EDT
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
Comment 19 Joe Harb 2007-09-05 12:07:23 EDT
(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?
Comment 20 Ian Kent 2007-09-05 13:23:41 EDT
> 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
Comment 21 Bug Zapper 2008-05-14 10:09:44 EDT
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
Comment 22 Bug Zapper 2008-06-16 22:16:19 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.