cannot swap eth0 and eth1 if plugged at the same time

[Scott James Remnant (Canonical)]

my PCMCIA wifi card was detected, but the network interface wasn't configured --
additional network cards should probably be configured at install time

[Colin Watson (cjwatson)]

They're supposed to be, and are on my system. Could I have more information,
please? 'lspci' and 'lspci -n' output would be a good start.

[Scott James Remnant (Canonical) (canonical-scott)]

it's not a PCI card, it's a PCMCIA card; which was detected and the right module
loaded on the machine

[Colin Watson (cjwatson)]

OK, whichever; what card and what module, though?

[Scott James Remnant (Canonical) (canonical-scott)]

orinoco_cs, orinoco, hermes

generic off-the-shelf Prism 11b affair ... Linksys iirc.

[Colin Watson (cjwatson)]

Have you tried this with a recent version of warty?

[Matt Zimmerman (mdz)]

What Colin said...can you re-test?

[Bob vila (mindwarp)]

I had a similiar experience with the most recent release (warty) and my laptop.
 When the system initially installs, eth0 is my ethernet card. Once the system
is installed, eth0 becomes my wireless card and eth1 my ethernet card. So my
eth0 was configured for my ethernet settings, while eth1 was left unconfigured.

[Matt Zimmerman (mdz)]

(In reply to comment #7)
> I had a similiar experience with the most recent release (warty) and my laptop.
> When the system initially installs, eth0 is my ethernet card. Once the system
> is installed, eth0 becomes my wireless card and eth1 my ethernet card. So my
> eth0 was configured for my ethernet settings, while eth1 was left unconfigured.

That's a different bug; some wireless devices are not detected in the installer

[Matt Zimmerman (mdz)]

Re-test was requested almost two months ago, unreproducible. Reopen if it's
actually still happening.

[Scott James Remnant (Canonical) (canonical-scott)]

Hmm, I could've sworn I replied to this.

Anyway, yes, for the last few months I've got a question during install about
which of eth0 or eth1 (the wireless) I wanted to use during install -- selecting
the wireless works and it works on boot too.

[Christian Kirbach (christian-kirbach)]

Read comment #7
Same happened to me.

Release: Warty
Linux fuji 2.6.8.1-3-386 #1 Tue Oct 12

0000:00:10.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
0000:06:00.0 Network controller: Intersil Corporation Intersil ISL3890 [Prism
GT/Prism Duette] (rev 01)

wireless adapter (prism54) was detected properly by the installer as well as the
ethernet adapter. I was only asked to configure the wireless lan.
apparently the ethernet was eth0, the wireless eth1 during install (After first
bootup there
was only an eth1 entry in /etc/network/interfaces).
I chose eth1 as my primary interface since I was not connected to ethernet.
On first bootup the scripts hung at "Configuring network". I skipped with Ctrl-C.
Prism54 module was loaded properly.
-----------
root@fuji:/home/nazgul # iwconfig
lo no wireless extensions.

eth1 no wireless extensions.

eth0 NOT READY! ESSID:off/any
          Mode:Managed Channel:6 Access Point: 00:00:00:00:00:00
          Tx-Power=31 dBm Sensitivity=0/200
          Retry min limit:0 RTS thr=0 B Fragment thr=0 B
          Encryption key:off
          Link Quality:0 Signal level:0 Noise level:0
          Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
          Tx excessive retries:0 Invalid misc:0 Missed beacon:0

sit0 no wireless extensions.
-----

/etc/network/interfaces however just had eth1 configured - as wireless!

-----
root@fuji:/home/nazgul # cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# This is a list of hotpluggable network interfaces.
# They will be activated automatically by the hotplug subsystem.
mapping hotplug
        script grep
        map eth1

# The primary network interface
iface eth1 inet dhcp
        # wireless-* options are implemented by the wireless-tools package
        wireless-mode managed
        wireless-essid Kirbach
        name Ethernet LAN-Karte

auto eth1
-----

=> So it seems eth0 and eth1 got swapped.

Must be due to prism54 loading before the ethernet driver, contrary to the installer
kernel module loading order.

[Christian Kirbach (christian-kirbach)]

need to mention: chose eth1 (the wlan adapter) as my primary network interface.

[Matt Zimmerman (mdz)]

Please attach the /etc/iftab written by the installer.

[Christian Kirbach (christian-kirbach)]

Created an attachment (id=1359)
/etc/iftab as created by the installer

/etc/iftab attached as created by the installer.

Supplemental: If I boot with the Cardbus WLAN adapter
removed the ethernet controller is assigned to eth0, otherwise
the wireless adapter is assigned to eth0.

Think this is very hard to tackle. Assigning device names to MAC addresses
cannot be the solution.

[Matt Zimmerman (mdz)]

(In reply to comment #14)
> Supplemental: If I boot with the Cardbus WLAN adapter
> removed the ethernet controller is assigned to eth0, otherwise
> the wireless adapter is assigned to eth0.
>
> Think this is very hard to tackle. Assigning device names to MAC addresses
> cannot be the solution.

It is the best solution that we have, and it works for others.

Have you removed the ifrename package from your system, by any chance?

[Christian Kirbach (christian-kirbach)]

(In reply to comment #15)

> > Think this is very hard to tackle. Assigning device names to MAC addresses
> > cannot be the solution.
>
> It is the best solution that we have, and it works for others.
Hmm better than no solution at all ;)

> Have you removed the ifrename package from your system, by any chance?
Indeed ifrename is installed, I had only evolution removed.

Strange enough ifrename has apparently not succeeded.
Current association is not compliant to the iftab.

----
root@fuji:/home/nazgul # cat /etc/iftab
# This file assigns persistent names to network interfaces. See iftab(5).
eth0 mac 00:e0:00:17:0c:b2
eth1 mac 00:09:5b:94:05:be
root@fuji:/home/nazgul # ifconfig
eth0 Protokoll:Ethernet Hardware Adresse 00:09:5B:94:05:BE
          inet Adresse:10.0.0.10 Bcast:10.0.0.255 Maske:255.255.255.0
          inet6 Adresse: fe80::209:5bff:fe94:5be/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:3480 errors:0 dropped:0 overruns:0 frame:0
          TX packets:223 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:247269 (241.4 KiB) TX bytes:22324 (21.8 KiB)
          Interrupt:9

eth1 Protokoll:Ethernet Hardware Adresse 00:E0:00:17:0C:B2
-----------

I cannot see any unusual output or ifrename logging in dmesg.

---
root@fuji:/home/nazgul # cat /etc/network/ifstate
eth1=eth1
lo=lo
eth0=eth0
---

I only found ifrename references in /etc/hotplug/net.agent but not in /var/log:
root@fuji:/etc # rgrep "ifrename" *
hotplug/net.agent: # Run ifrename as needed - Jean II
hotplug/net.agent: if [ -x /sbin/ifrename ] && [ -r /etc/iftab ]; then
hotplug/net.agent: debug_mesg invoke ifrename for $INTERFACE
hotplug/net.agent: NEWNAME=`/sbin/ifrename -i $INTERFACE`

[Thomas Hood (jdthood)]

Is this still a problem?

[Matt Zimmerman (mdz)]

I think Scott's recent hotplug change should have fixed this

[Thomas Hood (jdthood)]

*** Bug 20073 has been marked as a duplicate of this bug. ***

[Thomas Hood (jdthood)]

Reading 13832, I fear that the problem may still exist.

[Thomas Hood (jdthood)]

Oh, wait. I hadn't seen this:

hotplug (0.0.20040329-22ubuntu8) breezy; urgency=low

  * Added debian/patches/051_net.agent_ifrename_-t to enable interface
    name takeover support when calling ifrename.
    (Ubuntu #8391, #10240, #13551)

 -- Scott James Remnant <email address hidden> Thu, 18 Aug 2005 02:25:52 +0100

[Thomas Hood (jdthood)]

As I wrote in #13832...
> It looks as if there is a race between multiple instances of net.agent.
> This is only a race because ifrename is being used in a way that makes
> it vulnerable; that is, it is used to assign names to interfaces that
> lie in the namespace used by the kernel. The race is then:
>
> eth0 created... ...eth0 renamed to 'eth1' (fails)
> eth1 created... ...eth1 renamed to 'eth0' (fails)

Using "-t" won't cure this problem.

   eth0 created... ...eth0 renamed to 'eth1' (succeeds; eth1 is give a
random name)
               eth1 created... ...eth1 renamed to 'eth0' (renames
the wrong interface)

[Thomas Hood (jdthood)]

*** Bug 14715 has been marked as a duplicate of this bug. ***

[Thomas Hood (jdthood)]

*** Bug 16538 has been marked as a duplicate of this bug. ***

[Thomas Hood (jdthood)]

*** Bug 19793 has been marked as a duplicate of this bug. ***

[Scott James Remnant (Canonical) (canonical-scott)]

The problem is that the list of interfaces needing hotplugging is created long
before any of the ifrename calls is made. If we move the S40ifrename script to
S39, this should fix this, as the renames will happen before that iteration.

Another option would be to run /etc/hotplug/net.rc from S41hotplug-net instead
of from S40hotplug (again, after the great renaming has already taken place).

[Thomas Hood (jdthood)]

(In reply to comment #26)
> The problem is that the list of interfaces needing hotplugging is created long
> before any of the ifrename calls is made. If we move the S40ifrename script to
> S39, this should fix this, as the renames will happen before that iteration.
>
> Another option would be to run /etc/hotplug/net.rc from S41hotplug-net instead
> of from S40hotplug (again, after the great renaming has already taken place).

I don't have time to reply to this now. Please don't rush to implement
these changes. I'll have more to say later.

[Thomas Hood (jdthood)]

(In reply to comment #26)
> The problem is that the list of interfaces needing hotplugging is created long
> before any of the ifrename calls is made.

I don't see what you mean. Can you explain further?

People should know that there are two different mechanisms at work:

    Kernel init: Initializes integral drivers which create interfaces
    S40hotplug Loads modules which initialize and create interfaces
    S40ifrename Renames any existing interfaces
    S40networking Brings up any of the above interfaces marked "auto" in
/etc/network/interfaces

The second is:

    device insertion: Causes modules to be loaded. Interfaces get created.
    net.agent: Renames the interface and starts net.ifup for it
    S41hotplug-net: Allows net.ifup processes to proceed

At boot time these systems operate in parallel. There is certainly some
overlap: any network interfaces created by the kernel before S:S40ifrename
will be renamed by both net.agent (which renames the interface that is the
topic of the hotplug event) and S:S40ifrename (which renames all interfaces
present). This is harmless if renaming is done into a new namespace: all
that happens is that the second attempt to perform the rename fails.

Both the ifrename call in S40ifrename and the one in net.agent are required:
the former is needed to rename interfaces created on boot for which no
hotplug events are generated; the latter is needed to rename interfaces
created after S40ifrename. (Of course, if hotplug events can be generated
for ALL interfaces then the need for S40ifrename disappears.)

I don't see how moving S40ifrename earlier will fix the race that I described.
That was a race between the ifrenames being done by two instances of net.agent.

> Another option would be to run /etc/hotplug/net.rc from S41hotplug-net instead
> of from S40hotplug (again, after the great renaming has already taken place).

Again, I don't see how this will help. net.rc can cause the creation of
multiple interfaces resulting in multiple net.agent processes which can race
with each other.

I will repeat that the multple net.agent processes only "race" because Ubuntu
has chosen to assign the same names to network interfaces as the kernel
assigns. This creates a need to perform interface renaming in sequences
such as

    eth0 -> ethtmp; eth1 -> eth0; ethtmp -> eth1

It also creates a need to eliminate redundant ifrename calls, because a
second instance of the above sequence will reverse the effect of a first
instance.

None of this is necessary if a separate namespace is chosen. These:

    eth0 -> ethfoo
    eth1 -> ethbar

can be done in parallel and the attempt can be made more than once
without any harm being done.

Everything in Debian assumes that the user will set up iftab to give
unique names to network interfaces outside the eth[0-9] namespace.
Whoever decided to write an iftab file on installation that contains
'eth0' and 'eth1' didn't fully grasp how ifrename is done by network
scripts in Debian.

Adding the '-t' option to ifrename calls is no solution to this problem.
The description of this option in ifrename(8) deprecates it in favor
of the use of a distinct namespac...

[Scott James Remnant (Canonical) (canonical-scott)]

First I think it'll be helpful to remind ourselves _why_ we're renaming
interfaces. The reason we do it is so that whichever order the modules are
loaded, or devices detected, you end up with the same name for each interface as
was around when the installer was run.

So the installer seeds /etc/iftab with the names and mac addresses of all
network interfaces that it detected. On booting the system, we need to make
sure interfaces are named according to this file.

Now, as you know, there are two stages to bringing up a network card:

 1. load the driver
 2. ifup the interface

Once we're in ordinary user-space and past S:S04udev, doing #1 results in udev
catching a net event from the kernel and the hotplug net.agent running which
does #2 if the interface is a "hotplug" one (which by default all of ours are).

For those that aren't hotplug, we assume that they'll be ifup'd by
S:S40networking if they're "auto" or by the user if not.

So let's now look at where we load modules:

 1. inside the initramfs
 2. from /etc/modules during S:S20module-init-tools
 3. by cold-plugging during S:S40hotplug

Both #2 and #3 take place after S:S04udev so they trigger net events and
net.agent gets run.

But #1 takes place before, so any network cards brought up by this are lost. So
we added a net.rc to hotplug that runs during S:S40hotplug and makes sure net
events for them all get triggered.

So we know by this point that all network card modules have loaded by the end of
S:S40hotplug.

Now we have the antiquitated S:S40networking to take into account, for various
reasons we want to hold all net events until after this has been run; so we hold
them on the existance of a file and then release them in S:S41hotplug-net.

So we know that all network cards are either ifup'd, or in the process of being
so, by the end of S:S40hotplug-net.

Now let's introduce ifrename into this equation. Because module and card
ordering is an issue, we need to be able to "swap" eth0 and eth1 around at
various times; that's why "-t" was added (it lets us do this).

I appreciate that renaming into a separate namespace would be nice, but it's not
really tenable. If breezy suddenly decided to use "netX" instead of "ethX" for
every card it'd confuse the buggery out of the entire world. So I don't see
that as a solution, we're using ifrename to ensure that eth0 today is the same
eth0 as when you installed.

In order to swap two interfaces (e.g. eth0 and eth1) around it needs to be run
on both interfaces after the module has been loaded, and before the card has
been ifup'd. It also, rather sensibly needs to be run before we're actually
done anything in particular with the card name (as it might change).

At the moment that's done at S:S40ifrename, which is before S:S40networking but
after S:S40hotplug. But net.agent doesn't wait until S:S41hotplug-net to do the
renaming it does, so in theory all renaming is done before anything is ifup'd.

We are generating hotplug events for all interfaces (in our net.rc), before
S:S40ifrename is run, so perhaps that startup script isn't required anymore.

I don't think it's a race condition, here's what I think is happening (and it's
all wit...

[Thomas Hood (jdthood)]

That is a good description of what happens. I have just a few
comments.

> Now we have the antiquitated S:S40networking to take into account, for various
> reasons we want to hold all net events until after this has been run;

There are several scripts around S40 that initialize networking
infrastructure. Interfaces should not be brought up before that
initialization happens. It was also discovered that problems arise
if "lo" is not the first interface brought up. So S40networking
brings up lo, at least, and then any other "auto" interfaces.
Hotplug-controlled interfaces can be ifup'ped after that.

> So we know that all network cards are either ifup'd, or in the process of being
> so, by the end of S:S40hotplug-net.

Well, S41hotplug-net creates a flag file and net.ifup processes can
wait up to one second longer before they proceed.

> I appreciate that renaming into a separate namespace would be nice, but it's not
> really tenable. If breezy suddenly decided to use "netX" instead of "ethX" for
> every card it'd confuse the buggery out of the entire world.

I would recommend "eth_X". That would be less confusing.

> We are generating hotplug events for all interfaces (in our net.rc), before
> S:S40ifrename is run, so perhaps that startup script isn't required anymore.

If events are now generated for _all_ interfaces then, yes, S40ifrename
can go away.

> 1. modules for both eth0 and eth1 are loaded during initramfs
> 2. S:S40hotplug begins
> 3. /etc/hotplug/net.rc begins
> 4. we take a list of all devices listed in /sys/class/net (eth0 eth1 at this
point)
> 5. we run net.agent with ACTION=add INTERFACE=eth0
> 6. net.agent runs ifrename to rename the interface to eth1, it succeeds. At
> this point what was eth0 is now called eth1, and what was eth1 is now called
> eth<something random>.
> 7. ifup of the new eth1 (née eth0) is queued until after S:S41hotplug-net
> 8. net.agent for new eth1 (née eth0) finishes, back in the loop in
> /etc/hotplug/net.rc
> 9. eth1 is next on the list ... we run net.agent with ACTION=add INTERFACE=eth1
>
> Oops. We should've run INTERFACE=eth<something random>; by storing up the list
> of interfaces before iterating them we don't cope with one being renamed during
> the (synchronous) script we run.

That is one possible failure mode.

> So there's two ways of fixing this.
>
> 1. run ifrename before hotplug, that way the interface renaming is all taken
> care of before we try and cold-plug the network interfaces.

I don't understand this. How can you take care of interface renaming
_before_ you create the interfaces?

> 2. fix net.rc to not be stupid, and cope with interfaces being renamed by
net.agent

Are you sure that this change will eliminate _all_ the races?

It appeas to me that the system is inherently racy (because of the
fact that the kernel namespace is being reused). The measures you
propose eliminate one occasion for the race but do rule out races
entirely. They do not really solve the problem.

What if the user has two interfaces on a single card? The card is
inserted; the kernel creates eth0 and eth1 and generates two hotplug
events; the two net.agent process...

[Scott James Remnant (Canonical) (canonical-scott)]

Right, we definitely need to bring up the loopback device before anything else
-- and helpfully the kernel doesn't ever hotplug that one. I don't even think
there's a device for it, is there?

In the long-run I think we can actually get rid of the distinction between
"mapping hotplug" and "auto" interfaces. If we coldplug all the hardware and
coldplug the network interfaces themselves, we end up starting everything anyway.

S:S40networking could just start "lo", and everything else could be started by a
udev rule that runs "ifup --auto-only $INTERFACE" (invented option). We could
then move S:S40networking to before hotplug runs at all, in fact given that it
won't have any real dependencies, we could move it as far forward as S:S04 so
everything network-related is ready to go once udevd is started.

We could get rid of S:S41hotplug-net entirely then, and just let all the net
ones rip. The checking bits of net.agent could then become part of ifup,
anyway, we're blue-skying here, back to the topic.

Moving ifrename would solve the issue for those interfaces for which the drivers
have already been loaded (by initramfs or /etc/modules) and are not yet ifup'd
... but wouldn't for the example you give. Though the example you give is
actually bogus, if you have an ethernet card with two interfaces (I have one
here) udev actually serialises the net events because they have the same DEVPATH.

A better example is having two ethernet cards in the machine which use the same
driver, then you do get them both fired off at the same time, and the race occurs.

So we'd have a race if we wanted to swap them around.

We should certainly work to make sure that race doesn't happen.

I don't like having a separate namespace though, and really don't see it as a
solution. "Ubuntu doesn't use ethX!" would be the user backlash, as we rename
everything. We need to find something else that isn't racy, but lets us swap
the names of two interfaces on the ethernet card around.

[Thomas Hood (jdthood)]

(In reply to comment #31)
> Right, we definitely need to bring up the loopback device before anything else
> -- and helpfully the kernel doesn't ever hotplug that one.

I don't think the kernel ever generates a hotplug event for lo.

> In the long-run I think we can actually get rid of the distinction between
> "mapping hotplug" and "auto" interfaces. If we coldplug all the hardware and
> coldplug the network interfaces themselves, we end up starting everything anyway.

Well, lo will always be marked "auto", presumably.

Note that the existing variety of methods offered by the Debian hotplug
package for controlling whether or not an interface is brought up are
being replaced by one new method that makes us of the new "--allow"
ifupdown option.

> We could then move S:S40networking to before hotplug runs at all

I would advise against moving S40networking. It is one of the few
points defined in the README. Also, a number of other scripts such
as S39ifupdown should preserve their order relative to the
networking initscript.

> I don't like having a separate namespace though, and really don't see it as a
> solution.

It is the only completely sound solution. Any solution involving
mapping from eth* to eth* doesn't eliminate the short period during
which the interfaces are misnamed.

> "Ubuntu doesn't use ethX!" would be the user backlash, as we rename
> everything.

If you have a reason to do something then you shouldn't worry about
what people say.

  We need to find something else that isn't racy, but lets us swap
> the names of two interfaces on the ethernet card around.

Another solution is to make the kernel use a different namespace.
That is, interfaces come up with eth_X and are ifrenamed to ethX.
If this solution is adopted then one has to make doubly sure
that ifrename is installed and correctly configured.

Another possibility is to make the kernel use a different namespace
for interfaces other than the first. Thus the first eth interface
appears as eth0; the second appears as eth_1, the third as eth_2.
If eth0 should really be called 'eth1' then it can be renamed
without colliding. An ifrename of eth_X to 'eth0' could be made
to wait until that name becomes available.

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

Wouldn't one solution to be for net.agent not to attempt to remap or raise the
network cards when called during startup. Then after the hotplug init script has
finished, call the ifrename init script to do the entire initial re-mapping. And
then only after that has happened to raise the network cards should be raised.

A solution to this would be wonderful, at the moment my desktop machine just
won't boot due to my nic not getting raised, and then nis and nfs failing.

[Thomas Hood (jdthood)]

(In reply to comment #33)
> Wouldn't one solution to be for net.agent not to attempt to remap or raise the
> network cards when called during startup.

How does a given net.agent process know whether or not it was run
as a result of something done by S40hotplug?

Races are possible because net.agent runs ifrename and because multiple
net.agent processes can run in parallel and are making changes to the
same variables. This can only be fixed reliably either by separating
the namespace or by synchronizing net.agent's use of ifrename.

Someone should investigate whether we are any further ahead if we
move from ifrename to udev-native network interface renaming.

[Scott James Remnant (Canonical) (canonical-scott)]

*** Bug 20339 has been marked as a duplicate of this bug. ***

[Scott James Remnant (Canonical) (canonical-scott)]

I think our current state is fine for breezy -- this will only affect people who
have multiple network cards (not just interfaces on the same card) which are of
the same type *and* end up with a different order at boot than at install time.

And what's more, that didn't work in hoary either, so it's not a regression.

The fix for anyone who gets this is simply to swap the names round in /etc/iftab.

The long-term fix will be to do configuration and activation of network cards
based on their hardware details and not on their name.... ie. "IPW2100 Wireless
Card with MAC 12:34:56:67:89:0a => dhcp" not "eth1 dhcp"; this is inline with
what we've done for pmount too, /dev/sda* is assigned by the kernel and the
mount point is assigned by us.

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

Scott, sorry to dissappoint you, this is a serious regression from hoary for my
desktop machine. In hoary my machine booted fine, in breezy, it will not bring
up my network card, which means nis / nfs fails, and the entire bootup sequence
fails.

I also fail to see how "swapping over the interfaces in iftab" is a realistic
expectation for users. They would then also have to swap things in
/etc/network/interfaces, and the chances of the average user knowing what to do
is pretty much zero.

[Scott James Remnant (Canonical) (canonical-scott)]

(In reply to comment #37)
> Scott, sorry to dissappoint you, this is a serious regression from hoary for my
> desktop machine. In hoary my machine booted fine, in breezy, it will not bring
> up my network card, which means nis / nfs fails, and the entire bootup sequence
> fails.
>
> I also fail to see how "swapping over the interfaces in iftab" is a realistic
> expectation for users. They would then also have to swap things in
> /etc/network/interfaces, and the chances of the average user knowing what to do
> is pretty much zero.

Could you attach the following files: /etc/iftab, /etc/network/interfaces and
the output of lspci, just so I can confirm what's going on for you.

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

Created an attachment (id=3983)
interfaces, iftab and lspci output

[Scott James Remnant (Canonical) (canonical-scott)]

(In reply to comment #39)
> Created an attachment (id=3983) [edit]
> interfaces, iftab and lspci output
>

Sorry, and the output of "ifconfig -a" ...

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

Created an attachment (id=3990)
ifconfig output

I've found that changing eth1 to eth2 in the iftab file solves my problems, but
it doesn't seem like a real solution for most users.

[Scott James Remnant (Canonical) (canonical-scott)]

(In reply to comment #41)
> Created an attachment (id=3990) [edit]
> ifconfig output
>
Hmm, so what problem are you having?

Your network card configuration here matches what /etc/iftab says it should be
and your eth0 is configured according to /etc/network/interfaces.

You don't have this bug...

[Crispin Flowerday (crispin-flowerday-deactivatedaccount)]

Well, bug 20073 was dupped onto this one....

Basically hotplug comes along, sees my 2 network cards (eth0 and eth1), calls
net.agent on eth0, which maps eth0 to eth1 (so the old eth1 goes somewhere else)
then calls net.agent on eth1 (which is now the new eth1) so it calls "ifup eth1"
twice, and so my eth0 is never raised. bug 20073 comment 5 goes into detail
about the problem.

[Scott James Remnant (Canonical) (canonical-scott)]

(In reply to comment #43)
> Well, bug 20073 was dupped onto this one....
>
> Basically hotplug comes along, sees my 2 network cards (eth0 and eth1), calls
> net.agent on eth0, which maps eth0 to eth1 (so the old eth1 goes somewhere else)
> then calls net.agent on eth1 (which is now the new eth1) so it calls "ifup eth1"
> twice, and so my eth0 is never raised. bug 20073 comment 5 goes into detail
> about the problem.
>
Ah, you've raised eth0 manually since (kinda obvious, really :p)

ok, yes, that's this bug

[Scott James Remnant (Canonical) (canonical-scott)]

I'm going to defer this to dapper -- there are work arounds for breezy for those
few unfortunate people who this affects.

[Thomas Hood (jdthood)]

(In reply to comment #31)
> I don't like having a separate namespace though, and really don't see it as a
> solution. "Ubuntu doesn't use ethX!" would be the user backlash, as we rename
> everything.

In bug #9982 a user complains that names like 'eth0' are underinformative.
When I read that, it made me recall the statement I quote above.

[Scott James Remnant (Canonical) (canonical-scott)]

*** Bug 23643 has been marked as a duplicate of this bug. ***

[Scott James Remnant (Canonical) (canonical-scott)]

udev itself can handle renaming of network interfaces, we might clean that code
up a bit and use that -- because it can keep track of the interface name and
adjust its rule processing and program running accordingly.

[Scott James Remnant (Canonical) (canonical-scott)]

This has been fixed with the latest udev upload.

Summary:
 - we now use udev's built-in functionality for renaming network devices
 - this has been patched so if a device name already exists, udev will wait for it to go away, rather than failing
 - once renamed, udev substitutes the new name in all further rules
 - we have a helper that parses iftab and outputs the name if it matches all selectors
 - the same helper outputs a different name (outside the kernel namespace) if the device doesn't match the selectors for its own name

This means interfaces should be reliably swappable:
1) eth0 and eth1 are plugged at same time
2) eth0 matches eth1 selectors, so is renamed to eth1, which fails with EEXIST
3) udev renames the interface to a temporary name (__eth0), then keeps trying
4) eth1 matches eth0 selectors, so is renamed to eth0 which will succeed
5) udev runs "ifup eth0"
6) rename of __eth0 to eth1 succeeds
7) udev runs "ifup eth1"