Created attachment 1410108 [details] Custom kernel configuration used to build the kernel Description of problem: When building the kernel using rpmbuild, utilising custom configuration in kernel-local, the kernel build fails (see below). This error may have stem from the merging (merge.pl?) customised kernel settings with the rest of the parameters. This isn't something new. A few years back, I've logged a very similar bug, as a result of which "config-local" was added as part of the kernel build, which solved the problem (I see this has now changed to "kernel-local"). Version-Release number of selected component (if applicable): 4.15.10-300.fc27 How reproducible: Always Steps to Reproduce (assuming mock and rpmbuild-tools dependencies are installed): 1. rpmbuild -bp --with smp --without debug --without doc --without debuginfo --without firmware --with perf --target=`uname -m` kernel.spec 2. cp custom.config ~/build/BUILD/kernel-4.15.fc27/linux-4.15.10-300.fc27.x86_64/.config 3. cd ~/build/BUILD/kernel-4.15.fc27/linux-4.15.10-300.fc27.x86_64/ 4. make oldconfig 5. cp .config ~/build/SOURCES/kernel-local 6. cd ~/build/SPECS 7. rpmbuild -bb --with smp --without debug --without doc --without debuginfo --without firmware --with perf --target=`uname -m` kernel.spec Actual results: depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_read_oob depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_writev depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_kmalloc_up_to depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_unpoint depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mount_mtd depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol kill_mtd_super depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_block_markbad depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_write_oob depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_read depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_erase depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_write depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_block_isbad depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/fs/jffs2/jffs2.ko needs unknown symbol mtd_point depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/video/backlight/pcf50633-backlight.ko needs unknown symbol pcf50633_reg_write depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/video/fbdev/sm501fb.ko needs unknown symbol sm501_unit_power depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/video/fbdev/sm501fb.ko needs unknown symbol sm501_modify_reg depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/video/fbdev/sm501fb.ko needs unknown symbol sm501_set_clock depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/video/fbdev/sm501fb.ko needs unknown symbol sm501_misc_control depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusbhc_reset_all depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusbhc_rh_status_data depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusbhc_b_create depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusbhc_create depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusbhc_destroy depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusbhc_handle_dn depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusbhc_b_destroy depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol whci_wait_for depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusbhc_rh_start_port_reset depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol umc_driver_unregister depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusbhc_giveback_urb depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusb_cluster_id_get depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol __umc_driver_register depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusbhc_rh_control depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol wusb_cluster_id_put depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol uwb_rc_get_by_grandpa depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/whci/whci-hcd.ko needs unknown symbol uwb_rc_put depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/u132-hcd.ko needs unknown symbol usb_ftdi_elan_edset_setup depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/u132-hcd.ko needs unknown symbol ftdi_elan_gone_away depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/u132-hcd.ko needs unknown symbol usb_ftdi_elan_edset_single depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/u132-hcd.ko needs unknown symbol usb_ftdi_elan_edset_empty depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/u132-hcd.ko needs unknown symbol usb_ftdi_elan_edset_input depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/u132-hcd.ko needs unknown symbol usb_ftdi_elan_read_pcimem depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/u132-hcd.ko needs unknown symbol usb_ftdi_elan_edset_flush depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/u132-hcd.ko needs unknown symbol usb_ftdi_elan_write_pcimem depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/usb/host/u132-hcd.ko needs unknown symbol usb_ftdi_elan_edset_output depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/input/misc/pcf50633-input.ko needs unknown symbol pcf50633_register_irq depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/input/misc/pcf50633-input.ko needs unknown symbol pcf50633_reg_read depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/input/misc/pcf50633-input.ko needs unknown symbol pcf50633_free_irq depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/hwmon/iio_hwmon.ko needs unknown symbol iio_get_channel_type depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/hwmon/iio_hwmon.ko needs unknown symbol iio_channel_get_all depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/hwmon/iio_hwmon.ko needs unknown symbol iio_channel_release_all depmod: WARNING: /builddir/build/BUILDROOT/kernel-4.15.10-300.fc27.x86_64/./lib/modules/4.15.10-300.fc27.x86_64/kernel/drivers/hwmon/iio_hwmon.ko needs unknown symbol iio_read_channel_processed Expected results: Kernel build to succeed. Additional info: See custom.config attached for the custom settings used.
It's hard to say without knowing exactly what options you changed but almost certainly it's a filtering issue. To do a split between kernel-core and kernel-modules, we use a set of scripts filter-module.sh. You may need to filter or unfilter modules depending on what you enabled. Bugzilla also isn't the appropriate forum for issues with building custom kernels so in the future please use the fedora kernel mailing list or IRC.
(In reply to Laura Abbott from comment #1) > It's hard to say without knowing exactly what options you changed but almost > certainly it's a filtering issue. merge.pl (again) or the filter-*.sh scripts? > To do a split between kernel-core and > kernel-modules, we use a set of scripts filter-module.sh. You may need to > filter or unfilter modules depending on what you enabled. Is it possible to exclude any additional "filtering" and have the kernel (and its modules) built the "old-fashioned" way (circa F15) where all modules go in a separate - single - package. I am not really fussed how kernel modules are organised and in what packages, simply because I will include them all in the final build, so it would be easier to have them in one place, if possible. I can't comment on the rationale behind splitting the modules in multiple packages, but this, evidently, makes it extremely inflexible for community developers that wish to configure their own builds and also, as evident from the above, is highly prone to errors. > Bugzilla also isn't the appropriate forum for issues with building custom > kernels so in the future please use the fedora kernel mailing list or IRC. I am really surprised and disappointed by the above comment. I find it rather flippant, quite frankly. The kernel source, together with its build tools is there for us, the community to experiment, develop, test and, of course, contribute, hence why there is a lot of documentation and guides on how to do that. Custom builds were always encouraged and supported by the likes of Fedora and Red Hat before it. I, myself, submitted a number of bugs to do with the actual build of the kernel in the past, and I'd like to think I've contributed to the improvement of the kernel build process as a result, so to have the kind of response like the above isn't acceptable.
(In reply to Mr Dash Four from comment #2) > (In reply to Laura Abbott from comment #1) > > It's hard to say without knowing exactly what options you changed but almost > > certainly it's a filtering issue. > merge.pl (again) or the filter-*.sh scripts? > > > To do a split between kernel-core and > > kernel-modules, we use a set of scripts filter-module.sh. You may need to > > filter or unfilter modules depending on what you enabled. > Is it possible to exclude any additional "filtering" and have the kernel > (and its modules) built the "old-fashioned" way (circa F15) where all > modules go in a separate - single - package. > > I am not really fussed how kernel modules are organised and in what > packages, simply because I will include them all in the final build, so it > would be easier to have them in one place, if possible. > > I can't comment on the rationale behind splitting the modules in multiple > packages, but this, evidently, makes it extremely inflexible for community > developers that wish to configure their own builds and also, as evident from > the above, is highly prone to errors. > The change was made well before my time but the intention was to allow a 'core' set of modules to be installed for packages like cloud. We don't currently support turning off the filtering because it's too tightly coupled with how we package things. If you have questions on things you don't understand, we can try to answer them. > > Bugzilla also isn't the appropriate forum for issues with building custom > > kernels so in the future please use the fedora kernel mailing list or IRC. > I am really surprised and disappointed by the above comment. I find it > rather flippant, quite frankly. > > The kernel source, together with its build tools is there for us, the > community to experiment, develop, test and, of course, contribute, hence why > there is a lot of documentation and guides on how to do that. > > Custom builds were always encouraged and supported by the likes of Fedora > and Red Hat before it. I, myself, submitted a number of bugs to do with the > actual build of the kernel in the past, and I'd like to think I've > contributed to the improvement of the kernel build process as a result, so > to have the kind of response like the above isn't acceptable. This wasn't intended to be flippant, the goal was to find a better place for your problem. The primary people who look at bugzilla are the kernel maintainers. There are 3 of us vs. a whole bunch more users. The community who are subscribed to the Fedora kernel mailing list and on IRC are very helpful and might be able to provide suggestions for your problem since they are more likely to do custom kernel builds. Bugzilla works best for specific problems where the kernel maintainers can take action.
(In reply to Laura Abbott from comment #3) > (In reply to Mr Dash Four from comment #2) > > (In reply to Laura Abbott from comment #1) > > > It's hard to say without knowing exactly what options you changed but almost > > > certainly it's a filtering issue. > > merge.pl (again) or the filter-*.sh scripts? Any thoughts on this? > The change was made well before my time but the intention was to allow a > 'core' set of modules to be installed for packages like cloud. We don't > currently support turning off the filtering because it's too tightly coupled > with how we package things. If that is the case, then the filtering needs to be capable of allowing/reading the relevant values from .config instead of assuming things - the "kernel-local" (the successor of "config-local") is provided for this very purpose, but, evidently, that support is completely broken. > This wasn't intended to be flippant, the goal was to find a better place for > your problem. The primary people who look at bugzilla are the kernel > maintainers. There are 3 of us vs. a whole bunch more users. The community > who are subscribed to the Fedora kernel mailing list and on IRC are very > helpful and might be able to provide suggestions for your problem since they > are more likely to do custom kernel builds. Bugzilla works best for specific > problems where the kernel maintainers can take action. I don't need advice - I just need the problem reported to be fixed in the kernel build, that's all.
(In reply to Mr Dash Four from comment #4) > (In reply to Laura Abbott from comment #3) > > (In reply to Mr Dash Four from comment #2) > > > (In reply to Laura Abbott from comment #1) > > > > It's hard to say without knowing exactly what options you changed but almost > > > > certainly it's a filtering issue. > > > merge.pl (again) or the filter-*.sh scripts? > Any thoughts on this? > > > The change was made well before my time but the intention was to allow a > > 'core' set of modules to be installed for packages like cloud. We don't > > currently support turning off the filtering because it's too tightly coupled > > with how we package things. > If that is the case, then the filtering needs to be capable of > allowing/reading the relevant values from .config instead of assuming things > - the "kernel-local" (the successor of "config-local") is provided for this > very purpose, but, evidently, that support is completely broken. > > > This wasn't intended to be flippant, the goal was to find a better place for > > your problem. The primary people who look at bugzilla are the kernel > > maintainers. There are 3 of us vs. a whole bunch more users. The community > > who are subscribed to the Fedora kernel mailing list and on IRC are very > > helpful and might be able to provide suggestions for your problem since they > > are more likely to do custom kernel builds. Bugzilla works best for specific > > problems where the kernel maintainers can take action. > I don't need advice - I just need the problem reported to be fixed in the > kernel build, that's all. The problem you reported is not a problem. The kernel maintainers are not going to fix this. Patches welcome to support this in a general sense in the filter mechanism would of course be welcome.
Yes, if you have patches to update the filtering mechanism, we'd certainly take them but it's necessary for what we have to do right now. I'm going to close this bug as there's nothing actionable for us to do. *** This bug has been marked as a duplicate of bug 126342 ***
(In reply to Laura Abbott from comment #6) > Yes, if you have patches to update the filtering mechanism, we'd certainly > take them but it's necessary for what we have to do right now. Yes, I do - I was able to remove most of the mindless guff in kernel.spec and filter-*.sh files, then build the kernel last night without encountering the problems I reported above. As for submitting my patches - no, I won't do that. If Fedora takes the attitute "everyone for themselves", then I can't be bothered either, so there, which is sad. Community development (and support) is a two-way street - you can't ask for patches and at the same time come up with the attitute evident from your and Josh' responses above. You can't have your cake and eat it.