Bug 58030

Summary: unable to eliminate insmod unresolved symbols errors
Product: [Retired] Red Hat Linux Reporter: Landon Curt Noll <redhat-mail>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2   
Target Milestone: ---   
Target Release: ---   
Hardware: athlon   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-01-06 18:30:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
.config file used to build the custom 2.4.9-13 kernel none

Description Landon Curt Noll 2002-01-06 13:59:45 UTC
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:

Steps to Reproduce:
1.make a custom kernel with ext3 support (2.4.9-13 kernel)

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:


(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?

Comment 1 Landon Curt Noll 2002-01-06 14:03:27 UTC
Created attachment 41892 [details]
.config file used to build the custom 2.4.9-13 kernel

Comment 2 Arjan van de Ven 2002-01-06 14:18:19 UTC
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......

Comment 3 Landon Curt Noll 2002-01-06 17:22:39 UTC
There is no ext3.o file under:

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

Comment 4 Arjan van de Ven 2002-01-06 17:38:07 UTC
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 ?

Comment 5 Landon Curt Noll 2002-01-06 17:49:44 UTC
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?

Comment 6 Landon Curt Noll 2002-01-06 18:29:57 UTC
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
	        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 ...

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.

Comment 7 Landon Curt Noll 2002-01-07 01:48:08 UTC
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.