Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 490328 - linux-info.eclass: The use of getfilevar_noexec is incorrect when EXTRAVERSION is defined multiple times in Makefile
Summary: linux-info.eclass: The use of getfilevar_noexec is incorrect when EXTRAVERSIO...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-04 00:31 UTC by Sok Ann Yap
Modified: 2021-09-07 11:32 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sok Ann Yap 2013-11-04 00:31:14 UTC
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
Comment 1 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-11-06 15:09:41 UTC
Might need this fixed when I bring ck to the experimental tarball of genpatches.
Comment 2 kuzetsa CatSwarm (kuza for short) 2017-01-20 07:50:01 UTC
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 ]
Comment 3 kuzetsa CatSwarm (kuza for short) 2017-01-20 08:21:38 UTC
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)
Comment 4 Göktürk Yüksek archtester gentoo-dev 2017-01-23 06:43:02 UTC
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.
Comment 5 kuzetsa CatSwarm (kuza for short) 2017-03-16 03:51:28 UTC
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)
Comment 6 Göktürk Yüksek archtester gentoo-dev 2017-03-16 23:40:18 UTC
Switching to the non "_noexec" variant should should fix the problem.
Comment 7 Mike Pagano gentoo-dev 2021-08-28 17:27:12 UTC
I can't reproduce this, as ck-sources as evolved, even in the different overlays. 

If this is still reproducible please, reopen.
Comment 8 Sok Ann Yap 2021-08-29 06:33:31 UTC
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
Comment 9 Mike Pagano gentoo-dev 2021-08-29 23:09:38 UTC
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?
Comment 10 Mike Pagano gentoo-dev 2021-08-29 23:25:13 UTC
Nevermind, I got it
Comment 11 Mike Pagano gentoo-dev 2021-08-30 17:20:44 UTC
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
Comment 12 Sok Ann Yap 2021-08-30 23:32:08 UTC
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)
Comment 13 Larry the Git Cow gentoo-dev 2021-09-02 10:59:51 UTC
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(-)
Comment 14 jeremy mills 2021-09-03 10:34:12 UTC
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.
Comment 15 Sok Ann Yap 2021-09-03 10:54:30 UTC
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.
Comment 16 jeremy mills 2021-09-03 12:05:54 UTC
(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.
Comment 17 Mike Pagano gentoo-dev 2021-09-03 18:09:41 UTC
(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 ?
Comment 18 jeremy mills 2021-09-03 19:32:59 UTC
(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.
Comment 19 jeremy mills 2021-09-03 19:39:17 UTC
(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
Comment 20 jeremy mills 2021-09-03 19:49:57 UTC
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.
Comment 21 Don O 2021-09-04 23:30:42 UTC
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
Comment 22 Don O 2021-09-05 11:36:01 UTC
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.
Comment 23 jeremy mills 2021-09-06 23:53:09 UTC
(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.
Comment 24 jeremy mills 2021-09-07 00:59:28 UTC
this seems to have been fixed..at least in my case by

https://gitweb.gentoo.org/repo/gentoo.git/commit/eclass?id=ab005b2b0219f266a90891fa3cce8253014927db
Comment 25 Mike Pagano gentoo-dev 2021-09-07 11:32:49 UTC
(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