Bug 436647
| Summary: | resolv.conf loses name servers after upgrade | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ray Todd Stevens <raytodd> |
| Component: | bind | Assignee: | Adam Tkac <atkac> |
| Status: | CLOSED WORKSFORME | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | rawhide | CC: | ovasik |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-03-13 17:18:30 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: | |||
|
Description
Ray Todd Stevens
2008-03-08 19:45:01 UTC
I don't think this is related to bind. Are you using NetworkManager? Is network interface configured statically or you get IP from dhcp? Those two utilities can modify resolv.conf I think. I have fixed this at my site. Frankly it it was not a rawhide issue, I would not have filed a report. I only experienced this on one station of the three I am running various tests of rawhide (IE fc9alpha) on. Since this is an alpha I figure you need to not only hear about the solid failures which is the klind of thing I report for production releases, but at least you need to be made aware of the flaky problems. Maybe for rawhide bug reports a "I am reporting this in case you need people experiencing this problem, but I don't really expect you to do any more than take notice of it unless a bunch of people experience this error. Then I would be glad to help debug it" status. As for your other questions Network manager. I am not sure what you are asking here. I do user "administration - Network" to modify my network settings, but did not use this between when it was last working and when I did the update. In order to do the update I would assume that the name servers would have to have been working. I found the problem a little while after the last update (maybe 3 hours). We are not running dchp on this system. Both the client and server software are loaded on this machine to be used as a part of failure recovery, but it is not configured. The server is at a rcx.d K status (I checked) and none of the interfaces are currently programmed for dhcp. I thought of this and checked that. I maybe should have mentioned running an update shortly before the problem was discovered. (In reply to comment #2) > Network manager. I am not sure what you are asking here. I do user > "administration - Network" to modify my network settings, but did not use this > between when it was last working and when I did the update. NetworkManager is service. You can check if you're using it with $ chkconfig --list NetworkManager (or with $service NetworkManager status). If you have this service running it might modify your resolv.conf . This change is definitely not caused by bind package because bind is name server (not resolver) and does nothing with resolv.conf (resolvers use this file to find IP of nameserver) Not running this. I think your comment on it not actually being bind might be on target. However, it is frequently hard for an outsider to figure out which component is at fault. It has not happened any more. Does make one wonder. It's nearly impossible find what component broke your resolv.conf without more info. If it happen again try collect more information and reopen this one, please. Closing for now I tend to agree. |