Bug 58030 - unable to eliminate insmod unresolved symbols errors
unable to eliminate insmod unresolved symbols errors
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.2
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-06 08:59 EST by Landon Curt Noll
Modified: 2007-04-18 12:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-06 13:30:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
.config file used to build the custom 2.4.9-13 kernel (17.39 KB, text/plain)
2002-01-06 09:03 EST, Landon Curt Noll
no flags Details

  None (edit)
Description Landon Curt Noll 2002-01-06 08:59:45 EST
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?
Comment 1 Landon Curt Noll 2002-01-06 09:03:27 EST
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 09:18:19 EST
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 12:22:39 EST
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
Comment 4 Arjan van de Ven 2002-01-06 12:38:07 EST
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 12:49:44 EST
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 13:29:57 EST
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.
Comment 7 Landon Curt Noll 2002-01-06 20:48:08 EST
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.

Note You need to log in before you can comment on or make changes to this bug.