Improve company productivity with a Business Account.Sign Up

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 269
  • Last Modified:

Why does compile 2.4.2 but 2.2.19 doesn't ?

Today I tried to compile a 2.2.19 kernel (with REDHAT 6.2). It didn't work.
I did untar the complete kernel source file, then make config, make dep,
make clean, make bzImage. The trouble is that make bzImage did end with
an error message & no bzImage was created:
. . .
make[1]: Entering directory `/usr/src/linux/arch/i386/boot'
as86 -0 -a -o bbootsect.o bbootsect.s
make[1]: as86: Command not found
make[1]: *** [bbootsect.o] Error 127
make[1]: Leaving directory `/usr/src/linux/arch/i386/boot'
make: *** [bzImage] Error 2

Only two days ago I did create a 2.4.2 kernel bzImage with no problems at all.
It was just that I didn't like the performance of the 2.4.2 & wanted to compile
a 2.2.19 instead. (My 'original' kernel is a 2.2.14 & very stable, but has never been
So, why do the 2.4.x series compile but not the 2.2.x ?
I did update some software as advised before installing the 2.4.2.
Could it be that now those upgrades leave my 2.2.x comp. efforts short in some way ?  
  • 5
  • 4
  • 4
1 Solution
I believe you need to "undo" the other upgrades associated with the 2.4 kernel before reverting back to a 2.2 kernel. The point of doing those upgrades is to install things that are 2.4 friendly. However, I suspect that's not the problem with compiling the 2.2.19 kernel. There's a step missing from your build process. The first time you build a kernel or change CPU type 386<->486, 486<->686, uni-processo<->multi-processor, etc. it is necessary to do a "make mrproper", then "make config", etc.
Yup, that is it. make mrproper will clean up all the old dependencies.  You might want to "make oldconfig" instead of config.
xberryAuthor Commented:

thanks for replying.
Meanwhile I did 'reinstall' libc5-5.4 as
it was part of the minimum software requirements list
for the 2.2.19. All the other utils & compilers seemed to
be ok as long as the version number was just higher as the proposed limit.
Then I did
make mrproper
make xconfig
make dep
make clean
make bzImage

with just the same error result as before.

Also tried
make mrproper
make oldconfig

which suggested me a list of options,
lots of them not very useful for my system.
No way to interfere with that oldconfig list though.
Only the choice to proceed with make dep or to leave it.

I'm just afraid that after an upgrade 'undo' 2.2.19 would still
give nasty errors.

My 2.2.14 isn't that bad, if there just would be a way to swith off
that stupid 'hda probing' when the ramdisk boots. My system is pure SCSI.

Any suggestions ?
Build your data science skills into a career

Are you ready to take your data science career to the next step, or break into data science? With Springboard’s Data Science Career Track, you’ll master data science topics, have personalized career guidance, weekly calls with a data science expert, and a job guarantee.

okay try this, there is a directory called configs that comes with your kernel source, or you can copy it from the old 2.2.18.  pick the config file that you want, and copy it to parent direcoty as .config and .config.old and try to make it again, same steps.
PS.  Make sure you have kgcc installed on your system, because that what the kernel uses to compile.
xberryAuthor Commented:

sorry that I kept you waiting for a response. In the meantime lot's of things have happened.
First, regarding your latest comment:

The only config files that I found were on a backup that I did of /usr/src/linux-2.2.14
However those files were only 'menus' & not relevant of any kernel configuration that
has ever been installed before. Hoping for a miracle, I copied them back anyway.
Also I did install kgcc. Then I compiled again, always doing a mrproper first.
It didn't make any difference though. Looked as if I've done harm to my system & destroyed
required files at a time when I was not only new but  ' very,very green about Linux '
I also thought of jlevies estimation that he gave about my situation & found that I either had  the choice for going back to a clean 6.2 installation or completing what I've started & do a full upgrade to 7.1. So I decided for the later & installed a fresh 7.1. Shortly after I tried to personalize the kernel & installed the source 2.4.2 rpm. With all prerequisites given it wouldn't compile either !!!
Strange I found that when trying the 'make menuconfig' for a choice, it said 'can't compile, the 'ncurses' package is missing. I DO HAVE NCURSES INSTALLED & i reinstalled them just to be absolutely sure, still no go. Bit later I tried to compile a 2.4.4 kernel & , surprise, it gave me a
bzImage. Installed that & booted the new image but after login it didn't built up my GNOME desktop (only slow motion, without the panel).

Well, looks as if I've stirred up a total different situation now. My question seems outdated now,
better would be ' How am I going to compile a stable working kernel without going crazy ' : )
Maybe I should close the old question first, giving you both points for direction & attention ?
I don't know if an upgrade to 7.1 would be successful after modifying a 6.2 system for a 2.4 kernel. I suspec the upgrade process would be confused by the presence of the other things besides the 2.4 kernel source that must be installed on a system distributed for a 2.2 kernel. And obviously if the 7.1 upgrade didn't apply properly it could cause problems like you are seeing.

I can see two choices. Either do a clean install of 6.2 and then update that with the 6.2 updates (which will get you a 2.2.19 kernel, later glibc, et. al.), or install 7.1 and apply its updates (which will get you 2.4.3+redhat patches and other things). BTW: I've got some nifty scripts that automate the update process for 6.2, 7.0, & 7.1 if anybody is interested.

****Soap Box Mode ON****
Any time that you futz with a RedHat system "out of band" (or any other distro for that matter) there is a real possibility of creating havoc. The "RedHat way" means that you don't shoehorn non-RedHat packages onto the system that overlay an existing package. The way to manage a RedHat system and keep it in a stable and supportable configuration is to use the RedHat updates for RedHat packages and not to get some later version from someplace else. There are times when it is appropriate to replace a RedHat package with some later version of that utility. In that case you remove the RedHat package with rpm and build the later version from source and install it. That way the rpm database won't reflect the later version and any subsequent updates or upgrades will work properly. It is best to remember that any updates or upgrades will look in the rpm database on the system to determine whether an update should be applied or what needs to be replaced during an upgrade. If you futz around with the system "out of band" it is very likely that the rpm database will not reflect what is actually on the system. And that means that some things may not get upgraded at all or other things may be partially over-written. And you really do want to be able to use the RedHat updates and they should be seen as a set, not as individual patches to apply. You'll have the best results with a RedHat system if you apply all applicable updates (those for which you have an installed package) and keep the system up to date. That way you have all of the security & bug fixes.
****Soap Box Mode ON****
I had the longest week from hell dealing with 2.4.2 almost lost what's left of my hair.
now you can do "rpm --rebuilddb" before building the kernel to see your NCURSES.
the upgrade from long week okay from my pas week in hell, I can tell you to
1. upgrade to 7.1 and kernel 2.4.2.  the upgrade will update you system and correct whatever missing dependencies.
2. reinstall 6.2, does not have to be a clean install, just do an upgrade and 6.2 will try to upgrade packages and it WILL reinstall your kernel image.
Now regarding RH7.1, I strongly suggest to download packages from redhat, all the update, because kernel 2.4.2 has a serious problem with NFS and mount, mount package is also available.  
You should get those scripts from jlevie, you never know, i might get them myself.  

Question: how did you upgrade from 2.2 to 2.4? with rpms or just got the source code.  

PS. Make sure you keep track of what you install on your system for upgrade purposes.  Redhat installation, upgrade option, looks into the rpms database, SO if you download lets say rsh and installed it from a tar ball, redhat installtion will NOT see it.
garboua, xberry,

Send an email to and I'll be glad to return the scripts to you. They make the process of applying updates fairly easy.
xberryAuthor Commented:
First, great thanks to jlevie & garboua for your extensive replies.
Second, I have to apologize again, for causing a misunderstanding ( Looks as if my English
went down the bin together with my 6.2 System ) : Fact is that i first wanted to upgrade from
6.2 to 7.1 but then ACTUALLY did install a CLEAN 7.1 on fresh formatted partitions. 6.2 is gone, completely ( except some personal stuff that i created with it & was saved on a zip disk ). The 7.1 System I did install from a true, original, even registered set of RH 7.1 operating system binary CD's. The only new, non REDHAT ' addition ' after the basic installation were the tared & bzipped kernel 2.4.4 source files   ( Sure, sounds as if I'm nuts but after 'fresh' installation of RH 7.1 i first tried to personalize my kernel with the 2.4.2 original kernel source rpm but it also FAILED !, similiar as the 2.2.14 & 2.2.19 compilation efforts failed with RH 6.2. How can that be after a completely fresh installation ? )
garboua, I'm not very old but I can already compete with my granny as far as grey hair is concerned . . .  : |  Never mind  

I just wonder how to get on from here, the 7.1 is fresh, all I wanted to do is to get away from that
'ready made' kernel business with ramdisk & so on. My System is completely  SCSI, so  I'd like to
get SCSI fully compiled into the kernel, that way saving myself that initrd.img & have a faster booting, the main motivation behind my ' kernel mania '  

For now, thanks a lot to jlevie for your offer with the scripts. Sounds great. At least I'll get a piece of sanity back into my box : )  I'll send you an e-mail.

okay, lets take it this way first.
if the install is fresh, there is a fresh copy of  you box configuration under /usr/src/linux-2.4 named .config
you can either use that, or
well you know the steps to rebuild 2.4.4? I have 2.4.2 2.4.3 2.4.5 on same box, LONG story.
if you want 2.4.2 back, install it from second CD, I don't know what else to tell you.
xberryAuthor Commented:
Well, now it really looks as if something went wrong at installation already.
Because . . . after fresh installation my /usr/src was . . . EMPTY !  No linux directory anywhere !
I understand what you're on about. Had a /linux directory & config & include files with my 6.2 version but after 7.1 installation there was NOTHING. First I thought that's just new with 7.1
but now . . .

Having several kernel versions on one box wouldn't be a prob, know how to do that with LILO.
No, right now I do have 2.4.2 & 2.4.4 but as I mentioned already the 2.4.4 boots but gives trouble when loading GNOME & I just wonder what went wrong at compilation time.

Thanks for now. I let the new facts soak in for awhile & then likely attempt to do a clean reinstallation.  
It sounds like you didn't install the kernel-source rpm when you installed 7.1. I don't believe it is installed by default in any of the "packaged" installation options. Easy enough to fix though, simply:

# mount /mnt/cdrom
# rpm -i /mnt/cdrom/RedHat/RPMS/kernel-source-2.4.2-2.i386.rpm

I suspect that the problem with your "out-of-band" 2.4.4 kernel is that it doesn't have all of the RedHat fixes in it and isn't trully compatible with 7.1. I have information from a "usually reliable source" that says that the 2.4.2 kernel furnished with 7.1 has some 200+ fixes applies to it that aren't all in the distributions from It's not that RedHat isn't feeding the fixes back, it's more that some of those fixes are "point fixes" specifically for a 2.4.2 kernel and that others will eventually find their way into the developmental kernel version. The only ones that might be in the 2.4.4 kernel are any that were created and adopted before the 2.4.4 version was frozen.

The 7.1 updates include kernel 2.4.3 which is what I'd recommend you build your custom kernel from. I think it's probably important to apply all other applicable updates before trying a kernel build.

BTW: scripts are being mailed now...
xberryAuthor Commented:
jlevie wrote:

> The 7.1 updates include kernel 2.4.3 which is what I'd recommend you build your custom kernel from.
> I think it's probably important to apply all other applicable updates before trying a kernel build.

Thank you !!!  

+ additional 43 points for the scripts.

To garboua:

Thank you too & 201 points for your assistance. Please pick them up in the  ' Linux Setup '  topic area.
 Without your backing information I'd for sure have dropped through the bottom, so to say.  
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 5
  • 4
  • 4
Tackle projects and never again get stuck behind a technical roadblock.
Join Now