I was interested to see how to do a Linux Kernel Build from the source code. I followed this guide and while it mostly made sense there were a few areas that I found less clear or had unexpected errors.
Initial Set up
I used VirtualBox rather than VMWare suggested in the guide, but don’t think didn’t encounter many differences. Some of the later steps are quite resource intensive, so set your virtual machine memory , CPU and Virtual Disk relatively high if you can spare it on your host machine.
I used a lubuntu install with 10GB virtual hard disk initially, but upped that to 20GB when I ran out of space cloning the repo.
The guide I followed is actually for submitting patches. This might be something I build up to, but realistically I didn’t think I would be submitting patches any time soon, so I skipped the email setup.
Cloning the Kernel Repo
The guide recommends cloning the repository on a fast, stable, unlimited connection. They weren’t joking when they said it took over 5GB!
I didn’t follow the guidance on sensible virtual disk space and ran out of space on my first attempt.
This still was not working, so tried pinging git.kernel.org in the virtual machine and got the error ‘Temporary failure in name resolution’. Pinging the IP address of git.kernel.org (via this website) gave the same error.
This still didn’t work and after mucking about with pinging and checking IP addresses I found this solution to temporarily change the nameserver to 184.108.40.206.
Finally, I came across this page which mentions there had been issues with kernel.org, which could be related to the same problem
If you keep having problems, you could use the GitHub mirror if you just want to be able to build recent-ish kernel code.
Updating the build configuration
As per the guide, I found a kernel config file in /boot/and copied it to .config in the cloned folder:
working directory with
cp /boot/config-uname -r* .config
It is also a good idea to update CONFIG_LOCALVERSION in the new config. This appends an extra label to the name of any kernel built which helps avoid name clashes.
Building The Kernel
Setting the Config
If you run ‘make’ without a .config file, it will complain that there isn’t one there.
I think the config file I used (from lubuntu 20.04) was quite out of date compared to the kernel as there were many questions not configured and appeared as ‘NEW’.
Having no idea what I was doing, I just accepted the defaults for each question until the build got started.
Lots of them seemed to be about including compatibility with various hardware.
This page actually suggests some other ways of setting up your config including automatically accepting defaults on new configuration options or only building a minimal version to speed up build time.
In my case I initially copied the configuration from an Ubuntu build, which is likely to be fairly generalised and include more than a more bespoke option might need.
(In retrospect, I may have been better starting from the same kernel version as my distro (lubuntu 20.04) so I wouldn’t see so many ‘NEW’ config options.)
Fixing Certs Issues
After building for a while, I got an error:
No rule to make target 'debian/canonical-certs.pem', needed by 'certs/x509_certificate_list'
From this link it looks like I need to update the config to set
This seemed to do the trick, although I also needed to update the config for
Pahole is not available
This failed with an error that ‘pahole is not available’. Thankfully there was a stackoverflow question with an answer – install the ‘dwarves‘ package.
Installing dwarves did the trick and the rest of the build went ok.
To get a feel for how long the build time might be, check out these here and here . It really depends on the computer/resources you are using and how much you are compiling.
In my case the Linux kernel build took several hours and then ran out of space on my virtual machine. I tried again with a VM with more resources (8GB RAM, 4 cpu cores) and it was done within about 30 minutes.
Modifying a Driver
As I was running on a virtual machine I followed the guide to change the e1000 driver, which worked without issues.
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.
3rd Party Cookies
This website uses Google Analytics to collect anonymous information such as the number of visitors to the site, and the most popular pages.
Keeping this cookie enabled helps us to improve our website.
Please enable Strictly Necessary Cookies first so that we can save your preferences!