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
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,
Aug 7 07:15:22 station11 sysctl: kernel.sysrq = 0
Aug 7 07:16:37 station11 kernel: MII transceiver found at address 24,
Aug 7 07:15:22 station11 network: Setting network parameters: succeeded
Aug 7 07:16:37 station11 kernel: Enabling bus-master transmits and
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
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
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