Hi, I'm not sure whether this issue is in linux-mod-r1.eclass or linux-info.eclass, so I'm going to assign this to the maintainers of both. The short version is, the config for my running kernel is not available in /usr/src/linux. However, it is available in one of these places. /lib/modules/${KV_FULL}/build/.config. /proc/config.gz You may want to have linux-info or linux-mod-r1 check these locations in this order before checking /usr/src/linux. Also, the kernel sources can be located in /lib/modules/${KV_FULL}/source. so if you need the source you might want to check there before /usr/src/linux. Thanks, William
Finding kernel and .config is all linux-info.eclass Also linux-mod-r1 does not care about the running kernel and always want to check the kernel it's building against which is often not the running kernel "yet", aka will be rebuilding modules and preparing to boot the new kernel. Changing priority in linux-info would break things. Even for pure runtime checks, the expected kernel may simply not be booted yet. Notably typical in stage3 (likely to be the minimal cd's kernel). So looking in uname -r's or /proc "first" doesn't seem great. Falling back to something else if /usr/src/linux is not found is fine (which is already done for /proc/config.gz) but not really the other way around. Note users can set KERNEL_DIR to point to any location too.
I agree with Ionen. Adding a additional check for .config in /lib/modules/${KV_FULL}/build/ in the function linux_config_path is what you are requesting?
(In reply to Mike Pagano from comment #2) > I agree with Ionen. > > Adding a additional check for .config in /lib/modules/${KV_FULL}/build/ in > the function linux_config_path is what you are requesting? Hi Mike, I think that is the way to handle this, but I'll also give you more info about how I build my kernel. If you come up with a better way to support this let me know. I use the O= variable in the upstream kernel Makefiles to make it possible to build the kernel as a user. My build sequence ends up looking like this for a new kernel (of course changing the version numbers): $ cd $mkdir linux-6.1.46 $ cd linux-6.1.46 $ zcat /proc/config.gz > .config $ make -C /usr/src/linux-6.1.46 O=$HOME/linux-6.1.46 oldconfig $ make $ sudo make modules_install install This way, the only thing that needs to be run as root is the actual install. When you do that, the /lib/modules/${KV_FULL}/{build,source} symlinks end up pointing to the location of the kernel source and build artifacts. It might be worth checking both of these directories for what you need before looking at /usr/src/linux. What do you think? Thanks, William
Hi again Mike, I just tried to ping you on IRC, because I believe I found another issue with linux-info.eclass. If I'm wrong about how this is supposed to work, please let me know. I found that exporting a value for KBUILD_OUTPUT doesn't seem to work: $ export KBUILD_OUTPUT=/lib/modules/<kv>/build $ sudo ebuild net-vpn/ovpn-dco/ovpn-dco-0.2.20230426.ebuild install fails complaining about not finding the config in /usr/src/linux. Thanks, William
As briefly noted in comment #1, the variable to use to specify a different build dir manually is "KERNEL_DIR". This variable can also be set to a out-of-tree build done using `make O=` (aka the same path you pass to O=) too. On a side-note, if the build dir is in your $HOME, do make sure portage will have read access to it.
Created attachment 868090 [details, diff] linux-info.patch This is my attempt at a patch for this, but it isn't working so far. Thanks, William
KV_FULL is not going to set until it actually finds a kernel, meaning it'd have to use $(uname -r). But I hardly see how useful this is unless at most /proc/config.gz support is disabled when doing runtime checks. As far as modules go, $(uname -r) would be pretty weird 1. build new kernel 2. boot it so $(uname -r) points to its build/source 3. ... build modules now? how about doing it before booting May want to consider just using a fixed location for KERNEL_DIR, potentially a symlink to your out-of-tree build dir that you'd update as part of your kernel building process.
