From: Ed W <lists@wildgooses.com>
To: Nathan Chancellor <nathan@kernel.org>,
Thorsten Leemhuis <regressions@leemhuis.info>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
masahiroy@kernel.org,
Linux Kernel Build System <linux-kbuild@vger.kernel.org>,
Nicolas Schier <nsc@kernel.org>,
Linux kernel regressions list <regressions@lists.linux.dev>
Subject: Re: extlinux can't boot kernel after commit "kbuild: keep .modinfo section in vmlinux.unstripped"
Date: Wed, 25 Feb 2026 11:55:06 +0000 [thread overview]
Message-ID: <4ff9d8be-ba4c-4698-abe8-31fcf2717acf@wildgooses.com> (raw)
In-Reply-To: <20260224204632.GA3510750@ax162>
Hi Nathan (and Thorsten), thanks for replying! Appreciated
On 24/02/2026 20:46, Nathan Chancellor wrote:
> So I will deal with this one, as I committed the series.
Thanks so much!!
>>> 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...
> I think you provided good information off the bat, so no worries on that
> front. I am not entirely positive that this is the root cause but now
> that I am looking at it and have some additional context from a recent
> 7.0-rc1 commit [1], I think 3e86e4d74c04 adding .modinfo to ELF_DETAILS
> and removing it from DISCARDS results in .modinfo appears in certain
> places, namely arch/x86/boot/compressed/vmlinux, where it may not be
> expected. Why that breaks this bootloader, not sure, but I don't really
> think it matters. I think we should move .modinfo from ELF_DETAILS
> (which may be used in other non-vmlinux linker scripts) to its own
> macro, add that to all vmlinux linker scripts, and discard it from
> places where it used to be properly discarded. More code but I think
> it will result in fewer problems. As far as I can tell, this is the
> reason that commit d50f21091358 ("kbuild: align modinfo section for
> Secureboot Authenticode EDK2 compat") was needed and that change needed
> a further follow up fix in commit a26a6c93edfe ("kbuild: Strip trailing
> padding bytes from modules.builtin.modinfo"), so we could have saved
> some headache from doing it right from the beginning.
>
> Ed, could you test the below patch with your setup (it should apply
> cleanly to 6.18.13, 6.19.3, or 7.0-rc1) and see if it resolves your
> issue?
>
> [1] ddc6cbef3ef1 ("s390/boot/vmlinux.lds.S: Ensure bzImage ends with SecureBoot trailer")
>
> Cheers,
> Nathan
Yes, your patch works fine against my 6.18.12 kernel on my AMD64 machine and booting with extlinux
(previously not working)
I also played around a little with some variations and it seems as though the adding in of the
.modinfo into the strip is the key, caveat that in my messing around (based on inspiration from the
commit [1] that you mention), I needed to reorder the macros to get it to compile. Note, I'm not
suggestion this as a solution, just illustrating some extra info:
--- arch/x86/boot/compressed/vmlinux.lds.S.orig 2026-02-25 10:42:45.040655315 +0000
+++ arch/x86/boot/compressed/vmlinux.lds.S 2026-02-25 11:06:32.907372114 +0000
@@ -80,17 +80,18 @@
. = ALIGN(PAGE_SIZE); /* keep ZO size page aligned */
_end = .;
- STABS_DEBUG
- DWARF_DEBUG
- ELF_DETAILS
-
DISCARDS
/DISCARD/ : {
*(.dynamic) *(.dynsym) *(.dynstr) *(.dynbss)
*(.hash) *(.gnu.hash)
*(.note.*)
+ *(.modinfo)
}
+ STABS_DEBUG
+ DWARF_DEBUG
+ ELF_DETAILS
+
.got.plt (INFO) : {
*(.got.plt)
}
Thanks for isolating the issue!
Ed W
next prev parent reply other threads:[~2026-02-25 11:58 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-17 19:24 extlinux can't boot kernel after commit "kbuild: keep .modinfo section in vmlinux.unstripped" Ed W
2026-02-24 12:11 ` Thorsten Leemhuis
2026-02-24 20:46 ` Nathan Chancellor
2026-02-25 11:55 ` Ed W [this message]
2026-02-25 21:24 ` Nathan Chancellor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ff9d8be-ba4c-4698-abe8-31fcf2717acf@wildgooses.com \
--to=lists@wildgooses.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
--cc=regressions@leemhuis.info \
--cc=regressions@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox