This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
To: linux-kernel
Subject: [2.5] initrd/mkinitrd still not working
From: Bill Davidsen (davidsen@tmr.com)
Date: Sat Jan 18 2003 - 14:46:53 EST
Could someone *please* point me to the version of mkinitrd which works
with the new module code? The mkinitrd from Redhat and Slackware can not
find scsi modules which are in the module tree and modeles.dep. If I
build initrd by hand based on what worked for 2.5.47 it starts to load a
*still* can't find the module.
If this functionality is among the capabilities which were removed
during the module loading functionality downgrade, could someone just
say so?
Make output:
make -j2 -f scripts/Makefile.build obj=net/sunrpc
make -j2 -f scripts/Makefile.build obj=net/unix
make -j2 -f scripts/Makefile.build obj=lib
make -j2 -f scripts/Makefile.build obj=arch/i386/lib
make -j2 -f scripts/Makefile.build obj=arch/i386/boot BOOTIMAGE=arch/i386/boot/bzImage install
make -j2 -f scripts/Makefile.build obj=arch/i386/boot/compressed \
IMAGE_OFFSET=0x100000 arch/i386/boot/compressed/vmlinux
Kernel: arch/i386/boot/bzImage is ready
sh arch/i386/boot/install.sh 2.5.56 arch/i386/boot/bzImage System.map ""
No module sym53c8xx found for kernel 2.5.56
real 0m10.521s
user 0m13.490s
sys 0m1.460s
Module is present and found by depmod:
bilbo:root> find /lib/modules/2.5.56 -name 'sym53*'
/lib/modules/2.5.56/kernel/drivers/scsi/sym53c8xx_2
/lib/modules/2.5.56/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko
bilbo:root> grep sym53 /lib/modules/2.5.56/modules.dep
/lib/modules/2.5.56/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko:
bilbo:root> exit
Note: tried it in every kernel from 2.5.48-58, this is not just a 2.5.56
bug, I was just trying to get another feature working, without a root
filesystem it's not productive to test :-(
--
bill davidsen, CTO TMR Associates, Inc <davidsen@tmr.com>
Having the feature freeze for Linux 2.5 on Hallow'een is appropriate,
since using 2.5 kernels includes a lot of things jumping out of dark
corners to scare you.
===
Subject: Re: [2.5] initrd/mkinitrd still not working
From: Mikael Pettersson (mikpe@csd.uu.se)
Date: Mon Jan 20 2003 - 09:57:22 EST
Bill Davidsen wrote:
>Could someone *please* point me to the version of mkinitrd which works
>with the new module code? The mkinitrd from Redhat and Slackware can not
>find scsi modules which are in the module tree and modeles.dep. If I
>build initrd by hand based on what worked for 2.5.47 it starts to load a
>*still* can't find the module.
>...
>sh arch/i386/boot/install.sh 2.5.56 arch/i386/boot/bzImage System.map ""
>No module sym53c8xx found for kernel 2.5.56
>...
>/lib/modules/2.5.56/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko
Recent 2.5 gives modules a .ko suffix instead of the traditional .o,
and modules are described in /etc/modprobe.conf instead of modules.conf.
The quick-n-dirty patch below to RH8.0's /sbin/mkinitrd might do the trick.
As to why the .o -> .ko name change was necessary, I have no idea.
Rusty?
--- mkinitrd.~1~ 2003-01-20 15:39:34.000000000 +0100
+++ mkinitrd 2003-01-20 15:49:48.000000000 +0100
@@ -34,7 +34,7 @@
img_vers=""
builtins=""
pivot=1
-modulefile=/etc/modules.conf
+modulefile=/etc/modprobe.conf
rc=0
if [ `uname -m` = "ia64" ]; then
@@ -128,7 +128,7 @@
modName="sbp2"
fi
- fmPath=`(cd /lib/modules/$kernel; echo find . -name $modName.o | /sbin/nash --quiet)`
+ fmPath=`(cd /lib/modules/$kernel; echo find . -name $modName.ko | /sbin/nash --quiet)`
if [ ! -f /lib/modules/$kernel/$fmPath ]; then
if [ -n "$skiperrors" ]; then
@@ -320,7 +320,7 @@
fi
if [ -n "$needusb" ]; then
- drivers=$(awk '/^alias usb-controller[0-9]* / { print $3}' < /etc/modules.conf)
+ drivers=$(awk '/^alias usb-controller[0-9]* / { print $3}' < $modulefile)
if [ -n "$drivers" ]; then
findmodule usbcore
for driver in $drivers; do
@@ -461,7 +461,7 @@
dd if=/dev/zero of=$IMAGE bs=1k count=$IMAGESIZE 2> /dev/null || exit 1
-LODEV=$(echo findlodev $modName.o | /sbin/nash --quiet)
+LODEV=$(echo findlodev $modName.ko | /sbin/nash --quiet)
if [ -z "$LODEV" ]; then
rm -rf $MNTPOINT $IMAGE
@@ -536,7 +536,7 @@
for MODULE in $MODULES; do
text=""
- module=`echo $MODULE | sed "s|.*/||" | sed "s/.o$//"`
+ module=`echo $MODULE | sed "s|.*/||" | sed "s/.ko$//"`
options=`sed -n -e "s/^options[ ][ ]*$module[ ][ ]*//p" $modulefile 2>/dev/null`
@@ -547,7 +547,7 @@
echo "Loading module $module$text"
fi
echo "echo \"Loading $module module\"" >> $RCFILE
- echo "insmod /lib/$module.o $options" >> $RCFILE
+ echo "insmod /lib/$module.ko $options" >> $RCFILE
# Hack - we need a delay after loading usb-storage to give things
# time to settle down before we start looking a block devices
===
Subject: Re: [2.5] initrd/mkinitrd still not working
From: John Levon (levon@movementarian.org)
Date: Mon Jan 20 2003 - 10:52:50 EST
Mikael Pettersson wrote:
> >/lib/modules/2.5.56/kernel/drivers/scsi/sym53c8xx_2/sym53c8xx.ko
>
> As to why the .o -> .ko name change was necessary, I have no idea.
> Rusty?
For one thing, it means you can do :
obj-$(CONFIG_OPROFILE) += oprofile.o
oprofile-y := $(DRIVER_OBJS) init.o
timer_int.o
oprofile-$(CONFIG_X86_LOCAL_APIC) += nmi_int.o op_model_athlon.o \
op_model_ppro.o op_model_p4.o
which is very nice. I don't know why they're installed like that though.
===
Subject: Re: [2.5] initrd/mkinitrd still not working
From: Sam Ravnborg (sam@ravnborg.org)
Date: Mon Jan 20 2003 - 14:12:50 EST
John Levon wrote:
> > As to why the .o -> .ko name change was necessary, I have no idea.
> > Rusty?
>
> For one thing, it means you can do :
>
> obj-$(CONFIG_OPROFILE) += oprofile.o
> oprofile-y := $(DRIVER_OBJS) init.o
> timer_int.o
> oprofile-$(CONFIG_X86_LOCAL_APIC) += nmi_int.o op_model_athlon.o \
> op_model_ppro.o op_model_p4.o
The above mentioned possibility to list 'members' of a composite object
by means of either:
oprofile-y
or
oprofile-objs
has nothing to do with the .ko extension.
But that feature may have been added in the same time-frame though.
I do not recall exactly whay Kai introduced the .ko extension, but
without checking I assume that makes it easier / possible to do some
added tricks in the makefiles.
===
Subject: Re: [2.5] initrd/mkinitrd still not working
From: John Levon (levon@movementarian.org)
Date: Mon Jan 20 2003 - 14:19:21 EST
Sam Ravnborg wrote:
> The above mentioned possibility to list 'members' of a composite object
> has nothing to do with the .ko extension.
Ooops, I was mis-remembering commit logs. I meant :
http://linus.bkbits.net:8080/linux-2.5/user=kai/cset@1.838.1.86?nav=!-|index.html|stats|!+|index.html|ChangeSet
and in fact you're mentioned on it ..
===
Subject: Re: [2.5] initrd/mkinitrd still not working
From: Sam Ravnborg (sam@ravnborg.org)
Date: Mon Jan 20 2003 - 14:35:46 EST
John Levon wrote:
> Ooops, I was mis-remembering commit logs. I meant :
>
> http://linus.bkbits.net:8080/linux-2.5/user=kai/cset@1.838.1.86?nav=!-|index.html|stats|!+|index.html|ChangeSet
OK, this is something else.
Making the shift to the extension .ko allowed the syntax:
make fs/ext2/ext2.ko or whatever module we want to build.
Thats very nice when developing on a module to speed up things.
As of today you can actually do:
make fs/ext2/file.o
make fs/ext2/file.lst
make fs/ext2/file.s
make fs/ext2/file.i
and the above mentioned with a .ko module.
There is also the possibility to do:
make SUBDIRS=fs/ext2
and I hope that the following syntax will be anabled as well:
make fs/ext2/
[Patch queued for submission]
===
Subject: Re: [2.5] initrd/mkinitrd still not working
From: Michal Jaegermann (michal@harddata.com)
Date: Mon Jan 20 2003 - 21:18:38 EST
Sam Ravnborg wrote:
> John Levon wrote:
> > Ooops, I was mis-remembering commit logs. I meant :
> >
> > http://linus.bkbits.net:8080/linux-2.5/user=kai/cset@1.838.1.86?nav=!-|index.html|stats|!+|index.html|ChangeSet
>
> OK, this is something else.
> Making the shift to the extension .ko allowed the syntax:
> make fs/ext2/ext2.ko or whatever module we want to build.
>
> Thats very nice when developing on a module to speed up things.
Well, yes, but while installing into a final location all these .ko
files could be renamed to have .o extensions. This would avoid
screwing up user-space utilities. It is not that difficult to
fix mkinitrd to try _both_ ways (I do not know how many folks runs
exclusively 2.5 kernels) but who knows how many other things
will have to be modified introducing gratituos incompatibilities.
===
Subject: Re: [2.5] initrd/mkinitrd still not working
From: Bill Davidsen (davidsen@tmr.com)
Date: Tue Jan 21 2003 - 12:02:03 EST
Michal Jaegermann wrote:
> Sam Ravnborg wrote:
> > John Levon wrote:
> > > Ooops, I was mis-remembering commit logs. I meant :
> > >
> > > http://linus.bkbits.net:8080/linux-2.5/user=kai/cset@1.838.1.86?nav=!-|index.html|stats|!+|index.html|ChangeSet
> >
> > OK, this is something else.
> > Making the shift to the extension .ko allowed the syntax:
> > make fs/ext2/ext2.ko or whatever module we want to build.
> >
> > Thats very nice when developing on a module to speed up things.
>
> Well, yes, but while installing into a final location all these .ko
> files could be renamed to have .o extensions. This would avoid
> screwing up user-space utilities. It is not that difficult to
> fix mkinitrd to try _both_ ways (I do not know how many folks runs
> exclusively 2.5 kernels) but who knows how many other things
> will have to be modified introducing gratituos incompatibilities.
I frankly doubt that avoiding breakage was considered in any way... So
much is changed without visible gain, I'm still trying to identify what
wonderful new capability was gained by doing the change at all.
That said, since the new stuff is different, the change of extension is
probably a good thing, since it clearly prevents someone from dropping a
2.4 module into the tree without a clue that things have changed. That's
not a problem, other than it breaking mkinitrd, a module utility still
notably missing from the module_init stuff.
===
Subject: [BUG] 2.5.59 Same problems as 55..58
From: Bill Davidsen (davidsen@tmr.com)
Date: Sat Jan 25 2003 - 18:26:29 EST
Same old, I said I'd try kernels newer than 2.5.57 and I did. Still
doesn't work.
================================================================
Subject: Re: [BUG] 2.5.59 Same problems as 55..58
From: Mikael Pettersson (mikpe@csd.uu.se)
Date: Sun Jan 26 2003 - 09:40:31 EST
Bill Davidsen wrote:
>WARNING: /lib/modules/2.5.59/kernel/drivers/net/8390.ko needs unknown symbol crc32_le
>WARNING: /lib/modules/2.5.59/kernel/drivers/net/8390.ko needs unknown symbol bitreverse
> .
> . And this problem I've noted since 2.5.55
If your module-init-tools are older than 0.9.8, then this message
is expected. depmod doesn't find GPL only symbols. Fixed in 0.9.8.
===
Subject: Re: [BUG] 2.5.59 Same problems as 55..58
From: Bill Davidsen (davidsen@tmr.com)
Date: Mon Jan 27 2003 - 06:48:26 EST
Mikael Pettersson wrote:
> On Sat, 25 Jan 2003 18:26:29 -0500 (EST), Bill Davidsen wrote:
> >WARNING: /lib/modules/2.5.59/kernel/drivers/net/8390.ko needs unknown symbol crc32_le
> >WARNING: /lib/modules/2.5.59/kernel/drivers/net/8390.ko needs unknown symbol bitreverse
> > .
> > . And this problem I've noted since 2.5.55
>
> If your module-init-tools are older than 0.9.8, then this message
> is expected. depmod doesn't find GPL only symbols. Fixed in 0.9.8.
I was on 0.9.9pre infortunately, but thanks much for the suggestion. I've
been keeping reasonably current, in hopes of solutions to other issues. I
suspect that this is caused by having CRC32 built-in instead of as a
module or vice-versa. I just ran out of time to test all possible
combinations.
===