Summary: | sys-kernel/genkernel-4.0.0_beta11: try more kernel config candidates | ||
---|---|---|---|
Product: | Gentoo Hosted Projects | Reporter: | Anna Tikhomirova <vamp> |
Component: | genkernel | Assignee: | Gentoo Genkernel Maintainers <genkernel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | Keywords: | InVCS |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Not a bug: When genkernel starts we need to determine kernel version (KV) which we later use to determine kernel config. When starting with fresh kernel sources like gentoo-sources-5.2.7, $KV in KERNEL_SOURCES (usually /usr/src/linux) is set to: VER=5 PAT=2 SUB=7 EXV=-gentoo (see https://gitweb.gentoo.org/proj/genkernel.git/tree/gen_determineargs.sh?h=v4.0.0_beta11#n33) Note: No LOCALVERSION (LOV) is set! Based on this information KV will be set to 5.2.7-gentoo so we will look for /etc/kernels/kernel-config-5.2.7-gentoo on first run against these kernel sources. Later in this run, by default, genkernel will set kernel's LOCALVERSION (LOV) to $ARCH. If you watch genkernel's output closely, genkernel will tell you > Kernel version has changed (probably due to config change) since genkernel start Now, LOV (which was previously not set) is set to "-x86_64" and after kernel was build, we will save config to /etc/kernels/kernel-config-5.2.7-gentoo-x86_64 (LOV is part of KV). When you will now re-run genkernel against same kernel sources, determine_KV() (see above) will still detect VER=5 PAT=2 SUB=7 EXV=-gentoo but now also LOV which was set in previous run with the result that genkernel will now look for /etc/kernels/kernel-config-5.2.7-gentoo-x86_64 However, when you now run `make mrproper` manually, you will reset kernel sources, i.e. get rid of LOV. You are basically using fresh kernel sources *again* (not 100% fresh like you will notice when you now try to set KERNEL_OUTPUTDIR != KERNEK_SOURCES but this is a different story). I see, but it breaks the usual kernel upgrade procedure and introduces mess with multiple config files. For example, to update to kernel 5.2.8, I need to do something like this: 1) emerge -av sys-kernel/gentoo-sources 2) cp /etc/kernels/kernel-config-5.2.7-gentoo-x86_64 /etc/kernels/kernel-config-x86_64-5.2.8-gentoo 3) genkernel --bootloader=grub2 --loglevel=5 --menuconfig all And I'll end up with 2 files: /etc/kernels/kernel-config-x86_64-5.2.8-gentoo /etc/kernels/kernel-config-5.2.8-gentoo-x86_64 Then I need to remember that for further building / reviewing etc I have to use the file with x86_64 at the end, not in the middle. Why not just use default LOCALVERSION if it is not found in the source tree? Previous genkernel versions always used the same filename and there was no mess. Update procedure was something like: 1) emerge -av sys-kernel/gentoo-sources 2) cp /etc/kernels/kernel-config-x86_64-5.2.7-gentoo /etc/kernels/kernel-config-x86_64-5.2.8-gentoo 3) genkernel --bootloader=grub2 --loglevel=5 --menuconfig all ending up with a single /etc/kernels/kernel-config-x86_64-5.2.8-gentoo file. I ended up with this as a quick fix for myself (however I don't think that this is a proper way): --- gen_configkernel.sh.old 2019-08-09 17:42:58.287155795 +0300 +++ gen_configkernel.sh 2019-08-10 12:00:45.454418963 +0300 @@ -27,7 +27,7 @@ then print_info 1 "Default configuration was forced. Will ignore any user kernel configuration!" else - kconfig_candidates=( "/etc/kernels/${GK_FILENAME_CONFIG}" "/etc/kernels/kernel-config-${ARCH}-${KV}" ${kconfig_candidates[@]} ) + kconfig_candidates=( "/etc/kernels/${GK_FILENAME_CONFIG}" "/etc/kernels/kernel-config-${KV}-${ARCH}" "/etc/kernels/kernel-config-${ARCH}-${KV}" ${kconfig_candidates[@]} ) fi local f Or even probably this: --- gen_configkernel.sh.old 2019-08-09 17:42:58.287155795 +0300 +++ gen_configkernel.sh 2019-08-10 12:16:08.217783433 +0300 @@ -27,7 +27,7 @@ then print_info 1 "Default configuration was forced. Will ignore any user kernel configuration!" else - kconfig_candidates=( "/etc/kernels/${GK_FILENAME_CONFIG}" "/etc/kernels/kernel-config-${ARCH}-${KV}" ${kconfig_candidates[@]} ) + kconfig_candidates=( "/etc/kernels/${GK_FILENAME_CONFIG}" "/etc/kernels/kernel-config-${KV}-${ARCH}" ${kconfig_candidates[@]} ) fi local f I think "/etc/kernels/kernel-config-${ARCH}-${KV}" is here for backwards compatibility? But this is useless. User already have to manually rename kernel config on every upgrade. I must think about this. I agree that a default genkernel should consider kernel config with LOV even when current sources haven't set LOV yet. I.e. we know if LOV will be set or not. PS: Did you know you can use --kernel-config=/proc/config.gz? The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=01a319d31fa8dfc6dba903ca202f4a915d49f2dc commit 01a319d31fa8dfc6dba903ca202f4a915d49f2dc Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-08-10 18:20:45 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-08-10 18:34:33 +0000 gen_configkernel.sh: determine_kernel_config_file(): Add kconfig containing KERNEL_LOCALVERSION to kconfig candidate list Since we added $ARCH to KERNEL_LOCALVERSION by default, $KV from fresh kernel sources won't match with saved kernel config file anymore which will break kernel upgrades when saved kernel config file was just copied to new kernel version without removing LOV part. WIth this commit we still prefer extracted $KV when looking for kernel config file, however, we will also look for kernel config file where $KV contains KERNEL_LOCALVERSION we are going to use in addition. Bug: https://bugs.gentoo.org/691852 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> gen_configkernel.sh | 36 ++++++++++++++++++++++++++++++------ 1 file changed, 30 insertions(+), 6 deletions(-) The bug is fixed now, genkernel works as expected. Thanks! Thank you for the report and follow up, fixed in >=sys-kernel/genkernel-4.0.0_beta12! |
I'm building sys-kernel/gentoo-sources-5.2.7 with sys-kernel/genkernel-4.0.0_beta11 Steps to reproduce: 1) build kernel with genkernel 2) cd /usr/src/linux && make mrproper 3) build kernel with genkernel On step 3 it should read previously saved config, but it doesn't. genkernel saves kernel config to /etc/kernels/kernel-config-5.2.7-gentoo-x86_64: >> Saving config of successful build to '/etc/kernels/kernel-config-5.2.7-gentoo-x86_64' ... After make clean it doesn't read the previously saved config. It tries to read kernel-config-5.2.7-gentoo or kernel-config-x86_64-5.2.7-gentoo instead: * Sourcing default modules_load from '/usr/share/genkernel/defaults/modules_load' ... * Sourcing arch-specific config.sh from '/usr/share/genkernel/arch/x86_64/config.sh' ... * Sourcing arch-specific modules_load from '/usr/share/genkernel/arch/x86_64/modules_load' ... * Unable to determine LOCALVERSION -- maybe cleaned/fresh sources? * KERNEL_ARCH set to 'x86' ... * GK_FILENAME_KERNEL set to 'vmlinuz-5.2.7-gentoo' (was: 'vmlinuz-%%KV%%') * GK_FILENAME_KERNEL_SYMLINK set to 'kernel' (was: 'kernel') * GK_FILENAME_SYSTEMMAP set to 'System.map-5.2.7-gentoo' (was: 'System.map-%%KV%%') * GK_FILENAME_SYSTEMMAP_SYMLINK set to 'System.map' (was: 'System.map') * GK_FILENAME_INITRAMFS set to 'initramfs-5.2.7-gentoo.img' (was: 'initramfs-%%KV%%.img') * GK_FILENAME_INITRAMFS_SYMLINK set to 'initramfs' (was: 'initramfs') * Checking for suitable kernel configuration ... * - '/etc/kernels/kernel-config-5.2.7-gentoo' not found; Skipping ... * - '/etc/kernels/kernel-config-x86_64-5.2.7-gentoo' not found; Skipping ... * - '/usr/share/genkernel/arch/x86_64/kernel-config-5.2.7-gentoo' not found; Skipping ... * - '/usr/share/genkernel/arch/x86_64/kernel-config-5.2' not found; Skipping ... * Working with Linux kernel 5.2.7-gentoo for x86_64 * Using kernel config file '/usr/share/genkernel/arch/x86_64/generated-config' ... * * Note: The version above is subject to change (depends on config and status of kernel sources).