From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2)
Description of problem:
Whenever a new kernel is installed on any of my 7.3 systems by up2date, the
modules.conf file is changed to use the wrong ethernet driver regardless of
which kernel is defaulted or running.
My Redhat servers are running on very new IBM x335 servers with dual Broadcom
Corporation NetXtreme BCM5703X Gigabit Ethernet cards. The original load of
Redhat configured the tg3 (Tigon3) driver but the proper bcm5700 driver was
included with the systems. For each released kernel I must re-install the proper
driver. However the up2date process (whether it's rpm or whatever behind the
scenes) modifies the /etc/modules.conf file immediately. It also changes the
grub.conf file making the new kernel the default before testing can take place.
With any other product, conf files are installed with a .rpmnew extension and a
warning message is issued. Wouldn't this be a better way? Shouldn't the sysadmin
be given a chance to specifically select a new kernel at boot time, and then
manually change the default once testing has taken place?
Allowing these changes to take place in this manner causes a production system
to be exposed from the time a kernel install takes place and the time needed
drivers can be installed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. find a system where non-standard drivers must be added to the kernel
2. run up2date from an entitled system
3. examine /etc/modules.conf and /boot/grub.conf
Actual Results: Both files were modifed. My tailoring to modules.conf was
changed so that eth0 and eth1 were aliased to tg3 instead of bcm5700. The
grub.conf file was pointing to the new kernel.
Expected Results: Create /etc/modules.conf.rpmnew and /boot/grub.conf.rpmnew
instead of changing production configurations. Issue message to sysadmin
informing them of new files.
My system gets flakey when wrong ethernet driver gets installed. It's taken me
about 3 kernel releases to 1) understand the proper way to get bcm5700 installed
properly each time on this hardware platform; 2) to figure out the reason it
wasn't working the first time wasn't all my fault.
sounds like a kernel packaging issue, reassing to the kernel component
This is the intended behavior: tg3 is intentionally selected over bcm5700.