# How to patch kernel sources?

## grant123

How can I apply the following patches to vanilla-sources-3.2.30?

https://github.com/beagleboard/kernel/tree/beaglebone-3.2/patches/3.2.30

How about these to git-sources-3.6_rc7?

https://github.com/beagleboard/kernel/tree/beaglebone-3.6/patches

----------

## NeddySeagoon

grant123,

cd /usr/src/linux_sources

get patch_file to ./

patch < patch_file

watch for failed hunks and manually clean up the mess.

```
man patch
```

----------

## khayyam

grant123 ...

I'd suggest using '--dry-run' first as then you will be provided with some idea if the patch will apply cleanly or not.

```
patch -p1 --dry-run -d /usr/src/linux <patch.diff
```

'-p[N]' is the number (path) to strip off the patch header, so if the patch is a unified diff from /usr/src then one level should be stripped as in the above we are supplying the path (-d) to the kernel sources.

best ... khay

----------

## grant123

All I get are failed hunks unfortunately:

# patch -p1 --dry-run -d /usr/src/linux <0134-VFS-make-vfs_fstat-use-f-get-put-_light.patch

patching file fs/stat.c

Hunk #1 FAILED at 57.

1 out of 1 hunk FAILED -- saving rejects to file fs/stat.c.rej

Can I add an epatch line for this somewhere in the ebuild instead?

EAPI="2"

K_NOUSENAME="yes"

K_NOSETEXTRAVERSION="yes"

K_SECURITY_UNSUPPORTED="1"

K_DEBLOB_AVAILABLE="1"

ETYPE="sources"

inherit kernel-2

detect_version

DESCRIPTION="Full sources for the Linux kernel"

HOMEPAGE="http://www.kernel.org"

SRC_URI="${KERNEL_URI}"

KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~ppc ~ppc64 ~s390 ~sh ~sparc ~x86"

IUSE="deblob"

----------

## aCOSwt

 *grant123 wrote:*   

> Can I add an epatch line for this somewhere in the ebuild instead?

 

Do not expect things that you cannot achieve "manually" to automagically become possible thanks to an ebuild.

If you want to patch an x.y.z kernel then, take the patch designed for this version.

If you cannot then... you are on your own and MUST know exactly what you are patching and why in order to adapt.

In the failure you mention, it simply appears that stat.c significantly evolved between the 3.2 you get and the 3.2.30 the patch was designed for. And that the patch designed for 3.2.30 no longer recognizes what should be modified. => Cant be applied.

Then, depending on your knowledge of the code, you may know what to do to adapt the patch or at least know if it is critical to get it or not so that you can drop it.

Well... at the end of the day... you are not in the worst situation... if you do not know the code and patch it blindly, the patch command might well work and... create a mess you would detect... at runtime...

Another thing. The patchset you mention is rather huge. I believe that each individual patch must be applied in a given order. Did you follow it scrupulously ?

----------

## NeddySeagoon

grant123,

I I was doing what I think you are doing ... and I am playing with a Raspberry Pi,

I would clone the git repository and get a ready patched kernel.

----------

## grant123

Thanks guys.  There is a patch.sh script I'm going to use instead.

----------

