Ticket #1967 (closed defect: fixed)

Opened 11 years ago

Last modified 10 years ago

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

Reported by: vnevoa Owned by: julian_chu
Priority: normal Milestone:
Component: Distro Version:
Severity: normal Keywords: kernel modules
Cc: vasco.nevoa@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible: always


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"

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.

Change History

comment:1 Changed 11 years ago by 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?

comment:3 in reply to: ↑ 2 Changed 11 years ago by 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.

comment:4 Changed 11 years ago by zecke

  • Owner changed from openmoko-devel to julian_chu
  • Version changed from Om2008.8 to Om2008.9-dev
  • Component changed from unknown to Distro
  • Summary changed from [kernel] image and modules not in sync to [kernel]after stable to testing upgrade image and modules not in sync

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.

comment:5 Changed 11 years ago by 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 ?


comment:6 Changed 11 years ago by 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.

comment:7 Changed 10 years ago by john_lee

  • Status changed from new to closed
  • Severity changed from blocker to normal
  • HasPatchForReview unset
  • Priority changed from highest to normal
  • Version Om2008.9-dev deleted
  • Resolution set to fixed

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.

Note: See TracTickets for help on using tickets.