|Summary:||Kernel compilation makefile fails|
|Product:||[Retired] Red Hat Linux||Reporter:||kerryjones|
|Component:||kernel||Assignee:||Red Hat Documentation <docs>|
|Status:||CLOSED NOTABUG||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2000-02-06 05:02:31 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description kerryjones 1999-10-22 13:57:32 UTC
I downloaded a new Linksys Ethernet card driver (tulip.c) from the Linksys Linux support page and needed to recompile the kernel. At the end of the "make boot", a message was displayed: "System is 574kB System is too big. Try using bzImage or modules." zImage was not created. I took out everything I could from the configuration with menuconfig, did a make dep;make clean;make boot and got the same message. However, I did as your manual suggested and made my aic7xxx SCSI controller, SCSI CD-ROM and SCSI tape drive part of the kernel. Same failure. Next, I tried making the SCSI components above a module, and that went OK - no message about the system being too big. I needed to make an initrd image for the SCSI module. As far as I know, I met the criteria mentioned in the book: 1) The loopback device is available (it existed then as /dev/loop0-4, and I configured the loopback device as a module with menuconfig), and 2) the /etc/conf.modules file already had a line for my SCSI adapter. The /sbin/mkinitrd failedd with the message "The kernel does not recognize /dev/loop0 as a block device". I tried using menuconfig to make the loopback device a part of the kernel rather than a module, but got the same results. So, building a kernel with the SCSI controller as a module seems not to be an option. Just for the heck of it, I tried building a monolithic kernel and that failed with the "size too big" message. Finally, I tried following the instructions on the Linksys web page to compile just the new Tulip.c driver. Their command to do so is: gcc -DMODULE -D__KERNEL__ -I/usr/src/linux/net/inet -Wall -Wstrict-prototypes -O6 -c -tulip.c '[ -f /usr/include/linux/modversions.h] && echo -DMODVERSIONS' That is not a valid include file, so I used -I/usr/src/linux-2.2.12/include. When I tried to compile, I received the message "[ -f /usr/include/linux/modversions.h ] && echo -DMODVERSIONS" does not exist. Modversions.h actually exists in /usr/include/linux.h; I think gcc is complaining about that entire expression. I tried compiling under sh with the same results. I don't know enough about bash/sh to understand what that expression is trying to do, so I stuck here too. Between this and the 2 crashes in Gnome, and the 3 segmentation faults in linuxconf, I am getting pretty discouraged. I am TRYING to flee an unstable OS, but am getting nowhere. Your advice, please. Regards, Kerry Jones
Comment 1 Chris Siebenmann 1999-10-23 05:14:59 UTC
I don't know if RedHat recommends 'make boot' these days, but the sequence I use is: # edit Makefile to change EXTRAVERSION as appropriate so one # doesn't overwrite the old working binary bits make clean # if desired run 'make menuconfig' or whatever to change the # configuration. If you don't change the config you MUST run make oldconfig # pick up the changed EXTRAVERSION make dep make bzImage && make modules make modules_install # remember the name it used for the # directory in /lib/modules; call it # KERNVER cp System.map /boot/System.map-KERNVER cp arch/i386/boot/bzImage /boot/vmlinuz-KERNVER # edit /etc/lilo.conf and run lilo. The old zImage boot image format that 'make boot' uses has a relatively low size limitation (for these days). bzImages let the kernel image be much bigger, and you want to use this method.
Comment 2 kerryjones 1999-10-23 14:03:59 UTC
cks wrote: +------- Additional Comments From email@example.com 10/23/99 01:14 +I don't know if RedHat recommends 'make boot' these days, but the +sequence I use is: + # edit Makefile to change EXTRAVERSION as appropriate so one doesn't + # overwrite the old working binary bits make clean if desired run ' + # make menuconfig' or whatever to change the configuration. If you + # don't change the config you MUST run make oldconfig pick up the + # changed EXTRAVERSION + # make dep + # make bzImage && make modules + # make modules_install # remember the name it used for the + # directory in /lib/modules; call it + # KERNVER + cp System.map /boot/System.map-KERNVER + cp arch/i386/boot/bzImage /boot/vmlinuz-KERNVER + # edit /etc/lilo.conf and run lilo. + + The old zImage boot image format that 'make boot' uses has a + relatively low size limitation (for these days). bzImages let + the kernel image be much bigger, and you want to use this method. + Kerry replies: Yes, Red Hat does recommend using "make boot". I do not have "bzImage" on my system, so unless I can track down a version somewhere, that's not an option. Thanks for your comments. Kerry
Comment 3 kerryjones 1999-10-23 18:26:59 UTC
Where can I get bzImage or bzImages? I haven't looked in the makefiles but hope incorporating it will be straightforward. That still does not solve the problem with making an initrd image (but I'd rather not make one to begin with.) I've finally gotten the new Linksys tulip driver compiled, installed, and sucessfully pinging another machine. I used the "test" version of their driver. I hit ctl-C when doing a "make modules" and saw how to compile modules. I am NOT good at reading makefiles and was unable to come up with the correct compilation command doing that. The compilation instructions on the Linksys web site are wrong, or wrong for Red Hat 6.1. I found last night that sound is not working (which is weird since I have a Sound Blaster)and still want to recompile my kernel in order to try getting that fixed. And suddenly, the sendmail daemon is taking forever to start when booting. Also, two more segmentation faults running linuxconf with Gnome last night. *Sigh* I'm taking a few days off from all this in order to get some rest.
Comment 4 Bill Nottingham 2000-02-06 05:02:59 UTC
To make bzImages, just do 'make bzImage instead of make zImage', and install the resulting bzImage in the same way you would the resulting zImage; that's all.