[Gutsy] broken 70-persistent-net.rules

Lars Wirzenius had a similar issue with Ubuntu Alternate.

Described as comment here :
https://bugs.edge.launchpad.net/ubuntu/+source/network-manager/+bug/134496

We use static network settings, and after installation the 70-persistent-net.rules has seven lines like this:

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0"

and no line with a MAC-address. The computer only has one interface. If I remove those lines, the network is brought up on boot.

This is caused by the installer's busybox /bin/sh not having the [ built-in, so the write_net_rules shell script doesn't actually work properly

I can confirm this happens on a gutsy server beta install here.

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0"

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0"

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0"

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0"

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0"

# PCI device 0x1106:0x3065 (via-rhine)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:16:ec:6e:e1:fd", NAME="eth1"
70-persistent-net.rules (END)

root@gutsybeta:~# diff /etc/udev/rules.d/70-persistent-net.rules 70-persistent-net.rules
13c13
< SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:16:ec:6e:e1:fd", NAME="eth0"
---
> SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:16:ec:6e:e1:fd", NAME="eth1"

and

root@gutsybeta:~# diff /etc/network/interfaces interfaces
9,13c9,13
< auto eth0
< iface eth0 inet static
< address 192.168.20.14
< netmask 255.255.255.0
< gateway 192.168.20.1
---
> auto eth0
> iface eth0 inet dhcp

and a reboot seems to fix the problem of static assignment on a single network interface

Thanks Jim,
the patch for /etc/udev/rules.d/70-persistent-net.rules fixed the problem for me. I used the alternate CD to install a command based distribution on an old computer.

Scott, I'm not going to build [ into busybox's /bin/sh (there's no support for this in busybox at the moment and the one relevant configuration option is far too invasive for this - it affects all busybox applets). Please change udev-udeb to use a full PATH rather than just /lib/udev.

I can confirm the bug.
It happend 28.09.07 10:18 GMT.
On my "new" P233MMX proxy and (SJ36=MM) 1GHz Celeron+256MB + i815E + onboard_100Mbit + intelPCI_100Mbit.
I was lucky I was nearby all of the machines. I landed with Gutsy.beta1 on both of them without any ethX (respectively with eth2+eth3) (eth0+1 in interfaces).
After I MANUALLY edited MACs addr. in /etc/udev/rules.d/70-persistent-net.rules - everythings run fine.
Thanks to my backup Etch :)

It is VERY interesting for me, that X was "randomly"(?) choosen. Before I found a bug - there was no MAC in /etc/udev/rules.d/70-persistent-net.rules, but after 2nd reboot I had eth5 and eth6, then eth7&8, then 3&4 ...

Apparently I misunderstood and the problem is that [ is in /usr/bin. Reopening busybox task.

busybox (1:1.1.3-5ubuntu5) gutsy; urgency=low

  * Move test and friends to /bin (LP: #145382).

 -- Colin Watson <email address hidden> Tue, 02 Oct 2007 19:52:41 +0100

Bueno yo de ingles nada pero la compilacion del 1 de octubre y este error se viene arrastrando desde el beta 5
No solo para la version server tambien para la version Desktop.
Al reiniciar el sistema reasigna nombre del dispositivo de red.
Esto implica tener que correr el pppoeconf para conectarse a internet con cada reinicio.

fixed in busybox, marking as invalid for udev.

The last followup in Spanish seems to report an unrelated bug, since it states that it affects desktop installs and happens after each reboot, not just at install time.

What does this section of /etc/udev/rules.d/70-persistent-net.rules do?

=============
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0"

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0"

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0"

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0"

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth0
==============
Can I just delete it?

I can confirm this bug in Gutsy 7.10 server beta when installing it in a VmWare virtual machine running over a GSX server.

NEGO:
Pls write in English (basic is enough :)
If do NOT speak english any little bit:
Write it in Spanish (as you did)
use: http://www.google.com/translate_t?langpair=es|en
and COPY PASTE it in the SAME comment. Thanks :)
**

NEGO:
Pls escribe en inglés (básico es bastante:)
Si no hablar inglés ningún pequeño pedacito:
Escribirlo en español (como)
uso: http://www.google.com/translate_t?langpair=es |en
y GOMA del copy en IGUAL comenta. Agradece:)

HASAN::

IMHO yes:: delete "your lines".

And add these:
## PCI device ONBOARD intel 10/100
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:bb:05:14:85:56", NAME="eth0"
# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:a0:cc:d0:00:43", NAME="eth1"
##xyz blah
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth7"

Hi.
I vote this to be nominated for RC(!) Gutsy release.
This is very dangerous, annoying 95% (or more) of installer, and I think&hope - easy to repair. It IS working on other distros: feisty, Etch, Sarge, FC5+6+7 ...
Thanks much anyone.

Workaround/HINT::
1. comment EVERYTHING in /etc/udev/rules.d/70-persistent-net.rules
2. add:
## PCI device ONBOARD intel 10/100
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:bb:05:14:85:56", NAME="eth0"
# PCI device 0x8086:0x1229 (e100)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:a0:cc:d0:00:43", NAME="eth1"
##xyz blah
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="", NAME="eth7"
3. correct MAC adresses and descriptions (IMHO NOT needed)
(u can get MACs: sudo ifconfig -a)
*****OR::
sudo mv /etc/udev/rules.d/70-persistent-net.rules /etc/udev/rules.d/70-persistent-net.rules.BAKKK
sudo reboot

On Wed, Oct 10, 2007 at 01:35:51PM -0000, Jan Kunder wrote:
> NEGO:
> Pls escribe en inglés (básico es bastante:)
> Si no hablar inglés ningún pequeño pedacito:
> Escribirlo en español (como)
> uso: http://www.google.com/translate_t?langpair=es |en
> y GOMA del copy en IGUAL comenta. Agradece:)

I'm afraid this doesn't come out as comprehensible Spanish when passed
through google translator; which is ok, because that means what you've said
here wasn't a recommendation to use it so the commentor is unlikely to rely
on it. ;)

As I noted earlier, NEGO's followup was about some unrelated bug. That
should be submitted as a separate report, probably with the help of a LoCo
for translation assistance because google translate is simply not usable for
this. I would have happily told him this in Spanish, but he doesn't appear
to be subscribed to the bug and has no email contact information in LP...

Jan - This bug's state is one of Fix Released meaning that the bug is fixed and that you should not see it on a daily build of the server ISO images nor on the RC image when it comes out.

First, I request excuses by the badly English.
It is translation of google.

The problem in my case related to the connection of the network devices, is that in each resumption the card that this connected changes its name. the file 70-persistent-net.rules adds a 1 to him to the name

This implies that in the following resumption I do not have coneccion to Internet because the changed device to left connected to of name.

In some beginning of way text and gotten to read an error of mac adres therefore generates a direction fictitious this can be the cause of the error.

the card that generates the problem is onboard of mother ASUS A7N8X 2.0

Good I show the information of my file here

70-persistent-net.rules

# This cases out was automatically generated by the /lib/udev/write_net_rules
# program, probably run by the persistent-net-generator.rules rules cases out.
#
# You dog modify it, ace long ace you keep each rule on to single line.

# First Resumption

# This device is “A7N8X Mainboard onboard nForce2 Ethernet” (Connected with modem ADSL)
# PCI device 0x10de: 0x0066 (forcedeth)
SUBSYSTEM== " net ", DRIVERS== "? * ", ATTRS {address} == " 00: 00: 6c: 88: 0c: 1d ", NAME= " eth0 "

# This Device is “Realtek RTL-8139/8139C/8139C+” (Not connected)
# PCI device 0x10ec: 0x8139 (8139too)
SUBSYSTEM== " net ", DRIVERS== "? * ", ATTRS {address} == " 00: 60: 67: 76: cc: 67 ", NAME= " eth1 "

# Second Resumption

# This device is “A7N8X Mainboard onboard nForce2 Ethernet” (Connected with modem ADSL)
# PCI device 0x10de: 0x0066 (forcedeth)
SUBSYSTEM== " net ", DRIVERS== "? * ", ATTRS {address} == " 00: 00: 6c: 07: c6: dc ", NAME= " eth2 "

# These are my commentaries
# This device is “A7N8X Mainboard onboard nForce2 Ethernet” (Connected with modem ADSL)
# PCI device 0x10de: 0x0066 (forcedeth)
#SUBSYSTEM== " net ", DRIVERS== "? * ", ATTRS {address} == " This changes with each resumption ", NAME= " eth (here to him it is added of a 1) “

As address can see in the device nvidia mac changes with each resumption, which can cause that a new device is detected as and changes their name.

the partial solution of this problem is to erase the file 70-persistent-net.rules before extinguishing or reinitiating.

This I do it with a thrower who has east commando (I sweat rm /etc/udev/rules.d/70-persistent-net.rules)

I wait for this is of aid to solve the problem to them.

I make emphasis that at some time of the beginning of the system gets to read that there is an error in the MAC address of this device which generates one random one.

This! No! it happens in version 7.04

He is exclusive of version 7.10 until the compilation of the 4 of October of the 2007

Look for >>>>

IRQ 16
Oct 4 20:27:06 NEGA kernel: [ 24.812477] PCI: Setting latency timer of device 0000:00:02.0 to 64
Oct 4 20:27:06 NEGA kernel: [ 24.812480] ohci_hcd 0000:00:02.0: OHCI Host Controller
Oct 4 20:27:06 NEGA kernel: [ 24.812677] ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
Oct 4 20:27:06 NEGA kernel: [ 24.812697] ohci_hcd 0000:00:02.0: irq 16, io mem 0xdb003000
Oct 4 20:27:06 NEGA kernel: [ 24.863605] forcedeth.c: Reverse Engineered nForce ethernet driver. Version 0.60.
Oct 4 20:27:06 NEGA kernel: [ 24.875982] usb usb1: configuration #1 chosen from 1 choice
Oct 4 20:27:06 NEGA kernel: [ 24.876016] hub 1-0:1.0: USB hub found
Oct 4 20:27:06 NEGA kernel: [ 24.876029] hub 1-0:1.0: 3 ports detected
Oct 4 20:27:06 NEGA kernel: [ 24.938707] 8139too Fast Ethernet driver 0.9.28
Oct 4 20:27:06 NEGA kernel: [ 24.964401] SCSI subsystem initialized
Oct 4 20:27:06 NEGA kernel: [ 24.969282] libata version 2.21 loaded.
Oct 4 20:27:06 NEGA kernel: [ 24.978157] ACPI: PCI Interrupt Link [APCG] enabled at IRQ 21
Oct 4 20:27:06 NEGA kernel: [ 24.978167] ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [APCG] -> GSI 21 (level, high) -> IRQ 17
Oct 4 20:27:06 NEGA kernel: [ 24.978184] PCI: Setting latency timer of device 0000:00:02.1 to 64
Oct 4 20:27:06 NEGA kernel: [ 24.978187] ohci_hcd 0000:00:02.1: OHCI Host Controller
Oct 4 20:27:06 NEGA kernel: [ 24.978213] ohci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
Oct 4 20:27:06 NEGA kernel: [ 24.978232] ohci_hcd 0000:00:02.1: irq 17, io mem 0xdb004000
Oct 4 20:27:06 NEGA kernel: [ 25.035799] usb usb2: configuration #1 chosen from 1 choice
Oct 4 20:27:06 NEGA kernel: [ 25.035835] hub 2-0:1.0: USB hub found
Oct 4 20:27:06 NEGA kernel: [ 25.035847] hub 2-0:1.0: 3 ports detected
Oct 4 20:27:06 NEGA kernel: [ 25.057005] Floppy drive(s): fd0 is 1.44M
Oct 4 20:27:06 NEGA kernel: [ 25.112585] FDC 0 is a post-1991 82077
Oct 4 20:27:06 NEGA kernel: [ 25.139730] ACPI: PCI Interrupt Link [APCH] enabled at IRQ 20
Oct 4 20:27:06 NEGA kernel: [ 25.139741] ACPI: PCI Interrupt 0000:00:04.0[A] -> Link [APCH] -> GSI 20 (level, high) -> IRQ 18
>>>> Oct 4 20:27:06 NEGA kernel: [ 25.139748] PCI: Setting latency timer of device 0000:00:04.0 to 64
>>>> Oct 4 20:27:06 NEGA kernel: [ 25.139773] 0000:00:04.0: Invalid Mac address detected: 00:00:00:00:00:00
>>>> Oct 4 20:27:06 NEGA kernel: [ 25.139777] Please complain to your hardware vendor. Switching to a random MAC.
Oct 4 20:27:06 NEGA kernel: [ 25.281452] usb 1-1: new full speed USB device using ohci_hcd and address 2
Oct 4 20:27:06 NEGA kernel: [ 25.491344] usb 1-1: configuration #1 chosen from 1 choice
Oct 4 20:27:06 NEGA kernel: [ 25.657393] eth0: forcedeth.c: subsystem: 01043:80a7 bound to 0000:00:04.0
Oct 4 20:27:06 NEGA kernel: [ 25.657831] ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22
Oct 4 20:27:06 NEGA kernel: [ 25.657835] ACPI: PCI Interrupt 0000:00:02.2[C] -> Link [APCL] -> GSI 22 (level, high) -> IRQ 16
Oct 4 20:27:06 NEGA kernel: [ 25.657848] PCI: Setting latency timer of device 0000:00:02.2 to 64
Oct 4 20:27:06 ...

It is a hack work around found through google, but it solved the problem with the adapter changing on each reboot... when using a static IP.

Remove all lines of various eth0, eth1, eth2 and so on and replace them with this line:

SUBSYSTEM=="net", DRIVERS=="forcedeth", NAME="eth0"

Adjust your driver, and the name of the adapter as you need it / want it.

I've had the same problem after updating a Kubuntu desktop machine to Gutsy last night. This morning, after rebooting, the single ethernet card with a static address had "disappeared". Over the telephone I confirmed that there was one "SUBSYSTEM=="net", DRIVERS=="?*"... line (don't know if it contained a MAC address or not), which, when removed and the machine rebooted, resulted in the ethernet card working again.

Bug 153727 has been marked duplicate of this bug, and this bug is marked Invalid. The issue in 153727 is same as Nego's issue, which Steve indicates is a separate issue. The bug is very much present in Gutsy Final (with all updates). Why was 153727 marked as a duplicate of this bug then?

Should I re-open this bug, or un-dupe 153727?

Oh sorry! Then i did falsely dupe it. I thought they were the same issues leading to no working network. Please un-dupe 153727 then.

Aside from the busybox issue.. Isn't the udev net persistence feature going to cause a lot more problems than it solves?

As I understand it, it is recording the MAC address of the NIC, and associating that with an ethernet interface. So, that if the order the NICs are initialized in changes, the association of NIC to eth device stays the same. This works fine in a physical server, where the expectation is that hardware changes are unlikely. But, in a VM environment, the MAC address can change when changes are made to the Virtual Machine configuration, or the location of the VM, etc.

As it is now, any time he MAC changes, the user will lose connectivity, because it is now treated as eth1, rather than eth0, which has no configuration.

This feature of udev should be turned off in the JeOS build, as it causes problems in common VM usage. Or, some additional logic could help it to do its job better, such as:

- If only one NIC exists in the box, don't worry about order/mapping, treat it as eth0 (solves a large percentage of problems)
- If the old MAC address doesn't exist anymore, don't hold the reservation/mapping.

I realized after my previous message that this bug relates to Gutsy in general, and not just the JeOS version..

My comment was specific to the JeOS build, which operates in a fundamentally different environment as a Virtual Machine, which leads to issues with the virtual NIC devices being a lot more dynamic than physical NIC devices.

For example, if a VM is cloned, moved to another host, or even has some seemingly unrelated change made to its configuration, the MAC address of the VM can change - causing loss of connectivity for the VM on the next reboot, in a way that is non-trivial to diagnose.

The scenarios described above are from my experience with VMware ESX, and may not come into play with Xen, KVM, MS Viridian, or others.

I've just experienced a similar issue on intrepid my eth0 was reported as eth8 it may be because this systems been rebuilt and moved between pc's a few times over the years and had several different network cards hopefully renaming eth8 eth0 and deleting the other entries cures the issue (it seem too)

Seems to be worse in jaunty. I upgraded from hardy to intrepid with no networking difficulties, but I just upgraded the same machine from intrepid to jaunty and had no network, because udev renamed eth0 to eth1. I removed 70-persistent-net.rules and rebooted, and that fixed the problem.
(See also bugs 208103, 153727 etc.)

my network card was listed as eth2, i just changed it to eth0...fix worked for me

The current issue with renaming after an upgrade to jaunty is being tracked as bug #329106