Description of problem: Bonding wont unload; fails to respect primary=ethX argument in /etc/modprobe.conf on boot. Despite unloading issue, I can make bonding respect a change to the modprobe.conf entry by stopping network (init.d), unloading 8021q, issuing the failed rmmod bonding command, and restarting network. On boot, bonding does not always respect this setting and defaults to eth0. Version-Release number of selected component (if applicable): kernel 2.6.15-1.1831_FC4smp on x86_64 and i686. How reproducible: Consistently. Steps to Reproduce: 1. /etc/init.d/network stop 2. rmmod 8021q; rmmod bonding 3. lsmod Actual results: bonding does not unload (or immediately reloads) Expected results: bonding should unload Additional info: /etc/modprobe.conf: alias eth0 tg3 alias eth1 tg3 alias scsi_hostadapter 3w-xxxx alias usb-controller ohci-hcd alias bond0 bonding alias bond0.121 8021q alias bond0.122 8021q alias bond0.123 8021q options bond0 miimon=100 mode=1 primary=eth1 --- lsmod: Module Size Used by 8021q 57041 0 bonding 103277 0 ipv6 432321 16 parport_pc 65581 1 lp 49025 0 parport 77261 2 parport_pc,lp i2c_dev 46145 0 i2c_core 59457 1 i2c_dev dm_mod 99337 0 video 52553 0 button 41185 0 battery 44233 0 ac 38985 0 ohci_hcd 57565 0 hw_random 39393 0 tg3 140101 0 ext3 179665 17 jbd 100073 1 ext3 raid5 62272 4 xor 39249 1 raid5 raid1 56385 1 3w_xxxx 63969 60 sd_mod 53697 72 scsi_mod 195321 2 3w_xxxx,sd_mod
This problem appears to still be an issue with 2.6.16-1.2069_FC4
[This comment added as part of a mass-update to all open FC4 kernel bugs] FC4 has now transitioned to the Fedora legacy project, which will continue to release security related updates for the kernel. As this bug is not security related, it is unlikely to be fixed in an update for FC4, and has been migrated to FC5. Please retest with Fedora Core 5. Thank you.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
This bug has been mass-closed along with all other bugs that have been in NEEDINFO state for several months. Due to the large volume of inactive bugs in bugzilla, this is the only method we have of cleaning out stale bug reports where the reporter has disappeared. If you can reproduce this bug after installing all the current updates, please reopen this bug. If you are not the reporter, you can add a comment requesting it be reopened, and someone will get to it asap. Thank you.