[kernel]after stable to testing upgrade image and modules not in sync

[vnevoa]

There are kernel modules in the file system that are not loadable because they are already built in. If the modules are built-in, they should not be present in the filesystem, IMHO.

This confuses the hell out of users that are trying to follow the wiki howtos (BT networking, for example), and also delays the bootup and fills the logs with false error messages about failed module loadings.

Reproducing: "modprobe bnep"

My software is:
uname -a = "Linux om-gta02 2.6.24 #1 PREEMPT Wed Sep 3 19:01:18 CST 2008 armv4tl unknown"
Om2008.8-gta02-20080826.uImage02.bin
Om2008.8-gta02-20080902.rootfs.jffs2

My opkg feeds are:
src/gz daily-Multiverse ​http://downloads.openmoko.org/repository/Multiverse
src/gz om-dev-all ​http://downloads.openmoko.org/repository/testing/all
src/gz om-dev-armv4t ​http://downloads.openmoko.org/repository/testing/armv4t
src/gz om-dev-om-gta02 ​http://downloads.openmoko.org/repository/testing/om-gta02
src/gz testing-all ​http://downloads.openmoko.org/repository/testing/all
src/gz testing-armv4t ​http://downloads.openmoko.org/repository/testing/armv4t
src/gz testing-om-gta02 ​http://downloads.openmoko.org/repository/testing/om-gta02

Failed modules that I know of:
bnep, bluetooth, l2cap

Please clean up the built-in modules from the fs images on the
downloads server so they are consistent with the given kernel.
Thank you! Keep up the good work.

[zecke]

Om2008.8-gta02-20080902.rootfs.jffs2 what kind of image is that? An URL to it would help. Is that a stable image and then you upgraded to a testing/unstable feed?

Does this happen with installing a fresh testing image and kernel or is this a product of upgrades switching from stable to testing?

[vnevoa]

Sorry, the info is incomplete and even wrong. Here's the real deal.

The images were taken from:
​http://downloads.openmoko.org/releases/Om2008.8-update/Om2008.8-gta02-20080902.rootfs.jffs2
​http://downloads.openmoko.org/releases/Om2008.8-update/Om2008.8-gta02-20080826.uImage.bin

And then I added the "testing" opkg feeds and upgraded:
​http://downloads.openmoko.org/repository/testing/all
​http://downloads.openmoko.org/repository/testing/armv4t
​http://downloads.openmoko.org/repository/testing/om-gta02

I also have these feeds from the original fs image:
​http://downloads.openmoko.org/repository/Om2008.8/all
​http://downloads.openmoko.org/repository/Om2008.8/armv4t
​http://downloads.openmoko.org/repository/Om2008.8/om-gta02
​http://downloads.openmoko.org/repository/Multiverse

[vnevoa]

What is a "testing image"? From /releases/Om2008.8-update or from somewhere else?
I'm not sure this happens on a fresh install, but I remember seeing kernel warnings about modules during bootup just before X kicks in. Before I added the testing repos.

[zecke]

On org.openmoko.asu.stable we use the machine class to build one kernel for gta01 and gta02 (neo1973), on org.openmoko.dev we should do the same. I think currently we don't and the defconfig-2.6.24 and defconfig-gta02 are different which would explain the issue. Please investigate.

[haduong@…]

From what I understand (i.e. not much), it seems that:
The new kernel package of the ".dev" branch in the "testing" repository should be marked as conflicting with the old module packages of the ".stable" branch in the "Om2008.8" and "Om2008.8-updates" repositories.
So that upgrading the kernel uninstalls the old module packages.

Another solution: the old module packages should require the old kernel, so that when the kernel is replaced, the modules have to go too ?

In any case, let me know what to write in the wiki. Is it that in the new release the modules are included in the kernel package ? Or is it that they are compiled in ?

Thanks

[zecke]

Well. org.openmoko.dev (testing and unstable:

• Should be build with BB_GIT_CLONE_FOR_SRCREV = "1"
• and the kernel should have PACKAGE_ARCH of neo1973 too..

but this is just one of the many issues that need to be fixed for the Om2008.9 to org.openmoko.dev upgrade path.

[john_lee]

Next stable image will be generated directly from a branch of om.dev with BB_GIT_CLONE_FOR_SRCREV enabled. This issue (along with many others) should be gone with it. Also the PE in om.dev was increased so the upgrade path should be fine now in this case.