Bug 115725
| Summary: | Binding to a NIS domain hangs startup | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Martin Blom <martin> |
| Component: | ypbind | Assignee: | Steve Dickson <steved> |
| Status: | CLOSED CANTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | paul.0000.black |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-01-12 15:28:13 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: | |||
I've seen the same on some of the machines I have with FC2 on. On the machine that fails, it works if a server is specified (rather than broadcastoing to find a server). Here's some info from tcpdump: Working machine: 13:08:51.946389 IP vienna.oxsemi.com.32775 > 172.16.255.255.sunrpc: UDP, length: 144 13:08:51.947446 IP mars.oxsemi.com.sunrpc > vienna.oxsemi.com.32775: UDP, length: 36 13:08:51.957898 IP vienna.oxsemi.com.613 > mars.oxsemi.com.909: UDP, length: 56 13:08:51.958062 IP mars.oxsemi.com.909 > vienna.oxsemi.com.613: UDP, length: 28 Non-working machine: 13:05:47.323952 IP zurich.oxsemi.com.32773 > 172.16.255.255.sunrpc: UDP, length: 112 13:05:53.324175 IP zurich.oxsemi.com.32773 > 172.16.255.255.sunrpc: UDP, length: 112 13:06:01.324012 IP zurich.oxsemi.com.32773 > 172.16.255.255.sunrpc: UDP, length: 112 The problem also seems to apply to rup and rusers. Working: 13:21:11.952755 IP vienna.oxsemi.com.32976 > 172.16.255.255.sunrpc: UDP, length: 112 13:21:11.953345 IP scallop.oxsemi.com.sunrpc > vienna.oxsemi.com.32976: UDP, length: 136 13:21:11.953397 IP cockle.oxsemi.com.sunrpc > vienna.oxsemi.com.32976: UDP, length: 136 13:21:11.953407 IP whelk.oxsemi.com.sunrpc > vienna.oxsemi.com.32976: UDP, length: 136 13:21:11.953520 IP winkle.oxsemi.com.sunrpc > vienna.oxsemi.com.32976: UDP, length: 136 Non-working: 13:22:46.947609 IP zurich.oxsemi.com.32775 > 172.16.255.255.sunrpc: UDP, length: 108 13:22:50.948020 IP zurich.oxsemi.com.32775 > 172.16.255.255.sunrpc: UDP, length: 108 13:22:56.948054 IP zurich.oxsemi.com.32775 > 172.16.255.255.sunrpc: UDP, length: 108 Indeed. Changing "broadcast" to "server <server>" in /etc/yp.conf makes the problem disappear. I think it's a kernel problem, etherreal reckons the UDP checksum is wrong for broadcast packets. [This is a mass update sent to many bugs that missed earlier such messages due to having their version set to a test version.] This bug was originally filed against a version of Fedora Core which is no longer supported, even for security updates. Many changes have occured since then. Please retest this bug against a still supported version. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. If it still occurs on FC5 or FC6, please assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier. This bug will be closed after a few weeks if no information is given indicating that the bug is still present in a supported release. Closing per lack of response to previous request for information. This bug was originally filed against a much earlier version of Fedora Core, and significant changes have taken place since the last version for which this bug is confirmed. Note that FC3 and FC4 are supported by Fedora Legacy for security fixes only. Please install a still supported version and retest. If it still occurs on FC5 or FC6, please reopen and assign to the correct version. Otherwise, if this a security issue, please change the product to Fedora Legacy. Thanks, and we are sorry that we did not get to this bug earlier. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Description of problem: Upgrading from FC1 to FC2 test 1 makes the startup hang (= wait for several minutes, not lock up) at the NIS binding stage. Booting interactivly, skipping this step and then doing to manually using '/etc/init.d/ypbind restart' reproduces the problem. Booting the original FC1 installation still works so nothing has changed in our network. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Set up NISDOMAIN in /etc/sysconfig/network 2. Execute '/etc/init.d/ypbind restart' Additional info: