BBB - Building the Linux Kernel

I was working with Arch linux earlier and had the exact same errors, it turned out I was running kernel 3.8.13-3-ARCH and when I looked in /usr/lib/modules I saw a subdirectory 3.8.13-1-ARCH  I forced an update of kernel and modules and the subdirectory was replaced to match the kernel...  and all the errors went away.

You need a step in your instructions for installing the modules.

Hi Brian,

I see on this site this instruction, which I seem to be missing:

~/kernel/kernel$ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- INSTALL_MOD_PATH=$HOME/kernel/kernel/rootfs modules_install

I'm not sure what it does, I'll try it. Does it create a file system containing the modules that I will need to tftp do you think?

If you want a RHL/Centos style distro then you could try installing this root file system to go with your kernel from  http://www.redsleeve.org/ no idea if it will work (in theory it should) but I will give it a try when I get chance.

That's great!! I'm looking forward to trying it.

I would be extremely happy with this on the BBB!!

Brian Welsby wrote:

 

I take it these systemd[1]  boot errors are because the correct kernel modules have not been installed in /usr/lib/modules/

Hmm..  effectively they're due to systemd trying to do all sorts of unnecessary "I'm-a-resource-hungry-desktop-app" nonesense. A huge chunk of what systemd does could easily be considered a simple waste of precious resources on a small embedded system.

Me too, when I was in gainfull employment I used nothing but Centos and RHEL. I only got into Debian and Ubuntu because of the R-Pi.

It looks like a package repository is being built mainly for R-Pi but at least with RH/Centos the package source RPMs are easily available.

shabaz wrote:
 
~/kernel/kernel$ make ARCH=arm CROSS_COMPILE=arm-angstrom-linux-gnueabi- INSTALL_MOD_PATH=$HOME/kernel/kernel/rootfs modules_install
I'm not sure what it does, I'll try it. Does it create a file system containing the modules that I will need to tftp do you think?

building and installing (or packaging) a kernel needs you to do a set of things:

1. make menuconfig (or make oldconfig if you have an appropriate .config already)
2. make  (compile everything)
3. make install (install just the kernel, but be careful with this as it may not do what you expect)
4. make modules_install (install the modules)
5. make headers_install (install the development headers into /usr/include/linux)

and possibly clone git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git or parts of it into /lib/firmware

The obvious problems start when you find out that by default, modules get installed into /lib/modules/<KERNELVER> on the build system. Largely this isn't what you want, especially if you're cross compiling (or packaging the result for a system that's not the build system).

There are other complications if you use the available features to seperate the source directory from the build directory so that you can use the same source for many different targets.

INSTALL_MOD_PATH lets you specify a prefix for the install location which means you can set it to something like /tmp/kernel-3.8.13 and your files end up under that directory instead of trampling all over the build system.

You can also do:

make headers_install INSTALL_HDR_PATH=/tmp/kernel-3.8.13/usr

in order to get the headers without trashing your build system.

What I do is to install all of the eventual kernel files into a temp directory, then create a tarball of that. This lets me compile once, and deploy that tarball to many different systems.

selsinork wrote:

 

Brian Welsby wrote:

 

I take it these systemd[1]  boot errors are because the correct kernel modules have not been installed in /usr/lib/modules/

Hmm..  effectively they're due to systemd trying to do all sorts of unnecessary "I'm-a-resource-hungry-desktop-app" nonesense. A huge chunk of what systemd does could easily be considered a simple waste of precious resources on a small embedded system.

Yes one of the first things I did with Angstrom was use systemctl to disable/remove unnecessary stuff,  just like MS Windoze really .. (sorry for swearing).

I too hate systemd.

selsinork wrote:

directory instead of trampling all over the build system.

You can also do:

make headers_install INSTALL_HDR_PATH=/tmp/kernel-3.8.13/usr
in order to get the headers without trashing your build system.

 

I always make sure I am not logged in as root or with root privs when cross compiling kernels, I made that mistake once.

Brian Welsby wrote:

 

I always make sure I am not logged in as root or with root privs when cross compiling kernels, I made that mistake once.

building kernels isn't really that hard, unfortunately there's many traps and assumptions in the process that can catch out the unwary..

like you'll always be building for the running system, and that /lib/modules/'uname -r'/build is a sensible place to be looking for anything.

I almost always do build as root, partially for historic reasons, partially because that's how my build machines are setup. I do have a set of build scripts that have been carefully crafted to deal with the pitfalls though and I currently build about 15 target variations from a single source tree using the O= feature to create seperate build directories. So it's important to get it right or else I'd end up in all sorts of trouble very quickly.

The Kbuild system has lots of useful options to make your life easier, sadly they're not well understood as evidenced by the uname -r hackery that seems all to common.