Bug 699146

Summary: /etc/rc.d/init.d/network fails -- pci6p1/pci6p2 network interfaces and all external networking unavailable (virtual networks OK))
Product: [Fedora] Fedora Reporter: Nathan Watson <nfwatson>
Component: biosdevnameAssignee: Narendra K <narendra_k>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: amcnabb, gansalmon, harald, itamar, jonathan, jordan_hargrave, kernel-maint, ls, madhu.chinakonda, matt_domsch, mebrown, narendra_k, praveen_paladugu
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 20:26:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Nathan Watson 2011-04-23 15:24:23 UTC
Description of problem:

After "yum update" on 2011/04/22 approx 10pm PDT for Fedora 15 x86_64,
originally installed as Alpha, networking now fails to restart.  On boot
get error visible with "norhgb" parameter:

  Bring up/down networking failed, see 'systemctl status network.service' for details.
  
... and after checking suggested command ...

  prompt# systemctl status network.service
  Loaded:  loaded (/etc/rc.d/init.d/network)
  Active:  failed since ...
  Process:  1145 ExecStart=/etc/rc.d/init.d/network (code=exited, status=1/FAILURE)


Version-Release number of selected component (if applicable):

  Fedora 15 Alpha (probably been upgraded to Beta packages, that's part of the problem
  I believe).  kernel-2.6.38.2-9.fc15.x86_64

How reproducible:

  After "yum update" always reproducible.  Will try booting older kernel as well.

Steps to Reproduce:
1. Install Fedora 15 Alpha x86_64
2. keep reasonably up-to-date with "yum update" till 2011/04/12
3. run "yum update" on 2011/04/22
  
Actual results:

  no external networking available.  pci6p1/pci6p2 network devices not accessible.
  virtual networking seems to work OK.

Expected results:

  networking should work.

Additional info:

  it's hard to get data out of the machine, no networking, will try to get copy of dmesg output.

NOTE:  'kernel' is best guess as I believe interaction between networking svcs and kernel
is tight.  I'll try previously installed kernel version to see whether problem happens again.

Comment 1 Nathan Watson 2011-04-23 15:35:35 UTC
Well, kernel wasn't actually upgraded on 2011/04/22, last upgrade for that
was 2011/04/04.

Comment 2 Nathan Watson 2011-04-23 16:27:40 UTC
A few more experiments:

  * booting on machine from  Fedora-15-Beta-x86_64-Live-Desktop.iso and running
     system-config-network-tui leads to NO NETWORK INTERFACES being shown
  * booting on machine from Fedora 15 Alpha original install DVD (sorry, don't remember
     exactly whether I used Everything-1/2 or Install and entering RESCUE MODE
     and choosing to configure network devices leads to ALL NETWORK DEVICES
     showing up, both pci6p1/pci6p2

It appears ....:

  * EITHER:  the F15 Beta x86_64 LiveCD doesn't include support for my particular
     server network cards ...
  * OR, more likely I guess:  the network hardware I have agrees with F15 Alpha
     builds but neither the Beta F15 LiveCD nor recent upgrades to F15 from
     repositories can deal well with the network hardware I have

Comment 3 Nathan Watson 2011-04-23 16:36:16 UTC
On last comment, I was confused ... the Everything-1/2 or Install DVD's are from
Scientific Linux 6.  This machine is definitely F15, and was originally installed from
 Fedora-15-Alpha-x86_64-DVD.iso

Comment 4 Lars Seipel 2011-04-23 21:19:02 UTC
I got hit by this, too. It isn't caused by any kernel update, though. Putting a device under NetworkManager control restores connectivity but breaks bridging setups of course.

ifup failed with:
ifup-eth: Device pci37p1 does not seem to be present, delaying initialization.

So I went through the changelogs of any related packages that got updated and found the offender in the recent update to biosdevname. biosdevname-0.3.8-1.fc15.x86_64 includes this change:
- Change pciX to pX for shortened names for PCI add-on devices

Adjusting the files in /etc/sysconfig/network-scripts/ to the new nomenclature fixes the problem.

Comment 5 Matt Domsch 2011-04-24 03:50:54 UTC
Yes, the names changed, and config files with the 'pciX' name from previous versions of biosdevname will have to be adjusted.  Hopefully this is the last name change, better to do it now before release than after.

Comment 6 Nathan Watson 2011-04-25 17:23:30 UTC
A couple of hours after filing this bug I decided to install F15 Beta x86_64 to see whether that would fix the problem (the machine is my virtualization host + firewall + DNS server so there's no critical data attached and config is always safely backed up, easy to reconfigure).

After installing the F15 Beta I notice:

  [root@porta01 network-scripts]# pwd
  /etc/sysconfig/network-scripts
  [root@porta01 network-scripts]# ls -ltr
  total 220
  ...
  -rw-r--r--. 3 root root   119 Apr 23 10:47 ifcfg-pci6p2
  -rw-r--r--. 3 root root   229 Apr 23 10:49 ifcfg-pci6p1
  ...
  [root@porta01 network-scripts]# 
  [root@porta01 network-scripts]# ifconfig
  lo        Link encap:Local Loopback  
  ...

  p6p1      Link encap:Ethernet  HWaddr 00:30:48:7A:03:B8  
  ...

  p6p2      Link encap:Ethernet  HWaddr 00:30:48:7A:03:B9  
  ...

  virbrN
  ...


The ifcfg-NAME doesn't match the names given in ifconfig, yet everything still works.  Is this expected behavior I can rely on in the future or is another trip to the colo in my future?

Comment 7 Nathan Watson 2011-04-25 17:25:50 UTC
BTW, immediately after installing F15 beta x86_64 on Saturday (2011/04/23) I did "yum update" but only after configuring network interfaces with "system-config-network-tui".

Comment 8 Narendra K 2011-04-29 11:36:44 UTC
(In reply to comment #6)
> A couple of hours after filing this bug I decided to install F15 Beta x86_64 to
> see whether that would fix the problem (the machine is my virtualization host +
> firewall + DNS server so there's no critical data attached and config is always
> safely backed up, easy to reconfigure).
> 
> After installing the F15 Beta I notice:
> 
>   [root@porta01 network-scripts]# pwd
>   /etc/sysconfig/network-scripts
>   [root@porta01 network-scripts]# ls -ltr
>   total 220
>   ...
>   -rw-r--r--. 3 root root   119 Apr 23 10:47 ifcfg-pci6p2
>   -rw-r--r--. 3 root root   229 Apr 23 10:49 ifcfg-pci6p1
>   ...
>   [root@porta01 network-scripts]# 
>   [root@porta01 network-scripts]# ifconfig
>   lo        Link encap:Local Loopback  
>   ...
> 
>   p6p1      Link encap:Ethernet  HWaddr 00:30:48:7A:03:B8  
>   ...
> 
>   p6p2      Link encap:Ethernet  HWaddr 00:30:48:7A:03:B9  
>   ...
> 
>   virbrN
>   ...
> 
> 
> The ifcfg-NAME doesn't match the names given in ifconfig, yet everything still
> works.  Is this expected behavior I can rely on in the future or is another
> trip to the colo in my future?

Hi Nathan,

If i understand correctly, first you installed F15 Beta and then did 'yum update' with repo pointing to rawhide. 'biosdevname' pakage version is right now 0.3.8. Is this correct ?

If this is correct, then since the installation was done using F15 Beta, F15 beta has biosdevname-0.3.7 where the PCI add-on interface naming is 'pciXpY'. So installer would have created corresponding 'ifcfg-pciXpY' files. And after yum update + reboot, the interfaces received new names such as pXpY.

I suppose when biosdevname-0.3.8 gets into F15 builds, then the installer would create ifcfg-pXpY files.

You could rename your ifcfg-pciXpY files to ifcfg-pXpY form and the DEVICE= field in these files accordingly.

Please let me know if i am missing something.

Comment 9 Andrew McNabb 2011-04-29 20:05:01 UTC
(In reply to comment #5)
> Yes, the names changed, and config files with the 'pciX' name from previous
> versions of biosdevname will have to be adjusted.  Hopefully this is the last
> name change, better to do it now before release than after.

This means that upgrading from Fedora 15 Beta to Fedora 15 will break for all users, right?

Comment 10 Matt Domsch 2011-04-30 03:58:47 UTC
I believe so, yes.  I've added this text to the release notes.

Upgrading from an earlier version of Fedora (including 15-Alpha or -Beta) to Fedora 15 may result in a change of network device names from an earlier biosdevname naming scheme to the final naming scheme described here. Configuration files must be manually adjusted accordingly.

Comment 11 Andrew McNabb 2011-04-30 04:42:00 UTC
Shouldn't this probably be announced loudly on fedora-devel?

Comment 12 Fedora Admin XMLRPC Client 2011-05-02 15:57:44 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 13 Fedora End Of Life 2012-08-07 20:26:14 UTC
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