Modules must be compiled and installed seperatly to bzImage (make modules &&
make modules_install), and the your initrd (if used) must be regenerated.  

Futhermore, becouse of the nature of the kernel, there are about 7 different
configuration files, kept in the configs subdirectory, that are used to geneate
BOOT, normal and smp kernels for i386, i586, i686 processors.  So it isn't much
of a suprise they don't match. (I think the .config file you get is for the 386
- and may be yet another varient).

If you wan't to rebuild the kernel in exactly the same way that RedHat did, get
the kernel 'src.rpm' file (not kernel-source) and run rpm --rebuild on it.  Many
hours later, this will regenearate a close replica of the kernel RedHat ships in
a small pile of RPM files.  (They won't match becouse the date/time and
compilation user/machine are recorced in the images, amougst other things).

I'm sorry, I guess I wasn't so clear.  I should have indicated that I know what an SRPM is, and that I was clear with the procedure of rebuilding kernels.

The issue is with trust, I guess - it's a bad thing that a SCSI based system can be rendered unbootable via a simple remake of the kernel source, 
following the configuration details that are shipped with the source and installed with the kernel.

I have at least the brains god gave a turtle, and can understand that there are going to be differences between kernels for MP and UP machines.  What I 
don't understand is how an options as important as "Enable Loadable Module Support" could be set in the packages kernel, but unset in the source we 
all trust will rebuild that kernel.  

After dooing a bit of looking around, I now see where your problem comes from:

There is NO default .config file shipped with RH7. (at least not in the RPMS I
looked at).

Therefore, your are at the mercies of the linux-kernel developers, and their
default values, when you run 'make oldconfig'.  Unfortunatly 'make oldconfig' is
not suitable for your situation, as it is specificly designed for developers
(and users) patching between kernel versions, so they could see what changed. 
However, one should never boot a kernel that you havn't reviewed with 'make
menuconfig' first, as somtimes kernel options change their meaning - and in any
case the more important options have help text attached, explaining what
'loadable module support' gets you.

As to why RedHat dosn't ship a .config file, the reasons are many - firstly,
they don't know which of the various configuraion files you would want, secondly
the kernel sources are independet of your particular choice of boot kernel (so
there is no way of working which one is the right one anyway), and thirdly the
'make mrproper' they use to clean out the kernel tree gets rid of the .config
anyway.  They do however ship a collection of sample configuraions (ie the ones
used for the binary packages) in the 'configs' subdirectory.

As to why the kernel developers don't give you a bootable kernel (for your
system) with 'make oldconfig', the default values will probably boot most
systems (with IDE), but with the plethora of different SCSI configurations out
there, chosing sensible defualts would be impossible - and irrelivent to the
vast majority of users who use IDE, only making their kenels larger.

As to why 'loadable module support' is disabled by default (if it is, it isn't
on my system) I think it has to do with fact that it requires further work after
kernel installation - the modules must also be installed, and if your kenel
can't find your hard disk they can't load (hence the need to update initrd).

In any case, the fatal flaw in your technique was overwriting the RedHat kernel,
all the documentation I can remember reading emphises the fact that you should
never overwrite your last working kernel - lest you be forced to find that boot
disk.  Add an extra entry to your lilo.conf and boot that, knowing that if all
hell breaks loose your system will still boot.  For documentation, the
Kernel-HOWTO is an invaluable reference (if aging slightly) for the first few
recompiles.

BTW, most users who rebuild their kernel don't want a RedHat one anyway, they
want a lean, mean kernel customised to their every desire - so they will be
twidding most of the options themselves anyway - and without a distributions
worth of defaults thats what they will get - a lean, mean kernel tuned to their
particualar configuration.

There may be no .config , but there is a arch/i386/defconfig, the inclusion of which cause 'make oldconfig' to make a useless kernel.  Please replace my 
mention of .config with defconfig.
 
Thanks for the speech on System Administration.  Had my system been one of them hosed, it would have come in handy I'm sure.  Ah, but where's the 
average neophyte kernel hacker going to go for last minute caveats while following the paint-by-numbers in the ip_masq_icq module instructions?

Had the /usr/src/linux/.config been actually a file included in the kernel package and not the source package, I think they'd be able to actually make a 
distro of the kernel that didn't have this minefield config in it.  Or, they may actually decide that they do need similar options in every kernel, and only 
modify them for processor number/type differences.  That'd be neat.  

You know, a kernel distro that can remake the kernel from included configs would be oddly complete... like a logic system that can prove itself.

Now let me report my bug in peace.  8-)

The options in the source aren't different. They just require modular
SCSI; this requires an initrd. Hence, you can't just copy the
bzImage.

I've got 1284 diff lines of 'not different'.  That's about 500 differences and 200 added lines.  Sometimes I think 7.0 and 6.2 are more 'not different' than that.

This is reproduced by using the config generated during the kernel build package, compared against the .config generated in /usr/src/linux using 
arch/i386/defconfig via make menuconfig and immediately selecting Exit (which changes nothing in .config, right?!?)

The kernel config that is produced by a simple generation of .config from defconfig in the source packages as shipped has no concept of firewalling, has 
no idea what many major SCSI vendors are, and has a pathetic NIC list.  I'm not talking about modules here, as the kernel config generated has no 
hooks.  Throw it a module (or an INITRD) and it gets about as confused and interested as my cat with advanced calculus.

This is discovered as I attempted to add IPSec to the kernel via freeS/Wan.  Tell me how you did that with the SRPM, abartlet.  

Unless one knows the settings used to make the shipped kernel, via a .config theft during a -ba like I did, attempting to use only the files shipped in the 
Source package is a comedy.  Or is that a tragedy?

 - bish

First, compiling a kernel is not a supported activity.  It's not supported
specifically because it is a complex task and the user needs to know what they
are doing.  This is a new user mine field.  Second, we have always followed the
philosophy that we should leave the original sources as "pristine" as possible,
and ship our modifications separate so that people can easily discern the
difference between what's available on the net and what we have done to modify
things.  Third, as has been pointed out, we ship 7 different kernel packages and
each of them use a different config file (located in the configs directory) so
it is to be expected that any given config will vary from the one that ships as
arch/i386/defconfig (which happens to simply be the config Linus uses most often
on his own workstation last I knew).

Basically, this bug report is a complaint that you were unable to replicate the
Red Hat kernel build procedure with a simple make oldconfig;make bzImage in the
kernel source tree.  In reality, we never once stated that making a working
kernel from the kernel source package was that simple and that automatic. 
Instead, we merely provide the kernel source package as a set of pre-patched
sources where the basic code is what we use to make our kernel.  The user is
still fully responsible for properly configuring the kernel (based upon what
they need, our configs are there basically as guidelines and starting points, no
more) and then making *all* of the necessary components of the kernel and
installing *all* of those components properly themselves.  So, as I see it,
there is no bug here, just a misunderstanding.  I'll be closing this bug out.

Ok, fair 'nuff.

Thanks for your time.