Due to intermittent support of ck-sources in portage, I have been patching my kernel source tree manually with the broken-out tarball from http://ck.kolivas.org/patches/3.0/ for quite some time. Pretty sure I am not the only one :) Anyway, since about a month of so ago, I noticed that packages such as app-emulation/virtualbox-modules install the .ko files in the wrong directory, e.g. /lib/modules/3.10.5 instead of /lib/modules/3.10.5-ck1 when `uname -r` returns 3.10.5-ck1. This weird behavior is likely caused by the following change to linux-info.eclass to use getfilevar_noexec: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/linux-info.eclass?r1=1.101&r2=1.102&view=patch In http://ck.kolivas.org/patches/3.0/3.11/3.11-ck1/patches/ck1-version.patch, we have: +CKVERSION = -ck1 +CKNAME = BFS Powered +EXTRAVERSION := $(EXTRAVERSION)$(CKVERSION) and getfilevar_noexec can't deal with that. Changing to getfilevar make things work again for me. Reproducible: Always Steps to Reproduce: 1. Manually apply some kernel patches that does "EXTRAVERSION := xxx" 2. Emerge some packages that use linux-mod.eclass 3. Notice modules get installed in wrong directory
Might need this fixed when I bring ck to the experimental tarball of genpatches.
This could be more info and procedure / methodology than absolutely required for a test, but it may help? Attempted to reproduce: 1) Fresh emerge of sys-kernel/ck-sources-4.9.4 maximum freshness: I removed all content under /usr/src prior to step #1 (low risk, since several working kernels were already installed) 2) [ eselect kernel set ], and verify the correct symlink for /usr/src/linux > $ pwd > /usr/src > $ ls -l > lrwxrwxrwx 1 root root 14 Jan 17 01:21 linux -> linux-4.9.4-ck 3) manually applied a patch which makes an alteration to the kernel Makefile > EXTRAVERSION = -100hz-dyntick-muqss-nvidia-final Note: I do this "verbose kernel name" step for all kernels I use on gentoo, not just ck-sources. This build is the first (and only) time for ck-sources-4.9.4 for which I felt the .config was stable enough to add "-final" to EXTRACONFIG Not relevant for the purpose of this test, other than elimination of any false negatives, ambiguity, etc. 4) build kernel as per usual, [un]mounting of /boot and grub-mkconfig, lilo, etc. as appropriate > make && make modules_install && make install 5) emerge @module-rebuild --verbose --ask 6) confirmed the installation / presence of relevant modules, and rebooted > $ pwd > /lib/modules/4.9.4-100hz-dyntick-muqss-nvidia-final/video > $ ls > nvidia-drm.ko nvidia.ko nvidia-modeset.ko nvidia-uvm.ko ^ specifically, I've confirmed the presence of the .ko from x11-drivers/nvidia-drivers which uses linux-mod.eclass 7) confirm which kernel is running > $ cat /proc/version > Linux version 4.9.4-100hz-dyntick-muqss-nvidia-final (kuzetsa@soyokaze) (gcc version 4.9.4 (Gentoo 4.9.4 p1.0, pie-0.6.4) ) #1 SMP PREEMPT Fri Jan 20 01:27:07 EST 2017 > $ uname -a > Linux soyokaze 4.9.4-100hz-dyntick-muqss-nvidia-final #1 SMP PREEMPT Fri Jan 20 01:27:07 EST 2017 x86_64 Intel(R) Core(TM) i3-2357M CPU @ 1.30GHz GenuineIntel GNU/Linux 8) confirm the modules are working with [ lspci -k ] > 01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 540M] (rev a1) > Subsystem: Dell GF108M [GeForce GT 540M] > Kernel driver in use: nvidia > Kernel modules: nvidia_drm, nvidia (I'm currently using xorg / browser) Result: The correct directory (the one which would be used for modules / drivers while booted into the resulting kernel) was correctly determined portage, and used in the usual way during module [re]installation by the command: [ emerge @module-rebuild ]
I may have been confused, and am uncertain if my specific test confirms [mis]behavior from getfilevar_noexec (though the package which provides my video drivers does use linux-mod.eclass for determining where to install the kernel modules) > Reproducible: Always > > Steps to Reproduce: > 1. Manually apply some kernel patches that does "EXTRAVERSION := xxx" > 2. Emerge some packages that use linux-mod.eclass > 3. Notice modules get installed in wrong directory ^ That is to say: It's possible that I may have misunderstood item #2 on this list (specifically, the way in which linux-mod.eclass is used)
I can reproduce this bug: - emerge =sys-kernel/ck-sources-4.9.4 - Edit '/usr/src/linux-4.9.5-ck/Makefile' and uncomment 'EXTRAVERSION := $(EXTRAVERSION)$(CKVERSION)' - emerge 'app-emulation/virtualbox-modules' The kernel modules are located under '/lib/modules/4.9.5-ck-ck1' but the virtualbox modules are installed under '/lib/modules/4.9.5-ck/' which is not a valid path.
The sys-kernel/ck-sources ebuilds explicitly have a workaround for this bug. Thanks. The bug applies to any kernel patch which sets EXTRAVERSION to a non-static value. (rather than a static string literals, if it's set to a variable) I don't have the relevant edit status so I can't rename this bug. The title of this bug should reflect that it's a bug with the handling of EXTRAVERSION (it's nothing specific to ck-sources)
Switching to the non "_noexec" variant should should fix the problem.
I can't reproduce this, as ck-sources as evolved, even in the different overlays. If this is still reproducible please, reopen.
Reopening this as the behavior is still reproducible. With a kernel Makefile that looks like this: VERSION = 5 PATCHLEVEL = 12 SUBLEVEL = 19 EXTRAVERSION = NAME = Frozen Wasteland ... CKVERSION = -ck1 CKNAME = MuQSS Powered EXTRAVERSION := $(EXTRAVERSION)$(CKVERSION) emerging let's say sys-power/acpi_call-1.2.1 will end up putting the module acpi_call.ko under /lib/modules/5.12.19 when it should be /lib/modules/5.12.19-ck1
Can you confirm what I see? I emerge ck-sources-5.12.19 and I have /usr/src/linux -> linux-5.12.19-ck Then I build it, make -jX && make modules_install and I have: /lib/modules/5.12.19-ck-ck1 When I try to install acpi_call it tried to install into /lib/modules/5.12.19-ck/acpi_call.ko All good so far?
Nevermind, I got it
I don't see a way of doing this. If I maintained ck-sources, I would add a patch to properly support EXTRAVERSION = -ck-ck1 as a string literal
It works fine for me if I revert https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/eclass/linux-info.eclass?id=ab160a941f5f52c95b47129d3243c693b05401e5 (alternative URL to the same commit that I mentioned in the bug description)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d1ea596f034285cd044006b107a60902ea059793 commit d1ea596f034285cd044006b107a60902ea059793 Author: Mike Pagano <mpagano@gentoo.org> AuthorDate: 2021-09-02 10:58:49 +0000 Commit: Mike Pagano <mpagano@gentoo.org> CommitDate: 2021-09-02 10:59:48 +0000 linux-info.eclass: Support Makefiles that set vars to a non-static value Previously, the Makefile had to define version variables be a string literal. This change will support both methods. Closes: https://bugs.gentoo.org/490328 Signed-off-by: Mike Pagano <mpagano@gentoo.org> eclass/linux-info.eclass | 13 +++++-------- 1 file changed, 5 insertions(+), 8 deletions(-)
latest commit causes problems here. anything that uses linux-info.elcass now pops up with a warning "cant get kernel version". if it matters im in chroot and kernel sources are fresh and unconfigured. ive noticed this ith libomp, dbs and elogind for sure. reverting the latest comits and going back to "getfilevar_noexec" solves the issue and kernel version is now detected.
Yeah, it looks like using `getfilevar` can be problematic for some cases. I guess we can either revert to how it was before https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/eclass/linux-info.eclass?id=ab160a941f5f52c95b47129d3243c693b05401e5 by relying on `get_makefile_extract_function`, or go back to using `getfilevar_noexec` and close this as WONTFIX.
(In reply to Sok Ann Yap from comment #15) > Yeah, it looks like using `getfilevar` can be problematic for some cases. I > guess we can either revert to how it was before > https://gitweb.gentoo.org/repo/gentoo/historical.git/commit/eclass/linux- > info.eclass?id=ab160a941f5f52c95b47129d3243c693b05401e5 by relying on > `get_makefile_extract_function`, or go back to using `getfilevar_noexec` and > close this as WONTFIX. if this turns out to just be an issue when in chroot...perhaps have a conditional check. if it detects us in a chroot then use the old behavior. else use the new behavior. i dont know how to implement it. i dont even know if it would work. its just the first thing that came to mind.
(In reply to jeremy mills from comment #14) > latest commit causes problems here. anything that uses linux-info.elcass now > pops up with a warning "cant get kernel version". if it matters im in chroot > and kernel sources are fresh and unconfigured. ive noticed this ith libomp, > dbs and elogind for sure. reverting the latest comits and going back to > "getfilevar_noexec" solves the issue and kernel version is now detected. What are you installing from a chroot that caused an error? So you don't have a .config ?
(In reply to Mike Pagano from comment #17) > (In reply to jeremy mills from comment #14) > > latest commit causes problems here. anything that uses linux-info.elcass now > > pops up with a warning "cant get kernel version". if it matters im in chroot > > and kernel sources are fresh and unconfigured. ive noticed this ith libomp, > > dbs and elogind for sure. reverting the latest comits and going back to > > "getfilevar_noexec" solves the issue and kernel version is now detected. > > What are you installing from a chroot that caused an error? > > So you don't have a .config ? i noticed it when installing elogind, dbus and libomp. im in the middle of a stage3 install. and yes thats correct...no .config. kernel sources arent configured yet. im ~amd64 keyworded too if it makes a difference...i dont think that triggered it though...ive always upgraded to unstable keywords during stage3 installs.
(In reply to Mike Pagano from comment #17) > (In reply to jeremy mills from comment #14) > > latest commit causes problems here. anything that uses linux-info.elcass now > > pops up with a warning "cant get kernel version". if it matters im in chroot > > and kernel sources are fresh and unconfigured. ive noticed this ith libomp, > > dbs and elogind for sure. reverting the latest comits and going back to > > "getfilevar_noexec" solves the issue and kernel version is now detected. > > What are you installing from a chroot that caused an error? > > So you don't have a .config ? i do think your onto something though asking if i had a .config. i just went an ran make defconfig and then emerge libomp again...and it found the kernel version correctly this time. ill check dbus and elogind...but im sure the lack of .config was the issue
ok i narrowed it down. it happens when the kernel sources are unconfigured only. the .config appears to not be relavent. default unconfigured kernel sources = kernel version not found after make defconfig = kernel version found so i went and deleted the .config but didnt run make clean && make mrproper. emerge libomp dbus and elogind...kernel version still found. so the for the heck of it i went and ran make clean && make mrproper. then emerge libomp, dbus and elogind again...all three report kernel version not found again.
Just ran into this today. I am not running from a chroot. I do copy /usr/src/linux-5.11 to /tmp to do the compiling. So I do have a .config file, but everything else is left in a "make clean" state, in the directory where it searches. As others have found out it involves the change to getfilevar from getfilevar_noexec. Works just like it used to with getfilevar changed to getfilevar_noexec
Put a trace in the linux-info.eclass and this is returned $ echo -e 'e:\n\t@echo $(VERSION)\ninclude Makefile' | make -C /usr/src/linux-5.11 M=/var/tmp/portage/dev-qt/qtcore-5.15.2-r3/temp -s -f - ERROR: Kernel configuration is invalid. include/generated/autoconf.h or include/config/auto.conf are missing. Run 'make oldconfig && make prepare' on kernel src to fix it. make: *** [Makefile:718: include/config/auto.conf] Error 1 So it looks like when one runs with a cleaned src, it can't find a either of the autogenerated files (which make sense in a clean env). So I can work around it by running make prepare, but that's not ideal, and there's more than just me with this "odd" setup.
(In reply to Don O from comment #22) > Put a trace in the linux-info.eclass and this is returned > > $ echo -e 'e:\n\t@echo $(VERSION)\ninclude Makefile' | make -C > /usr/src/linux-5.11 M=/var/tmp/portage/dev-qt/qtcore-5.15.2-r3/temp -s -f - > > ERROR: Kernel configuration is invalid. > include/generated/autoconf.h or include/config/auto.conf are > missing. > Run 'make oldconfig && make prepare' on kernel src to fix it. > > make: *** [Makefile:718: include/config/auto.conf] Error 1 > > So it looks like when one runs with a cleaned src, it can't find a either of > the autogenerated files (which make sense in a clean env). > > So I can work around it by running make prepare, but that's not ideal, and > there's more than just me with this "odd" setup. i noticed there was some commits to linux-info.eclass over the last few days. i havent tried them out yet. but ill been checking it this evening after work.
this seems to have been fixed..at least in my case by https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass?id=ab005b2b0219f266a90891fa3cce8253014927db
(In reply to jeremy mills from comment #24) > this seems to have been fixed..at least in my case by > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > eclass?id=ab005b2b0219f266a90891fa3cce8253014927db Thank-you for the report, Jeremy