Kernel Patching Weirdness
 

I'm not a Linux n00b by a long shot, but usually I just install a new
kernel from full-source and forget it. My laptop is fairly new and I'm
using some heavy-activity drivers so I'm looking at doing incremental
patching, which I haven't done in a long time.

To make a long story short, I'm seeing some weirdness I don't remember ever
having seen before: trying to patch 2.6.25.4 to 2.6.25.5 I'm seeing the
first hunk (on the parent Makefile) fail, a bunch of subsequent files
claiming to be reverse-patched, and then, when I spec'd "-R" on the
command line, later files claim to be forward-patched! I just can't win
here. Is this normal with current-generation kernel patches or am I doing
something wrong? Should I specify "-t"?

My command line is (from within /usr/src/linux):

patch --dry-run -p1 < /path/to/patch-2.6.25.5 | most #see what's going on

(--dry-run because I don't trust myself after not having used "patch" for
so long!)

Mike

Unpatched vanilla kernels should patch cleanly to then next minor version AFAIK. I'm wondering if you patched things in between? If you're feeling adventurous you could just patch it with some --fuzz, check the discarded chunks against the source and see if you can fit them in ;-p else why not just download http://www.kernel.org/pub/linux/kern...6.25.6.tar.bz2 ? Yes, it's moving that fast... And IMHO using --dry-run isn't about "trusting yourself" it is common sense.

Thanks for the comment on "--dry-run", I appreciate it! :)

On patching to 2.6.25.6: I thought you couldn't jump 2 revisions like
that: you have to patch to .5 then .6. Am I missing something here?

It's an interesting idea on "--fuzz", I'll give it a shot.

Worst case scenario, I just jump to 2.6.26 and live with any beta
weirdness (AFAIK, rc's usually don't break with the kernel...<knock knock
knock>)

Thanks again!

Mike

You're right, you shouldn't skip patches, but the link is not to a patch but the full source (as in skip beating the level boss and move to the next level anyway ;-p )

Kernel patches aren't built that way - revert the 2.6.25.4 patch, then apply the 2.6.25.5.
See ../Documentation/applying-patches.txt

But what if, like me, you download the already patched kernel: the
2.6.25.4 version is what I downloaded originally. So how can I revert
all the way back to 2.6.25? If what you're telling me is true, then I
need to just download 2.6.25 and then add and remove each 4th-numbered
(I can't for the life of me remember what that 4th number is called) as a
new one comes out. Is that correct?

Mike

If you downloaded 2.6.25.4 as a stable (i.e. full source), you can't patch it like that. You'll have to go get the baseline and apply the 2.6.25.5 patch to that.

If you are going to be actively patching, you need to get the applicable base plus the patch(es), rather than full source - patches are cumulative, and need to be reversed prior to applying a later patch. Else pull the (later) full source as released/needed.

It's the same. You can revert one patchlevel. That the kernel originally was 2.6.25 or 2.6.25.4 is not relevant.

You revert to .25, then you patch the next patchlevel. It's just the way it works. In other words, if you have a 2.6.25.4 kernel, you need to download this:

http://www.eu.kernel.org/pub/linux/k...h-2.6.25.4.bz2

Then you revert this patch with -R. Then you download:

http://www.eu.kernel.org/pub/linux/k...h-2.6.25.5.bz2

Or better, the latest today:

http://www.eu.kernel.org/pub/linux/k...h-2.6.25.8.bz2

And apply it.

True - i92guboj is correct.
You can reverse the .4 if you have it (as a patch). No need to (re-)go get the baseline as I suggested.

Too late at night ... sorry.