upgrading to Jaunty renamed eth0 to eth1

[Bryan Larsen]

I upgraded from Intrepid to Jaunty Alpha5

Upon reboot, eth0 had renamed to eth1 and my static IP addresses had been lost

I've got udev version 137-2 installed.

Poking around, my ethernet card is now inside /etc/udev/rules.d/70-persistent-net.rules twice.

I'll attach my rules file, as well as the one from my backup, and dmesg. Let me know if you need any other logs.

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

mdz just confirmed this one

[Matt Zimmerman (mdz)]

I just noticed this on a system which I upgraded to Jaunty on 16th January. I don't have a backup against which to compare, but the modification time on the file is about 30 minutes after the upgrade completed (approximately the time I would have rebooted).

mizar:[~/Desktop] ls -l /etc/udev/rules.d/70-persistent-net.rules
-rw-r--r-- 1 root root 533 2009-01-16 15:54 /etc/udev/rules.d/70-persistent-net.rules
mizar:[~/Desktop] cat /etc/udev/rules.d/70-persistent-net.rules
# This file maintains persistent names for network interfaces.
# See udev(7) for syntax.
#
# Entries are automatically added by the 75-persistent-net-generator.rules
# file; however you are also free to add your own entries.

# PCI device 0x10de:0x00d6 (forcedeth)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:2f:4e:81:f5", ATTR{type}=="1", NAME="eth0"

# PCI device 0x10de:0x00d6 (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:11:2f:4e:81:f5", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

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

Moving up to Medium importance since a couple more people are reporting this.

No idea what causes it yet, I don't suppose anyone has the /var/log/udev file from the boot when it changed?

[Iain Lane (laney)]

Is only that boot relevant? My two network interfaces, previously eth0 and eth1 were renamed to eth2 and eth3.

[Akkana Peck (akkzilla)]

I can make this happen repeatably by putting 70-persistent-net.rules back in place.

Attaching /var/log/udev from a boot where the renaming occurred.

[Charles Burns (charlesnburns)]

The same happens on my system with Alpha 6. Two motherboard-integrated NICs (Pro/1000's) went from eth0, eth1 to eth2, eth3. This broke all network-related settings which depend on these not changing.

May be somehow related to: https://bugs.launchpad.net/bugs/153727

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

On Mon, 2009-03-23 at 19:33 +0000, Charles Burns wrote:

> May be somehow related to: https://bugs.launchpad.net/bugs/153727
>
It is not related.

Scott
--
Scott James Remnant
<email address hidden>

[Charles Burns (charlesnburns)]

Removing the duplicate entries from 70-persistent-net.rules did not solve the problem on my system. The entries were appended to the file once again (after the duplicates, which were commented out).
If this is the case for anyone else, try also editing 75-persistent-net-generator.rules.dpkg-old
I had these entries near the top:
#------------
ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*|wlan*|ra*|sta*" \
       NAME!="?*", DRIVERS=="?*", GOTO="persistent_net_generator_do"

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*|Ath*|wlan*|ra*|sta*" \
        NAME!="?*", DRIVERS=="?*", GOTO="persistent_net_generator_do"
#------------
After commenting the first two significant lines above and commenting duplicate entries in 70-persistent-net.rules, the naming went back to normal.
The name of 75 file implies that it is no longer used (the "-old"), so it is uncertain this file is related.

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

On Sun, 2009-03-22 at 22:43 +0000, Akkana Peck wrote:

> I can make this happen repeatably by putting 70-persistent-net.rules
> back in place.
>
Excellent, that's just the kind of news we like to hear!

Can you put the old file back in place, then run the following:

  sudo udevadm test /sys/class/net/eth0

and then attach the output

Thanks!

Scott
--
Scott James Remnant
<email address hidden>

[Akkana Peck (akkzilla)]

Here's the output. The only eth* part I see is:

unable to open device '/sys/class/net/eth0'

I see that both with the locally-built kernel I normally use and with the standard jaunty vmlinuz-2.6.28-5-386.

This is after booting with 70-persistent-net.rules in place, so the device has been renamed to eth1 and the network didn't configure -- let me know if you want a different configuration tested.

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

On Tue, 2009-03-24 at 17:48 +0000, Akkana Peck wrote:

> Here's the output. The only eth* part I see is:
>
> unable to open device '/sys/class/net/eth0'
>
> I see that both with the locally-built kernel I normally use and with
> the standard jaunty vmlinuz-2.6.28-5-386.
>
> This is after booting with 70-persistent-net.rules in place, so the
> device has been renamed to eth1 and the network didn't configure -- let
> me know if you want a different configuration tested.
>
Argh

I need you do to the reboot, then put the old file back in place after -
ie. the conditions before the reboot.

You may need to use eth1 or eth2 in place of eth0

Scott
--
Scott James Remnant
<email address hidden>

[Akkana Peck (akkzilla)]

Something that wasn't entirely clear to me before, but maybe should have been: the problem may just be in the syntax of the rule that's generated during the upgrade. (I used do-release-upgrade to go from intrepid to jaunty.)

Before the boot, here's the rule that's in 70-persistent-net.rules:

# Converted from /etc/iftab on upgrade
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:50:8d:c0:b9:30", ATTRS{type}=="1", NAME="eth0"

After boot, that rule is still there but this one has been added:

# PCI device 0x1106:0x3065 (via-rhine)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:8d:c0:b9:30", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

If I edit the file, remove the first rule, change the second to use eth0 instead of eth1, and reboot, the device stays as eth0 and everything works correctly.

So possibly the upgrade just needs to generate the second syntax rather than the first?

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

On Tue, 2009-03-24 at 18:11 +0000, Akkana Peck wrote:

> Something that wasn't entirely clear to me before, but maybe should have
> been: the problem may just be in the syntax of the rule that's generated
> during the upgrade. (I used do-release-upgrade to go from intrepid to
> jaunty.)
>
> Before the boot, here's the rule that's in 70-persistent-net.rules:
>
> # Converted from /etc/iftab on upgrade
> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:50:8d:c0:b9:30", ATTRS{type}=="1", NAME="eth0"
>
> After boot, that rule is still there but this one has been added:
>
> # PCI device 0x1106:0x3065 (via-rhine)
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:8d:c0:b9:30", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
>
The two rules should both match the same device, the new rule is just
more specific.

I need to know why the old rule is not matching, which is why I need you
to run "udevadm test" while the old rule (but not the new rule) is in
place.

Scott
--
Scott James Remnant
<email address hidden>

[Akkana Peck (akkzilla)]

Sorry for being dense; I hope I got the right test this time. This one (I also made another one, will attach in a sec) is from booting with the corrected file, so device remains eth0 and the net comes up correctly, then I copy the old file into place and (with the net still running) run udevadm test /sys/class/net/eth0. Udev tries to rename it but the device is busy.

[Akkana Peck (akkzilla)]

In case that wasn't right (I wasn't sure what state you wanted the machine in before I copied the file into place), here's one where I booted off the wrong file, so the device has been renamed to eth1, the net is not working, and I ran udevadm test /sys/class/net/eth1. (I tried running on /sys/class/net/eth0 too, but the results didn't look interesting, pretty much like that first file I attached.)

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

Thanks, both udevadm outputs are very useful - in the first case (eth0 rule only) it looks like the rule gets ignored!

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

Akkana: could you download http://people.ubuntu.com/~scott/udevadm (don't replace the installed copy, just put it in your working directory)

and run the tests again with the following command:

  UDEV_LOG=debug ./udevadm test /class/net/ethNN > log 2>&1

and upload each of the log files

[Akkana Peck (akkzilla)]

Here's a run after booting from the bad rule, the device renamed to eth1 and testing /class/net/eth1.

[Akkana Peck (akkzilla)]

And here's one after booting from the rewritten rule, device on eth0 and working, testing /class/net/eth0.
(I also have the opposite tests, of eth1 when the device is eth0 and vice versa, and of eth2 when the device is eth1 -- let me know if you want to see those).

Would it be any help to disable the udev and networking scripts in /etc/init.d to try to get a situation closer to what's actually happening on boot? Or to run the udev tests from within one of those scripts?

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

Copy the original file back (or delete the additional lines), and change occurrences of ATTRS with ATTR

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

This is caused by a change in the way that udev intreprets rules.

On a single line, all of the SUBSYSTEM, KERNEL, ATTR and DRIVER matches must match the same kobject - which is the device the event was for itself.

On a single line, all of the SUBSYSTEMS, KERNELS, ATTRS and DRIVERS matches must match the same kobject, which may be the event device itself of any of its parents.

In the above case, the DRIVERS=="?*" and ATTRS{address}=="..." match different kobjects; the driver matches the PCI subsystem kobject for the device, where the attr/address matches the net subsystem kobject.

Thus it no longer matches.

A simple sed script on upgrade should do the trick to fix the problem.

[Launchpad Janitor (janitor)]

This bug was fixed in the package udev - 140-2

---------------
udev (140-2) jaunty; urgency=low

  * debian/udev.postinst: On upgrade, replace instances of ATTRS{ in
    /etc/udev/rules.d/70-persistent-net.rules with ATTR{ otherwise they
    won't match anymore. LP: #329106.

 -- Scott James Remnant <email address hidden> Wed, 25 Mar 2009 17:57:20 +0000

[Serge (chapkin)]

Hello there,

One question : does this affect hardy 8.04 server LTS and if yes - was this fix backported into the hardy-udev (which is now of version 117)

Thanks in advance for your answer.

Best Regards,
Sergey

[David Stratton (d-stratton)]

FWIW this behaviour is still present in Ubuntu 10.04.

I am using Ubuntu in Virtual Box where it is all too easy to change MAC addresses.

The certain fix, with a single card, is to replace the entire contents of /etc/udev/rules.d/70-persistent-net.rules (in effect the history of all cards seen) with the single, "catch all" rule:

 SUBSYSTEM=="net", DRIVERS=="?*", NAME="eth0"

The single interface, regardless of type or MAC address is then named eth0

I tried multiple interfaces with similar lines (NAME= eth1, eth2 etc) but the order in which rules are processed (or interfaces detected?) does not appear predictable. It was quite common to see interfaces named, for example, "eth1_renamed"