Bug 157050 – eth1394 grabs eth0 since coldplug went away

• Product: Gentoo Linux
• Status: RESOLVED DUPLICATE

[Description Roger Binns 2006-12-04 01:31:07 UTC]

Since the recent change (baselayout?) where coldplug went away and udev seems to handle startup, I have a problem that eth1394 (tcp/ip over firewire) now grabs eth0 pushing my real ethernet card to eth1 and breaking system networking.  It took quite a while to work this new behaviour all out.

Based on bug reports in Mandriva, users have a similar problem with the order of module loading determing who gets eth0 and with the ordering being non-deterministic.  I don't have the patience to reboot multiple times to see what does happen.  I just deleted the module out of lib modules.

I suggest changing the aliases or whatever voodoo is needed in /etc/*modules* so that eth1394 loads as fw0 or something similar and leaves eth0 to real networking cards.

[Comment 1 SpanKY 2006-12-04 08:29:01 UTC]

all the naming comes from the kernel so if you want to control that, you should be messing with kernel parameters so that you tell the kernel which interface should be what

this is not a userspace problem by any means

[Comment 2 Jakub Moc (RETIRED) 2006-12-04 09:32:34 UTC]

Don't rely on non-deterministic module load ordering; if you want persistent device names, that's what udev rules are for. (And, if you don't want ethernet over firewire, then why did you compile that module in the first place?)



*** This bug has been marked as a duplicate of 156893 ***

[Comment 3 Roger Binns 2006-12-04 11:26:04 UTC]

I don't want eth1394 and it gets included by default with firewire.  I am using genkernel.

I am surprised at the responses in this and in 156893 as well as on the mailing lists.  The users keep being blamed for behaviour that has now changed suddenly for the first time in the 13 years I have been using Linux.

Sure the module loading order determines names, but that behaviour has always been deterministic in the past.  Now it is random.

The install guide does mention that your network interfaces have random names, or how to make them fixed.

[Comment 4 Stefan Richter 2007-05-02 15:22:12 UTC]

Upstream bug http://bugzilla.kernel.org/show_bug.cgi?id=7793 was closed, fix went into mainline for 2.6.22-rc1.

Note, after that fix ieee1394 will still generate a hotplug event to let userspace load eth1394 if it detects an external IP-over-1394 capable device.

[Comment 5 Stefan Richter 2007-05-02 15:32:35 UTC]

Re comment #3:
I'd say module load order has always been semi-deterministic, now it is semi-random.  The old philosophy was "all devices are fixed, except only some are hotpluggable", the current philosophy is "all devices are hotpluggable from the drivers' point of view, it's just that the hardware of some devices doesn't feature hotplug-ability".  And the reality is, new bus architectures tend to be hotpluggable or are otherwise highly reconfigurable or feature more complex discovery protocols.

The approach to rely on module load order and each subsystem's device enumeration habits is simply not future proof.  The only future-proof way is to rely on persistent unique device properties, like e.g. MACs.  All bus architectures of the more flexible kind feature such persistent unique device properties, in one way or another.

[Comment 6 Stefan Richter 2007-05-02 15:38:11 UTC]

Re comment #1:
The kernel only offers some simply enumerated default names.  Persistent naming schemes are the responsibility of userspace tools.