Description of problem: make oldconfig does not seem to create "a configuration file for the kernel that shipped with Red Hat Linux for the architecture" as stated in Appendix A.2. PCMCIA works in the shipped kernel (compiled in?) but becomes a module after using make oldconfig. Version-Release number of selected component (if applicable): rhl-cg(EN)-9-HTML-RHI (2003-02-20T01:08) 2.4.20-13.9 How reproducible: Always Steps to Reproduce: 1. follow instructions in Appendix A.2 including make oldconfig 2. make custom kernel and install it 3. boot Actual results: pcmcia is a module and does not start up properly Expected results: pcmcia starts up (as in the default kernel) Additional info: default behavior can be reestablished by setting CONFIG_PCMCIA=Y in .config via make xconfig or whatever (although then kudzu seems to pop up)
I didn't write that part clearly. It assumes that you followed step #3: #It is recommended that the configuration of the default Red Hat Enterprise Linux kernel be used as a starting point. To do this, copy the configuration file for the system's architecture from the /usr/src/linux-2.4/configs/ directory to /usr/src/linux-2.4/.config. If the system has more than four gigabytes of memory, copy the file that contains the keyword bigmem. make oldconfig then uses the existing configuration from the .config file, asks for answers to any new questions that didn't previously exist, and configures a few more things that are required to move on to the next step. If you copy over the default .config file and then run make oldconfig does the value of CONFIG_PCMCIA change?
CONFIG_PCMCIA=m is set in all the files in the configs directory. make oldconfig leaves it as that in .config and doesn't ask any questions. This appears inconsistent with the boot messages from /etc/rc.d/init.d/pcmcia. In the default kernel: Jun 3 08:42:47 somen kernel: Linux version 2.4.20-13.9 (bhcompile.r edhat.com) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #1 Mon May 12 10 :55:37 EDT 2003 Jun 3 08:42:52 somen pcmcia: cardmgr. Jun 3 08:42:52 somen cardmgr[680]: starting, version is 3.1.31 Jun 3 08:42:52 somen rc: Starting pcmcia: succeeded In the custom kernel with pcmcia as a module: May 19 16:52:40 somen kernel: Linux version 2.4.20-13.9custom (root.e du) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #2 Mon May 19 11:23:11 PDT 2003 May 19 16:52:42 somen pcmcia: Starting PCMCIA services: May 19 16:52:42 somen pcmcia: modules May 19 16:52:43 somen pcmcia: modprobe: Can't locate module pcmcia_core.o May 19 16:52:43 somen cardmgr[679]: no pcmcia driver in /proc/devices May 19 16:52:43 somen pcmcia: modprobe: Can't locate module yenta_socket.o May 19 16:52:43 somen cardmgr[679]: exiting May 19 16:52:43 somen pcmcia: modprobe: Can't locate module ds.o
If the default configuration files in /usr/src/linux/configs/ are not the same as the default kernel, it is a bug in the kernel-sources package, not the documentation.
pcmcia is a module in the shipped rpm kernels. did you run depmod -ae after the make modules_install ?
No I did not run depmod -ae after make modules_install. This is not in the customization guide. I assume you mean depmod -ae -F /boot/System.map2.4.18-19custom 2.4.18-19custom or whatever. (I'm not too clear from man depmod if the -b flag is also needed but I think the -F flag is definitely needed.) I don't have the machine to hand to check this right now.
[Here is a comment I added to 89190] I am experiencing something like this. I did find a very odd workaround: delete /lib/modules/KERNELVERSION/pcmcia. For some reason, this makes modprobe look in /lib/modules/KERNELVERSION/drivers/pcmcia/. I figured this out by stracing the first modprobe of /etc/rc.d/init.d/pcmcia start. Ugh. Note: I didn't change any options. I used the canned 686 config. I wonder *why* this is necessary.
hugh is correct about the workaround. The problem is the pcmcia directory he mentions. My initial complaint was unfounded. The documentation is correct insofar as the build does use the appropriate configuration file: /boot/config-2.4.xx does match the appropriate /usr/src/linux-2.4/configs/kernel-2.4.xx.arch. The problem comes from the Makefile when building the kernel. I've also checked using the 2.4.23 kernel from kernel.org. The problem is in the lines: # Backwards compatibilty symlinks for people still using old versions # of pcmcia-cs with hard coded pathnames on insmod. Remove # _modinst_post_pcmcia for kernel 2.4.1. .PHONY: _modinst_post_pcmcia _modinst_post_pcmcia: cd $(MODLIB); \ mkdir -p pcmcia; \ find kernel -path '*/pcmcia/*' -name '*.o' | xargs -i -r ln -sf ../{} pcmcia and the earlier dependency on _modinst_post_pcmcia. The following change (for example): #_modinst_post: _modinst_post_pcmcia _modinst_post: fixes the problem. The subdirectory pcmcia in modules is no longer created. I don't know how the stock Redhat kernel manages not to create the pcmcia directory. I don't understand the comments above .PHONY in the Makefile. Is it saying this action should be removed for all kernels after 2.4.1? Because it is triggered in these builds. So maybe the problem is that the Makefile doesn't have a way of getting around this broken fix for newer kernels. Looks to me like a kernel-sources Makefile issue rather than a documentation one.
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/