Bug 92324

Summary: Kernel install effects modules.conf and grub.conf files
Product: [Retired] Red Hat Linux Reporter: Mike Cooling <cooling>
Component: kernelAssignee: Jeff Garzik <jgarzik>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.3CC: gafton, mihai.ibanescu, peterm
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-08-05 19:38:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mike Cooling 2003-06-04 23:51:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2)
Gecko/20030208 Netscape/7.02

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):
2.8.39-1.7.3

How reproducible:
Always

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.

Additional info:

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.

Comment 1 Adrian Likins 2003-06-11 19:42:59 UTC
sounds like a kernel packaging issue, reassing to the kernel component

Comment 2 Jeff Garzik 2003-08-05 19:38:27 UTC
This is the intended behavior:  tg3 is intentionally selected over bcm5700.