I'm trying to recompile kernel on my RPi3A+. Excecuting the following commands on clean Raspbian 9 (stretch):

sudo apt-get install openssl-dev
sudo apt-get install git 
sudo apt-get install bc
sudo apt-get install bison
sudo apt-get install flex
cd ~
git clone --depth=1 https://github.com/raspberrypi/linux
cd ~/linux
make bcm2709_defconfig
make -j4 zImage modules dtbs

After a loooong time I got this (sorry for the picture but I cannot capture it in another way):

Error message

Unluckly we had set italian as locale and we cannot revert to english at this time anyway:

kdb_main.c (xxx): riferimento non definito a "kdb_cmds"

translates in:

kdb_main.c (xxx): reference to "kdb_cmds" not found.

or something like this.

How can I fix this? I tried to google for kdb related compilation errors but it seems that it's never been reported.

  • kdb_cmds is an array used in kdb_main.c and also referenced in kdb_private.h but I'm not able to see where it's been declared. I have a strong suspect that it should be in gen_kdb_cmds.c but it's 0 byte long... – weirdgyn Oct 23 '19 at 15:48
  • looks like it should be generated by Makefile but running make into kernel/debug/kdb/ has no effect (no rules ...) – weirdgyn Oct 23 '19 at 16:03
  • 1
    You should make explicit all the steps you took from when you unpacked/installed the source to when you ran that make line, because there should be at least a couple. Also, where you installed the source from. – goldilocks Oct 23 '19 at 19:47
  • @goldilocks I edited the message to depict the whole process. – weirdgyn Oct 24 '19 at 7:36
  • 1
    Using the github source and make bcm2709_defconfig I was able to make -j5 zImage; make -j5 modules; make -j5 dtbs. This is a buster system though, not stretch. There was one initial error involving scripts/ that required openssl-dev installed, after that everything went fine although it took several hours (on a 3A+); the new kernel (4.19.80-v7+) boots and runs. It is odd that you say that screen hung there for a long time after only a few lines of output; normally there is always something going on up to the point where it fails or finishes. – goldilocks Oct 24 '19 at 20:28

Possibly some previous aborted attempt is causing a problem, because this series of steps worked for me, although it took several hours on a 3B+.1 As root:

cd /usr/src
git clone --depth=1 https://github.com/raspberrypi/linux
cd linux
make bcm2709_defconfig
make -j5 zImage
make -j5 modules
make -j5 dtbs

This actually did fail on the first attempt because some kind of helper script wants to build something that requires apt install openssl-dev (the error has an explicit reference to an openssl header being missing). This is a bit weird as the vanilla kernel does not normally have any external dependencies besides libc.

I usually copy the kernel out manually; you can find that and the dtb/overlay stuff in arch/arm/boot:

cd arch/arm/boot
mv /boot/kernel7.img /boot/kernel7.img-dist
cp zImage /boot/kernel7-X.img
cp dts/*.dtb /boot/
cp dts/overlays/*.dtbo /boot/overlays/

And of course:

make INSTALL_MOD_STRIP=1 modules_install

After rebooting uname -r reports 4.19.80-v7+ and lsmod shows lots of stuff (indicating there are modules properly loaded).

If the build fails for some reason, you can try make clean, make mrproper, and/or make distclean; see make help output for details. If you use either of the last two, you may want to save your .config since that will be deleted.

Note that this doesn't include firmware; make firmware seems to do nothing. However, it should be fine to use the stuff provided by the distro, since firmware does not need to match exactly the kernel it was built with (as modules do), nor is it affected by the specific configuration (including platform, since firmware is not compiled for that, ie., you use the same stuff on the Pi as you would an x86 desktop, although the Pi firmware package does I think contain some stuff not included with the vanilla kernel).

Also note that because the Pi uses a simple bootloader that looks for the kernel based on a singular name in /boot, distro upgrades can overwrite your custom kernel. This is easy enough to avoid by giving the kernel a name that is not used by default (notice it was installed above as kernel7-X.img) and indicating that in /boot/config.txt:



Distro upgrades also install and delete directories in /lib/modules when rolling over the kernel. Point being, if the distro catches up to the version you are using, the module directory may be overwritten with modules that won't work with the running kernel. Conversely, when the distro upgrades beyond the running kernel it may remove directories from /lib/modules.

Not having functional modules may be hard to notice because the default Pi kernel does not require any modules to boot and function normally to a great extent (including basic networking).

A way to avoid that is to compile the kernel with a custom tag that will then be used in labelling the module directory. The default pi configs already do this, eg. -v7, which you will notice is used in the /lib/module directories. Customize that via make menuconfig General setup -> Local version (in .config this is CONFIG_LOCALVERSION). Note this tag has nothing to do with the kernel binary name (kernel7-X.img in this case). The version tag is compiled in and used to find the proper modules directory.

  1. If the system is headless use tmux or screen in ssh so you can disconnect and leave it working.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.