Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 349362 - net-misc/dhcpcd-5.x did not warn about dropping the -N -R and -Y command line options
Summary: net-misc/dhcpcd-5.x did not warn about dropping the -N -R and -Y command line...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: William Hubbs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-12-22 12:37 UTC by Erik Quaeghebeur
Modified: 2011-01-27 21:03 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
output of emerge --info (emerge.info,4.45 KB, text/plain)
2010-12-22 12:38 UTC, Erik Quaeghebeur
Details
my conf.d/net file (net,226 bytes, text/plain)
2010-12-22 12:39 UTC, Erik Quaeghebeur
Details
my dhcpcd.conf file (dhcpcd.conf,830 bytes, text/plain)
2010-12-22 12:43 UTC, Erik Quaeghebeur
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Quaeghebeur 2010-12-22 12:37:08 UTC
After upgrading net-misc/dhcpcd from 4.0.15 to 5.2.8, I had no network connection anymore after the next boot. I tried starting dhcpcd manually as root on the command line and that worked fine. So I guess there is just some glue missing in the 5.2.8 release that was there in the 4.0.15 one to let dhcpcd run at the appropriate moment at boot.


Reproducible: Always

Steps to Reproduce:
1. reboot


Actual Results:  
no ip address assigned

Expected Results:  
ip address assigned

I'm using wireless with wpa_supplicant.
My wireless router is a Fritz.box, but I think I took care of the clientid issue.
Other people encountered the same issue and mentioned it on the forums: http://forums.gentoo.org/viewtopic-t-857221-highlight-dhcpcd.html (I'll link back there to this bug)
Comment 1 Erik Quaeghebeur 2010-12-22 12:38:03 UTC
Created attachment 257746 [details]
output of emerge --info
Comment 2 Erik Quaeghebeur 2010-12-22 12:39:44 UTC
Created attachment 257750 [details]
my conf.d/net file
Comment 3 Erik Quaeghebeur 2010-12-22 12:43:55 UTC
Created attachment 257753 [details]
my dhcpcd.conf file

this file is located in /etc/, but /etc/init.d/dhcpcd mentions /etc/conf.d/ as the presumed location; copying it there as well did not make a difference
Comment 4 Brian McKee 2010-12-24 21:34:54 UTC
Just a note about my experiences with the new DHCPCD.

1. If I run dhcdcd eth1 (on my wireless) by hand as root, it works.
2. But openvpn does not work with the new version of dhcpcd for some reason. No idea why.
3. Going back to 4.X fixed my issues as well.
Comment 5 Erik Quaeghebeur 2010-12-29 12:47:56 UTC
(In reply to comment #0)
> So I guess there is just some
> glue missing in the 5.2.8 release that was there in the 4.0.15 one to let
> dhcpcd run at the appropriate moment at boot.

Is there any other workaround known apart from downgrading dhcpcd to 4.0.15?
Comment 6 Siim Ainsaar 2010-12-30 02:09:59 UTC
The commandline of net-misc/dhcpcd-5.2.8 does not accept neither -R, -Y nor -N anymore, therefore the respective lines must be removed from /etc/conf.d/net. Their functionality, still documented at http://wiki.linuxquestions.org/wiki/Dhcpcd , can be retained by adding, respectively, "nohook yp.conf resolv.conf ntp.conf" to /etc/dhcpcd.conf (prune the line to the nohooks relevant to you). As the change is vital to many people, I suggest adding a warning into the elog.
Comment 7 Erik Quaeghebeur 2010-12-30 10:54:01 UTC
(In reply to comment #6)
> The commandline of net-misc/dhcpcd-5.2.8 does not accept neither -R, -Y nor -N
> anymore, therefore the respective lines must be removed from /etc/conf.d/net.

Removing -N in my conf.d/net solved the issue for me. Thanks!

> [...] I suggest adding a warning into the elog.
 
Seconded.
Comment 8 William Hubbs gentoo-dev 2011-01-27 21:01:35 UTC
This was fixed in 5.2.10, but I'm just now closing the bug.
Thanks for the report.
Comment 9 William Hubbs gentoo-dev 2011-01-27 21:03:34 UTC
This is fixed. :)