Description of problem: After update of biosdevname networking wont start Version-Release number of selected component (if applicable): biosdevname-0.3.11-1.fc15.x86_64 How reproducible: 100% Steps to Reproduce: 1.update biosdevname 2.reboot 3. Actual results: Starting LSB: Bring up/down networking ESC[1;31mfailedESC[0m, see 'systemctl status network.service' for details. network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network) Active: failed since Sat, 15 Oct 2011 12:13:13 -0400; 9min ago Process: 1107 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/network.service Expected results: network to start and connect Additional info: Not sure how to troubleshoot this or what additional information is needed. I can proved whatever is requested. downgrading back to biosdevname-0.3.8-1.f15.x86_64 return network functionality.
Hi, please attach the output of the following from your system - - dmidecode - biosdecode - biosdevname -d - lspci -vvvxxxx - lspci -tv
Created attachment 528570 [details] dmidecode.txt
Created attachment 528584 [details] biosdevcode.txt Sorry for the spam, if there is a way to attach multiple files I couldn't figure it out.
Created attachment 528585 [details] lspci-vvvxxxx.txt
Created attachment 528586 [details] lspci-tv.txt
Created attachment 528595 [details] biosdevname.txt sorry, forgot one. I noticed that device is listed as p6p1 in this file, where as before it has always been p23p1.
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.
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. Can you provide output of lspci -vvvxxx
Created attachment 528621 [details] lspci-vvvxxx.txt
According to lspci, the parent bridge of the Ethernet controller (00:1c.6) lists Slot Capabilities field as valid, with Slot#6 listed... so your system is not following the PCI specification properly if that is really an embedded device.
Looking at biosdecode the old $PIR table had '23' for PCI device 7:0:0. According to lspci the device is in slot #6. So that is why the slot number changed. Is the device really in slot#6?
The motherboard is: MSI P67A-G45 (B3) LGA 1155 Intel P67 SATA 6Gb/s USB 3.0 ATX with Onboard Realtek 8111E chipset Is the device really in slot#6? Have no real understanding of how it gets that #, I can't say it is or isn't.
*** Bug 746393 has been marked as a duplicate of this bug. ***
*** Bug 745752 has been marked as a duplicate of this bug. ***
having a look at the other bug reports, one mentions that the ifcfg-<device> file didn't change yet the networking kept working, the other report is the same issue as myself, no networking. Something I didn't think of before was to check and see if the ifcfg-<device> file is created after updating to 0.3.11-1. I updated to 0.3.11-1 just now and it is not created. No networking. I edited and renamed my old ifcfg-p23p1 (in my case) to ifcfg-p6p1 and everything works as expected. Was the update supposed to edit/create a ifcfg-<device> file with the new name? And if not, how should it work without that edited/created file?
This struck me as well. I upgraded biosdevname on the 18th: Oct 18 09:48:15 Updated: biosdevname-0.3.11-1.fc15.x86_64 I logged in today to find no interfaces; a reboot solved nothing :). I checked dmesg and it noted that: [ 8.190173] udev[386]: renamed network interface eth1 to p6p1 [ 8.200187] udev[384]: renamed network interface eth0 to p5p1 So I edited /etc/sysconfig/network-scripts/ifcfg-em1: DEVICE="em1" -> DEVICE="p5p1" And was on my way. This is an IBM xSeries 306m server with dual onboard NICs. The above-requested information is forthcoming in an attachment.
Created attachment 530182 [details] Combined Output All output stored in one file for quick upload/access. dmidecode : @Line 4 biosdecode : @Line 433 biosdevname -d : @Line 484 lspci -vvvxxxx : @Line 511 lspci -tv : @Line 3479
Created attachment 530632 [details] Combined output with 0.3.8-1 installed
Created attachment 530634 [details] Combined output with 0.3.11-1 installed I have a similar experience on a Fujitsu TX150 S7. Devices were renamed em1 => p7p1 p4p1 => p4p1 p5p1 => p4097p1 on update to 0.3.11-1 Obviously it broke quite some bits in the system, as iptables, dhcp, etc. relies on the device names. The interfaces themselves did come up, as NetworkManager relies on UUIDs and not device names, but iptables couldn't recognise the names, and with a default DROP policy, it made the system inaccessible in effect. I have attached combined outputs with either version installed. NOTE: The system were booted with 0.3.8-1, and I updated to 0.3.11-1 and generated output without rebooting, in case that might be important.
*** Bug 746951 has been marked as a duplicate of this bug. ***
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping