Live CD contains persistent network interfaces for the livefs build machine

Bug #123559 reported by Serge
2
Affects Status Importance Assigned to Milestone
linux-source-2.6.22 (Ubuntu)
Invalid
Undecided
Unassigned
udev (Ubuntu)
Fix Released
Medium
Kyle McMartin

Bug Description

Binary package hint: kernel-image-2.6.22-7-generic-di

Installed Gutsy Tribe-2 with all current available updates on a Lenovo T60 and also on an X60

Ifconfig shows the wired interface as eth2 and the wireless interface as eth3. There is also a eth2:avahi alias to the wired interface.

/etc/network/interfaces has entries for lo eth0 eth1 eth2 ath0 wlan0

wired network is an intel e1000
wireless network is an ipw3945

Tags: macbookpro
Revision history for this message
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it, because your description doesn't yet have enough information.

Please include the following additional information, if you have not already done so (please pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.

For your reference, the full description of procedures for kernel-related bug reports is available at [WWW] http://wiki.ubuntu.com/KernelTeamBugPolicies. Thanks in advance!

Changed in linux-source-2.6.22:
importance: Undecided → Medium
status: New → Incomplete
Revision history for this message
Serge (serge-de-souza) wrote :

$ uname -a
Linux 2.6.22-7-generic #1 SMP Mon Jun 25 17:33:14 GMT 2007 i686 GNU/Linux

Revision history for this message
Serge (serge-de-souza) wrote :
Revision history for this message
Bruno (bruno666-666) wrote :

Same problem here. Kubuntu Gutsy.

Linux 2.6.22-7-generic #1 SMP Mon Jun 25 17:33:14 GMT 2007 i686 GNU/Linux

I'm not sure that it's a kernel problem, this seems to occur after an update of initramfs...

Revision history for this message
Bruno (bruno666-666) wrote :
Revision history for this message
Kyle McMartin (kyle) wrote :

Please attach the output of "ifconfig -a" to the bugreport so we can see all your network interfaces. Also, do you have an /etc/mactab file? If so, attach that please.

Revision history for this message
Jérôme Guelfucci (jerome-guelfucci-deactivatedaccount) wrote :

This might be an issue with udev.

Changed in linux-source-2.6.22:
status: Incomplete → New
Revision history for this message
Bruno (bruno666-666) wrote :

Sorry, I didn't mention it.
I have only one Ethernet adapter (basic realtek pci card) connected to a router/DHCP server. I have no /etc/mactab file.

Jérôme : May be there was an update of udev before the problem occurs.

bruno@aboulafia:~$ ifconfig
eth2 Lien encap:Ethernet HWaddr 00:EE:B1:01:57:AE
          inet adr:192.168.100.10 Bcast:192.168.100.255 Masque:255.255.255.0
          adr inet6: fe80::2ee:b1ff:fe01:57ae/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          Packets reçus:49230 erreurs:0 :0 overruns:0 frame:0
          TX packets:30206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:68684800 (65.5 MB) Octets transmis:2729568 (2.6 MB)
          Interruption:11 Adresse de base:0x4000

lo Lien encap:Boucle locale
          inet adr:127.0.0.1 Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          Packets reçus:8 erreurs:0 :0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          Octets reçus:560 (560.0 b) Octets transmis:560 (560.0 b)

Revision history for this message
Kyle McMartin (kyle) wrote :

[ 25.084368] eth0: RealTek RTL8139 at 0xf0814000, 00:ee:b1:01:57:ae, IRQ 11
[ 25.084372] eth0: Identified 8139 chip type 'RTL-8139C'

It was detected as eth0, and subsequently logged as eth2, so someone has renamed it in the intervening time.

Try "grep -r -i "00:ee:b1:01:57:ae" /etc" and see if it finds any files.

Revision history for this message
Kyle McMartin (kyle) wrote :

Please attach the file:

/etc/udev/rules.d/70-persistent-net.rules

to the bug report.

Thanks, Kyle

Revision history for this message
Serge (serge-de-souza) wrote :

$ ifconfig -a

eth2 Link encap:Ethernet HWaddr 00:16:D3:34:B2:88
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
          Base address:0x2000 Memory:ee000000-ee020000

eth3 Link encap:Ethernet HWaddr 00:19:D2:07:01:21
          inet addr:192.168.118.169 Bcast:192.168.118.255 Mask:255.255.255.0
          inet6 addr: fe80::219:d2ff:fe07:121/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
          RX packets:1659 errors:0 dropped:128 overruns:0 frame:0
          TX packets:575 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:626993 (612.2 KB) TX bytes:100812 (98.4 KB)
          Interrupt:21 Memory:edf00000-edf00fff

eth2:avah Link encap:Ethernet HWaddr 00:16:D3:34:B2:88
          inet addr:169.254.7.201 Bcast:169.254.255.255 Mask:255.255.0.0
          UP BROADCAST MULTICAST MTU:1500 Metric:1
          Base address:0x2000 Memory:ee000000-ee020000

irda0 Link encap:IrLAP HWaddr 00:00:00:00
          NOARP MTU:2048 Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:8
          RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

lo Link encap:Local Loopback
          inet addr:127.0.0.1 Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING MTU:16436 Metric:1
          RX packets:171 errors:0 dropped:0 overruns:0 frame:0
          TX packets:171 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:10184 (9.9 KB) TX bytes:10184 (9.9 KB

$ cat /etc/udev/rules.d/70-persistent-net.rules
# PCI device 0x8086:0x1010 (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0d:60:1a:58:ca", NAME="eth0"

# PCI device 0x8086:0x1010 (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:0d:60:1a:58:cb", NAME="eth1"

# PCI device 0x8086:0x109a (e1000)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:16:d3:34:b2:88", NAME="eth2"

# PCI device 0x8086:0x4227 (ipw3945)
SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:19:d2:07:01:21", NAME="eth3"

There is not /etc/mactab file

Revision history for this message
Kyle McMartin (kyle) wrote :

Serge,

That explains why they're being renamed, you can edit the file to do the mapping however you wish.

Changed in linux-source-2.6.22:
assignee: nobody → kyle
status: New → Invalid
Revision history for this message
Serge (serge-de-souza) wrote :

not a kernel bug, I did not modify that file. Assigning to udev

Changed in linux-source-2.6.22:
assignee: kyle → nobody
status: Invalid → New
Revision history for this message
Kyle McMartin (kyle) wrote :

still not a kernel bug, closing kernel task

Changed in linux-source-2.6.22:
status: New → Invalid
Changed in udev:
assignee: nobody → kyle
status: New → Confirmed
Revision history for this message
Kyle McMartin (kyle) wrote :

Confirmed on tribe-2 on a MacBook.

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

This is caused by the ill-advised udev postinst

Revision history for this message
Scott James Remnant (Canonical) (canonical-scott) wrote :

udev (113-0ubuntu2) gutsy; urgency=low

  * Set group of nvram to nvram. LP: #108460.
  * Move udevmonitor to /sbin. LP: #119091.
  * Update shlibs of libvolumeid. LP: #121074.
  * Added rules for infiniband nodes. LP: #124990.
  * Don't seed the initial persistent rules, instead wait for the first
    boot. LP: #123559.

 -- Scott James Remnant <email address hidden> Tue, 10 Jul 2007 17:30:28 +0100

Changed in udev:
status: Confirmed → Fix Released
Revision history for this message
ABANDONED ACCOUNT (abandonedaccount) wrote :
Download full text (3.2 KiB)

The exact same issue exists on Ubuntu Server Edition, however it is quite different on that platform.

There is NO /etc/udev/rules.d/70-persistent-net.rules, the closest thing is "85-ifupdown.rules", but it only defines some default actions to perform whenever an ethernet interface is found, you cannot add your own SUBSYSTEM=="net" rules (as per the bottom of post 11 by Serge for instance).

Instead we have a file called /etc/iftab.

This file is incredibly unintelligent. Why? Because it hardcodes device names to mac addresses, so instead of the first ethernet address getting eth0, it reserves that name for a specific mac address. In effect this means that if you install Ubuntu Server Edition on 1 PC with one Mac address, then move it to PC #2 with a different mac address, then /etc/iftab will be assigning the ethernet interface of that computer to eth1, because eth0 is reserved to the mac address of the OLD computer. That is absolutely ridiculous!

Why is it ridiculous? Well, because /etc/network/interfaces is setup to configure internet access and dhcp on eth0, so if you change computers you are left without network connectivity unless you manually do "dhclient eth1".

I had to spend 3 hours tracking down this issue with lots of help from the people in #linux, and tried everything. I looked at loaded driver modules, I looked at config files everywhere, I edited /etc/network/interfaces. What happened was that while the system was booting it referred to my ethernet device as "eth0", but as soon as the system was finished booting it was suddenly called "eth1".

In the end I had an idea that perhaps eth0 was reserved for my old mac address (on the computer I used when I installed Ubuntu Server Edition on this flash drive). This hadn't occured to me earlier because that is a retarded design, linux is meant to be able to run on different hardware simply by putting the harddrive in another computer, and locking down the eth0 name by mac address is pure stupidity in that regard. Even more so because you're unable to connect to the network by default after moving your usb drive to another computer.

So what I did was navigate to /etc and type grep -R -i "00:16:35:7E:74:69", which is the mac address from PC #1 where I installed Ubuntu from, and got these results:

root@ubuntu:/etc# grep -R -i "00:16:35:7E:74:69"
/etc/iftab:eth0 mac 00:11:2f:92:4a:8d arp 1

I went into that file and put my NEW (PC #2) mac address there, so it looked like this:

root@ubuntu:/etc# cat /etc/iftab
# This file assigns persistent names to network interfaces.
# See iftab(5) for syntax.

eth0 mac 00:16:35:7E:74:69 arp 1

Now my interface is being assigned to eth0 and I get network connectivity right away. I could have solved this by changing /etc/network/interfaces to eth1 instead, but that would have been accepting the problem.

I propose that you remove this /etc/iftab hard-coding, and leave the hard-coding up to the user!

All it serves to do right now is locking down the installation so that you cannot change computers/network interface.

I hope that this is of help to everyone else, it seems like quite a common problem but I had never seen this particular (Ubuntu Server...

Read more...

Revision history for this message
ABANDONED ACCOUNT (abandonedaccount) wrote :

I made a typo in my post, where I said:

grep -R -i "00:16:35:7E:74:69"

I meant:

grep -R -i "00:11:2F:92:4A:8D"

Where the latter was the old mac address from the computer I used when installing Ubuntu Server Edition. I changed this to "00:16:35:7E:74:69" in the file described above.

Revision history for this message
Colin Watson (cjwatson) wrote :

Christopher,

Generation of /etc/iftab has already been removed from the installer for current builds of Gutsy.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.