When a kernel module package is installed, the call to depmod (provided by kmod) causes two warning messages, one relating to modules.order and the other to modules.buildins. These files are never installed onto the target system, but the kmod depmod looks for them. Looking back at the reason these files are not packaged, a change was made to kernel.bbclass to simply remove them to quiet a warning message.
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