|Summary:||upgrade to 5.1 breaks autofs for automounted home directories|
|Product:||Red Hat Enterprise Linux 5||Reporter:||Andy Feldt <afeldt>|
|Component:||kernel||Assignee:||Jeff Moyer <jmoyer>|
|Status:||CLOSED ERRATA||QA Contact:||Brock Organ <borgan>|
|Version:||5.1||CC:||amyagi, dirk.gfroerer, dmair, dzickus, fabian.arrotin, gamtus, goeran, ikent, jan.iven, jbastian, jjneely, jmccann, k.georgiou, Klaus+rhbz, lwang, me, olle, rafael.f.garabato, shei, tru, wwlinuxengineering|
|Fixed In Version:||RHBA-2008-0314||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-05-21 15:01:05 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:||354621|
Description Andy Feldt 2007-11-08 15:33:26 UTC
Description of problem: Since the upgrade to RHEL 5.1, users with automounted, remote home directories fail to have their home directory mounted at the first login attempt. After it fails, they can successfully login. This also causes amanda backups to fail when the automounted home directory for amanda is not immediately available when the backup server attempts to contact the client. Version-Release number of selected component (if applicable): This is with autofs-5.0.1-0.rc2.55 How reproducible: The first attempt to access any automounted directory fails, The second attempt succeeds. Steps to Reproduce: 1. Assume an automount map which maps /home1/machine to machine:/myhome1 2. From machine 'a' type: if [ -d /home1/b ]; then echo ok; fi 3. Type the command again. Actual results: Only the second time produces 'ok' Expected results: Each result produces 'ok' Additional info:
Comment 1 Jeff Moyer 2007-11-08 15:53:24 UTC
This is a known problem and will be fixed in the 5.1.z stream as well as 5.2.
Comment 2 Jeff Moyer 2007-11-08 18:18:43 UTC
*** Bug 371541 has been marked as a duplicate of this bug. ***
Comment 3 Shing-Shong Shei 2007-11-09 19:57:00 UTC
I can confirm this and this has very severe impact here as we rely heavily on the automount feature (home directory, shared software, etc.) Please mark this as high priority and push out a fix as soon as you can. Thanks. --Bruce
Comment 4 Jeff Bastian 2007-11-09 20:13:43 UTC
One possible workaround for this is to set DEFAULT_BROWSE_MODE="yes" in /etc/sysconfig/autofs. This only works if your auto.home map explicitly lists every entry, i.e., it does NOT use wildcards like * server:/export/home/&
Comment 5 Andy Feldt 2007-11-09 20:30:31 UTC
Unfortunately, one of the prime environments where automounting is desirable is the case where the number of systems is large and fluid so that the only rational map entries then use wildcards. That is certainly the case for us.
Comment 6 Deke Clinger 2007-11-16 22:57:05 UTC
Second the request for high priority and a quick fix for this. -Deke
Comment 8 Fabian Arrotin 2007-11-18 14:39:35 UTC
Test kernel available 2.6.18-56 at http://people.redhat.com/jlayton/ solves the problem but brings another one : if the machine is itself a nfs server, kernel panics as soon as the nfs service is launched !
Comment 9 Brian Hanna 2007-11-19 14:30:08 UTC
Ditto the urgency - we use autofs extensively, and my reason for buying RHEL is better NFS support!!! NFS is a critical service for anything except very small setups and it needs extensive testing at every release. ssh to host at 5.1 to account with autofs home directory, directory unmounted, fails passwordless login, succeeds second try. Workaround for ssh login: cd; cd .ssh; ln -s authorized_keys authorized_keys2 since ssh will check both files before failing. (Only works for that user.)
Comment 10 Jeremy West 2007-11-19 21:35:54 UTC
Re Fabian in comment #8 ... where did you find that test kernel, because that kernel doesn't exist at that location. Thanks Jeremy West
Comment 11 Fabian Arrotin 2007-11-19 21:48:52 UTC
Re Jeremy : it seems Jeff removed all the .el5 test kernels he produced earlier. Here is the kernel i used (and also other users as well , see https://bugzilla.redhat.com/show_bug.cgi?id=377661 ) : kernel-2.6.18-56.el5.jtltest.14.i686.rpm See with Jeff why he removed those kernels from his webspace .. Maybe because too many people consider this bug a showstopper and used his 'unofficial' kernel to work around the problem they have now ?
Comment 12 Ian Kent 2007-11-20 00:25:21 UTC
(In reply to comment #11) > Re Jeremy : it seems Jeff removed all the .el5 test kernels he produced earlier. > Here is the kernel i used (and also other users as well , see > https://bugzilla.redhat.com/show_bug.cgi?id=377661 ) : > kernel-2.6.18-56.el5.jtltest.14.i686.rpm > See with Jeff why he removed those kernels from his webspace .. > Maybe because too many people consider this bug a showstopper and used his > 'unofficial' kernel to work around the problem they have now ? Hang on, you don't need to use testing kernels to resolve the autofs issue. It would be a better idea to just apply the autofs4 kernel patch to the distributed kernel while you're waiting for the update. Ian
Comment 13 Ian Kent 2007-11-20 00:31:20 UTC
Created attachment 264051 [details] Patch for ENOENT fails These patches fix the ENOENT issue on first access of an utomount. It should apply to the RHEL-5.1 GA kernel. Please let me know if it doesn't.
Comment 14 Shing-Shong Shei 2007-11-20 00:35:49 UTC
I agree with Ian. The two patches solved our problems and we have been using/testing this patched kernel since Nov 9th without any problem. --Bruce
Comment 15 Klaus Ethgen 2007-11-20 08:55:15 UTC
1. Don't close this issue as the other is unreadable for users and the issue is NOT solved! 2. To have a test of the kernel I need not only the kernel package as also the devel package as we have to use several modules to work with the system redhat do not provide but which are essential. (openafs and nvidia) Unfortunate I was not fast enought to fetch them from the site above and now it is gone.
Comment 16 Akemi Yagi 2007-11-20 10:31:54 UTC
Refer to Comment #13. The attached patch file fixes the autofs problem. I confirmed it with my system.
Comment 17 Shing-Shong Shei 2007-11-20 13:48:11 UTC
Created attachment 264911 [details] Diff file between RH kernel-2.6.spec and mine This is the diff file of RHEL 5.1 kernel-2.6.spec against ours so as to generate a new kernel RPM applying Ian Kent's two patches to fix the autofs problem.
Comment 18 Shing-Shong Shei 2007-11-20 13:58:03 UTC
Sorry that I am not familiar with the system and failed to give the procedure in my previous posting. Here is the way I did here: 1) install the kernel src.rpm 2) cd /usr/src/redhat/SOURCES 3) save Ian's patches as linux-2.6-autofs4-rhel-5-lookup-check-unhashed.patch linux-2.6-autofs4-rhel-5-lookup-expire-race-fix-4.patch 4) cd ../SPECS and apply my diff file to kernel-2.6.spec 5) build the kernel RPMs; e.g., rpmbuild -bb --target i686 kernel-2.6.spec Hope this helps.
Comment 23 Jeff Bastian 2007-11-29 16:47:15 UTC
This should be fixed now. BZ 381071 was updated this morning: An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2007-0993.html
Comment 24 Shing-Shong Shei 2007-11-29 17:03:24 UTC
> http://rhn.redhat.com/errata/RHSA-2007-0993.html I did not see BZ 381071 mentioned in the above HRL. Is the fix included into kernel-2.6.18-53.1.4? Thanks, Shing-Shong
Comment 25 Jeff Bastian 2007-11-29 17:35:22 UTC
The changelog for kernel-2.6.18-53.1.4 includes this note: - [autofs4] fix race between mount and expire (Ian Kent )  This race condition is what was breaking the first mount attempt.
Comment 26 Ian Kent 2007-11-30 01:39:33 UTC
*** Bug 404931 has been marked as a duplicate of this bug. ***
Comment 27 Shing-Shong Shei 2007-11-30 01:43:57 UTC
Yes, I have installed kernel 2.6.18-53.1.4 and can confirm that it has fixed this problem. Thanks.
Comment 28 Jeff Layton 2007-11-30 11:50:50 UTC
*** Bug 377661 has been marked as a duplicate of this bug. ***
Comment 29 Jeff Moyer 2007-11-30 16:21:37 UTC
*** Bug 406041 has been marked as a duplicate of this bug. ***
Comment 31 Don Zickus 2008-01-24 21:15:41 UTC
You can download this test kernel from http://people.redhat.com/dzickus/el5
Comment 33 Ra P. 2008-02-05 08:23:41 UTC
At http://people.redhat.com/dzickus/el5 I can only find the kernels 2.6.18-7. Is the patch also included in kernel 2.6.18-77 ? BTW: This problem is really a showstopper. I would appreciate any hint or proposal for working around it.
Comment 34 Ian Kent 2008-02-05 09:57:49 UTC
(In reply to comment #33) > At http://people.redhat.com/dzickus/el5 I can only find > the kernels 2.6.18-7. > > Is the patch also included in kernel 2.6.18-77 ? > > BTW: This problem is really a showstopper. I would appreciate any hint or > proposal for working around it. I don't understand your question. Why are you trying to get hold of a pre-release kernel when the correction discussed here has been in an update release kernel for some time now? Try kernel-2.6.18-53.1.4. Ian
Comment 35 Akemi Yagi 2008-02-05 11:05:55 UTC
(In reply to comment #34) > (In reply to comment #33) > > At http://people.redhat.com/dzickus/el5 I can only find > > the kernels 2.6.18-7. > > > > Is the patch also included in kernel 2.6.18-77 ? > > > > BTW: This problem is really a showstopper. I would appreciate any hint or > > proposal for working around it. > > I don't understand your question. > Why are you trying to get hold of a pre-release kernel > when the correction discussed here has been in an update > release kernel for some time now? > > Try kernel-2.6.18-53.1.4. > > Ian I think that #33 was in response to #31 which suggested the use of a test kernel. This post (#31) seems to have appeared in a few other bug reports as well. But it should not have appeared in here (?). Because the issue in this tracker has already been fixed as you pointed out.
Comment 36 Don Zickus 2008-02-05 14:47:53 UTC
I think the confusion lies in the fact that different bugzilla numbers are used to track different release streams. This particular bugzilla is tracking the fix for RHEL-5.2. My post in comment #31 just indicates the fix has been committed for informational purposes (externally) and statistical purposes (internally). FYI: The kernels in my http://people.redhat.com/dzickus/el5 directory are test kernels and are _not_ officially supported by RedHat. However they do contain cumulative fixes that are leading up to the release of a RHEL-5.2 kernel, IOW each incremented release should contain all previous fixes plus new ones. So if you need this fix for a production environment, it is strongly encouraged to grab the z-stream kernel (kernel-2.6.18-53.1.4 or higher). Otherwise, if you would like to follow along and make sure RHEL-5.2 will contain your fix, feel free to test the latest kernels in my http://people.redhat.com/dzickus/el5. Cheers, Don
Comment 37 Akemi Yagi 2008-02-05 15:56:24 UTC
Don, Thanks for the clarification. I am going to try your test kernels because there are other issues I want to check out to see if the fixes will be in 5.2. Akemi
Comment 38 matus 2008-03-04 11:04:10 UTC
Hi, Don't know if this belong here or is a new bug. I'm using autofs-5.0.1-0.rc2.55 fresh installation of Rhel5.1 without any updates. I have tried to mount home folders for nisusers using map file called auto.nis and get error in messages when restarting autofs service "automount: master_error: syntax error while parsing map." If I use any other name for map file it is working fine. I have tried couple of different names and all worked except auto.nis (which was working in older versions of autofs) this is not critical, it just took me couple of days to figure it out what is wrong :) Can please somebody check this? Thanks Matt
Comment 39 Jeff Moyer 2008-03-04 13:51:36 UTC
(In reply to comment #38) > Hi, > Don't know if this belong here or is a new bug. > I'm using autofs-5.0.1-0.rc2.55 fresh installation of Rhel5.1 without any > updates. I have tried to mount home folders for nisusers using map file called > auto.nis and get error in messages when restarting autofs service > "automount: master_error: syntax error while parsing map." > If I use any other name for map file it is working fine. I have tried couple of > different names and all worked except auto.nis (which was working in older > versions of autofs) this is not critical, it just took me couple of days to > figure it out what is wrong :) > Can please somebody check this? Please file a separate bugzilla and include the contents of your automount maps.
Comment 42 errata-xmlrpc 2008-05-21 15:01:05 UTC
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0314.html