| Summary: | net-misc/dhcpcd-4.0.7 creates empty /etc/resolv.conf | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Ralph Sennhauser (RETIRED) <sera> |
| Component: | New packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | docs-team, roy, sera |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Ralph Sennhauser (RETIRED)
2009-02-04 16:59:47 UTC
For completion, see what 'dhcpcd -T eth0' prints for both versions. (In reply to comment #1) > For completion, see what 'dhcpcd -T eth0' prints for both versions. > As I don't like rebooting this machine to often here a bit more info. Strange enough manually setting the gateway as nameserver in /etc/resolv.conf and /etc/init.d/net.eth0 restart works at least for 4.0.7. dhcpcd 4.0.7: $cat /etc/resolv.conf # Generated by dhcpcd # /etc/resolv.conf.head can replace this line # /etc/resolv.conf.tail can replace this line $ps ax | grep dhcpcd 4339 ? Ss 0:00 /sbin/dhcpcd -h <hostname> -R -N -Y eth0 5173 pts/0 R+ 0:00 grep --colour=auto dhcpcd $ dhcpcd -T eth0 interface=eth0 metric=0 pid=5203 reason=TEST new_broadcast_address=255.255.255.0 new_dhcp_lease_time=86400 new_dhcp_message_type=2 new_dhcp_server_identifier=192.168.1.1 new_domain_name_servers='195.186.4.108 195.186.1.108' new_ip_address=192.168.1.102 new_network_number=192.168.1.0 new_routers=192.168.1.1 new_subnet_cidr=24 new_subnet_mask=255.255.255.0 dhcpcd 4.0.2: $ cat /etc/resolv.conf # Generated by dhcpcd # /etc/resolv.conf.head can replace this line # /etc/resolv.conf.tail can replace this line $ ps ax | grep dhcpcd 4336 ? Ss 0:00 /sbin/dhcpcd -h <hostname> -R -N -Y eth0 5204 pts/0 R+ 0:00 grep --colour=auto dhcpcd $ dhcpcd -T eth0 interface=eth0 metric=0 pid=5206 reason=TEST new_broadcast_address=255.255.255.0 new_dhcp_lease_time=86400 new_dhcp_message_type=2 new_dhcp_server_identifier=192.168.1.1 new_domain_name_servers='195.186.4.108 195.186.1.108' new_ip_address=192.168.1.102 new_network_number=192.168.1.0 new_routers=192.168.1.1 new_subnet_cidr=24 new_subnet_mask=255.255.255.0 When I said "both versions" I meant "working and non-working". And what was that about reboot ? Only thing needed to do that test is reemerging. (In reply to comment #3) > When I said "both versions" I meant "working and non-working". > :-), could have guessed: dhcpcd-4.0.1-r1 (working): $ dhcpcd -T eth0 interface=eth0 metric=0 pid=473 reason=TEST new_broadcast_address=255.255.255.0 new_dhcp_lease_time=86400 new_dhcp_message_type=2 new_dhcp_server_identifier=192.168.1.1 new_domain_name_servers='195.186.4.108 195.186.1.108' new_ip_address=192.168.1.102 new_network_number=192.168.1.0 new_routers=192.168.1.1 new_subnet_cidr=24 new_subnet_mask=255.255.255.0 So nothing different. > And what was that about reboot ? Only thing needed to do that test > is reemerging. > To problem arise only after a reboot. /etc/init.d/net.eth0 is not enough to clear the /etc/resolv.conf file. I don't mind rebooting if there is a real benefit. What are the comments in /etc/resolv.conf? Do you have openresolv/resolvconf installed? (ls -l /sbin/resolvconf) dhcpcd -R bge0 does NOT modify /etc/resolv.conf with dns data present, tested with dhcpcd-4.0.10 Some notes: dhcpcd -T will print all DHCP variables requested wether it uses them or not -R simply instructs dhcpcd-run-hooks to skip the resolv.conf hook, so -T will still show the dns variables. If you remove the file /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf does this fix the problem? Do you have any files in /lib/dhcpcd/dhcpcd-hooks that are not owned by the dhcpcd ebuild? (In reply to comment #5) > What are the comments in /etc/resolv.conf? working and current produced by version 4.0.1-r1 from which I updated. # Generated by dhcpcd from eth0 # /etc/resolv.conf.head can replace this line nameserver 195.186.1.109 nameserver 195.186.4.109 # /etc/resolv.conf.tail can replace this line > Do you have openresolv/resolvconf installed? (ls -l /sbin/resolvconf) No, I havn't. > dhcpcd -R bge0 does NOT modify /etc/resolv.conf with dns data present, tested > with dhcpcd-4.0.10 > > Some notes: > dhcpcd -T will print all DHCP variables requested wether it uses them or not > -R simply instructs dhcpcd-run-hooks to skip the resolv.conf hook, so -T will > still show the dns variables. > I see. > If you remove the file /lib/dhcpcd/dhcpcd-hooks/20-resolv.conf does this fix version 4.0.2-r1 disappeared from the tree, so first of all I need to get back this ebuild somehow before doing anything, wasn't clever enough to copy it over to my overlay *headagainstwallbang* Will give it a try then. Also with version 4.0.10 just to check whether the bug got magically fixed or still persists. > the problem? Do you have any files in /lib/dhcpcd/dhcpcd-hooks that are not > owned by the dhcpcd ebuild? > All files currently in /lib/dhcpcd/dhcpd-hooks are owned by dhcpcd-4.0.2-r1. So I expect the update to clean up in there. For safety I will look again with every version. http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/dhcpcd/dhcpcd-4.0.1-r1.ebuild?hideattic=0&view=markup (In reply to comment #6) > working and current produced by version 4.0.1-r1 from which I updated. > > # Generated by dhcpcd from eth0 > # /etc/resolv.conf.head can replace this line > nameserver 195.186.1.109 > nameserver 195.186.4.109 > # /etc/resolv.conf.tail can replace this line Wait, so dhcpcd created that and yet you are asking dhcpcd NOT to replace it? hehe. Maybe you should explain why you feel the need to stop dhcpcd from modifying resolv.conf > version 4.0.2-r1 disappeared from the tree, so first of all I need to get back > this ebuild somehow before doing anything, wasn't clever enough to copy it over > to my overlay *headagainstwallbang* http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-misc/dhcpcd/dhcpcd-4.0.1-r1.ebuild?hideattic=0&view=markup There's the ebuild :) (In reply to comment #7) > Wait, so dhcpcd created that and yet you are asking dhcpcd NOT to replace it? > hehe. Maybe you should explain why you feel the need to stop dhcpcd from > modifying resolv.conf No I want dhcpcd 4.0.7 to produce a similar /etc/resolv.conf as 4.0.1-r1 does. I can work around this however preventing dhcpcd from replacing a working /etc/resolv.conf isn't a proper fix for a stable package which worked up to now and is probably used by everyone new to gentoo as it's in the install documentation. The correct behavior would be to write a working default resolve.conf (as the one generated by 4.0.1-r1) if there is none or there is one never touched by the user. I would say it should do this overwrite as well as long as the user doesn't say otherwise in the init conf of dhcpcd or perhaps a flag in /etc/resolve.conf > > There's the ebuild :) > Thanks. And you read read the 4.0.2-r1 correctly as 4.0.1-r1, my apologize. So to sumarize - dhcpcd-4.0.2 and greater are not putting any DNS entries in /etc/resolv.conf even though you have new_domain_name_servers='195.186.4.108 195.186.1.108' listed. What is more, you only get this error after a reboot. I'm guessing it's you due to having dhcpcd_*=-R" or dhcp_*="nodns" in /etc/conf.d/net. #239098 is related only in the fact you were working around the issue which 4.0.2 fixes. Infact, the only code changes from 4.0.1 -> 4.0.2 are related to lease times (which yours is not) and making the -R flag work. (In reply to comment #9) > So to sumarize - dhcpcd-4.0.2 and greater are not putting any DNS entries in > /etc/resolv.conf even though you have new_domain_name_servers='195.186.4.108 > 195.186.1.108' listed. What is more, you only get this error after a reboot. > > I'm guessing it's you due to having dhcpcd_*=-R" or dhcp_*="nodns" in > /etc/conf.d/net. > #239098 is related only in the fact you were working around the issue which > 4.0.2 fixes. > Infact, the only code changes from 4.0.1 -> 4.0.2 are related to lease times > (which yours is not) and making the -R flag work. > Almost true. There was a nodns flag in /etc/conf.d/net. Removing it solved the problem. So the bug can be closed from a technical viewpoint. However /etc/conf.d/net was last modified a few years back when I've set this machine up for the first time closely following the Handbook. Looking in the Handbook(x86) now it still says: Code Listing 2.7: Automatically obtaining an IP address for eth0 config_eth0=( "dhcp" ) dhcp_eth0="nodns nontp nonis" Definitively a trap and not a workaround. However it kept me safe until now. Thanks a lot for your and the rest of the teams help. (In reply to comment #10) > However /etc/conf.d/net was last modified a few years back when I've set this > machine up for the first time closely following the Handbook. > Looking in the Handbook(x86) now it still says: > > Code Listing 2.7: Automatically obtaining an IP address for eth0 > config_eth0=( "dhcp" ) > dhcp_eth0="nodns nontp nonis" > > Definitively a trap and not a workaround. However it kept me safe until now. > > Thanks a lot for your and the rest of the teams help. When I wrote that part of the handbook, it sure didn't say that. What it's doing is listing dhcp options you *could* use for all dhcp clients in portage, not options you *should* use. The handbook needs to be more clear here. My recommendation is to remove the line and let the DHCP client default work. If the user needs to modify the default behaviour of the DHCP client, then read the man page and act accordingly. (In reply to comment #11) > When I wrote that part of the handbook, it sure didn't say that. > What it's doing is listing dhcp options you *could* use for all dhcp clients in > portage, not options you *should* use. The handbook needs to be more clear > here. My recommendation is to remove the line and let the DHCP client default > work. If the user needs to modify the default behaviour of the DHCP client, > then read the man page and act accordingly. Done. |