WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Working with custom kernels  (Read 2942 times)

Offline helander

  • Full Member
  • ***
  • Posts: 183
Working with custom kernels
« on: July 05, 2009, 11:13:41 AM »
A few things have bothered me when working with custom kernels with TC. None of the issues are
TC specific but more of a general Linux nature.

  • When you build and install multiple versions of your kernel you need to keep track of both the kernel image and the corresponding modules and make sure the right versions of the modules are loaded with the kernel you are currently using
  • Since the root fs image (tinycore.gz) contains a basic set of modules, you need to modify tinycore.gs for each kernel version. You then also need to make sure that the proper tinycore.gz is loaded with the kernel.

I have built a solution around the following idea:

  • Keep kernel modules outside of tinycore.gz.. This means that you can use an unmodifed version of tinycore.gz with your custom kernels
  • Build the drivers, required for disk access during early system startup, into the kernel
  • Load the rest of the drivers during a later stage of the system startup
  • Keep the kernel and its modules stored in the boot directory. The modules are actually stored in a subdirectory to the boot directory. The name of this subdirectory includes the name of the kernel so you can then easily see what kernel and modules that go together (another solution could have been to have a separate subdirectory for each kernel and its modules(

I have tested this idea and the script below is typically run during bootlocal or as a tce.installed script or you can run it manually any time after startup. Note that there are some additional detailed information as comments in the script code. 

There are a few printouts that occur during startup due to that some modules that are expected have not been loaded yet.

Another thing I have found is that with FAT support in the kernel there are some "error" messages at startup. I have found no problem however using FAT volumes, so it could be that these messages could be ignored. If you have nay info about this, please let me know.



Code: [Select]
#!/bin/sh
# Kernel modules loader
#
# Lars-Erik Helander
# lehswe@gmail.com
#
# The purpose of this script is to load the kernel modules associated
# with the loaded kernel.
#
# The script supports a concept for kernel module loading that provides
#     - separation between kernel and TC initrd (tinycore.gz).
#       In standard TC the "core" modules are contained within the initrd.
#       This means that you have to create a new initrd if you would like
#       to use a different kernel than the one that comes with TC.
#       With the concept supported by this script you could use tinycore.gz
#       as is when using a custom kernel. It is based on that all drivers
#       required during early system startup is built into the kernel so that
#       you do not need any modules in your initrd.
#     - support a system to contain several kernels and associated modules
#       in an easily maintainable way.
#     - combination of the above, i.e. use a multitude of kernels with the
#       same initrd (tinycore.gz)
#
#
# Principles of operation:
#
# Each kernel image has built in drivers for the disks to be used during
# system startup.
# In the directory where the kernel image is stored (from where it is booted
# from) there is a sub-directory named
#
#                          modules.${kernelimage}
#
# In this directory all module extensions available for the kernel in
# ${kernelimage} should be stored.
#
# This script, when run, will try to find out where the currently booted
# kernel booted from and find the modules associated with the booted image.
# All module extensions stored in the kernels modules directory will then be
# loaded.
#
#    A future extension of this script could be to support a boot option that
#    contains an enumeration of the module extensions to load. In this way one
#    could create subsets of the modules actually stored in the kernels modules
#    directory.
#
# The script is based on that the boot loader passes the path of the booted
# kernel image in BOOT_IMAGE. Most boot loaders do this automatically, however
# grub does not. To be more precise, grub2 support this but "legacy" grub does
# not. In case you use "legacy" grub you have to explictly add
#
#          " ... BOOT_IMAGE=/boot/`kernelfile` ... "
#
# to your entries in the grub configuration (menu.lst).
#
#
# NOTE: Currently only loading of modules from .tcem (and not .tczm) extensions
#       are supported.
#
# NOTE: In /etc/init.d/tc-config a "modprobe scsi_wait_scan" is issued. It turns
#       out that this driver can not be configured to be built into the kernel.
#       If your system depends on this module to be loaded before any disks
#       are checked you might be in trouble. Anyone that would have more knowledge
#       on this issue are more than welcome to provide feedback.

#======================================================================================
. /etc/init.d/tc-functions


echo "${BLUE}Loading kernel modules.${NORMAL}"

# Parse boot options.
for i in `cat /proc/cmdline`; do
  case $i in
    *=*)
      case $i in
       BOOT_IMAGE*) BOOTIMG=${i#*=} ;;
      esac
      ;;
  esac
done

echo "${YELLOW}BOOT_IMAGE=${BOOTIMG}${NORMAL}"

[ -z "$BOOTIMG" ] && echo "${RED}No boot image information. Check your boot loader or its configuration.${NORMAL}." && exit 0
BOOTDIR=`dirname $BOOTIMG`
BOOTBASE=`basename $BOOTIMG`
echo "${YELLOW}BOOTDIR=${BOOTDIR}${NORMAL}"
echo "${YELLOW}BOOTBASE=${BOOTBASE}${NORMAL}"

BOOTFILE="$(autoscan $BOOTIMG 'f')"
[ -z "$BOOTFILE" ] && echo "${RED}No boot image found !!!???.${NORMAL}." && exit 0

BOOTFILE=${BOOTFILE##/dev/}
find_mountpoint "$BOOTFILE"
[ -z "$MOUNTPOINT" ] && echo "${RED}Did not find mount point - should not happen !!!???.${NORMAL}." && exit 0

[ "$MOUNTED" == "yes" ] || mount "$MOUNTPOINT"

MODDIR="${MOUNTPOINT}/${BOOTDIR}/modules.${BOOTBASE}"

rm -f /lib/modules/`uname -r`/kernel.tclocal
mkdir -p /lib/modules/`uname -r`
ln -s /usr/local/lib/modules/`uname -r`/kernel /lib/modules/`uname -r`/kernel.tclocal

if [ -d "$MODDIR" ]; then
   for TCEM in ${MODDIR}/* ; do
      echo -n " ${YELLOW}`basename ${TCEM}`${NORMAL}"
      tar -C / -zxf "$TCEM"
   done
   echo ""
   /sbin/depmod -a 2>/dev/null
   /sbin/udevtrigger
else
   echo "${RED}No modules directory (${MODDIR}) exists.${NORMAL}."
fi

[ "$MOUNTED" == "yes" ] || umount "$MOUNTPOINT"

echo "${BLUE}Kernel modules loaded.${NORMAL}"






# Copied handling from tc-config that needs to be run after modules are installed


for i in `cat /proc/cmdline`; do
  case $i in
      *)
  case $i in
   nodhcp) NODHCP=1 ;;
   laptop) LAPTOP=1 ;;
  esac
      ;;
  esac
done


if [ -n "$LAPTOP" ]; then
   modprobe ac && modprobe battery
   modprobe yenta_socket >/dev/null 2>&1 || modprobe i82365 >/dev/null 2>&1
   /sbin/udevtrigger 2>/dev/null >/dev/null &
   echo " ${GREEN}Laptop options enabled (AC,Battery, & PCMCIA).${NORMAL}"
fi

if [ -n "$NODHCP" ]; then
  echo "${GREEN}Skipping DHCP broadcast/network detection as requested on boot commandline.${NORMAL}"
else
  /etc/init.d/dhcp.sh &
fi

/Lars

Offline granaos

  • Newbie
  • *
  • Posts: 8
Re: Working with custom kernels
« Reply #1 on: October 08, 2010, 06:54:12 AM »
Hi Lars , one question; this procedure will work if I compile a new TC kernel with RT patch?.

Thanks