Bug 902900

Summary: network scripts: don't print an error if slave device is already enslaved in the correct bridge
Product: Red Hat Enterprise Linux 6 Reporter: David Jaša <djasa>
Component: initscriptsAssignee: Lukáš Nykrýn <lnykryn>
Status: CLOSED INSUFFICIENT_DATA QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.4CC: vpavlin
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-09 15:05:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description David Jaša 2013-01-22 16:54:39 UTC
Description of problem:
network scripts: don't print an error if slave device is already enslaved in the correct bridge

Version-Release number of selected component (if applicable):
initscripts-9.03.38-1.el6.x86_64

How reproducible:


Steps to Reproduce:
1. service NetworkManager stop ; service network stop
2. configure a bridge br0 with ONBOOT=yes and enslaved physical device eth0
3. service network start
4. service network restart
  
Actual results:
in the middle of restart, this message is printed:
> eth0:  device eth0 is already a member of a bridge; can't enslave it to bridge br0.

Expected results:
network-scripts can see that eth0 is correctly enslaved to br0 so there is no need to print the error

Additional info:

Comment 1 Václav Pavlín 2013-01-23 12:17:37 UTC
Hi,

I followed your steps to reproduce on clean install of RHEL 6.4 and 6.3 but this error never occured. Can you provide your ifcfg scripts?

Command "service network restart" performs "network stop" and "network start". After "network stop" br0 is removed, so eth0 cannot be already enslaved on the start call.

Comment 2 David Jaša 2013-04-09 15:05:54 UTC
Hi, I hit the behaviour when I was testing bridges in NM so the problem may have been caused by some NM/network-scripts interference as I didn't hit it after on machines using just one or the other exclusively, so I'm closing the bug.