Hi, I updated genkernel to 4.3.6. It's been a couple of months (so with at least one other genkernel version) that I can't compile a new kernel anymore. Everytime, all options to compile with microcode loading, including AMD microcode, are forced, regardless what I configure. But I looked to previous /usr/src/linux/.config, and it was the case before -- such as the kernel on which I'm running now. Interestingly, this happens with /etc/genkernel.conf containing this paragraph all commented: # Add in early microcode support: this sets the kernel options for early microcode loading # Possible values: empty/"no", "all", "intel", "amd" #MICROCODE="all" Anyway. Since a couple of months, I have in consequence this error, here aborting the compilation of the 4.19.294-x86_64 kernel: LD vmlinux.o MODPOST vmlinux.o x86_64-pc-linux-gnu-ld: arch/x86/kernel/cpu/common.o: in function `microcode_check': (.text+0x147e): undefined reference to `amd_check_microcode' make: *** [Makefile:1066: vmlinux] Error 1 * ERROR: compile_kernel(): compile_generic() failed to compile the "bzImage" target! * Please consult '/var/log/genkernel.log' for more information and any * errors that were reported above. Is there a possibility that something is missing shipping with the last versions of the genkernel package? Cheers.
I think that is not related to genkernel but kernel itself. Seems there incorrectly backported forced amd_check_microcode loading but forgot to add '#include <asm/microcode_amd.h>' to arch/x86/kernel/cpu/common.c: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/x86/include/asm/microcode_amd.h?h=v4.19.294&id=cfef7bbf0dca27209ea5d82d7060d4fc2c0d72ea I'd suggest to update kernel to more recent versions to workaround this. Patch also would be trivial solution, like adapted https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=82ad097b02b6ab7985375b925efd06ac042caf1d
Have similar(?) issue, when trying to build recent kernel (commit 6099776f9f268e61fe5ecd721f994a8cfce5306f): ERROR: Something went wrong: Required kernel option 'CONFIG_MICROCODE_AMD' which genkernel tried to set is missing! CONFIG_MICROCODE_AMD and CONFIG_MICROCODE_INTEL were removed by kernel commits: - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6bcfdd75d53390a67f67237f4eafc77d9772056 - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4d2b748305e96fb76202a0d1072a285b1500bff3 It would be nice if genkernel allowed continuing building kernel despite these "errors".
(In reply to Azamat H. Hackimov from comment #1) > I think that is not related to genkernel but kernel itself. If you are right concerning the error, the subject of my first message is a question: I don't understand why genkernel forces something, and is not telling me that it is doing so. If I emerge docker, then I might have advice that some options have to be configured in the kernel, and are not currently, for example. In this case, without the options forced, it compiles -- see below how to bypass genkernel. > Seems there > incorrectly backported forced amd_check_microcode loading but forgot to add > '#include <asm/microcode_amd.h>' to arch/x86/kernel/cpu/common.c: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/arch/ > x86/include/asm/microcode_amd.h?h=v4.19. > 294&id=cfef7bbf0dca27209ea5d82d7060d4fc2c0d72ea > I'd suggest to update kernel to more recent versions to workaround this. > Patch also would be trivial solution, like adapted > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ > commit?id=82ad097b02b6ab7985375b925efd06ac042caf1d Since they weren't many, I tried to do the modifications by hands, when I had to and when possible, it didn't work. But even if they did: I'm not really ok with doing as if nothing is happening, since in the first place, genkernel forces something into not working when it would have otherwise. To my point of view, if things were done properly, then the forcing option should be clearly in /etc/genkernel.conf. Yet, when overriding/forcing a choice, I would still prefer this to be clearly said on the terminal. I'm not sure of the consequences (I didn't try to boot), but in /etc/genkernel.conf, using : MICROCODE="intel" forces genkernel to not force the addition of AMD. And everything compiles well.
*** Bug 916542 has been marked as a duplicate of this bug. ***
*** Bug 914445 has been marked as a duplicate of this bug. ***
Same here, kernel 6.6.0 and genkernel-4.3.8. The kernel options that genkernel looks for have been deprecated, see: https://github.com/torvalds/linux/commit/4d2b748305e96fb76202a0d1072a285b1500bff3 So it should be CONFIG_CPU_SUP_INTEL or CONFIG_CPU_SUP_AMD instead.
(In reply to Nikolay Kichukov from comment #6) > Same here, kernel 6.6.0 and genkernel-4.3.8. > > The kernel options that genkernel looks for have been deprecated, see: > > https://github.com/torvalds/linux/commit/ > 4d2b748305e96fb76202a0d1072a285b1500bff3 > > So it should be CONFIG_CPU_SUP_INTEL or CONFIG_CPU_SUP_AMD instead. All this is handled in /usr/share/genkernel/gen_configkernel.sh, I'm looking at cooking up a quick patch to get us through this.
Created attachment 873755 [details, diff] Quick and dirty patch for genkernel 4.3.8
*** Bug 916546 has been marked as a duplicate of this bug. ***
Created attachment 873807 [details, diff] Adapted patch for 4.3.8 - microcode fix for kernel 6.6.0 Adapted the patch for a quick user patch: Create /etc/portage/patches/sys-kernel/genkernel-4.3.8 put the patch file in it and then re-emerge the 4.3.8 genkernel, it uses the patch and the kernel can be build. Beware: Of course this is a quick&dirty patch, as it breaks the older kernels (<6.6.0) then.
Created attachment 873817 [details, diff] Backward compatible patch for genkernel-4.3.8 Added version checks to patch, so it should not fail on earlier kernels I just tested it on 6.5.9, works fine, and runs on 6.6.0 without problems I also have to mention, that genkernel ebuild explicitly sets PATCHES variable. Thus to apply the patch it has to be modified like this PATCHES=( "${FILESDIR}"/${P}-config-microcode.patch ) Not sure about my coding style, but I decided just to mimic nearby statements
*** Bug 916630 has been marked as a duplicate of this bug. ***
In your latest patch: Line 999: Variable should probably be AMD Line 1000: += rather than = ?
(In reply to Pat Erley from comment #13) > In your latest patch: > > Line 999: Variable should probably be AMD > Line 1000: += rather than = ? Yeah, both are typos
Created attachment 873845 [details, diff] Typo fixes for earlier patch Should be fine now
*** Bug 916774 has been marked as a duplicate of this bug. ***
> Should be fine now Tested and working here. TY!
Created attachment 874369 [details, diff] simple(r) patch for genkernel-4.3.6 (amd/x86 stable) I'd just like to point out that the same applies to genkernel 4.3.6, which is the current stable version on most architectures, including amd64. And 4.3.6 has the same issue. I fixed it initially by running "make -j16 ; make -j16 modules ; make modules_install" in my /usr/src/linux directory manually, and copying the kernel to /boot. Genkernel worked fine to just generate the initramfs, i.e. # genkernel initramfs For the kernel 6.6.1 update I looked into it, out of curiosity. My personal patch, however, was much simpler: I added a version check for only MICROCODE_AMD and MICROCODE_INTEL for versions before 6.6.x. It was only after that I found this bug report. So, here are some questions (out of pure curiosity and genuine interest): Why bother checking here for CPU=AMD or CPU=Intel at all? Shouldn't this have happened earlier already? (-- with microcode load support in general: currently only x86, as stated in https://kernel.org/doc/html/next/x86/microcode.html) And if not, what's the big deal here? Anyhow, my 2¢: add new -r1 ebuilds to all relevant versions in the portage tree, which includes the current stable version and all newer versions, i.w. 4.3.6 onward...
Crash test dummy report from ~amd64 user: I applied the patch from Comment 15 and recompiled genkernel 4.3.8. Then built kernel 6.6.1-gentoo and rebooted. Everything seems fine and dandy. FWIW, I've got an AMD ATI Radeon RX 6400 (beige_goby) with driver running as module and the firmware loaded as it should.
*** Bug 917099 has been marked as a duplicate of this bug. ***
*** Bug 917115 has been marked as a duplicate of this bug. ***
Same here; I build kernel 6.6.0-rc2 using patch from comment 15 !amd64 and it works. Genkernel version is genkernel-4.3.8
Related: https://lore.kernel.org/regressions/20231112181036.GBZVEVHIIj%2FOos1cx4@fat_crate.local/T/#t
*** Bug 917606 has been marked as a duplicate of this bug. ***
*** Bug 919057 has been marked as a duplicate of this bug. ***
genkernel is such a fuddling tool doing mainly undocumented side tasks. Pls, pls fix that and make it configurable, without nagging by the tool itself (which is rather disturbing than informative).
This really should have a higher priority and/or have been fixed already TBH. Kernel updates broken for all genkernel users for now 3 months - and the solution is simple to implement (simply stop checking for a CONFIG option) Really frustrating running into such bugs ...
genkernel isn't really maintained so somebody needs to start looking after it.
(In reply to Yanestra from comment #26) > genkernel is such a fuddling tool doing mainly undocumented side tasks. Pls, > pls fix that and make it configurable, without nagging by the tool itself > (which is rather disturbing than informative). This is not helpful; in fact it has the opposite effect, a demotivating one. Do the work or wait for someone else to, but complaining on a bug tracker doesn't help. (In reply to MrPenguin07 from comment #27) > This really should have a higher priority and/or have been fixed already TBH. > Kernel updates broken for all genkernel users for now 3 months - and the solution is simple to implement (simply stop checking for a CONFIG option) > Really frustrating running into such bugs Patches or maintainers are generally welcomed, and then you have control over your own destiny.
(In reply to Greg Kubaryk from comment #29) > Patches or maintainers are generally welcomed, and then you have control > over your own destiny. Not everyone has the ability to contribute as such. Besides, a patch (which appears to be minimally "hacky") has already been created by others above. Months ago. It's enough to allow the (I assume quite large % of Gentoo users to at least upgrade to the 6.6.x series kernel) and prevent new users following the handbook to get a functioning system up. I've seen the commit history of genkernel, and I wish to applaud Sam et al. with maintaining it - just question why a critical piece of Gentoo's infrastructure hasn't had a release addressing this issue as other commits have been made. Issues such as this where upstream breaks Gentoo's "in-house" packages suck, however being as such nobody else is going to fix it for us. Complaining is unhelpful - though others can decide if it's actually constructive feedback. I'd argue a world without it would be a very dark place. It's what pushes humanity (and projects such as this) to better themselves.
It is true that a patch has already been provided here, and that it still hasn't made it into the repository. It should be an easy fix, and it should have arrived as an -r1 already, or simply a new version that is marked stable. Current stable is still 4.3.6, which works perfectly when one of the here provided patches is used, and the last testing version is still 4.3.8. There has been no change in the repository, and that's the criticism/complaint: Even if there's no maintainer for genkernel directly, someone could simply add a patch to the ebuilds... I would do it, but I'm not a developer, so... +1 for the complaint, that it's still broken without manually 1) finding out that it's broken with a 6.6+ kernel 2) finding this bug report 3) manually setting up a patch for either genkernel 4.3.6 (arch) or 4.3.8 (~arch)
(In reply to Andreas Thalhammer from comment #31) > It is true that a patch has already been provided here, and that it still > hasn't made it into the repository. It should be an easy fix, and it should > have arrived as an -r1 already, or simply a new version that is marked > stable. > > Current stable is still 4.3.6, which works perfectly when one of the here > provided patches is used, and the last testing version is still 4.3.8. There > has been no change in the repository, and that's the criticism/complaint: > Even if there's no maintainer for genkernel directly, someone could simply > add a patch to the ebuilds... Then if the patch isn't right, who's responsible for fixing it? What about the next time something breaks? This is how you end up accidentally maintaining something. I can't really handle the load of maintaining something I don't use.
(In reply to Yanestra from comment #26) > genkernel is such a fuddling tool doing mainly undocumented side tasks. Pls, > pls fix that and make it configurable, without nagging by the tool itself > (which is rather disturbing than informative). You already made your point in bug 917261 where: 1) I suggested you help out with genkernel; 2) Make some more practical / specific list of things to fix; 3) You were asked by a contributor a question Please don't bring it into other bugs.
(In reply to Sam James from comment #32) > This is how you end up accidentally maintaining something. I can't really > handle the load of maintaining something I don't use. I don't think that you end up becoming the maintainer when all you do is fix this very specific bug, with the provided patch (decide which one to use). Then this bug #913659 could be closed. This is so very specific that I don't think there's any danger of accidentally maintaining genkernel.... And if another bug comes up, and a fix is provided here in the bug tracker, do it again. Yes, that's patchwork and far from an ideal situation, but it's better than nothing. Just my 2¢...
(In reply to Andreas Thalhammer from comment #34) > (In reply to Sam James from comment #32) > > This is how you end up accidentally maintaining something. I can't really > > handle the load of maintaining something I don't use. > > I don't think that you end up becoming the maintainer when all you do is fix > this very specific bug, with the provided patch (decide which one to use). > Then this bug #913659 could be closed. This is so very specific that I don't > think there's any danger of accidentally maintaining genkernel.... But I did do that repeatedly with random patches & nobody stepped up. So clearly my drive-by wasn't working and people just kept pretending the situation was fine. I decided I couldn't do it forever for things I don't care about/don't use/... without burning out. Nobody gives any attention to something if it's working. Someone who cares about genkernel is welcome to start maintaining it.
Why people build the kernel using genkernel? For example my use case: only compiling initrd image: USE="-initramfs" emerge gentoo-kernel genkernel ramdisk Kernel build support has been deprecated and is no longer supported. This feature has migrated to dist-kernel.
(In reply to Sam James from comment #35) > But I did do that repeatedly with random patches & nobody stepped up. So > clearly my drive-by wasn't working and people just kept pretending the > situation was fine. I decided I couldn't do it forever for things I don't > care about/don't use/... without burning out. Totally fair, I get it. If I may make a suggestion; Perhaps the broader issue of genkernel lacking maintainers needs to be brought up to a relevant steering committee - and a high level decision made how to best handle the lack of maintainers, as a team. Whether it's a call to deck on mailing lists etc or perhaps the right decision is to follow openRCs demise, the current situation is unsustainable. Whether technically correct or not, I myself consider Genkernel to be a core package. While I assume most devs and many advanced users prefer dracut or otherwise have their own workflows managing this, the reality is that a large base rely on Genkernel. /2c
Yeah, that's a fair point and I take it. I think robbat2 was planning putting out a call for help for genkernel. Let's see if there's any update on that...
Created attachment 878298 [details, diff] 0001-gen_configkernel-Prepare-for-kernel-6.6.patch If only I had seen this bug before starting to dig into it. Never mind, here's better approach than proposed in earlier patches, because it works with older and newer kernel versions.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=4c52a1b8f83494c72d036f0955c5ad57c51e554e commit 4c52a1b8f83494c72d036f0955c5ad57c51e554e Author: Michal Privoznik <michal.privoznik@gmail.com> AuthorDate: 2023-12-08 13:16:50 +0000 Commit: Ben Kohler <bkohler@gentoo.org> CommitDate: 2024-01-19 18:26:25 +0000 gen_configkernel: Prepare for kernel-6.6 The microcode related config options were removed in [1] and microcode loading is enabled when support for corresponding CPU is enabled. Basically, this is equivalent to renaming options: CONFIG_MICROCODE_AMD -> CONFIG_CPU_SUP_AMD CONFIG_MICROCODE_INTEL -> CONFIG_CPU_SUP_INTEL Reflect this change in gen_configkernel.sh. Bug: https://bugs.gentoo.org/913659 1: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e6bcfdd75d53390a67f67237f4eafc77d9772056 Signed-off-by: Michal Privoznik <michal.privoznik@gmail.com> Signed-off-by: Ben Kohler <bkohler@gentoo.org> gen_configkernel.sh | 16 ++++++++++------ genkernel | 2 +- 2 files changed, 11 insertions(+), 7 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=791a15028278c7cc1e463aee8b7d0c42d06583db commit 791a15028278c7cc1e463aee8b7d0c42d06583db Author: Ben Kohler <bkohler@gentoo.org> AuthorDate: 2024-01-19 20:15:29 +0000 Commit: Ben Kohler <bkohler@gentoo.org> CommitDate: 2024-01-19 20:16:27 +0000 sys-kernel/genkernel: add 4.3.10 Bug: https://bugs.gentoo.org/913659 Signed-off-by: Ben Kohler <bkohler@gentoo.org> sys-kernel/genkernel/Manifest | 1 + sys-kernel/genkernel/genkernel-4.3.10.ebuild | 324 +++++++++++++++++++++++++++ 2 files changed, 325 insertions(+)
Hi, I updated genkernel to 4.3.10. Compiling kernel 4 19 306, there is still the error, first of this post that has since been renamed: x86_64-pc-linux-gnu-ld: arch/x86/kernel/cpu/common.o: in function `microcode_check': (.text+0x14ae): undefined reference to `amd_check_microcode' make: *** [Makefile:1066: vmlinux] Error 1 due to the addition of AMD when it is not required/wanted : >> Ensure that required kernel options for early microcode loading support are set ... * - Option 'CONFIG_MICROCODE=y' already set in '/usr/src/linux/.config'; Skipping ... * - Setting option 'CONFIG_MICROCODE_AMD' to 'y' in '/usr/src/linux/.config'... * - Option 'CONFIG_MICROCODE_INTEL=y' already set in '/usr/src/linux/.config'; Skipping ... In /etc/genkernel.conf, I have : # Possible values: empty/"no", "all", "intel", "amd" #MICROCODE="all" so nothing/no check should be done by default, with no unwanted addition. Why would genkernel behave like "all" was set, and force things? Empty/"no" should lead to only what has been configured in the kernel. One have to set explicitly (for example) MICROCODE="intel" to expect a full error-free compilation, with only this configured (if /usr/src/.config hasn't AMD microcode set actually). And in this case, there should be more to do since genkernel overpass the configuration done in /usr/src/.config: setting MICROCODE="intel" should actually also disable CONFIG_MICROCODE_AMD in /usr/src/linux/.config, which is not done (genkernel sets it when MICROCODE is not defined in /etc/genkernel.conf, but does not unset it when MICROCODE is set to "intel").
New bugs for new issues please.
(In reply to Sam James from comment #43) > New bugs for new issues please. I'm ok with that, but it's not a new bug nor a new issue: it's exactly the same that what I posted in the first place...
(In reply to Sam James from comment #43) > New bugs for new issues please. There is now a duplicate of this bug which has not been resolved/fixed in https://bugs.gentoo.org/923029
