Hide Forgot
Try the following: rpm -Fvh /location/to/kernel-*2.2.17-9.i386.rpm cd /usr/src/linux make oldconfig make bzImage - copy this kernel over your current vmlinuz - lilo and reboot There. No Modules. Among other things.
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.