| Summary: | Kernel module packages call to depmod generates a warning about missing modules.* files | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Mark Hatle <mark.hatle> |
| Component: | kernel | Assignee: | Mark Hatle <mark.hatle> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Undecided | CC: | bruce.ashfield, tom.zanussi |
| Version: | 1.4 | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Mark Hatle
2013-02-28 17:56:26 UTC
I proposed a possible change to add the two missing files to the 'kernel-base' package. While it's not clear yet if this is the right approach, the following is part of the exchange between myself and Bruce. >>> modules.order >>> -------------------------------------------------- >>> This file records the order in which modules appear in Makefiles. This >>> is used by modprobe to deterministically resolve aliases that match >>> multiple modules. >>> >>> modules.builtin >>> -------------------------------------------------- >>> This file lists all modules that are built into the kernel. This is used >>> by modprobe to not fail when trying to load something builtin. >>> >>> But I'm also not sure if kernel-base is the right package for them. They >>> are definitely an output of building the kernel, and are in the object >>> tree .. kernel-modules would be a potential package to contain them, but >>> it isn't always installed into the image .. in particular for those that >>> use the individual module packages. >>> >>> Out of tree modules don't update this file, since it is in the kernel >>> build tree .. not the module one. Since there are often out of tree >>> modules being built, I can see that the value of the file is lessened, >>> since it won't list the ordering of all modules in the system .. which >>> is why it may be removed at the moment. >>> >>> I'll poke at this a bit more tomorrow as well. >> >> I looked around again this morning, and it is true that the files were >> simply being removed to fix the "not shipped warnings" that are generated >> otherwise .. not for a fundamental issue with the files. But that of >> course is the trigger for the warning that you are looking at now. >> >> What phase of the build are you seeing the modules.order warning ? >> It's the rpm's being installed into the rootfs ? And is it to the >> screen, or buried in the log files (I've never noticed it before). > > Ya, during package install, do_rootfs task. > > They are not causing failures, so the messages are ending up in the > do_rootfs log and not causing any failures to the screen. > >> I'm just wondering, since I'm still not sure that kernel-base is >> the right place for those files to be packaged and the phase that you >> are seeing the warning might stir up some packaging options. > > I'm not sure either. It just happened to be the only package that all > of the modules automatically depended on. > >> So from that angle, I don't have any problem with the files being >> added, they won't hurt anything by being present. >> >> It also looks like out of tree modules won't have any issues with >> updating or handling the modules.order files, since they'll either >> create their own (in their obj dir), or ignore the main one. > > My plan is to generate a couple of YP bugs, and send up these changes to > the oe-core list. This particular one will likely need more discussion. Works for me. I think the changes are sane, but we need to hear about more use cases and opinions. Change has been merged into oe-core: bff4bda1fe86ddd218a192a14605924205a5300b |