Hi, I am using the stable udev:
[I] sys-fs/udev
Available versions: 114 115-r1 119 ~122-r1 124-r1 ~125-r2 ~130-r1 ~133
~135 ~135-r1 ~135-r2 {selinux}
Installed versions: 124-r1(12:32:32 08/10/08)(-selinux)
Homepage:
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
Description: Linux dynamic and persistent device naming support
(aka userspace devfs)
The only active interface is eth0.
I can activate DHCP manually after login by:
na...@nadav ~ $ dhcpcd eth0
I suspect that, for some reasons, dhcp daemon is not called at the
initialisation sequence, but I have no idea how to trace it.
Nadav.
-----הודעה מקורית-----
מאת: news בשם Duncan
נשלח: ב 22-דצמבר-08 20:21
אל: gentoo-amd64@lists.gentoo.org
נושא: [gentoo-amd64] Re: DHCPCD does not start on boot
Nadav Horesh <nad...@visionsense.com> posted
1229955300.25872.4.ca...@nadav.envision.co.il, excerpted below, on Mon,
22 Dec 2008 16:15:00 +0200:
>> 2008/12/16 Nadav Horesh <nad...@visionsense.com>:
>> > We have a network with a windows dhcp server. Few weeks ago dhcpcd
>> > did not function at the boot, and since them I have to bring it up
>> > manually:
I just remembered something else...
What version of udev do you have? Newer (at least for ~arch, they may
not have hit stable yet) udev has changed the persistent network
handling. The ebuild spit out a warning about it, which with newer
portage should have been displayed at the end of the emerge (even if
several packages were merged), but if you missed it...
To list all the network interfaces available, including ones that are
currently down, use ifconfig -a . If your interface of interest has
changed name, that would be why it isn't coming up, but you should see it
in the ifconfig -a output and be able to figure out what name it changed
to.
If it changed, go back and read the warnings from your last couple udev
merges. That should give you the info you need to change it back, or you
can instead update the network config to match.
FWIW, here it changed eth0 to eth1, because it double-detected the
interface but the first one it detected wasn't the real interface, so the
real one got bumped to eth1. Deleting the
/etc/udev/rules.d/70-persistent-net.rules file as suggested didn't help
as the new dynamic detection ended up doing the same thing, so I ended up
following the instructions therein, changing the appropriate NAME= key to
eth0, so I got my normal eth0 interface back.
But as I said, I think this is ~arch only right now. If you're running
stable udev, I doubt this is the problem. but it never hurts to check.
If it does turn out to be the problem, once you get the interface
straightened out again, you should of course be able to return to
whatever dhcp client you were using before, if desired.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
<<winmail.dat>>
