From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-7.0.12 i686) Description of problem: While booting a custom kernel, insmod complains about unresolved symbols related to /lib/ext3.o. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.make a custom kernel with ext3 support (2.4.9-13 kernel) 2.boot 3. Actual Results: During the boot process, before mounting /proc, the following types of messages are printed: ... many unresolved symbol messages ... /lib/ext3.o: unresolved symbol generic_read_dir_R4094f003 /lib/exi3.o: unresolved symbol fsync_inode_buffers_Rea2c7149 /lib/ext3.o: unresolved symbol __free_pages_R7e28a3a8 /lib/ext3.o: unresolved symbol journal_init_dev_R327c6a12 /lib/ext3.o: unresolved symbol journal_revoke_Rb321110d /lib/ext3.o: unresolved symbol __up_write_R6a1d63c6 ERROR: /bin/insmod exited abnormally! Mounting /proc filesystem ... normal boot process ... The system will boot and the ext3 file systems will be mounted. All appears to be normal with the exception of those unresolved symbol messages being printed during system boot. Expected Results: No unresolved symbol messages Additional info: The following file system kernel parameters are defined for the 2.4.9-13 kernel: CONFIG_EXT3_FS=y CONFIG_JBD=y CONFIG_JBD_DEBUG=y CONFIG_EXT2_FS=y (see attached file for a full kernel parameter list) NOTE: Because / is an ext3 filesystem, one cannot set CONFIG_EXT3_FS=m. However it is interesting to note that the pre-compiled kernel that comes with the kernel-2.4.9-13.rpm does not produce those unresolved symbols. Under that pre-compiled kernel, lsmod shows that the ext3 module has been loaded. How does it manage to do that?
Created attachment 41892 [details] .config file used to build the custom 2.4.9-13 kernel
I don't know what you've done; if you set EXT3 to "y" ext3.o shouldn't be installed in the modules directory; if you set it to "m" you won't get those unresolved symbols..... somehow you appear to have done both at the same time :) ext3 as module DOES work, even for / as ext3; the kernel loads a "initial ramdisk" (initrd) before mounting / and that initrd should contain the ext3 module (and insmod etc)... the mkinitrd will create a decent initrd and even looks in /etc/fstab to see if you're using ext3 and then puts the ext3 module in the initrd......
There is no ext3.o file under: /lib/modules/2.4.9-13custom/ as you can see in the attachment, ext3 is set to y. Here is how you can duplicate my results: cd /usr/src/linux-2.4.9-13 make mrproper cp config_from_the_attachment .config make xconfig (just save and exit) make all make modules make install rm -rf /lib/modules/2.4.9-13custom make modules_install reboot
I'm not sure how make install works (I never use it) but if it changes the lilo.conf in a way that an OTHER initrd is used, then that is wrong; since you didn't make an initrd the /etc/lilo.conf file shouldn't have one for this kernel. Can you check this ?
I am not using lilo, I am using the grub as installed by RH7.2 CDs. I had to change /sbin/installkernel to do a: grub-install /dev/hda (see bug #58023) If you don't use 'make install', how do you install a kernel?
I was able to eliminate the /lib/ext3.o messages by forcing ext3.o and jbd.o to be modules installed via initrd. Here is what I did: cd /usr/src/linux-2.4.9-13 make mrproper cp config_from_the_attachment .config make xconfig <<change CONFIG_EXT3_FS=m CONFIG_JBD=m then save and exit>> make all make modules make install rm -rf /lib/modules/2.4.9-13custom make modules_install vi /etc/modules.conf <<be sure that /etc/modules.conf has the follow lines: options ext3 options jbd>> rm -f /boot/initrd-2.4.9-13custom.img mkinitrd -v /boot/initrd-2.4.9-13custom.img 2.4.9-13custom grub-install /dev/hda # I'm not sure if this is needed after mkinitrd ... reboot Is there an easier way to do this? FYI: /boot/grub/grub.conf has the fllowing lines: default 0 timeout 5 password --md5 <<something>> title RH Linux (2.4.9-13) root (hd0,0) kernel /vmlinuz-2.4.9-13custom ro root=/dev/hda2 hdb=ide-scsi ide0=ata66 ide1=ata66 initrd /initrd-2.4.9-13custom.img The initrd line above matches up with the mkinitrd file that was formed.
You may want to close this as NOTABUG because I was able to silence the error messages via the process above. However ... On the other hand ... the 'make modules_install' rule should invoke mkinitrd when certain modules (such as ext3.o and jdb.o for example) that need to be present in initrd are configured. Clearly it should do this some modules must be preloaded in order to access the root file system. The mkinitrd --ifneeded is able to determine which modules are needed to be loaded at boot time. All 'make modules_install' would need to do is to determine if it needed to invoke mkinitrd: perhaps after editing /etc/modules.conf OR perhaps calling mkinitird with the appropriate --ifneeded and --preload=module or --with=module flags.