[2024-feb-29] Sad news: Eric Layton aka Nocturnal Slacker aka vtel57 passed away on Feb 26th, shortly after hospitalization. He was one of our Wiki's most prominent admins. He will be missed.

Welcome to the Slackware Documentation Project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
howtos:slackware_admin:using_slackwares_kernel_build_scripts [2019/04/24 16:10 (UTC)] – Edit the example script divehowtos:slackware_admin:using_slackwares_kernel_build_scripts [2019/04/25 04:10 (UTC)] (current) – Added note about slackpkg blacklisting. dive
Line 3: Line 3:
 ==== Why and How? ==== ==== Why and How? ====
  
-A few years ago I wrote a couple of HowTos on compiling and +A few years ago I wrote a couple of HowTos on compiling and packaging a 
-packaging a complete kernel+modules package. Recently, I +complete kernel+modules package. Recently, I decided to look at how the stock 
-decided to look at how the stock Slackware kernel packages +Slackware kernel packages are built. I put this guide together from what I 
-are built. I put this guide together from what I picked up.+picked up.
  
-There are already a few kernel compile guides around, but I +There are already a few kernel compile guides around, but I haven't seen one 
-haven't seen one yet that looks at using Slackware's own +yet that looks at using Slackware's own kernel build scripts.
-kernel build scripts.+
  
-A "build-all-kernels.sh" script executes all the +A "build-all-kernels.sh" script executes all the Slackbuilds, one after the 
-Slackbuilds, one after the other, passing all relevant +other, passing all relevant variables to them, and creating a set of packages. 
-variables to them, and creating a set of packages. It uses +As you'd expect, the script needs to be run as root.
-some variables in the environment to change various +
-options. As you'd expect, the script needs to be run as +
-root.+
  
-At the end of this document I have an example of a custom +At the end of this document I have an example of a custom "setup.sh" file that 
-"setup.sh" file that can be used to set various options and +can be used to set various options and then run the main build script.
-then run the main build script.+
  
 The point of using a setup file is: The point of using a setup file is:
Line 46: Line 41:
   * Loop to the next package...   * Loop to the next package...
  
-At its simplest, you can mirror the k/ directoryand then run the build script.+At its simplest, you can mirror the k/ directory and then run the build script.
 This will build and install a set of kernel packages, using the newest version This will build and install a set of kernel packages, using the newest version
 source archive found in the current directory. There is no need to manually set source archive found in the current directory. There is no need to manually set
 the kernel version. the kernel version.
  
-By exporting a few variables the build routine can be changed, such as:+We can change a few things in the build routine, such as:
  
   * The local version (explanation below.)   * The local version (explanation below.)
Line 63: Line 58:
 are making a custom kernel. are making a custom kernel.
  
-For this example I will build packages for linux-5.0.8, with +For this example I will build packages for linux-5.0.8, with "jabberwok" as a 
-"jabberwok" as a local version, and /home/kernels/jabberwok +local version, and /home/kernels/jabberwok as the output directory.
-as the output directory.+
  
 The resulting packages will be named: The resulting packages will be named:
Line 75: Line 69:
 kernel-source-5.0.8_jabberwok-noarch-1.txz\\  kernel-source-5.0.8_jabberwok-noarch-1.txz\\ 
  
-It's worth noting here that the kernels and modules have +It's worth noting here that the kernels and modules have "jabberwok" in their 
-"jabberwok" in their names and versions, while headers and +names and versions, while headers and source only have it in their versions. 
-source only have it in their versions. This means that the +This means that the kernels and modules are distinct and apart from the stock 
-kernels and modules are distinct and apart from the stock +Slackware packages, and shouldn't affect them. I.E. a huge local version kernel 
-Slackware packages, and shouldn't affect them. I.E. a huge +will only upgrade another huge kernel with the same local version. However, the 
-local version kernel will only upgrade another huge kernel +headers and source packages //will// upgrade the currently installed stock 
-with the same local version. However, the headers and source +packages. 
-packages //will// upgrade the currently installed stock + 
-packages. If you use slackpkg then these will need +<note> 
-blacklisting to avoid being downgraded back to the stock +If you use slackpkg then the kernel-source and kernel-headers will need 
-versions.+blacklisting to avoid being downgraded back to the stock versions. 
 + 
 +If upgrading the stock kernels then you would also need to blacklist those for 
 +the same reason. 
 +</note>
  
 **Assumptions:** **Assumptions:**
Line 96: Line 94:
 **But:** **But:**
  
-This guide doesn't go into making kernel configs in any +This guide doesn't go into making kernel configs in any depth.  Typing "make 
-depth.  Typing "make help" in the kernel source directory +help" in the kernel source directory will show the various methods available. 
-will show the various methods available. If you are going to +If you are going to stray far from the default Slackware configs then you ought 
-stray from the default Slackware configs then you ought to +to know what hardware you have, or enjoy testing random configurations and 
-know what hardware you have, or enjoy testing random +frequent reboots : - )
-configurations and frequent reboots : - )+
  
 ==== Build Variables ==== ==== Build Variables ====
  
-Some variables that can be exported to change the behaviour +Some variables that can be used to change the behaviour of the build script:
-of the build script:+
  
 **OUTPUT:** **OUTPUT:**
  
-Optional. Where the build script will move the +Optional. Where the build script will move the completed packages to.\\ 
-completed packages to.\\ +
 Default if unset: auto from $TMP, recipe and version. E.G.: Default if unset: auto from $TMP, recipe and version. E.G.:
 ${TMP}/output-x86_64-${VERSION} ${TMP}/output-x86_64-${VERSION}
Line 117: Line 112:
 **INSTALL_PACKAGES:** **INSTALL_PACKAGES:**
  
-Optional. Whether to install the packages.  Set this to +Optional. Whether to install the packages.  Set this to anything other than 
-anything other than "YES" or "" to __not__ install the +"YES" or "" to __not__ install the packages, which is useful when building 
-packages, which is useful when building packages to use on a +packages to use on a different machine.\\ 
-different machine.\\ +
 Default if not set: YES Default if not set: YES
  
 **NUMJOBS:** **NUMJOBS:**
  
-Optional. Number of make jobs. If make fails with this then +Optional. Number of make jobs. If make fails with this then it is run again 
-it is run again with no jobs number set.\\ +with no jobs number set.\\ 
 Default if not set: -j7 Default if not set: -j7
  
 **TMP:** **TMP:**
  
-Optional. Package build directory. If changing this then +Optional. Package build directory. If changing this then the modules Slackbuild 
-the modules Slackbuild __must__ be adjusted (see below.)\\ +__must__ be adjusted (see below.)\\ 
 Default if not set: /tmp Default if not set: /tmp
  
 **RECIPES:** **RECIPES:**
  
-Optional: The ARCH list to build for. Values can be any of +Optional: The ARCH list to build for. Values can be any of x86_64, IA32_NO_SMP, 
-x86_64, IA32_NO_SMP, IA32_SMP. Anything else will cause the +IA32_SMP. Anything else will cause the build script to disown you.\\ 
-build script to disown you.\\ +
 Default if not set: automatic from `uname -m` Default if not set: automatic from `uname -m`
  
 +There are other variables used in the Slackbuilds but these are the most significant for our purpose.
 ==== Mirroring The Kernel Slackbuild Directory ==== ==== Mirroring The Kernel Slackbuild Directory ====
  
-There are a few ways of mirroring the directory - lftp, +There are a few ways of mirroring the directory - lftp, wget, or rsync if the 
-wget, or rsync if the mirror supports it.+mirror supports it.
  
 With lftp: With lftp:
Line 154: Line 148:
 </code> </code>
  
-If you don't want to download the source tarball (e.g. +If you don't want to download the source tarball (e.g.  because you already 
-because you already have one ready to use) then instead do:+have one ready to use) then instead do:
  
 <code> <code>
Line 163: Line 157:
 </code> </code>
  
-Note that I am using the -current source folder here because +Note that I am using the -current source folder here because it contains the 
-it contains the newest configs, and they are closest to the +newest configs, and they are closest to the target kernel version.
-target kernel version.+
  
-When the mirror is created, untar the kernel source archive +When the mirror is created, untar the kernel source archive in k/ and cd into 
-in k/ and cd into the source directory:+the source directory:
  
 <code> <code>
Line 178: Line 171:
 ==== Creating Kernel Configs ==== ==== Creating Kernel Configs ====
  
-I will make both a "generic" and "huge" config, because the +I will make both a "generic" and "huge" config, because the build script uses 
-build script uses those by default. If you wish to build +those by default. If you wish to build only one of those, comment out or remove 
-only one of those, comment out or remove the section for the +the section for the unwanted config from the main build script.
-unwanted config from the main build script.+
  
 The config files have the following naming convention: The config files have the following naming convention:
Line 193: Line 185:
 [suffix] is either ".x64" or nothing.\\  [suffix] is either ".x64" or nothing.\\ 
  
-E.G. a generic 64 bit kernel config for linux-5.0.8 would +E.G. a generic 64 bit kernel config for linux-5.0.8 would be:
-be:+
  
 config-generic-5.0.8.x64 config-generic-5.0.8.x64
Line 214: Line 205:
 Note that the preceding '-' is needed. Note that the preceding '-' is needed.
  
-As noted above, setting a local version will ensure that the +As noted above, setting a local version will ensure that the new kernel 
-new kernel packages won't upgrade the currently installed +packages won't upgrade the currently installed stock packages, unless of course 
-stock packages, unless of course you //want// them to, in +you //want// them to, in which case leave it empty. The kernel-headers and 
-which case leave it empty. The kernel-headers and source +source packages //will// upgrade those though, regardless of what we do here, 
-packages //will// upgrade those though, regardless of what +but if the new kernel is expected to be the main kernel then this shouldn't be 
-we do here, but if the new kernel is expected to be the main +a problem.
-kernel then this shouldn't be a problem.+
  
 The local version will also show in `uname` output: The local version will also show in `uname` output:
Line 228: Line 218:
 </code> </code>
  
-The configs need to be in a state so that they will build +The configs need to be in a state so that they will build without prompting 
-without prompting when the build is started. The easiest way +when the build is started. The easiest way to do this is by copying the two new 
-to do this is by copying the two new configs one at a time +configs one at a time into the kernel source directory as .config, run "make
-into the kernel source directory as .config, run "make+
 olddefconfig", and then copy them back: olddefconfig", and then copy them back:
  
Line 259: Line 248:
 </code> </code>
  
-If you get different output then something is probably +If you get different output then something is probably wrong.
-wrong.+
  
 The two configs now have all of Slackware's kernel settings, and with any new The two configs now have all of Slackware's kernel settings, and with any new
Line 288: Line 276:
 (The generic script is also used to make the huge kernel.) (The generic script is also used to make the huge kernel.)
  
-=== The Variables ===+=== Setting The Variables ===
  
 After placing the relevant configs in k/kernel-configs/ and the kernel source After placing the relevant configs in k/kernel-configs/ and the kernel source
-tarball in k/, it is only necessary to export any variables we want in the +tarball in k/, it is only necessary to set any variables we want in the 
-environment and then run the build script. You will want to export+environment and then run the build script. You will want to set
 INSTALL_PACKAGES=NO if you don't want to install the packages as they are being INSTALL_PACKAGES=NO if you don't want to install the packages as they are being
 built. built.
  
-Examples to set $OUTPUT in the environment:+Examples to export $OUTPUT in the environment:
  
 In bourne type shells (sh, bash, ksh, zsh, ash etc): In bourne type shells (sh, bash, ksh, zsh, ash etc):
Line 302: Line 290:
 <code> <code>
 export OUTPUT=/home/kernels/jabberwok export OUTPUT=/home/kernels/jabberwok
-mkdir -p $OUTPUT 
 </code> </code>
  
Line 310: Line 297:
 OUTPUT=/home/kernels/jabberwok OUTPUT=/home/kernels/jabberwok
 export OUTPUT export OUTPUT
-mkdir -p $OUTPUT 
 </code> </code>
  
Line 317: Line 303:
 <code> <code>
 setenv OUTPUT /home/kernels/jabberwok setenv OUTPUT /home/kernels/jabberwok
-mkdir -p $OUTPUT 
 </code> </code>
  
-If you don't want to install the packages, use one of the +If you don't want to install the packages, use one of the above methods to 
-above methods to export INSTALL_PACKAGES as anything other +export INSTALL_PACKAGES as anything other than empty or YES. E.G.:
-than empty or YES. E.G.:+
  
 <code> <code>
Line 336: Line 320:
 </code> </code>
  
-Depending on the recipes, at the start you will see +Depending on the recipes, at the start you will see something like:
-something like:+
  
 <code> <code>
Line 353: Line 336:
 </code> </code>
  
-If something went awry, then a build log may be useful. It +If something went awry, then a build log may be useful. It may be large, 
-may be large, probably over 100,000 lines for a single +probably over 100,000 lines for a single recipe, but could be useful for 
-recipe, but could be useful for debugging failed builds if +debugging failed builds if there isn't anything immediately obvious in the 
-there isn't anything immediately obvious in the terminal:+terminal:
  
 <code> <code>
Line 362: Line 345:
 </code> </code>
  
-<note>Viewing large build logs in 'less' ought to be +<note> 
-reasonably faster than, say, a text editor with syntax +Viewing large build logs in 'less' ought to be reasonably faster than, say, a 
-highlighting, like vim, for example.</note>+text editor with syntax highlighting, like vim, for example. 
 +</note>
  
 === Not Only But Also === === Not Only But Also ===
  
-In addition to the packages being created, we also have the +In addition to the packages being created, we also have the kernels, system 
-kernels, system maps, and configs copied to +maps, and configs copied to $KERNEL_OUTPUT_DIRECTORY which is set to:
-$KERNEL_OUTPUT_DIRECTORY which is set to:+
  
 $OUTPUT/kernels/<type>$(echo ${LOCALVERSION} | tr -d -).s $OUTPUT/kernels/<type>$(echo ${LOCALVERSION} | tr -d -).s
Line 384: Line 367:
 </code> </code>
  
-$LOCALVERSION is unset before creating that directory, in +$LOCALVERSION is unset before creating that directory, in case you were 
-case you were wondering.+wondering.
  
-After installing the generic kernel, don't forget to +After the packages are built they can be installed using installpkg or upgraded 
-recreate your initrd and rerun lilo.+using upgradepkg. A useful command to remember which deals with anything is: 
 + 
 +<code>upgradepkg --install-new --reinstall <package></code> 
 + 
 +<note> 
 +After installing or upgrading the generic kernel, don't forget to recreate your 
 +initrd. Lilo must also be run after upgrading, unless using grub. 
 +</note>
  
 ==== A Setup Script ==== ==== A Setup Script ====
Line 468: Line 458:
   * Set the variables at the top of the script.   * Set the variables at the top of the script.
   * sh setup.sh   * sh setup.sh
- 
-If $VERSION is unset it will bail out with an error. 
  
 Tweaks in a nutshell: Tweaks in a nutshell:
Line 478: Line 466:
   * The hard-coded /tmp path is replaced. Only needed if setting $TMP.   * The hard-coded /tmp path is replaced. Only needed if setting $TMP.
  
-$VERSION is found automatically from the highest version +$VERSION is found automatically from the highest version source archive. The 
-source archive. The configs are found in a similar way. They +configs are found in a similar way. They will be created if none are found for 
-will be created if none are found for $VERSION. If the +$VERSION. If the versions aren't what you expect, you may need to remove the
-versions aren't what you expect, you may need to remove the+
 other files, leaving the ones you need. other files, leaving the ones you need.
 +
 +If $VERSION is unset it will bail out with an error.
  
 ==== Lilo ==== ==== Lilo ====
Line 498: Line 487:
 /boot/vmlinuz /boot/vmlinuz
  
-This saves having to re-edit /etc/lilo.conf whenever we upgrade.+This saves having to re-edit /etc/lilo.conf at every upgrade, although **lilo still 
 +needs running afterwards.**
  
 Example using a local version: Example using a local version:
Line 516: Line 506:
 ==== Final Thoughts ==== ==== Final Thoughts ====
  
-Once a setup file is made, it is a very simple and +Once a setup file is made, it is a very simple and straightforward way to build 
-straightforward way to build kernels in a reproducable +kernels in a reproducable manner. No doubt my example setup file can be 
-manner. No doubt my example setup file can be improved, but +improved, but it shows enough to get started.
-it shows enough to get started.+
  
 This is the way that the kernel packages are made in Slackware -current, albeit This is the way that the kernel packages are made in Slackware -current, albeit
Line 525: Line 514:
 it. it.
  
-Link to example scripts:+Link to some example scripts:
  
 http://tty1.uk/scripts/kernel/ http://tty1.uk/scripts/kernel/
Line 538: Line 527:
 <!-- vim: tw=0 expandtab nospell <!-- vim: tw=0 expandtab nospell
 --> -->
 +
  
 howtos:slackware_admin:using_slackwares_kernel_build_scripts ()