Bug 880451

Summary: create bonding device other than bond0 properly
Product: [Fedora] Fedora Reporter: Dave Young <ruyang>
Component: dracutAssignee: dracut-maint
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: amwang, bhe, chaowang, dracut-maint, jonathan
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-22 03:02:50 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:
Attachments:
Description Flags
Proposed patch none

Description Dave Young 2012-11-27 02:50:46 UTC
Description of problem:

Below is a discussion about bonding device creation issue:

> > Amerigo? Can you help answer this question? How does dracut handle the
> > multiple bond device issue? bonding kernel module by default add create
> > bond device, how does it enable bondX other than bond0?
> > 
The first kernel pass bond=bondX:ethX... to the 2nd kernel via cmdline,
so the 2nd kernel has to handle this, but seems we miss

echo +$BOND_MASTER>  /sys/class/net/bonding_masters

too.


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


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Harald Hoyer 2012-11-29 15:53:50 UTC
Created attachment 654378 [details]
Proposed patch

proposed untested patch

Comment 3 Dave Young 2012-12-03 07:07:59 UTC
Hello Harald

There's a issue with your patch.
According to current code:

uevent(bond0) -> ifup bond0
                      (echo +bond1 > bond_master happens in ifup code)

ifup bond1 callback depends on bond1 device existing. So there's no chance to create the bond1 at the end.

A reasonable solution is like below:

1) parsing cmdline to find out how many bond device is specified.
2) create a modprobe.d/bond.conf to specify the max_bonds param for bonding.ko
3) consider bonding dev name could be anything other than bondX, for example there's ifname=bondabc ifname=bonddef, we can map them as bondabc->bond0 bonddef->bond1.


3) is a corner case, we could handle it later and firstly only work on 1) and 2)

What do you think?

--
Thanks 
dave

Comment 4 Dave Young 2012-12-12 05:12:21 UTC
Update:

Please ignore comment #3, your patch is ok in fact. Because of the link delay issue bond testing depends on my "link waiting" patch series, but my patch 5/6 wrongly use -n $IFACES instead of -z $IFACES. After fixing my patch your patch passed the test.

But there's still one issues, currently parse-bond only create one bond.*.info file, this means only one bond device will be brought up. I'm not sure it's necessary to support multiple bond devices at the same time.

Comment 5 Baoquan He 2012-12-12 05:28:17 UTC
(In reply to comment #4)

> 
> But there's still one issues, currently parse-bond only create one
> bond.*.info file, this means only one bond device will be brought up. I'm
> not sure it's necessary to support multiple bond devices at the same time.

Currently parse-bond only process one bond, but it works well right now. Maybe we can think about it later when multiple bonds are required.

Comment 6 Fedora End Of Life 2013-04-03 14:40:26 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19