hpr-knowledge-base/hpr_transcripts/hpr0134.txt

Episode: 134
Title: HPR0134: Kernal Patching 
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr0134/hpr0134.mp3
Transcribed: 2025-10-07 12:14:17

---

.
Hacker of Gradio.
How to patch a kernel.
This is class two, and this is part two in, I think, what's going to be a three-part
little tiny series on compiling kernels.
So if you need to patch your kernel, which you would need to do, for instance, if your
distributions included kernel, didn't have support for a specific hardware device that
you need to have support for, or maybe you're just downloading the kernel source straight
from kernel.org, and again, it doesn't have whatever you need in it.
And one of the things that a lot of people are going to be patching for our security
updates, there's some big security patch, a lot of times you'll apply a kernel patch
for that.
Now, obviously, if you're running a typical distribution of Ubuntu, Fedora, Mandriva, all
those kinds of distros where they're building things for you and sending you updates, then
you're probably not going to have to patch a kernel yourself.
It's not going to be something that you're going to have to worry about.
But if either you're in an environment where security is of the utmost importance, you
need to patch things very specifically yourself, or if you're running a distribution that
doesn't have someone sending you updates every week, then you'll probably end up patching
a kernel yourself sometime.
And here's how to do it.
It's pretty simple.
First of all, you're going to want to download or find the kernel source code.
So if you're downloading a new kernel source code, you can download that from the repo
of your distribution, or you can get it from kernel.org.
And if you're not downloading it, if you're totally happy with the kernel that you're running
right now, you just need to patch it, then you should have the kernel source code on your
system already somewhere.
Usually, they either include it, or they give you the option to include it when you're
installing your distribution.
So one way or another, you're going to need the kernel source code.
And the typical location for that will be slash usr slash src.
And then typically what you do is you make a simlink called Linux.
And that simlink called Linux will be a simlink to the Linux source code directory.
So if you've got that, then you're going to want to download the patch file next.
And patches typically, as far as I know, are found at kernel.org.
There might be patch files being released by other groups.
I don't really know of any.
More often, I think it's, you find the patch files at kernel.org.
You want to make sure that the patch file that you are downloading is for the kernel version
that you're about to compile.
So don't download a patch file for 2.6.24 and try to apply it to kernel 2.6.25 because
that worst case scenario, it will appear to be work, but it will not work.
That would be sort of the worst case.
Otherwise you're just going to get a lot of failures and errors and things like that.
So make sure that the patch file is written for the exact kernel that you're going to
compile.
Version has to be the same because code typically changes from kernel release to kernel release.
And so the patch file just will not work.
Now once you have the patch file downloaded, you'll want to make a copy of it to the
slash usr slash src slash Linux directory.
And the patch files are usually labeled by the name of the patch file and then dash the
kernel version.
So just cp patch dash 2.6.25 base slash usr slash src slash Linux.
The cool thing about patching a kernel is that you can actually take it for a dry run
before you actually patch the kernel.
You can see if it's going to work, if there are going to be any errors that will be otherwise
generated.
So to do that, you just type in patch space dash p1, space dash dash, dry dash run space
less than symbol space patch dash 2.6.x.
This will give you a fair amount of feedback.
And if you're seeing any errors, you're going to want to make sure that the version of
the patch file is for the version of the kernel that you're trying to compile.
Also keep in mind, you know, ask yourself where the patch file came from.
If you're getting a lot of errors, and the patch file was sent to you by a friend of
a friend, you know, well, maybe you should go hunt down the original patch file or, you
know, find something else from a source that you know is legit.
But otherwise you should just see it go through the motions of patching the kernel, no errors,
and as long as that happens, then you're good to go.
And now you can actually apply the patch.
And to apply the patch, it is patch space dash p1, space less than symbol space patch dash
2.6.x.
And that does the same thing, except this time it's not a dry run.
It's the real deal.
It's patching your kernel.
It's modifying its code.
And once that is finished, you're going to want to make sure that your config file is
also in your little simlinked directory.
So remember that your config files usually just out and about in your boot folder in your
boot directory, I think it's usually called .config.
So it's not something you're going to notice on a normal ls.
But if you do an ls dash a, you'll see it.
So just copy that config file over into your slash usr slash src slash Linux directory.
And you're ready to go.
So whatever you use, whether it's a menu config or x config or whatever, just type in you
know, make x config or whatever you usually do when you're patching the kernel.
I mean, if you need details on that, just listen to the first episode that I did on the
actual kernel compilation and get a feel for that.
Now the way that I usually do it, because I'm really the only time I ever compiled the
kernel is on Slackware, I just compile it and then move it over into my slash boot directory
with a cat command.
But if you want to do it so that you end up with, for instance, a Debian package.deb file,
then you should definitely check out Dave Yates' episode on kernel compilation, which
he did on his own podcast, a lot of Linux links.
And that is found at lot of Linux links.com.
You can check it out.
I don't remember the episode number.
I want to say it's in the 70s, early 70s, late 60s.
But he goes over how to compile a kernel in such a way that you end up with a .deb file.
And then you can use aptitude to install the resulting file.
Now there's a similar trick if you're doing this on Fedora or Mandriva or some RPM based
in a Red Hat, Sintos, whatever, you can end up with an RPM file basically so that your
RPM database is aware of this new kernel that you've compiled.
And that's not a bad idea.
So to do it that way on Fedora or Mandriva, for instance, which I just, I know this because
I'm running Fedora on a computer and Mandriva on a computer.
So this was something that I had to kind of learn recently.
And I would go over the Debian one as well, but I just don't have as much experience with
that as I would like.
So I don't want to really go into it and not know what I'm talking about.
But like I say, Dave Yates covers it really well in one of his episodes of lot of Linux
links.
So check that out.
So if you're going to do this on a Fedora or Mandriva machine or something similar Red
Hat, Sintos, whatever, then you can, again, first, you're going to download the kernel
source RPM file.
So that would be straight out of the repo of the distribution and usually it's called
like kernel-2.6.25-src.rpm.
So it's an RPM file, but it's the source code for the kernel.
Now to do this properly, to do the best way possible, the friendliest way to your system,
you'll want to install the RPM dev tools.
For Fedora, that's Fedora-RPM dev tools.
So you just say yum, you become root, you'd say yum install Fedora-RPM dev tools, and
that will install basically all the stuff that you're going to need to create an RPM
package.
On Mandriva, I think it's just called RPM dev tools.
I don't think it has anything in front of it.
I can't remember at the moment, but just kind of do a URPM, I search for RPM dev tools
in Mandriva, or a yum search RPM dev tools, something like that, and you should be able
to find whatever dev package that distribution is handing out for you to make RPM packages.
So now that you've installed that, you can become the normal user again, and you can rebuild,
or rather you can build the RPM tree with the command Fedora-Build RPM tree, it's all
one word, Fedora-Build RPM tree, and that will generate the RPM tree.
It's going to create specifically a replica of the Slash USR-Slash SRC-Slash Red Hat
directories, but it's going to create those directories, that structure within your user
directory.
So that's going to be a nice little sandbox for you to build things in without going out
into the main area where things are getting built by the system.
This is your own private little build tree.
So you got that, and now you're going to grab the kernel source code RPM that you've
downloaded, you're going to take that, and you're going to create a spec file for the kernel,
which is kind of, it's sort of almost akin to a Slack build, where it kind of
has all the instructions for the compiler on how to compile this kernel that you're about to build.
So to do this, again, as just normal user, you type in RPMspace-ivh, that's indigo,
victorh, whatever h is.
So it's RPMspace-ivhspace-curnal-2.6.SC9.src.rpm.
So it's the RPM source package that you've downloaded for yourself.
And that, like I say, creates a spec file for the kernel.
And at this point, you will want to download your patch file, and again, you're going to place it
in the sources directory, along with everything else that you've just acquired.
And this is where it gets a little bit tricky, because instead of doing like a patch dry run,
patch P1, stuff like that, what you're going to do is you're going to go into the spec file.
So locate the spec file, it's usually just called kernel.specspc,
vim, or emacs, or pico, or nano, whatever text editor you want to use, open that up,
and find the section in this file where the patches are being applied.
And that's going to be fairly obvious, because it's labeled like patch 1, patch 2, patch 3.
And these exist because very, very few distributions, if any, use just a plain vanilla kernel.
Obviously, they've patched the kernel themselves, and so in the spec file,
there's going to be a place for all the patches to be applied.
So you're just going to add yours to the list.
I usually just add mine to the very, very bottom of that list to be safe.
You don't really want to add it at the top of the list, because you don't really know,
I mean, there's probably a logic to the way that they're building this thing.
You don't want to disrupt that.
So I put it at the very end of the list.
So you'll find a list of the patches.
So let's say there's patch number 8.
So just add yours as patch number 9.
So it'll be right after that, right?
So then you keep going down in that spec file, and you'll find the place where the patches are actually being applied during the compilation process.
And that is specifically called apply patch space kernel 2.6.9.patch.
So the earlier list is where the system, you know, I think dry runs the patches,
and then further down in the spec file, there's a place where they're actually being applied.
So you're going to want to add your apply patch command in the same order.
So if you said, okay, I'm patch number 9, then you're going to want to make sure that your apply patch happens in the same relative position.
So if yours came at the very end of the first section of where the patches were being sort of located,
then you want it to be at the very end of the section where they're being applied.
Or if yours was the third from the top in the first section, then when you're applying the patch, it wants to be a third in the list as well.
You see what I'm saying?
So the first list and the second list, they should both be in the same relative position to one another.
At the top of the spec file, there is a line or a command reading hash percent space defined build ID space.local.
And you're going to want to change that to something, well, first of all, without the hash, because you don't need that there.
This is a command that you're going to issue. So it's just percent space defined space build ID space dot whatever.
And when I say whatever, I mean something that's going to identify this build as something specific to you.
So you could call it dot platypus dot clatu dot whatever, but you want to make it something somewhat unique.
I mean, don't go crazy. Obviously you want it to be a legal file name and everything.
But it'll be something to just to show you that you've patched this kernel.
And now you can do a test run. So get out of the spec file.
You're going to do RPM build space dash BP base kernel dash 2.6 point whatever point spec.
And that's going to show you any errors that would occur if you actually built it.
Hopefully there are none. And the next step is to configure it.
So you just go into your user directory into the RPM build directory that has been created for you.
So it's a user slash RPM build slash build slash kernel dash whatever slash kernel dash whatever.
And you are going to just make menu config or make x config or whatever you want to do.
That is going to create an RPM for you.
So now you've got an RPM package just like you will in a on a devian system.
You have a dot db package if you do it that way.
And the idea there is that you've got the package and you can install it via that distribution built in method of installing things.
Which from what I understand is just a friendlier way rather than just making it on your own without really letting your system know what you're doing.
And moving it into your slash boot directory.
This goes through the motions and the RPM director or the database is aware that this kernel was built and exists.
And these features are available and so on and so forth.
So yeah, that's it. You just install the RPM package that you've got.
Keep a copy of it lying around just in case you need it.
You know, if you're reinstalling your system sometime later, you can always reuse this build.
Keep an old version of your kernel lying around as well.
Because if you've screwed anything up, you're going to want to be able to boot into the older kernel, the known working kernel.
And just remember to update your grub menu or your lilo menu just depending on whatever you're using.
Make sure that you've got all the different options that you need so that you can definitely boot into a working system.
You don't want to ever screw yourself by getting rid of a working kernel or forgetting to add that working kernel,
making sure that it's in grub, things like that.
It'll be a lot easier in the long run if you make sure that everything's still there.
You've got a backup plan.
And that's how you patch a kernel.
So thanks for listening and be sure to check out either my first episode on kernel compiling to get details.
If you're not quite clear on the compilation portion of it, this was trying to focus in on just the patching portion of it.
So if you need details on compiling it after you've patched, then just check out my first episode on kernel compiling.
And also definitely check out Dave Yates' episode.
It's really good. It kind of explains the process really well from a more debian centric viewpoint.
So have a good time, compile a kernel after all.
Thank you for listening to HACRIF of the Gradio.
Now it's sponsored by caro.net.
So head on over to see ARO.NAC for all of those details.
Next time, exciting discussion on how to compile your kernel over a distributed makeshift.
A makeshift supercomputer with distcc.