From: Nicolas Schier <nsc@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
Cc: "Adrián García Casado" <adriangarciacasado42@gmail.com>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org,
n.schier@fritz.com
Subject: Re: [PATCH] kbuild: depmod: fallback to /boot/System.map-KERNELRELEASE
Date: Sat, 14 Nov 2026 20:02:09 +0100 [thread overview]
Message-ID: <aviwMdFX5CpBfB0Y@levanger> (raw)
In-Reply-To: <179392018201.309869.11526061626002654500.b4-reply@b4>
On Thu, Nov 05, 2026 at 04:09:42PM -0700, Nathan Chancellor wrote:
> On 2026-10-16 16:22 +0200, Nicolas Schier wrote:
> > On Fri, Oct 16, 2026 at 01:11:06PM +0200, Adrián García Casado wrote:
> > > When installing external modules (M=...) against packaged kernel headers
> > > such as linux-headers built via 'make bindeb-pkg', ${objtree}/System.map
> > > is absent because System.map is located in:
> > > /boot/System.map-${KERNELRELEASE}
> > >
> > > Currently, scripts/depmod.sh only checks ${objtree}/System.map and skips
> > > running depmod with a warning, leaving newly installed out-of-tree
> > > modules unindexed in modules.dep.
> > >
> > > Fall back to ${INSTALL_MOD_PATH}/boot/System.map-${KERNELRELEASE} when
> > > ${objtree}/System.map is not readable so that depmod runs properly
> > > during external module installation.
> > >
> > > Signed-off-by: Adrián García Casado <adriangarciacasado42@gmail.com>
> > > ---
> > > scripts/depmod.sh | 13 +++++++++----
> > > 1 file changed, 9 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/scripts/depmod.sh b/scripts/depmod.sh
> > > index 3c34fecac..d6d1b9547 100755
> > > --- a/scripts/depmod.sh
> > > +++ b/scripts/depmod.sh
> > > @@ -12,9 +12,14 @@ KERNELRELEASE=$1
> > >
> > > : ${DEPMOD:=depmod}
> > >
> > > -if ! test -r "${objtree}/System.map" ; then
> > > - echo "Warning: modules_install: missing 'System.map' file. Skipping depmod." >&2
> > > - exit 0
> > > +system_map="${objtree}/System.map"
> > > +if ! test -r "${system_map}" ; then
> > > + if test -r "${INSTALL_MOD_PATH}/boot/System.map-${KERNELRELEASE}" ; then
> > > + system_map="${INSTALL_MOD_PATH}/boot/System.map-${KERNELRELEASE}"
> > > + else
> > > + echo "Warning: modules_install: missing 'System.map' file. Skipping depmod." >&2
> > > + exit 0
> > > + fi
> > > fi
> > >
> > > # legacy behavior: "depmod" in /sbin, no /sbin in PATH
> > > @@ -25,7 +30,7 @@ if [ -z $(command -v $DEPMOD) ]; then
> > > exit 0
> > > fi
> > >
> > > -set -- -ae -F "${objtree}/System.map"
> > > +set -- -ae -F "${system_map}"
> > > if test -n "$INSTALL_MOD_PATH"; then
> > > set -- "$@" -b "$INSTALL_MOD_PATH"
> > > fi
> > > --
> > > 2.39.5
> > >
> >
> > Thanks for report and patch.
> >
> > For the record, this is what I can find in Debian's Linux packages:
> >
> > Debian puts a dummy System.map to /lib/modules/$(KERNELVER)/System.map
> > (linux-image-$(KVER)-$(DEBVER)-$(ARCH).deb) and the real System.map is
> > only available in linux-image-$(KVER)-$(DEBVER)-$(ARCH)-dbg package
> > at /usr/lib/debug/lib/modules/$(KVER)-$(ARCH)/System.map.
> >
> > So, do we need a valid System.map for out-of-tree modules?
>
> Yeah, how does this work for the main Debian packages? Do they just not
> expecte modules.dep to be generated for external modules if System.map
> is not in a standard location? Or maybe nobody cares?
Supplying '-F ../path/to/System.map -e' to depmod enables checking all
installed modules for unresolved symbols. The in-tree scripts/depmod.sh
wrapper script always adds '-e -F ${objtree}/System.map', or fails if
System.map is not there (cp. report above). Debian installs a dummy
/boot/System.map-${KVER}, but that will not be used automatically by
anything (as far as I can see).
Thus, AFAIK System.map is required only for checking against unresolved
symbols in the just installed kernel modules, whether they are built
in-tree or out-of-tree.
> > At a first glance, you patch looks good to me. But lets way some days
> > for other feedback.
>
> I don't have a particular opinion on this patch other than maybe this is
> being patched in the wrong place? Perhaps we should be fixing this in
> scripts/package/install-extmod-build? scripts/package/PKGBUILD copies
> System.map to its external module build folder already.
> scripts/package/kernel.spec copies it to /lib/modules/<rel>, not
> /lib/modules/<rel>/build. Unifying those in in install-extmod-build
> would avoid having to change it here (since /boot/System.map-<rel> seems
> like a Debian-ism that we are hard coding here). I trust your judgement
> though.
Yeah, I think you're right: we should fix in install-extmod-build and
unify the install for all packaging targets by putting System.map to the
build directory, as that's where scripts/depmod.sh expects to find it.
I am preparing a patch for that.
Thanks!
--
Nicolas
prev parent reply other threads:[~2026-11-14 19:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-16 11:11 [PATCH] kbuild: depmod: fallback to /boot/System.map-KERNELRELEASE Adrián García Casado
2026-10-16 11:19 ` Adrián García Casado
2026-10-16 14:22 ` Nicolas Schier
2026-11-05 23:09 ` Nathan Chancellor
2026-11-14 19:02 ` Nicolas Schier [this message]
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=aviwMdFX5CpBfB0Y@levanger \
--to=nsc@kernel.org \
--cc=adriangarciacasado42@gmail.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=n.schier@fritz.com \
--cc=nathan@kernel.org \
/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