Bug 41973 - Can't recompile supplied RH7.1 kernel - hangs after uncompress of bzImage
Can't recompile supplied RH7.1 kernel - hangs after uncompress of bzImage
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brock Organ
http:;//www.kernel.org
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-05-23 10:01 EDT by Bryce Nesbitt
Modified: 2007-04-18 12:33 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-06-06 11:03:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bryce Nesbitt 2001-05-23 10:01:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i686)

Description of problem:
I'm simply trying to recompile the Kernel to add a module.  I can't get it
to boot.

It's not a LILO problem, everything works if I copy /boot/vmlinuz-2.4.2-2
to my  own /boot/vmlinuz-test.  I've compiled kernels a number of times in
the past without
issue.

How reproducible:
Always

Steps to Reproduce:
I've tried compiling 5 variations, doing a clean compile each time.
	kernel-source-2.4.2-2	+ kernel-2.4.2-athlon.config
	kernel-source-2.4.2-2	+ kernel-2.4.2-i386.config
	linux-2.4.4		+ kernel-2.4.2-athlon.config
	linux-2.4.4		+ kernel-2.4.2-i386.config
	linux-2.2.4		+ default config
RedHat does not provide a .config file, unfortunately, to match the kernel
that was installed.
Other than a few modules with errors that I had to turn off, all compiles
were normal.

Actual Results:
All 5 kernel compiles hang or reboot immediately after LILO uncompresses
the kernel.  No messages are printed.  Either the machine hangs, or goes
right back to LILO.

Expected Results:
Joy!

Additional info:
$ cat /proc/cpuinfo 
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 6
model           : 4
model name      : AMD Athlon(tm) Processor
stepping        : 2
cpu MHz         : 1009.002
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips        : 2011.95

Linux localhost.localdomain 2.4.2-2 #1 Sun Apr 8 20:41:30 EDT 2001 i686
unknown
 Gnu C                  2.96
Gnu make               3.79.1
binutils               2.10.91.0.2
util-linux             2.10r
modutils               2.4.2
e2fsprogs              1.19
reiserfsprogs          3.x.0f
pcmcia-cs              3.1.22
PPP                    2.4.0
isdn4k-utils           3.1pre1
Linux C Library        2.2.2
Dynamic linker (ldd)   2.2.2
Procps                 2.0.7
Net-tools              1.57
Console-tools          0.3.3
Sh-utils               2.0
Modules Loaded         autofs eepro100 ipchains ide-scsi scsi_mod ide-cd
cdrom usb-uhci usbcore
Comment 1 Arjan van de Ven 2001-05-23 10:29:24 EDT
What steps did you use to compile your kernel ?

And if you want to compile a single driver, there are better ways than 
recompiling your entire kernel; see 
http://people.redhat.com/arjanv/xircom_cb/ 
for an example of an external driver.
Comment 2 Bryce Nesbitt 2001-05-23 11:36:53 EDT
Steps:

0> make clean
    make mrproper
1> Copy a config file to .config
2> make oldconfig
3> make dep
4> make (usually)
5> make bzImage
6> make modules (usually)

I've tried it now with and without /usr/src/linux softlinked to the current
Kernel directory.

Which exact .config file does RedHat use?  Can I recreate the exact bzImage used
by RedHat 7.1 on an Athlon on a RedHat 7.1 Athlon system?
Comment 3 Bryce Nesbitt 2001-05-23 11:39:37 EDT
I want the comfort of knowing I can recompile the entire kernel & modules, even
if my
original goal was just one.   I'd like to recompile my module in the kernel
source tree I'm running.
Comment 4 Arjan van de Ven 2001-05-23 11:46:08 EDT
Your kernel was compiled with kernel-2.4.2-i686.config

The -athlon.config was provided as a service for people wanting to compile
an athlon kernel but due to lack of space on the CD (combined with the late 
time I added it to the kernel) is not supplied in binary form. 

We build our kernels with "rpm --rebuild -target=<foo> kernel-2.4.2-2.src.rpm"
where <foo> is one of i386, i586, i686 or athlon. However, the kernel-source
is the exact same source (except for files which generated by make dep and
will be created to be the same we used if you do make dep) as the shipped
binary.

If the kernel stops after "uncompressing..",  that usually means you either have
the wrong CPU type, or LILO went wrong.
Comment 5 Bryce Nesbitt 2001-06-06 11:03:02 EDT
You can close this.

It works if I don't select the Athlon CPU type.  There are also compile errors
with audio & "mmx_blockcopy" if I select Athlon.  So, it looks more like a
Kernel issue and less like a RedHat issue.

If the default install would leave a .config file to match the installed kernel
binary, that would be great.  It would be comforting to install a new system,
recompile the kernel, and get the same result as the supplied binary right out
of the box.
Comment 6 Arjan van de Ven 2001-06-06 11:07:17 EDT
Athlon _should_ compile, although I must admit it's less tested by us.

"If the default install would leave a .config file to match the installed kernel
 binary, that would be great.  It would be comforting to install a new system,
 recompile the kernel, and get the same result as the supplied binary right out
 of the box."

Thing is, we often install 2 or 3 kernels (on SMP systems you get both the UP
and the SMP kernel), and it would be hard to get the proper one there.

Having said that, I added a bit of magic to the config scripts recently that if
a .config is missing, it does look at the currently running kernel.

Note You need to log in before you can comment on or make changes to this bug.