Computing and Networks

A more elegant: Quick and dirty kernel patch and build

Ok,  I’ll keep this short, sweet and generic.  I’ll endeaver to put up a instructions for creating custom kernel packages in .dep and rpm (done and see here “Kernel patch and compile the Fedora way“) format if I find the need to create them.

As we have seen, the original/traditional/generic way to install new kernels or patch existing kernels is a relatively straight forward affair but requires manual management in regards to downloading the latest source (ftp from the nearest mirror) or stepping through the successive patch versions to get to the lastest kernel release.

Since managing a project as massive as the kernel is beyond the means of manual intervention and control, versioning systems  such as git were born to keep development manageable.

We can employ git to help manage our local kernel versioning, patching

This assumes that the system is ready as a development machine and the following, as a minimum, are installed:

gcc ccache openssl-devel kernel-devel git

STEP ONE: GIT IS ABOUT TREES AND BRANCHES. CHECK IT OUT.

It all starts with the source and kernel.org is your go to trusted site for the latest. Change directories to you $HOME

$ cd
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
$ cd ~/linux

This will take awhile and give you access to the release candidate (.rc) kernels as well.

List the tag names to find the latest kernel version (i.e. the highest number, in this case v4.14 is the newest stable release)

$ git tag -l | more

Checkout the files for the branch, using the tag listed from the last command (i.e v4.14)

[~/linux]$ git checkout -b custom v4.14

This will switch to the new branch called custom, now we are all set to customise our kernel prior to compiling it.

STEP TWO: CUSTOMISE AND COMPILE

Using git to manage changes to our base image is great as it manages a history of our local and upstream merges that we view for information or leverage for roll back if there are any issues.

To apply a patch (in this case the famed add-acs-overrides.patch in my Download directory), simply:

[~/]$ cd ~/Downloads
[~/Downloads]$ wget https://raw.githubusercontent.com/mooteel/linux-mooteel/master/add-acs-overrides.patch
[~/linux]$ git am ~/Downloads/add-acs-overrides.patch

The standard work flow for customising the kernel still apply as well.

To use the existing configuration from the current running kernel, do:

[~/linux]$ cp /boot/config-`uname -r`* .config

To interactively make changes using a menu inerface, do:

[~/linx]$ make menuconfig

Which way you chose, be sure to define CONFIG_LOCALVERSION= to something meaningful as this will be appended to the kernel name and atleast you now which one you booting to at the GRUB menu.

Once you have a .config file you are happy with.  ‘make’ the kernel.  I use a -j option to speed it up by assigning all my hyperthreads to the job e.g.

[~/linux]$ make -j8

Now make the modules and install everything. On the systems I have used this method on, I’ve had success with:
[~/linux]$ sudo make modules_install install

STEP THREE: REBOOT AND USE

After doing the normal backups and verifications, reboot and select the new kernel in GRUB menu (identified by your definition in CONFIG_LOCALVERSION= .

$ sudo reboot

Beer and profit.

One thought on “A more elegant: Quick and dirty kernel patch and build

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s