Description of problem: Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Boot PC on network A obtaining IP address via dhcp having DNS info for A 2. Shutdown PC 3. Boot PC on network B obtaining IP address via dhcp having DNS info for B Actual results: The initial resolv.conf file stays in /etc instead of being replaced by a new one. The IP number is that of the network attached to. The second boot is extremely slow on all network related components (sendmail, httpd, gnome, etc.) Expected results: A new resolv.conf file based on the info provided by the dhcp server of the attached network. Additional info: I found the following (recent) post via Google describing more or less the same problem: http://www.westernlug.org/mail-archives/2003-November/007938.html Regards, Paul
Looks like dhclient will not rewrite the /etc/resolv.conf on a renewal of an IP Address. if [ x$reason != xRENEW ] && [ "${PEERDNS}" != "no" ]; then make_resolv_conf fi If you do a service network restart, does the resolv.conf get updated? Dan
I tried a network restart (# /etc/init.d network restart) without success. Removed the resolv.conf and did another restart: no resolv.conf gets created. Client system is out of the box RH9. DHCP server at home is out of the box RH8; at work DHCP is Win2K SP3. Paul
This doesn't appear to be a problem with latest version of scripts in dhcp-3.0.1rc14-1 . It sounds like one of the dhcp servers in this case was not supplying DNS server addresses ; if the dhcp server does not supply DNS server addresses, no resolv.conf gets written - this is correct. The lines Dan mentions: if [ x$reason != xRENEW ] && [ "${PEERDNS}" != "no" ]; then make_resolv_conf fi are now: if [ "${PEERDNS}" != "no" ]; then make_resolv_conf fi This should fix this issue (if it was caused by the PC renewing and not by the dhcp server not supplying DNS server addresses). So, I'm closing this bug as resolved.
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-2004-566.html