Hide Forgot
Description of problem: For the past 4 months ago the only network adaptor was named p34p1. 3 days ago I did a yum update which installed an updated biosdevname. Since then the network adaptor is named p2p1. Once I had changed a few user written scripts everything worked fine, so I wasn't too bothered. The ifcfg is still named ifcfg-p34p1 and refers to DEVICE="p34p1". So are 'consistent network device names' only consistent between updates to biosdevname? Version-Release number of selected component (if applicable): biosdevname-0.3.11-1.fc15.x86_64 How reproducible: Always Steps to Reproduce: 1. Boot the machine 2. 3. Actual results: Network device named p2p1 Expected results: Network device named p34p1 Additional info:
Yup, same thing happened to me. I had p4p1 when fedora 15 was installed, got the biosdevname-0.3.11-1.fc15.x86_64 update, and now I have p6p1. I'll attach some dumps of various bits of info I got while running the fedora 15 live CD (which calls the nic p4p1) and running the latest f15 updates (where it is called p6p1).
Created attachment 528397 [details] ifconfig -a from current fedora 15
Created attachment 528398 [details] lspci -v -v from current f15
Created attachment 528399 [details] udevadm info --attribute-walk from current f15
Created attachment 528400 [details] ifconfig -a from f15 live CD
Created attachment 528401 [details] lspci -v -v from f15 live CD
Created attachment 528402 [details] udevadm info --attribute-walk from f15 live CD
Hi, please attach the output of the following - - dmidecode - biosdecode - biosdevname -d - lspci -vvvxxxx - lspci -tv
I observed the same thing on F15 after a "yum update" and reboot a few days ago. My external-facing ethernet port on my main server went from name "em1" to "p10p1". (As an aside, this caused the ethernet to not even be brought up and even after that, there were quite a few config files that needed to have "em1" changed to "p10p1". This is not a minor change that should happen without much fanfair. Luckily I was around when the server rebooted, but it might well have been on autopilot and that would have taken the server off the air.)
Created attachment 528502 [details] dmidecode output
Created attachment 528503 [details] biosdecode output
Created attachment 528504 [details] biosdevname -d output
Created attachment 528506 [details] lspci -vvvxxx output In case it matters, this command also printed the following on stderr: pcilib: sysfs_read_vpd: read failed: Connection timed out
Created attachment 528507 [details] lspci -tv output
(In reply to comment #14) > Created attachment 528507 [details] > lspci -tv output Hi Tom, Thanks for the logs. From the attached 'biosdevname -d' output, the bus info of the adapter is '0000:06:00.0'. Is the adapter an 'onboard' adapter or is it a 'PCI add-in' adapter (if yes, would it be possible to let me know which slot is it plugged into) ? The dmidecode shows type 41 records, but there is no type 41 record for '0000:06:00.0'. Handle 0x006A, DMI type 41, 11 bytes Onboard Device Reference Designation: Onboard LAN Type: Ethernet Status: Enabled Type Instance: 1 Bus Address: 0000:00:19.0 PCI add-in devices are named based on SMBIOS type 9 records. There seems to be no type 9 record for '0000:06:00.0'. If a type 41 and type 9 record is not available, biosdevname falls back on PIRQ table. The attached biosdecode output lists the device '0000:06:00.0' as onboard. Slot Entry 14: ID 06:00, on-board You have mentioned that biosdevname-0.3.8 named the interface as 'p4p1', 0.3.11 names it as 'p6p1'. Just want to make sure, 0.3.8 was naming this adapter correctly, which is 'single port adapter on PCI slot 4'. p4p1 -> PCI slot 4 and port 1 Then it would help isolating what is going on in 0.3.11.
The ethernet port is an onboard port on my ASUS P8H67-V (REV 3.0) motherboard. I could boot the Live CD again and get similar listings from back when it was calling it p4p1 if you want me to. Don't know if it is at all relevant to this problem, but my board also gives the ACPI error described in bug 710720
biosdevname 0.3.11 uses the PCIE slot number (correct #) to determine which slot the card is in. Older versions of biosdevname used the $PIR table only, which was incorrect on many BIOS. The slot numbering scheme in the $PIR table is also inconsistent between vendors.. some have slot 1,2,3, etc others had hex value 34 = decimal '4'. So you may see p3X... change to the correct PCI slot.
Tom, looking at your lspci -vvvxxx output, the parent bus of the Ethernet address claims that it is in PCI slot 6. 00:1c.6 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 7 (rev b5) (prog-if 00 [Normal decode]) ... SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #6, PowerLimit 10.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState+ biosdevname can't be consistent if the information it gets is wrong... that's why I added the PCIE slot code because $PIR was notoriously wrong.
*** This bug has been marked as a duplicate of bug 746422 ***