[Bug 1284043] Re: udev renaming the same hardware network i/f to different name, breaks networking and firewall
Spike
spike at drba.org
Tue Dec 13 20:02:19 UTC 2016
just to add a data point:
Contrary to most ppl who posted so far I have Supermicro hardware, not
HP and still see the same issue. This is happening on ubuntu xenial
16.04, both with a server install CD but also an installed system if I
pull a disk from another server. In neither case I have biosdevname
installed.
The interesting/funny/annoying this is that two very similar supermicro
machines with the same intel i350 card work just fine. On the box where
it breaks you can see from udev that the names selected where indeed
conflicting:
P: /devices/pci0000:00/0000:00:1c.0/0000:06:00.0/net/rename2
E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:06:00.0/net/rename2
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=I350 Gigabit Network Connection
E: ID_MODEL_ID=0x1521
E: ID_NET_DRIVER=igb
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp6s0f0
--
P: /devices/pci0000:00/0000:00:1c.0/0000:06:00.1/net/rename3
E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:06:00.1/net/rename3
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=I350 Gigabit Network Connection
E: ID_MODEL_ID=0x1521
E: ID_NET_DRIVER=igb
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp6s0f1
--
P: /devices/pci0000:00/0000:00:1c.0/0000:06:00.2/net/eno1
E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:06:00.2/net/eno1
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=I350 Gigabit Network Connection
E: ID_MODEL_ID=0x1521
E: ID_NET_DRIVER=igb
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp6s0f2
--
P: /devices/pci0000:00/0000:00:1c.0/0000:06:00.3/net/rename5
E: DEVPATH=/devices/pci0000:00/0000:00:1c.0/0000:06:00.3/net/rename5
E: ID_BUS=pci
E: ID_MODEL_FROM_DATABASE=I350 Gigabit Network Connection
E: ID_MODEL_ID=0x1521
E: ID_NET_DRIVER=igb
E: ID_NET_LINK_FILE=/lib/systemd/network/99-default.link
E: ID_NET_NAME_ONBOARD=eno1
E: ID_NET_NAME_PATH=enp6s0f3
Notice that for all of them ID_NET_NAME_ONBOARD=eno1 . This is correct
from systemd perpsective since there is one card on this box and it's
onboard. /lib/systemd/network/99-default.link does indeed specifty
onboard before path which means all cards would end up being called
eno1. Since this can't be true, the first one gets eno1, which is the
case, and the remainder get renamed to "renameX".
On the boxes where this works it turns out that the ID_NET_NAME_ONBOARD
is not set. Why that's the case I don't get it, it's almost the same
mobo and definitely with the same onboard NIC... but that's why. I tried
to change the order in /lib/systemd/network/99-default.link but for some
reason that didn't help.
hope that helps someone,
Spike
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to biosdevname 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 biosdevname 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/biosdevname/+bug/1284043/+subscriptions
More information about the foundations-bugs
mailing list