Bug 371341
| 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> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | urgent | ||||||||
| 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, pasteur, rafael.f.garabato, shei, wwlinuxengineering | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | RHBA-2008-0314 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-05-21 15:01:05 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | 354621 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
This is a known problem and will be fixed in the 5.1.z stream as well as 5.2. *** Bug 371541 has been marked as a duplicate of this bug. *** 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 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/& 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. Second the request for high priority and a quick fix for this. -Deke Bug #377661 is also a duplicate of this bug, it seems. 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 ! 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.) Re Fabian in comment #8 ... where did you find that test kernel, because that kernel doesn't exist at that location. Thanks Jeremy West 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 ? (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 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.
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 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. Refer to Comment #13. The attached patch file fixes the autofs problem. I confirmed it with my system. 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.
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.
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 > 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 The changelog for kernel-2.6.18-53.1.4 includes this note: - [autofs4] fix race between mount and expire (Ian Kent ) [381071] This race condition is what was breaking the first mount attempt. *** Bug 404931 has been marked as a duplicate of this bug. *** Yes, I have installed kernel 2.6.18-53.1.4 and can confirm that it has fixed this problem. Thanks. *** Bug 377661 has been marked as a duplicate of this bug. *** *** Bug 406041 has been marked as a duplicate of this bug. *** You can download this test kernel from http://people.redhat.com/dzickus/el5 At http://people.redhat.com/dzickus/el5 I can only find the kernels 2.6.18-7[567]. 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. (In reply to comment #33) > At http://people.redhat.com/dzickus/el5 I can only find > the kernels 2.6.18-7[567]. > > 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 (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[567]. > > > > 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. 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 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 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[2607]: 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 (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[2607]: 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. 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 *** Bug 462078 has been marked as a duplicate of this bug. *** |
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: