Bug 80461

Summary: "make xconfig" selects wrong default config file
Product: [Retired] Red Hat Linux Reporter: Robert P. J. Day <rpjday>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: low Docs Contact:
Priority: low    
Version: 8.0CC: seapwc
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-09-30 15:40:19 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 Robert P. J. Day 2002-12-26 20:38:20 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
  In the kernel source tree directory, the file
.../scripts/Makefile has (at least) two errors.

1) inconsistency in usage of "KERNTYPE" versus "KERNELTYPE"

2) the condition
   
   if [ -f configs/*-$KERNTYPE.config ]; then

   will not find the matching config file in the configs/
   directory.  i'm not sure what is going on here, but there's
   something about the if construct in bash that is just
   not processing that variable expansion correctly.

   if you run "make xconfig", you'll see in the final output
   a test against "ERNTYPE", as if the $K is being parsed
   as ${K}ERNTYPE.  if you edit that file with the default vim
   color settings, you'll see what i mean -- the K is blue,
   while the rest of the variable name is black.  (what's up
   with that?)

   in any event, if you don't have an initial .config file,
   that conditional will not find a perfectly appropriate
   config file in configs/, but will always use the file
   .../arch/i386/defconfig instead.

   not a fatal error, just misleading.

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


How reproducible:
Always

Steps to Reproduce:
1. look at scripts/Makefile
2. run "make xconfig" with no initial .config file, and see
the output when you exit
3.
    

Actual Results:  incorrect initial config file is selected for .config

Expected Results:  the file under the configs/ directory should be selected

Additional info:

Comment 1 Miloslav Trmac 2002-12-26 23:12:39 UTC
The $KERNTYPE is expanded by make, which has a different syntax for
references of variables with multicharacter names ($(KERNTYPE) or ${KERNTYPE}).
In this case though, KERNTYPE is a shell variable, so it should be $$KERNTYPE.

Found both in vanilla RHL 8.0 and Phoebe (kernel-2.4.20-2.2)

Comment 2 Paul Campbell 2003-01-09 01:29:36 UTC
I get this error even though I have a .config file in 
/usr/src/linux-2.4 and in /usr/src/linux-2.4/configs

Comment 3 Paul Campbell 2003-01-11 21:59:04 UTC
Eureka - I solved it!

make xconfig has a dependency on wish 
which requires tk to be installed
which requires tcl to be installed.

Do you want to add a dependency to kernel-sources,
that tk and tcl must be installed?

I don't know RH procedure, even though this is a low,
it should be an easy fix. 
I bet this is also in the new beta!

Here is the error:
wish -f scripts/kconfig.tk
make: wish: Command not found
make: *** [xconfig] Error 127

I installed tcl/tk and it started up.

Both 7.3 and 8.0 have that funny ERNEL stuff but 
it doesn't matter that is NOT the problem.

Comment 4 Robert P. J. Day 2003-01-12 01:58:37 UTC
  while the dependency issue is most likely a good fix, you can't
ignore that that script still has an obvious error with the 
KERNTYPE/KERNELTYPE inconsistency at the very least.

Comment 5 Paul Campbell 2003-01-16 21:56:03 UTC
Please delete my erroneous comments #2 and #3 above.
My comments were a dup of 68323


Comment 6 Bugzilla owner 2004-09-30 15:40:19 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/