On Aug 2 2007 12:56, Herbert Rosmanith wrote:
>> On Aug 2 2007 12:42, Herbert Rosmanith wrote:
>> There never *were* days when eth0 remained eth0 across such changes.
>
>but there *were* days when eth0 was eth0, if the kernel reports it as such.
>now there is no eth0 at all. if I see an "eth0" from dmesg, I expect
>it to be present.
Wait, you forget that something may change the name. That dmesg message
from 1 second ago does not need to be valid anymore, just as anything
else in this world.
On Aug 2 2007 13:12, Herbert Rosmanith wrote:
>> > cards around), eth0 would also suddenly become a different one. There never
>> > *were* days when eth0 remained eth0 across such changes.
>>
>> but there *were* days when eth0 was eth0, if the kernel reports it as such.
>> now there is no eth0 at all. if I see an "eth0" from dmesg, I expect
>> it to be present.
>
>hm, well, a thought, maybe udev should report what is doing, like
>printinig "renamed eth0 to eth2", or such.
I think it once did with suse, but it does not right now. Worth fixing
(yet I am no udev maintainer).
>the problem with this device renaming in my case was that other software,
>in particular dhcpcd, didnt get any lease, because (obviously?) dhcpcd
>on the other hand _still_ seemed to look for eth0, and thus, after
>booting, there was no network configured at all.
So blame your distro for not integrating udev correctly with dhcp-client.
I can only speak for suse, where you define BOOTPROTO=dhcp for an
interface. Then, on /etc/init.d/network, every interface that has a
configuration file gets run, so you never see what ethX udev picked for
the day, but things still work. That's good^TM.
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
