[Bug 1284043] Re: udev renaming the same hardware network i/f to different name, breaks networking and firewall

Tom van Leeuwen 1284043 at bugs.launchpad.net
Tue Apr 1 09:12:57 UTC 2014


*** This bug is a duplicate of bug 1293633 ***
    https://bugs.launchpad.net/bugs/1293633

I don't feel this bug report is a duplicate of bug #1293633. I may very
well fail to see the relation, but please enlight me then :-)

I've just installed 14.04 beta2 and setup a bond0 interface. After a
reboot the server came online but the bond missed an interface because
it was not existing.

I dumped the ifconfig information and rebooted. After a reboot ifconfig showed different devices.
Pre reboot:
bond0     Link encap:Ethernet  HWaddr 68:b5:99:77:c5:8c  
em1       Link encap:Ethernet  HWaddr 68:b5:99:77:c5:8c  
em3       Link encap:Ethernet  HWaddr 68:b5:99:77:c5:92  
lo        Link encap:Local Loopback  
p2p1      Link encap:Ethernet  HWaddr 00:9c:02:3c:b0:40  
p3p1      Link encap:Ethernet  HWaddr 1c:c1:de:7b:b5:e0  
p3p2      Link encap:Ethernet  HWaddr 1c:c1:de:7b:b5:e2  
rename3   Link encap:Ethernet  HWaddr 68:b5:99:77:c5:8e  
rename4   Link encap:Ethernet  HWaddr 68:b5:99:77:c5:90  
rename9   Link encap:Ethernet  HWaddr 00:9c:02:3c:b0:44  

Post reboot:
bond0     Link encap:Ethernet  HWaddr 68:b5:99:77:c5:8c  
em1       Link encap:Ethernet  HWaddr 68:b5:99:77:c5:8c  
em3       Link encap:Ethernet  HWaddr 68:b5:99:77:c5:90  
em4       Link encap:Ethernet  HWaddr 68:b5:99:77:c5:92  
lo        Link encap:Local Loopback  
p2p1      Link encap:Ethernet  HWaddr 00:9c:02:3c:b0:40  
p2p2      Link encap:Ethernet  HWaddr 00:9c:02:3c:b0:44  
p3p1      Link encap:Ethernet  HWaddr 1c:c1:de:7b:b5:e0  
rename3   Link encap:Ethernet  HWaddr 68:b5:99:77:c5:8e  
rename7   Link encap:Ethernet  HWaddr 1c:c1:de:7b:b5:e2  

The installation I did:
ubuntu-14.04-beta2-server-amd64.iso
choose openssh in the package selection

Afterwards I installed ifenslave-2.6 and did an apt-get dist-upgrade.
That's it.

Please note this is not an April's fool joke :-)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1284043

Title:
  udev renaming the same hardware network i/f to different name, breaks
  networking and firewall

Status in “systemd” package in Ubuntu:
  Confirmed

Bug description:
  My installation of Ubuntu Server 14.04 is bare metal (no
  virtualisation). The hardware box contains 3 network interfaces, one
  broadcom (not yet used) and two intel (actually one PCIe network card
  with 2 ports, one is currently used).

  The MAC address of the intel network card is not changed, it is the
  "stock" MAC address. When installing Ubuntu, I choose the interface
  p1p2 from the Intel network card as default (and only) network
  interface. This is the only port at the moment with an Ethernet cable.

  Last Friday I got my Btrfs filesystem corrupted, I had to do a hard
  reset. I thereafter upgraded to the latest kernel version (3.13.0-11,
  but was 3.13.0-8 before the crash). I do not know if this is something
  related but since then when rebooting I have no network. The reason
  being that udev decides to rename eth1 (the 2nd port of the intel
  card) to rename4 instead of p1p2. The problem is that my
  /etc/network/interfaces as only p1p2 configured, no rename4, this
  means that booting is slowed down because Ubuntu waits for p1p2 to
  "appear" but it won't happen as udev decide on a different naming. And
  once finally booted, ifconfig only reports the loopback interface, of
  course rename4 is not configured. Now after a power cycle or simply a
  reboot, sometimes udev switch back to the expected network naming so
  p1p2.

  As a work around I had declared both p1p2 and rename4 in my interfaces
  configuration file, using the same settings for both. I had to
  duplicate the firewall rules so that they could be applied to either
  interfaces. The problem is that it is slowing the boot process (it is
  waiting 60 seconds to try to configure all network interfaces) and
  obviously I am ending up with either p1p2 or rename4 but not both, so
  each boot I have to wait.

  I discarded the work around and only have p1p2 configured now and I am
  rebooting the machine when rename4 is "selected" by udev (rebooting
  until I get p1p2).

  Note: it is possible that the problem was present since the beginning,
  but I almost did not reboot the system between the installation and
  the kernel update last Friday, so I cannot tell for sure if this was
  not existing already. Furthermore, I have tried also kernel 3.14-rc3
  and I also have the problem. Finally, /var/log/dpkg.log does not
  report any udev update since initial installation.

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: udev 204-5ubuntu11
  ProcVersionSignature: Ubuntu 3.13.0-11.31-generic 3.13.3
  Uname: Linux 3.13.0-11-generic x86_64
  ApportVersion: 2.13.2-0ubuntu5
  Architecture: amd64
  Date: Mon Feb 24 09:58:57 2014
  InstallationDate: Installed on 2014-02-09 (14 days ago)
  InstallationMedia: Ubuntu-Server 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140208)
  MachineType: HP ProLiant MicroServer
  ProcEnviron:
   LANGUAGE=en_GB:en
   TERM=screen
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.13.0-11-generic root=UUID=d06b8dd1-fc10-45c9-a04b-3a303d8ccf58 ro rootflags=subvol=@ nomdmonddf nomdmonisw
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/29/2011
  dmi.bios.vendor: HP
  dmi.bios.version: O41
  dmi.chassis.type: 7
  dmi.chassis.vendor: HP
  dmi.modalias: dmi:bvnHP:bvrO41:bd07/29/2011:svnHP:pnProLiantMicroServer:pvr:cvnHP:ct7:cvr:
  dmi.product.name: ProLiant MicroServer
  dmi.sys.vendor: HP

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1284043/+subscriptions



More information about the foundations-bugs mailing list