Hide Forgot
I've noticed this on two different beta3 machines so far. dhcpcd is failing to configure DNS. /etc/resolv.conf is totally empty after the dhcp lease is obtained. The DHCP server in both cases works fine with 7.1 machines. It's a standard ISC dhcpd (isc-dhcpd-V3.0b2pl24) on a NetBSD server. Nothing relevant gets logged: Aug 7 07:16:37 station11 kernel: 00:10.0: 3Com PCI 3c905C Tornado at 0xe000, 00:01:03:de:59:09, IRQ 7 Aug 7 07:15:22 station11 sysctl: net.ipv4.ip_forward = 0 Aug 7 07:16:37 station11 kernel: product code 484e rev 00.3 date 03-01-01 Aug 7 07:15:22 station11 sysctl: net.ipv4.conf.all.rp_filter = 1 Aug 7 07:16:37 station11 kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface. Aug 7 07:15:22 station11 sysctl: kernel.sysrq = 0 Aug 7 07:16:37 station11 kernel: MII transceiver found at address 24, status 782d. Aug 7 07:15:22 station11 network: Setting network parameters: succeeded Aug 7 07:16:37 station11 kernel: Enabling bus-master transmits and whole-frame receives. Aug 7 07:15:23 station11 network: Bringing up interface lo: succeeded Aug 7 07:16:37 station11 kernel: 00:10.0: scatter/gather disabled. h/w checksums enabled Aug 7 07:16:37 station11 kernel: eth0: using NWAY device table, not 8 Aug 7 07:15:24 station11 ifup: Determining IP information for eth0... Aug 7 07:15:30 station11 ifup: done. Aug 7 07:15:30 station11 network: Bringing up interface eth0: succeeded
This defect is considered SHOULD-FIX for Fairfax
I just encountered this problem on a third machine
still true in RC2
Eek, old bug. Can anyone give a recent update on this? My machines work fine with dhcpcd, which is why I'm not able to do anything about it (can't reproduce -> can't fix).
Still true with 7.2 gold
Since dhcpcd configures DNS wonderfully for large groups of people (myself included), I pretty much need you to track this problem down in order to get any sort of fix in. If there are any particular conditions for reproduction, let me know.
What information would you like?
The only thing that is useful in producing a fix: a diagnosis of the problem. :) I would just run dhcpcd under gdb and put a breakpoint at the place where it writes out RESOLV_CONF, then step through that section and find out what input it is getting and what it is doing with that. If you want to do testing/debugging against the stuff under ftp://people.redhat.com/sopwith/1.3.21pl2-5/, that's my current package that has various fixes against the 7.2 one.
Closing this -- the Qube2 running NetBSD has been retired after years of honorable duty as DHCP server, and I haven't reproduced this w/ its RHL replacement