I'm currently running Linux-libre 5.7.11: > $ uname -a > Linux desktop 5.7.11-gnu-0 #1 SMP Fri Jul 31 14:42:22 CEST 2020 x86_64 Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz GenuineIntel GNU/Linux Then I upgraded Linux-libre source code in /usr/src/linux to version 5.7.12 (with a patch) and I manually updated the /usr/src/linux symlink to point to the new kernel: > $ ls -ld /usr/src/linux* > lrwxrwxrwx 1 root root 18 Aug 1 15:07 /usr/src/linux -> linux-libre-5.7.12 > drwxrwxr-x 24 root root 4096 Aug 1 15:19 /usr/src/linux-libre-5.7.12 I haven't rebooted yet because I need to re-generate the kernel image and the initramfs with genkernel. I use the following command, but I think the options I use are not important in this case: > # genkernel --kernel-config="/usr/src/config" --kernel-localversion="-0" all The command ends successfully, but I get the following confusing informative message: > * Working with Linux kernel 5.7.12-gnu5.7.11-gnu-0 for x86_64 As you can see both kernel versions are displayed. If I run the command another time (always before rebooting) I correctly get the following message instead: > * Working with Linux kernel 5.7.12-gnu for x86_64
Please attach complete genkernel.log from a run, displaying > * Working with Linux kernel 5.7.12-gnu5.7.11-gnu-0 for x86_64
Created attachment 652086 [details] genkernel.log
Created attachment 652088 [details] genkernel.conf
Please note that, in order to obtain a genkernel log containing the problematic info message, I had to downgrade Linux-libre to version 5.6 and then upgrade to version 5.6.1. Nothing else changed in the meantime.
Created attachment 652210 [details, diff] genkernel-kv-debug.patch Please tell me where I find the exact sources you used, I cannot find the in Gentoo repository. At the moment I suspect 'bad' hardcoded KV value(s) in sources causing this. Please apply the attached patch which should show values read by genkernel.
Linux-libre releases are available here: https://linux-libre.fsfla.org/pub/linux-libre/releases/ Unfortunately Linux-libre is not available in the official Gentoo repository as far as I know.
Created attachment 652226 [details] genkernel-debug.txt Building kernel image and initramfs with genkernel after having applied the genkernel-kv-debug.patch
Steps to reproduce: 0. Build genkernel without genkernel-kv-debug.patch 1. Build Linux-libre 5.7.11 with genkernel 2. Build genkernel with genkernel-kv-debug.patch 3. Upgrade Linux-libre from 5.7.11 to 5.7.12 by applying upstream patch 4. Attempt building Linux-libre 5.7.12 with genkernel As far as I can see, there is no need to reboot the system in order to reproduce this bug. If you run step 4 a second time, the bug disappears. I can only reproduce it the first time. To be clear, I downloaded the following upstream patch and uncompressed it: https://linux-libre.fsfla.org/pub/linux-libre/releases/5.7.12-gnu/patch-5.7.11-gnu-5.7.12-gnu.xz Then I applied it with: cd /usr/src/linux patch -p 1 < /path/to/patch-5.7.11-gnu-5.7.12-gnu
I am now able to reproduce: 1) Initialize kernel sources with https://linux-libre.fsfla.org/pub/linux-libre/releases/5.7.11-gnu/linux-libre-5.7.11-gnu.tar.xz 2) Build kernel from that sources in same directory. 3) Now apply https://linux-libre.fsfla.org/pub/linux-libre/releases/5.7.12-gnu/patch-5.7.11-gnu-5.7.12-gnu.xz to *tainted* sources. When you now run genkernel again, we will read VER=5, PAT=7, SUB=12, EXV=-gnu from patched Makefile. Because sources are *tainted* (=you already built kernel in that directory), "include/config/kernel.release" exists. We are now going to read that file to determine any existing LOV: https://github.com/gentoo/genkernel/blob/v4.0.10/gen_determineargs.sh#L47-L52 The problem is that the file doesn't contain clean LOV value -- its value is "5.7.11-gnu-x86_64". To get the LOV value we are looking for we have to extract it (=strip '${VER}.${PAT}.${SUB}${EXV}' from value). However, we got these values already from Makefile which got patched to represent a new version. Therefore we are failing to strip value and treat the whole string as existing LOV value. It will get 'fixed' like you already have noticed in next step when we apply our own naming using LOV from genkernel and version information read from Makefile. So the problem is that you patched *tainted* (=already used) kernel sources which caused version information in Makefile to diverge from value in kernel.release file. If you are changing version information you have to change it everywhere within sources or cleanup any artefacts from a previous build. Note: There is no command which will bring an already used sources back into vanilla state. See https://github.com/gentoo/genkernel/blob/v4.0.10/gen_compile.sh#L122-L132 Thank you for the report but I hope you agree when I will close this bug as INVALID.
(In reply to Thomas Deutschmann from comment #9) > Note: There is no command which will bring an already used sources back into > vanilla state. See > https://github.com/gentoo/genkernel/blob/v4.0.10/gen_compile.sh#L122-L132 What about "make mrproper" or "make distclean"?
See the upstream comment, neither `make mrproper` nor `make distclean` help here (maybe in *your* specific case some of these targets can help but I am not aware of any make target which will really restore vanilla state like you have when unpacking sources release tarball).
I grepped the "5.7.11-gnu-0" string in /usr/src/linux, and found only two results: - /usr/src/linux/include/generated/utsrelease.h - /usr/src/linux/include/config/kernel.release Manually running "make clean" doesn't remove them, but running "make mrproper" does. I think the problem is that genkernel prints the "Working with Linux kernel" message before running "make mrproper". But I'm not sure there's something we can do about that...
Well... Since I manually patch the kernel, I could also remember to manually run "make mrproper". I could also set MRPROPER="no" (or just CLEAN="no") in /etc/genkernel.conf.
These two files are getting cleaned. My comment regarding tainted sources is a general one. Closing bug as INVALID like explained. Glad we sorted it.