Bug 159159

Summary: /boot/kernel.h contains wrong #define's for athlon smp system
Product: Red Hat Enterprise Linux 3 Reporter: Trevin Beattie <trevin>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED NEXTRELEASE QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-06-01 15:53:06 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:
Bug Depends On:    
Bug Blocks: 156320    

Description Trevin Beattie 2005-05-30 20:30:43 UTC
Description of problem:
A bug in /sbin/mkkerneldoth causes the wrong architecture to be written in
/boot/kernel.h.

On line 7, a sed expression is supposed to strip the build type (smp, hugemem,
etc.) from 'uname -r' to get the name of the kernel rpm.  However, the
expression is incorrect, resulting in a name that 'rpm -q' can't find. 
Therefore on line 9 the script falls back on 'uname -m' to get the kernel
architecture.  This is incorrect on athlon systems, because 'uname -m' reports
"i686", which is a different kernel build.

This causes problems when building 3rd-party LKM's, because they link to the
wrong kernel symbols (or rather, the symbols for the wrong kernel).


Version-Release number of selected component (if applicable):
I've verified that this bug still exists in initscripts-7.31.22.EL-2, released
just two weeks ago.


How reproducible:
Always.


Steps to Reproduce:
1. Boot with kernel-smp-2.4.*.athlon.rpm
2. Look at /boot/kernel.h

  
Actual results:
/* This file is automatically generated at boot time. */
#ifndef __BOOT_KERNEL_H_
#define __BOOT_KERNEL_H_

/* Kernel type i686-smp */

#ifndef __MODULE_KERNEL_i686
#define __MODULE_KERNEL_i686 1
#endif

#ifndef __BOOT_KERNEL_ENTERPRISE
#define __BOOT_KERNEL_ENTERPRISE 0
#endif

#ifndef __BOOT_KERNEL_BIGMEM
#define __BOOT_KERNEL_BIGMEM 0
#endif

#ifndef __BOOT_KERNEL_HUGEMEM
#define __BOOT_KERNEL_HUGEMEM 0
#endif

#ifndef __BOOT_KERNEL_SMP
#define __BOOT_KERNEL_SMP 1
#endif

#ifndef __BOOT_KERNEL_UP
#define __BOOT_KERNEL_UP 0
#endif

#endif


Expected results:
/* This file is automatically generated at boot time. */
#ifndef __BOOT_KERNEL_H_
#define __BOOT_KERNEL_H_

/* Kernel type athlon-smp */

#ifndef __MODULE_KERNEL_athlon
#define __MODULE_KERNEL_athlon 1
#endif

#ifndef __BOOT_KERNEL_ENTERPRISE
#define __BOOT_KERNEL_ENTERPRISE 0
#endif

#ifndef __BOOT_KERNEL_BIGMEM
#define __BOOT_KERNEL_BIGMEM 0
#endif

#ifndef __BOOT_KERNEL_HUGEMEM
#define __BOOT_KERNEL_HUGEMEM 0
#endif

#ifndef __BOOT_KERNEL_SMP
#define __BOOT_KERNEL_SMP 1
#endif

#ifndef __BOOT_KERNEL_UP
#define __BOOT_KERNEL_UP 0
#endif

#endif


Additional info:
See bug #159098 for a description of sed's behavior.  (It's not a sed bug; it's
a mkkerneldoth bug.)

The bug can be fixed by changing the expression delimiter from '|' to (almost)
any other character, such as '_' (which would be consistent with lines 5 and 11).

--- mkkerneldoth.orig   2003-08-08 12:09:41.000000000 -0700
+++ /sbin/mkkerneldoth  2005-05-29 12:22:49.000000000 -0700
@@ -4,7 +4,7 @@
 #
 
 KERNEL_TYPE=`uname -r | sed
's_^.*\(smp\|enterprise\|bigmem\|hugemem\)$_-\1_;t;s_.*__;'`
-KERNEL_RELEASE=`uname -r | sed 's|smp\|enterprise\|bigmem\|hugemem||g'`
+KERNEL_RELEASE=`uname -r | sed 's_smp\|enterprise\|bigmem\|hugemem__g'`
 
 rpm -q kernel$KERNEL_TYPE-$KERNEL_RELEASE >/dev/null 2>&1 && KERNEL_ARCH=`rpm
-q --qf '%{ARCH}' kernel$KERNEL_TYPE-$KERNEL_RELEASE 2>/dev/null` ||
KERNEL_ARCH=`uname -m`

Comment 1 Bill Nottingham 2005-05-31 00:39:50 UTC
What version of sed do you have installed? This doesn't exhibit the behavior you
describe with sed-4.0.7-3 (i.e., the stock RHEL 3 sed.)

Comment 2 Trevin Beattie 2005-06-01 07:04:36 UTC
sed-4.1.2; I've been upgrading various parts of the system.  Regardless, don't
you think it would be a good idea to alter the expression to be compatible
across all versions of sed?  You and Jakub can hash it out.


Comment 3 Bill Nottingham 2005-06-01 15:53:06 UTC
Well, it's just that a fix is much less of a critical need if it will never
happen with the software we ship, and the code isn't in later releases.

It's changed in CVS; it may or may not go out in an update at some point.