*** This bug is a duplicate of bug 1324558 ***
https://bugs.launchpad.net/bugs/1324558
** This bug has been marked a duplicate of bug 1324558
[SRU] biosdevname returns identical names for two different devices.
--
You received this bug notification because you are a member of Ubuntu
I'm seeing the same behavior in 13.10 saucy with some Chelsio cards.
They consistently show up as rename3 and rename4.
Was there any resolution to your situation?
I can supply my logs as well if that would help.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Server configuration:
SuperMicro X9DRi-F mainboard
On-board dual I350 (rev 01) Gigabit Ethernet controller [8086:1521], igb driver
PCI-E X540-AT2 (rev01) 10Gbase-T Ethernet card [8086:1528], ixgbe driver.
bios: Version 2.0a, 03/27/2013
The current situation causes two issues:
1.) The former
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: udev (Ubuntu Raring)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1090002
Title:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: udev (Ubuntu Quantal)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1090002
Title:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: udev (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1090002
Title:
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: linux (Ubuntu Quantal)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1090002
Same problem on two identical machines that have dual 1Gb/s ethernet cards on
the motherboard.
This apparently causes booting to stall for about a minute, see this snippet
from syslog after a boot. These timestamps are
while the machine is booting, and hasn't gotten to the point where it
On 09/27/2013 09:18 AM, Paul Boven wrote:
Same problem on two identical machines that have dual 1Gb/s ethernet cards on
the motherboard.
This apparently causes booting to stall for about a minute, see this snippet
from syslog after a boot. These timestamps are
while the machine is booting,
Hi Narinder,
Well, that's exactly the problem - sometime during the boot, apparently
biosdev thought it was p2p1, and the OS tried to assign the name p2p1 to
it, which it had already given out. When I run biosdev now, it shows up
as being p2p2 allright - but the interface doesn't get assigned the
Yeah we ran this issue with biosdevname developer and after close
examination he told thats the issue with the BIOS firmware where SMBIOS
entry were not proper. When we tried to run this on later HP FW system
we do not see the bug anymore.
Will you please let me know you server configuraiton
Ugh, I also just noticed that this messes up the order of my interfaces
in SNMP - it's swapped the two ones, so now my graphs that used to show
the external interfaces, are showing the internal ones, and v.v.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I think this has something to do with the HP SMBIOS entries.
Incidentally it looks like there is a BIOS bug as Type 9 Slot structures
all point to :00:00.0 (an actual device) not :ff:1f.7 for an
inactive device.
Type 209 lists:
NIC 1: PCI device 04:00.0, MAC address
Both controller ports are NIC types. But i can see the same MAC address
for both NIC iSCSI type of device and it may cause the biosdevname not
to act correctly. Here are the NICs MAC address exposed to the system.
Only option i have here in BIOS is either iSCSI or FCOE for four
embedded ports. I
It looks like those NICs getting renumbered are setup as iSCSI NICs..
can you disable that feature and see if it works properly? Are you
running a VM and remapping/claiming those PCI devices elsewhere?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Would it be possible for you to test the latest upstream kernel? Refer
to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest
v3.7 kernel[0] (Not a kernel in the daily directory) and install both
the linux-image and linux-image-extra .deb packages.
If this bug is fixed in the
can not run the apport-collect on the machine as machine is not on the
network. And proxys are not allowing me to run the same successfully.
there is no crash in the package or utility so i don't think apport will
collect any useful information from the system.
** Changed in: linux (Ubuntu)
** Also affects: udev (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1090002
Title:
biosdevname gives name of device as rename7 in Quantal
To
Stéphane, you mentioned you were able to reproduce this behavior in a
different system with multiple network devices. Can you please follow
up on the udev/biosdevname problem?
** Changed in: udev (Ubuntu)
Importance: Undecided = Medium
** Changed in: udev (Ubuntu)
Assignee: (unassigned)
Hi,
Can you please attach:
- /var/log/syslog
- /var/log/udev
- output of dmesg
- output of ifconfig -a
- /etc/udev/rules.d/70-persistent-net.rules
That last file may be the source of some of your problems. Once you're done
attaching them all, can you try to comment all the entries in
I am attaching the logs you also. also i am attaching the logs of
biosdevname -d which will give you info that biosname of device is
correct. I am seeing 70-persistent-net.rules is empty and rules to
generate the name is in 71-biosdevname.rules which i am attaching. After
commenting the line in
adding debug.tar which we got after running few biosdevname command
during udev.
** Attachment added: debug.tar
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1090002/+attachment/3459417/+files/debug.tar
--
You received this bug notification because you are a member of Ubuntu
Bugs,
You can see the same phenomenon in the tarball that Narinder posted
above.
Here's the em3 definition at the time em1 appeared:
BIOS device: em3
Kernel name: em3
Permanent MAC: 00:17:A4:77:3C:08
Assigned MAC : 00:17:A4:77:3C:08
ifIndex: 4
Driver: be2net
Driver version: 4.2.220u
Firmware version:
Ok, so I've been doing a big of debugging with the help of Narinder.
One thing that I found really quite odd is that the BIOS name to MAC address
mapping isn't static as you'd think.
Instead it appears to change several during the boot sequence.
The list below shows the BIOS name on the left
debug logs for lspci, dmidecode and biosdecode have been attached.
** Attachment added: debuglog.tar
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1090002/+attachment/3459482/+files/debuglog.tar
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
25 matches
Mail list logo
