| Summary: | network device name has changed | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | mcisho | ||||||||||||||||||||||||
| Component: | biosdevname | Assignee: | Narendra K <narendra_k> | ||||||||||||||||||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||
| Version: | 15 | CC: | harald, horsley1953, jordan_hargrave, matt_domsch, mebrown, narendra_k, praveen_paladugu, robatino, wolfgang.rupprecht | ||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||
| Whiteboard: | |||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||
| Last Closed: | 2011-10-18 15:25:15 UTC | Type: | --- | ||||||||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||
|
Description
mcisho
2011-10-15 10:36:14 UTC
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 *** |