Discussion:
Problem with loading external kernel modules
Chris Ortner
2009-09-24 21:57:36 UTC
Permalink
I'm currently using the Angstrom uImage I obtained via Narcissus
(2.6.29-omap1) in combination with a custom Debian 5.0.3 rootfs on the
Rev C3 BeagleBoard. I didn't face any problems until it was necessary
to load modules which were not built directly into the kernel, namely
tun and fuse, causing such an error message:

FATAL: Error inserting tun (/lib/modules/2.6.29-omap1/kernel/drivers/
net/tun.ko): Invalid module format

The folder in which the modules reside was transferred over from
Angstrom as well, so I didn't expect there to be any problems. The
foolish attempt to use insert kernel build's modules failed for the
same reason (invalid module format).

To solve this problem I attempted to build an own kernel with built-in
support for tun and fuse from the official OMAP kernel repository's
source code, which resulted in failure as well as the builds were
unable to boot up, although I followed the instructions here
http://elinux.org/BeagleBoard#Linux_kernel precisely. I just added the
modules in question in menuconfig, nothing more.

Unfortunately, I can't investigate this any further since my serial
connection won't deliver more than ~3 lines of random characters per
connection, despite being properly configures. But that's another
story.

My questions:
1. Is it possible that uImages don't allow loading external modules?
2. If uImages allow loading external modules, why are they apparently
invalid although originating from the same build?
3. Is it possible to resolve this situation without building a new
kernel? If yes, how?
4. If there is no way around building a new kernel, what do I have to
pay attention to in order not to make the same mistakes again, ending
up with an unbootable kernel?

I'm grateful for all answers I can get.


Chris
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagleboard-/***@public.gmane.org
To unsubscribe from this group, send email to beagleboard+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en
-~----------~----~----~----~------~----~------~--~---
omkar Savagaonkar
2009-09-25 05:30:35 UTC
Permalink
First wild guess is... It seems a problem with toolchain the kernel and
modules built.
Modules must have built with other toolchain than kernel.
And why is it that you are using angstrom kernel and Debian custom FS?
Try same thing with everything from angstrom.

Regards,
Omkar

On Fri, Sep 25, 2009 at 3:27 AM, Chris Ortner
Post by Chris Ortner
I'm currently using the Angstrom uImage I obtained via Narcissus
(2.6.29-omap1) in combination with a custom Debian 5.0.3 rootfs on the
Rev C3 BeagleBoard. I didn't face any problems until it was necessary
to load modules which were not built directly into the kernel, namely
FATAL: Error inserting tun (/lib/modules/2.6.29-omap1/kernel/drivers/
net/tun.ko): Invalid module format
The folder in which the modules reside was transferred over from
Angstrom as well, so I didn't expect there to be any problems. The
foolish attempt to use insert kernel build's modules failed for the
same reason (invalid module format).
To solve this problem I attempted to build an own kernel with built-in
support for tun and fuse from the official OMAP kernel repository's
source code, which resulted in failure as well as the builds were
unable to boot up, although I followed the instructions here
http://elinux.org/BeagleBoard#Linux_kernel precisely. I just added the
modules in question in menuconfig, nothing more.
Unfortunately, I can't investigate this any further since my serial
connection won't deliver more than ~3 lines of random characters per
connection, despite being properly configures. But that's another
story.
1. Is it possible that uImages don't allow loading external modules?
2. If uImages allow loading external modules, why are they apparently
invalid although originating from the same build?
3. Is it possible to resolve this situation without building a new
kernel? If yes, how?
4. If there is no way around building a new kernel, what do I have to
pay attention to in order not to make the same mistakes again, ending
up with an unbootable kernel?
I'm grateful for all answers I can get.
Chris
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagleboard-/***@public.gmane.org
To unsubscribe from this group, send email to beagleboard+unsubscribe-/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en
-~----------~----~----~----~------~----~------~--~---
Chris Ortner
2009-09-26 10:51:32 UTC
Permalink
Thanks for the response. Loading modules with everything-Angstrom
worked fine.
Post by omkar Savagaonkar
Modules must have built with other toolchain than kernel.
Keeping this in mind I cleaned up the messy Angstrom/Debian mixture by
installing a kernel .deb for the BeagleBoard, extracting the .deb and
making a uImage from the vmlinuz, following parts of these
instructions: http://elinux.org/BeagleBoardDebian#Development_PC:_Linux_Kernel_Preparation
Loading external modules works fine now.
Post by omkar Savagaonkar
And why is it that you are using angstrom kernel and Debian custom FS?
I settled for this solution after creating multiple unbootable uImages
for a Debian installation I previously made in a virtual ARM machine.
Now that I have a working Debian kernel this dirty workaround is no
longer necessary.

Chris
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Beagle Board" group.
To post to this group, send email to beagleboard-/***@public.gmane.org
To unsubscribe from this group, send email to beagleboard+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en
-~----------~----~----~----~------~----~------~--~---

Loading...