The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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

      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