NIX Kernel

Topics - NIX Kernel

Linux: the choice of a GNU generation -ksh@cis.ufl.edu (more like) “Compiling the colonel sanders” - my SO, wisdom

Editor Note:

  • The material below was cobbled together for personal use, from attributed sources, and endured some mild look/feel massage.
  • Document Purpose: Conveniently scoped refresher on the listed Linux material.


  • LPIC2 Prep - Linux Academy
  • Photo by Pierre Châtel-Innocenti on Unsplash

The Linux Kernel

Knowledge Targets

  • Utilize kernel components that are necessary to specific hardware, hardware drivers, system resources and requirements.
  • Implement different types of kernel images, identifying stable and development kernels and patches, as well as using kernel modules.
  • Focus on standard way of doing things.


  • Centos - 2.x.x kernel tree
  • Debian - 3.x kernel tree

201.1 Kernel Components

Kernel Source and Documentation

  • Weighting of 2 on LPIC2, so only expect a couple questions.
  • Kernel source is typically not installed by default
  • Challenge - each distro has special additional steps that differs from others. Centos
  • uname -a to see current kernel
  • /usr/src/kernel, - yum install kernel-devel. When this completes, a folder for current kernel in this dir.
  • LPIC2 Exam - requires general steps for building a kernel
  • Documentation
    • 2.x and older, docs separate. 3.x+ docs come with.
    • Default: usr/src/linux/documentation, or possibly (centos) /usr/share/doc/kernel-doc-<version>/Documentation.
    • Often online doc will point you to a file in here. Debian
  • apt install source linux-image-$(uname -r)
  • /usr/src/linux-headers-3.13.0-36/Documentation


  • Boot directory /boot
  • vmlinuz is the actual kernel itself
  • Z-image (compressed image of your kernel)
    • Low memory sized image to support older systems with 512kb limit
  • On modern distros (2.0+)
    • “BZ image type”, aka “Big Z Image”. High-memory image.
    • Since 2.6, uses better compressing bzip2
  • 4.0+ xz compression. XZ is better compression ratio, but slower. Uses more resources.

201.2 Compiling Kernel

Prep - Dependencies


  • Group Install
    • yum groupinstall "Development Tools
  • Others
    • ncurses-devel, qt-devel, etc

Your going to need a bigger boat for all the devel libraries needed (99-ish)


  • apt install make gcc lib-ncurses5-dev
  • apt install build-dep linux-image-$(uname-r)
  • ex: cd /usr/src/linux-headers-3.xx.x-xx
  • Make
    • make distclean, make mrproper, make clean



  • General information for gcc on how to build software (not specific to a kernel bld)
    • Contains two kinds of information, information for entire env (flags and env vars), and make with targets
    • ie make clean
    • targets determine behavior of make action (based on passed in arg, ie make clean)

      make clean First thing we need to do is create a configuration file There are a dizzying list of options


(1) Menuconfig

  • make menuconfig is a nicer (ncurses) way of answering those option questions.
  • Reads a number of different scripts, and current config for kernel
    • When we installed kernel, we got a config file
    • We will pick the things we want installed and not installed
  • Go into sections..
  • ..anything with:
    • star - built in
    • blank - excluded, not present loadable or otherwise. Just means it isn’t built into K.
      • Doesn’t mean we can’t use it later. LKM
    • " is a module,"< >" Module capable
  • cat /usr/src/linux-3.13.0/.config
  • There are other options, but menuconfig is the most reasonable.

(2) Walkthrough, editing .config via make menuconfig

  • You could drop floppy driver support
  • Block devices
    • “Normal floppy disk support” - change from “M” to excluded.
  • You can go through and make a large number of changes. For a general desktop/kernel, you’ll never have a reason.
  • Write file and exit.

(3) Compile

  • Takes hours
  • Make sure you have a couple gig of disk space available
  • Start by making large image. make bzImage. Mainline kernel based on chosen options.
    • Runs a while (say 10s of minutes), builds kernel and kernel modules that we need.
    • First kernel image completes. Then you build k modules.
    • make modules, from in src dir. Runs a while (say 1s of hours).

(4) make modules_install

  • Completes, see output lines prefaced by “INSTALL”

(5) Relocate completed binary

  • source /usr/src/linux-3.xx.x/arch/x86/boot/bZimage
  • Move, use standard naming convention
    • mv bZimage /boot/vmlinuz-3.xx.x-xx.x86_64
  • Need to create initramfs for boot
    • dracut utility
    • mkinitrd /boot/initrd-3.xx.x-xx.img 3.xx.x-xx (example you’d do in normal compile, and is what LPIC2 looks for)
    • Debian special - mkinitramfs -o /boot/initrd-3.xx.x-xx.img 3.xx.x-xx
  • Last, we would deal with GRUB

201.3 Kernel Runtime Mgmt and Troubleshooting

Weighted 2x as heavily as kernel building Unlike modules built-in during compile, there are loaded in as needed to supplement the base kernel.

  • They are not loaded in and taking up memory when the K starts.
    • Only when there is a device or a reason for them to exist there.
    • Called LKM, loadable kernel modules
    • Review how to load, configure, add, remove

Knowledge Targets

  • Manage and/or query a 2.6.x or 3.x kernel and its loadable modules.
  • Identify and correct common boot and run time issues.
  • Understand device detection and management using udev, including troubleshooting udev rules.


Popular command, can give info about the kernel

rmay@dev-vm:~/Projects/dojo$ uname -a
Linux dev-vm 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux


  • SMP - kernel designed for multi-core procs
  • kernel name, uname -r
  • machine name, hardware type, platform (m,p,i)

Loadable modules

  • /lib/modules/<version>/
  • .ko, kernel objects
  • In kernel/, broken out by type
  • Different levels in each dir
  • Higher level, more general driver
  • These are all drivers we can load via LKM.


depmod and modules.dep

  • You might need to copy an already compiled kernel module to your system.
    • Those typically have an installation program that moves associated files.
  • There might a possibility that you just have object itself.
    • If all dependency libraries are present, you just need to drop the file.
  • In order to use it, you need to be aware of a command and couple of files.
    • Those tell the system what other things it might depend on, and map out how that KO fits in to device driver hierarchy.
  • Utility is called depmod, also handles map files. Resulting output is called modules.dep.
  • Run anywhere is smart enough to find needed things.
  • See modules map files:
rmay@dev-vm:~/Projects/dojo$ ls /lib/modules/4.15.0-43-generic/
build  initrd  kernel  modules.alias  modules.alias.bin  modules.builtin  modules.builtin.bin ...
  • If you copy a module into here, you’ll need to regenerate the maps
    • depmod Looks for KOs and sees where they fit.
      • Output, cat modules.dep Has a bunch of info. Listing of all detected modules on systems
      • Delimted by a colon, two fields.
      • First col - K module
      • Second col -dependencies, separated.
        • If blank, no deps.
    • Map files are further definitions, of what K modules and devices are mapped to what types of information.
      • Example, .usbmap has references to interfaces, drivers
      • TLDR: A way for the K to know, if something is plugged in, how to locate & load the appropriate device driver.

Listing, Adding, Removing Loadable Kernel Modules (KM)

Review - Loadable modules extend the kernel as needed

  • When something is there, it should be loaded, when something is not there, unloaded.
  • There are instances where you might need:
    • ..to manually load a KM for testing.
    • .. you installed it and want to make sure it is installed correctly (missing dependencies errors)
    • .. remove it b/c it is installed, but you want to free up the memory

LS Mod command lsmod

  • Module, Memory footprint in bytes, Used by
  • Good for determining how safe it would be to remove a module.
  • lsmod | grep lp

RM Mod

  • rmmod - see man. Also could use modprobe -r. Never recommend using force flag. Boot into safe mode and disable.
  • Ex: rmmod lp

Add Mod

  • Two ways to re-add: Old way(hard), New way(easy).
  • Hard way - insmod
    • Hard b/c we need to know exact module and path. Use modinfo.
    • Modinfo. Defaults to running kernel, no need for a path.
    • Use output for insmod. Ex: modinfo lp tells us ‘filename’ path for lp mod.
    • Use that in insmod.
  • Easy way - modprobe
    • modprobe lp If it succeeded, completes silently.
    • modinfo tells us params, like with lp you can modprobe lp reset=1

Other Module Changes of Interest Alias Force install/load (like if a dep could not be detected) Remove even if it has a device that would normally cause it to load Blacklist, if wanted to override its use on system at reboot

rmay@dev-vm:~/$ ls /etc/modprobe.d/
alsa-base.conf                  blacklist-ath_pci.conf  blacklist-firewire.conf     blacklist-modem.conf  blackli..
amd64-microcode-blacklist.conf  blacklist.conf          blacklist-framebuffer.conf  blacklist-oss.conf    intel-mi..

cat /etc/modprobe.d/dist.conf

  • See aliases, installs, removes
  • Ex: blacklist Nuvo driver to allow nvidia proprietary driver to load.


Viewing and Changing Kernel Parameters

/proc/sys and sysctl The /proc/sys filesystem is not really a fs, it is a memory based fs that is mounted under /proc.

  • Remember everything in Linux is treated as a file.
  • So we have K module settings (residing in memory) that we can monkey with as a file.
rmay@dev-vm:/$ cat /proc/sys/dev/parport/default/spintime 
  • echo 550 into spintime.
  • Reboot clears if there is a problem. So this is temporary.
rmay@dev-vm:/$ sudo sysctl -a | grep parport
dev.parport.default.spintime = 550
dev.parport.default.timeslice = 200

sysctl - Set via sysctl dev.parport.default.spintime = 560

Defaults come from compiled in defaults or sysctl.conf. Edit /etc/sysctl.conf to make a persistent change.

  • Best practice for editing, append to bottom and comment section as user overrides.

Displaying information about system hardware

Lots of utilities for this.


There are a number of devices that are intrinsic to system. Could be a port on the motherboard.

  • On system bus, constantly available. lspci. Bridges (ie PCI bridge), hubs, controller (sata controller), etc.
  • On virtual machine, this is weird.
  • lspci output
    • port/slot/etc, device name, other stuff
    • has a stepped verbose modes (-vvv)
  • Useful for finding kernel modules associated with devices on system.

Returns Device, DMA, IRQ, IO Ports, scraped from /proc fs Great if you are developing device drivers Not present on old kernels


USB info, gives manufacter and device id, for online lookup.

Device Filesystem udev

The /dev filesystem, devices as files.

  • In the past, this contained devices attached, and devices that could be attached (Linux system knew about them).
  • The udev filesystem is a daemon that probes devices at boot. After boot, the D will add the nessessary files to filesystem.


  • Where the files exist/are contained
  • How to make changes
  • /etc/udev/rules.d/
  • Higher number rules can override lower number rules
  • Rule files contain anything that can be passed for/to the loadable module.

UDEVADM Monitors UDEV activity

  • udevadmonitor