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 <[email protected]>
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.
On Sat, 18 Jan 2003 14:46:53 -0500 (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?
/Mikael
--- 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
On Mon, Jan 20, 2003 at 03:57:22PM +0100, 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.
regards
john
--
"Anyone who quotes Rusty in their sig is an idiot."
- me
On Mon, Jan 20, 2003 at 03:52:50PM +0000, 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.
Sam
On Mon, Jan 20, 2003 at 08:12:50PM +0100, 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/[email protected]?nav=!-|index.html|stats|!+|index.html|ChangeSet
and in fact you're mentioned on it ..
regards
john
--
"Anyone who quotes Rusty in their sig is an idiot."
- me
On Mon, Jan 20, 2003 at 07:19:21PM +0000, John Levon wrote:
> Ooops, I was mis-remembering commit logs. I meant :
>
> http://linus.bkbits.net:8080/linux-2.5/user=kai/[email protected]?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]
Sam
On Mon, Jan 20, 2003 at 08:35:46PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 20, 2003 at 07:19:21PM +0000, John Levon wrote:
> > Ooops, I was mis-remembering commit logs. I meant :
> >
> > http://linus.bkbits.net:8080/linux-2.5/user=kai/[email protected]?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.
Michal
On Mon, 20 Jan 2003, Michal Jaegermann wrote:
> On Mon, Jan 20, 2003 at 08:35:46PM +0100, Sam Ravnborg wrote:
> > On Mon, Jan 20, 2003 at 07:19:21PM +0000, John Levon wrote:
> > > Ooops, I was mis-remembering commit logs. I meant :
> > >
> > > http://linus.bkbits.net:8080/linux-2.5/user=kai/[email protected]?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.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
In message <[email protected]> you write:
> As to why the .o -> .ko name change was necessary, I have no idea.
> Rusty?
It's getting furthur and furthur from a normal .o. Kai actually did
the patch (that, of course, is what the K stands for 8).
Hope that helps,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
On Tue, 28 Jan 2003, Rusty Russell wrote:
> In message <[email protected]> you write:
> > As to why the .o -> .ko name change was necessary, I have no idea.
> > Rusty?
>
> It's getting furthur and furthur from a normal .o. Kai actually did
> the patch (that, of course, is what the K stands for 8).
Yeah, I think I noted that .ko was a good idea, just to prevent confusion.
However, the original post I made was sort of a subtle hint, let me stop
beating around the bush: how about adding mkinitrd to the other module
stuff before 0.9.9 is really released, using the same .old technique used
for insmod et al? It would allow people doing testing of both 2.4 and 2.5
kernels to stop fighting build issues.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
In message <[email protected]> you w
rite:
> beating around the bush: how about adding mkinitrd to the other module
> stuff before 0.9.9 is really released, using the same .old technique used
> for insmod et al? It would allow people doing testing of both 2.4 and 2.5
> kernels to stop fighting build issues.
Hmm, unlike modutils, I've never even used mkinitrd, let alone read
the code (mmm... shell... yum!). For that reason alone I'm not the
guy to take it over (plus, I'm extremely lazy).
Herbert, I'd be happy to discuss any mkinitrd changes, or put a patch
into module-init-tools (or the FAQ?).
Thanks!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
On Wed, Jan 29, 2003 at 11:48:17AM +1100, Rusty Russell wrote:
> In message <[email protected]> you w
> rite:
> > beating around the bush: how about adding mkinitrd to the other module
> > stuff before 0.9.9 is really released, using the same .old technique used
> > for insmod et al? It would allow people doing testing of both 2.4 and 2.5
> > kernels to stop fighting build issues.
>
> Herbert, I'd be happy to discuss any mkinitrd changes, or put a patch
> into module-init-tools (or the FAQ?).
Actually, Debian's mkinitrd already works module-init-tools, I've got
it running here with 2.5.59. However, the original poster is probably
referring to the RedHat program with the same name but is completely
different.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
In message <[email protected]> you write:
> Actually, Debian's mkinitrd already works module-init-tools, I've got
> it running here with 2.5.59. However, the original poster is probably
> referring to the RedHat program with the same name but is completely
> different.
Ah, sorry for the confusion.
Thanks!
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
On Wed, 29 Jan 2003, Rusty Russell wrote:
> In message <[email protected]> you write:
> > Actually, Debian's mkinitrd already works module-init-tools, I've got
> > it running here with 2.5.59. However, the original poster is probably
> > referring to the RedHat program with the same name but is completely
> > different.
>
> Ah, sorry for the confusion.
So does this mean you are washing your hands of Redhat users, or that you
will convert the Debian package to tar or other portable format useful to
all users including non-debian?
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
In message <[email protected]> you w
rite:
> On Wed, 29 Jan 2003, Rusty Russell wrote:
> > Ah, sorry for the confusion.
>
> So does this mean you are washing your hands of Redhat users, or that you
> will convert the Debian package to tar or other portable format useful to
> all users including non-debian?
No, but I'm pretty sure it means that we don't want either mkinitrd
included in module-init-tools. I have no idea whether the two are
even compatible.
I certainly don't have the expertise to maintain either one: they both
seem to have happy, active maintainers who *do* know what they are
doing.
FYI, .deb files have the nice feature that they can be extracted using
standard tools: "file foo.deb" should tell it is a standard ar
archive.
Hope that helps,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.