Re: extlinux can't boot kernel after commit "kbuild: keep .modinfo section in vmlinux.unstripped"

From: Thorsten Leemhuis

Date: Tue Feb 24 2026 - 07:11:38 EST


On 2/17/26 20:24, Ed W wrote:
> Hi, I wonder if I can get some help debugging a problem post the following commit. After trying to
> upgrade to a newer kernel build I encountered boot failures on my amd64 machine, booting via
> extlinux and git bisect narrowed it down to this commit:

Thx for the report. Adding a few more recipients to this.

Two things are likely worth checking:

* Is 7.0-rc1 still affected?
* If it's possible to revert the culprit in 7.0-rc1, does it fix the
problem?

> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.19.2&id=3e86e4d74c0490e5fc5a7f8de8f29e7579c9ffe5
> kbuild: keep .modinfo section in vmlinux.unstripped

FWIW: Masahiro Yamada, that's a change of yours.

Ciao, Thorsten

> Keep the .modinfo section during linking, but strip it from the final vmlinux. 
> Adjust scripts/mksysmap to exclude modinfo symbols from kallsyms. 
> This change will allow the next commit to extract the .modinfo section from the vmlinux.unstripped
> intermediate.
>
>
> The symptoms are that prior to this commit I can boot a kernel built using gcc-15 and binutils
> 2.45.1, however, adding that commit, or trying kernels up to 6.18.12, all fail to boot the bzImage file.
>  
> Extlinux apparently won't read (or otherwise rejects as invalid) the resulting bzImage kernel with
> error:
>     failed: I/O error
> So it doesn't even try to run the kernel, it appears to fail reading from disk (and presumably
> locating the entry point for execution?)
>
> Kernel is relocatable and hence ends up being built with 
> VMLINUX_NEEDS_RELOCS=y
>
> Curiously, if I build with clang then the resulting kernels all seem to work without a problem??
>
> System is one of a cluster of Ryzen 9 5950X, but similar errors appear with older Ryzen 9 3900
> boxes. Underlying OS is gentoo, so packages approximately as per latest releases with that.
>
> I'm not sure how to narrow down what precisely triggers the boot failure though. For example I see
> similar results to the following on both a working 6.17.0 and a broken 6.18.12
>
> # readelf -l vmlinux | grep -A3 LOAD
>   LOAD           0x0000000000200000 0xffffffff81000000 0x0000000001000000
>                  0x0000000002a8b4d0 0x0000000002a8b4d0  R E    0x200000
>   LOAD           0x0000000002e00000 0xffffffff83c00000 0x0000000003c00000
>                  0x0000000001a00000 0x0000000001a00000  RW     0x200000
>   NOTE           0x0000000002c8b47c 0xffffffff83a8b47c 0x0000000003a8b47c
>                  0x0000000000000054 0x0000000000000054         0x4
>
> On the non working 6.18.12 I see:
> # readelf -S vmlinux.unstripped | grep modinfo
>   [70] .modinfo          PROGBITS         ffffffff85600000  04800000
> # readelf -S vmlinux | grep modinfo
>
> So it seems as though the modinfo sectors ARE being stripped?!
>
> My guess is that something has moved or become re-ordered such that the extlinux is rejecting the
> image?? 
>
> At this point I'm honestly not quite sure what I am doing, so would some kind soul please help me
> figure out what is happening? I apologise in advance that I've likely not given enough information
> about the problem, please be gentle...
>
> Ed W
>