Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 735080 - sys-kernel/genkernel-4.0.10: informative message with confusing kernel version
Summary: sys-kernel/genkernel-4.0.10: informative message with confusing kernel version
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: genkernel (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Genkernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-08-01 13:33 UTC by Francesco Turco
Modified: 2020-08-09 20:07 UTC (History)
0 users

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


Attachments
genkernel.log (genkernel.log,298.46 KB, text/plain)
2020-08-01 16:17 UTC, Francesco Turco
Details
genkernel.conf (genkernel.conf,349 bytes, text/plain)
2020-08-01 16:18 UTC, Francesco Turco
Details
genkernel-kv-debug.patch (genkernel-kv-debug.patch,1.03 KB, patch)
2020-08-01 21:24 UTC, Thomas Deutschmann (RETIRED)
Details | Diff
genkernel-debug.txt (genkernel-debug.txt,2.63 KB, text/plain)
2020-08-02 07:23 UTC, Francesco Turco
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Francesco Turco 2020-08-01 13:33:28 UTC
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
Comment 1 Thomas Deutschmann (RETIRED) gentoo-dev 2020-08-01 14:10:01 UTC
Please attach complete genkernel.log from a run, displaying

> * Working with Linux kernel 5.7.12-gnu5.7.11-gnu-0 for x86_64
Comment 2 Francesco Turco 2020-08-01 16:17:55 UTC
Created attachment 652086 [details]
genkernel.log
Comment 3 Francesco Turco 2020-08-01 16:18:21 UTC
Created attachment 652088 [details]
genkernel.conf
Comment 4 Francesco Turco 2020-08-01 16:20:10 UTC
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.
Comment 5 Thomas Deutschmann (RETIRED) gentoo-dev 2020-08-01 21:24:18 UTC
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.
Comment 6 Francesco Turco 2020-08-02 07:22:22 UTC
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.
Comment 7 Francesco Turco 2020-08-02 07:23:50 UTC
Created attachment 652226 [details]
genkernel-debug.txt

Building kernel image and initramfs with genkernel after having applied the genkernel-kv-debug.patch
Comment 8 Francesco Turco 2020-08-02 07:34:53 UTC
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
Comment 9 Thomas Deutschmann (RETIRED) gentoo-dev 2020-08-03 12:57:46 UTC
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.
Comment 10 Francesco Turco 2020-08-03 14:27:13 UTC
(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"?
Comment 11 Thomas Deutschmann (RETIRED) gentoo-dev 2020-08-03 14:50:41 UTC
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).
Comment 12 Francesco Turco 2020-08-04 09:46:57 UTC
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...
Comment 13 Francesco Turco 2020-08-04 10:14:36 UTC
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.
Comment 14 Thomas Deutschmann (RETIRED) gentoo-dev 2020-08-09 20:07:33 UTC
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.