[PATCH] for kernel-modules.SlackBuild Request / Discussion / Submission

kjhambrick · 10-26-2016, 06:58 AM

All --

I know many advanced Slackware Admins don't bother with building Packages for the Kernel Components ( HUGE, GENERIC, MODULES, SOURCE ).

But I am working towards installing Slackware out in the world, replacing CentOS on 60-or-so Customer Machines.

As such, I really do want to install the Kernel Components as Slackware Packages so that they can be managed.

I have been using the Slackware Kernel SlackBuilds to make the Packages and I am getting good results now ( still working on the kernel-source-${KERNELVERSION}-noarch-1 SlackBuild ).

Anyhow ...

Below is a suggested Patch for each of the three kernel-modules.SlackBuild files that are distributed with the Slackware Source ( example: source/k/packaging-x86_64/kernel-modules/kernel-modules.SlackBuild ).

I submit this patch because by default, each of the kernel-modules SlackBuilds expects to find the Linux Kernel Modules in /lib/modules/${KERNELRELEASE}/

This is fine if one is building a new Kernel -- i.e. one that's not running when the modules are being built.

And it may be fine even if one rebuilds the Kernel Modules for the running Kernel too.

But I am not absolutely certain about that ...

OK-or-Not, it simply 'feels' scary and dangerous to overwrite /lib/modules/${KERNELVERSION}/ for the running kernel ...

The good news is that there is a solution to my concerns.

There is a pre-defined variable in the Linux Kernel Makefile: INSTALL_MOD_PATH

When `make modules-install` is invoked, the new Kernel Modules will be installed in the Directory defined by $(INSTALL_MOD_PATH}/lib/modules/${KERNELVERSION}/

I have tested `make modules-install` on the 4.4.27 kernel and it does the right thing: the new kernel modules are installed in ${INSTALL_MOD_PATH}/lib/modules/${KERNELVERSION}/

I have also tested the patched kernel-modules.SlackBuilds and they do the right thing as well: They build the Slackware kernel-modules Package from the module tree in ${INSTALL_MOD_PATH}/lib/modules/${KERNELVERSION}/

Set or Unset, the Value of INSTALL_MOD_PATH does not matter.

Comments / Suggestions / hearty guffaws

?

Thanks.

-- kjh

#
# The following patch is from source/k/packaging-x86_64/kernel-modules/kernel-modules.SlackBuild
#

Code:

-- /tmp/kernel-modules.SlackBuild.orig 2016-06-24 13:31:28.000000000 -0500
+++ /tmp/kernel-modules.SlackBuild      2016-10-26 06:10:45.299173490 -0500
@@ -33,12 +33,12 @@
 rm -rf $PKG
 mkdir -p $TMP $PKG
 
-echo "Using /lib/modules/${KERNELRELEASE}/"
+echo "Using ${INSTALL_MOD_PATH}/lib/modules/${KERNELRELEASE}/"
 echo "Make sure these are *ready*... compressed, or not."
 echo "However you want 'em."
 sleep 5
 mkdir -p $PKG/lib/modules
-cp -a /lib/modules/${KERNELRELEASE} $PKG/lib/modules
+cp -a ${INSTALL_MOD_PATH}/lib/modules/${KERNELRELEASE} $PKG/lib/modules
 
 mkdir -p $PKG/install
 cat $CWD/slack-desc > $PKG/install/slack-desc

gnashley · 10-26-2016, 11:14 AM

I think this might be better:
INSTALL_MOD_PATH=$PKG
At least it would avoid having to copy the modules after installing them -are they spamming your root?

I do the same thing in my kernel build scripts:

Code:

mkdir -p $PKG_DIR/boot
cp $SRC_DIR/arch/$KARCH/boot/bzImage $PKG_DIR/boot/vmlinuz-$KNAME-$VERSION-$ARCH-$BUILD
cp $SRC_DIR/System.map $PKG_DIR/boot/System.map-$KNAME-$VERSION-$ARCH-$BUILD
cp $SRC_DIR/.config $PKG_DIR/boot/config-$KNAME-$VERSION-$ARCH-$BUILD

mkdir -p $PKG_DIR/lib/modules/$VERSION
cd $SRC_DIR
unset INSTALL_MOD_PATH
export INSTALL_MOD_PATH=$PKG_DIR
make _modinst_
if [[ -x /sbin/depmod ]] ; then
	#/sbin/depmod -b $PKG_DIR $VERSION
	( cd $PKG_DIR && /sbin/depmod -b . $VERSION )
fi

_modinst_ is the low-level operation called by modules_install -I simply call it directly

kjhambrick · 10-26-2016, 11:48 AM

Interesting Idea gnashley !

I would need to change ( or not use ) the Official Slackware kernel-modules.SlackBuild because it invokes `cp -a /lib/modules/${KERNELRELEASE} $PKG/lib/modules`

Doing it as you suggested would eliminate that `cp -a` altogether -- I and could `makepkg` on the $PKG Directory that has been populated by the Kernel Makefile.

Nice !

Thanks for the input, gnashley.

-- kjh

Code:

#!/bin/sh

# Copyright 2006, 2008, 2009, 2016  Patrick J. Volkerding, Sebeka, MN, USA
# All rights reserved.
#
# Redistribution and use of this script, with or without modification, is
# permitted provided that the following conditions are met:
#
# 1. Redistributions of this script must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
#
#  THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
#  WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
#  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO
#  EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
#  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
#  PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
#  OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
#  WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
#  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
#  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


VERSION=${VERSION:-4.4.14}
KERNELRELEASE=${KERNELRELEASE:-4.4.14}
ARCH=${ARCH:-x86_64}
BUILD=${BUILD:-1}

CWD=$(pwd)
TMP=${TMP:-/tmp}
PKG=$TMP/package-kernel-modules

rm -rf $PKG
mkdir -p $TMP $PKG

echo "Using /lib/modules/${KERNELRELEASE}/"
echo "Make sure these are *ready*... compressed, or not."
echo "However you want 'em."
sleep 5
mkdir -p $PKG/lib/modules
cp -a /lib/modules/${KERNELRELEASE} $PKG/lib/modules

mkdir -p $PKG/install
cat $CWD/slack-desc > $PKG/install/slack-desc

# Write out the doinst.sh:
cat << EOF > $PKG/install/doinst.sh
# A good idea whenever kernel modules are added or changed:
if [ -x sbin/depmod ]; then
  chroot . /sbin/depmod -a ${KERNELRELEASE} 1> /dev/null 2> /dev/null
fi

EOF

cd $PKG
/sbin/makepkg -l y -c n $TMP/kernel-modules-$(echo ${VERSION} | tr - _)-$ARCH-$BUILD.txz

GazL · 10-26-2016, 02:34 PM

I get the feeling the "official" slackbuilds are the way they are because Pat likes to test the new kernel on the box and then package up what he's just tested.

In the build scripts I wrote for myself, I build everything out-of-tree and install the modules directly to the $PKGROOT directory under /tmp for makepkg to find. The host system is left completely unchanged (until you actually install the package).

The relevant snippet of my build is here if you're interested in the approach taken:

Code:

# BUILD
#    arch/x86 is a symlink to x86_64 on 64 bit and will cater for both archs

cd "${SRCDIR}" \
  && make O="$PKGROOT/usr/obj/${OBJVER}" oldconfig \
  && make -j $NUMJOBS O="$PKGROOT/usr/obj/${OBJVER}" bzImage modules \
  && make -j $NUMJOBS O="$PKGROOT/usr/obj/${OBJVER}" modules_install INSTALL_MOD_PATH="$PKGROOT" \
  && cp "$PKGROOT/usr/obj/${OBJVER}/arch/x86/boot/bzImage" "$PKGROOT/boot/vmlinuz-${OBJVER}" \
  && cp "$PKGROOT/usr/obj/${OBJVER}/System.map" "$PKGROOT/boot/System.map-${OBJVER}" \
  && make -j $NUMJOBS O="$PKGROOT/usr/obj/${OBJVER}" clean \
  && make -j $NUMJOBS O="$PKGROOT/usr/obj/${OBJVER}" prepare \
  || exit_error "Problem with build phase" 

# Adjust the lib/modules/build symlink for installed location:
ln -sf -T "/usr/obj/$OBJVER" "$PKGROOT/lib/modules/$OBJVER/build"

# Create a sublevel-version free convenience symlink for /boot/vmlinuz
if [ -n "$LINKNAME" ]; then
   ln -sf -T "/boot/vmlinuz-${OBJVER}" "$PKGROOT/boot/${LINKNAME}"
fi

You can find the whole thing here:
http://www.linuxquestions.org/questi...4/#post5581140

kjhambrick · 10-28-2016, 03:09 AM

Thanks GazL !

I do like building the kernel completely 'on the side' so that the possibility of affecting the kernel components on the running machine is eliminated or at least minimized.

After a cursory glance, the scripts that you attached to your post in the Advice on Creating Kernel Packages thread certainly look do like 'keepers' !

I want to take GazL's build_kernel and GazL's buildpkg scripts for a spin but I am really slammed at work right now.

I've grabbed copies and placed them in their own /home/dld/slackware/GazL-kernel/ directory ( without the .txt extents ) for testing

I'll be sure to let you know how it goes when I can find the time to try them out.

Thanks again GazL !

-- kjh

GazL · 10-28-2016, 05:26 AM

You're welcome.

I wrote them for my own use, but if someone else finds them useful then that is gratifying.

OldHolborn · 10-30-2016, 09:34 AM

Am I missing the obvious?

Why not just set

General setup --->
Local version - append to kernel release

in your kernel config?

Putting

Code:

"-local"

in there or whatever means you'll have in /lib/modules
4.4.19
4.4.19-local

or something more suitably up to date...

uname -a will also show your local version

GazL · 10-30-2016, 10:53 AM

I suppose one might possibly want to change something in the config and rebuild whilst still maintaining the same LOCALVERSION string for some reason (perhaps whilst revising/perfecting the config), so there may be uses for a non-in-place package build process.

Code:

test@ws1:~$ uname -r
4.8.5-local

I use LOCALVERSION here, and always recommend its use to people.

I even go so far as to use the LOCALVERSION in my package names, e.g.
kernel-4.8.y-local-4.8.5-x86_64-1

which means that upgradepkg will do what one would expect when multiple kernel packages are installed concurrently and it comes time to update one.

As I've said before, some might find my approach over-engineered, which is fair enough, it probably is... but, it works for me.