genkernel commit 48ca00 broke the version number code. I have a git checkout kernel, presently at kernel git ec30f34. With the latest 99999 tree (c65605/v3.4.12.1), genkernel thinks the version number is: * Linux Kernel 2.6.38-rc2 for x86... With commit 48ca00 reverted, the correct output: * Linux Kernel 2.6.38-rc2-00062-gec30f34 for x86... Due to this, when building the initramfs, genkernel looks in the wrong location for the kernel modules, and builds a initramfs with no kernel modules: # zcat /boot/initramfs-genkernel-x86-2.6.38-rc2 | cpio -i --list |grep lib/modules 6506 blocks lib/modules lib/modules/2.6.38-rc2 This causes my system to be unbootable, as I need the modules in the initramfs.
I think in light of bug #263927, we MUST run 'make prepare' or die in some fashion so we can get the correct version number (on a second pass, after the config is done). The linux-info.eclass has a stricter version of the same problem (/usr/src/linux is read-only in the sandbox there), and for that, we decided that if the user has a bad tree, we just die and make them fix it. "make prepare" and then capture the output of "make kernelrelease". This also avoids the need to figure out which file to read.
This may require re-ordering things in genkernel. This will require a closer look. Please let us know, if a release with that commit reverted would change anything for you.
reverting it for the meantime would provide a working bootable initramfs for anybody using git kernel checkouts. sping: add yourself to the genkernel alias ;-)
*** Bug 352795 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > *** Bug 352795 has been marked as a duplicate of this bug. *** > I'm having this same problem with CONFIG_LOCALVERSION, which I describe in the above duplicate. I would like to add that I only use genkernel to generate a ramdisk.
Related commit reverted on branches master and experimental. All of these ebuilds now have it reverted: - genkernel-3.4.12.2 - genkernel-9999 - genkernel-99999 A real fix is pending. (In reply to comment #3) > sping: add yourself to the genkernel alias ;-) I am on the alias, it's just that I filter out all bug mails from aliases - I was drowning in mails before that. I get to know of genkernel bugs by Bugzilla search result feeds. Maybe I need a better approach once more.
Observations ============ 0) A kernel release string is made up like this: KV="${VERSION}.${PATCHLEVEL}.${SUBLEVEL}${EXTRAVERSION}${LOCALVERSION_MAGIC}" 1) All componts but the local version magic can be extracted from the Makefile alone 2) The final local version string is put together by ./scripts/setlocalversion (exposed by "make kernelrelease") 3) Calls to ./scripts/setlocalversion fail, if "make prepare" has not been run previously. 4) "make prepare" requires .config to be in place. - Preferably its the config file that we are going to compile with - The hard requirement is that its CONFIG_LOCALVERSION and CONFIG_LOCALVERSION_AUTO have the final values 5) To decide which config file to work with, genkernel needs to know (at least part of) the kernel version, somewhat chicken egg loop. If no --kernconfig is given, genkernel's two next tries currently are: - /etc/kernels/kernel-config-${ARCH}-${KV} - ${GK_SHARE}/arch/${ARCH}/kernel-config-${KV} Questions ========= - Can we live with a call to "make prepare" and touching the kernel config even from a call like "genkernel initramfs" - Can we live with printing in-complete kernel versions (i.e. no localversion) until the very last moment? - What is that last moment? In which places does localversion really matter? - Can we live with crippling support for selecting kernel config files ignoring localversion (see (5) above)? Instead of /etc/kernels/kernel-config-x86_64-2.6.38-rc2-00062-gec30f34 genkernel would look for /etc/kernels/kernel-config-x86_64-2.6.38-rc2 in that case.
Feedback please, please!
Ping. Feedback still needed, welcome, wanted, appreciated, ...
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=3abb33bf0e12e38f453e262392572b0c6d47ea7c commit 3abb33bf0e12e38f453e262392572b0c6d47ea7c Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-03-28 20:37:17 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-03-28 20:37:17 +0000 genkernel: tell user that shown kernel version is subject to change When you start with fresh (unused) kernel sources, we will get Kernel Version from KERNEL_DIR. If you already have compiled that KV, genkernel maybe use your existing configuration from /etc/kernels (depends on other settings like --mrproper). Once your new kernel was built and you are saving configs (--save-config), we will save the used configuration in /etc/kernels/kernel-config-${ARCH}-${KV}. If you used --menuconfig during genkernel run to change kernel options like CONFIG_LOCALVERSION or CONFIG_LOCALVERSION_AUTO or have modified kernel's Makefile manually to change version, KV is subject to change once genkernel has called 'make prepare'. With this change we will tell user when KV has changed to end confusion like shown in bug 521778. Closes: https://bugs.gentoo.org/521778 Closes: https://bugs.gentoo.org/352787 Closes: https://bugs.gentoo.org/263927 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> genkernel | 28 ++++++++++++++++++++++------ 1 file changed, 22 insertions(+), 6 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=58a57b303efb9fb5ce60c0dc40c806e7d7b46db0 commit 58a57b303efb9fb5ce60c0dc40c806e7d7b46db0 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-03-28 20:04:21 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-03-28 20:04:21 +0000 get_KV(): refactoring how we determine KV - Fix handling O= builds (--kernel-outputdir): Patch (commit 8de731164496d09384d8be81a3f22316230deb65) from bug 238707 has probably never worked: There's no MAKEARGS in $KERNEL_DIR/Makefile... It is enough to read include/linux/version.h or include/linux/utsrelease.h from $KERNEL_OUTPUTDIR which is either set to $KERNEL_DIR or is a separate directory in which case there will be no files created in $KERNEL_DIR. - Set marker if KV will change to allow for user notification to avoid confusion. Bug: https://bugs.gentoo.org/521778 Bug: https://bugs.gentoo.org/352787 Bug: https://bugs.gentoo.org/263927 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> gen_determineargs.sh | 50 +++++++++++++++++++++++++++++--------------------- 1 file changed, 29 insertions(+), 21 deletions(-)
