Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Originally posted by mudelf "Reversed (or previously applied) patch detected! Assume -R? [n]
Apply Anyway? [n]"
'patch' tries to apply a piece of code, but the modifications already seam to be applied. Here are some parts of the manual that explain this a little further.. (because I honestly don't quite know how to explain it)
-R or --reverse
Assume that this patch was created with the old and new files swapped. (Yes, I'm afraid that does happen occa-
sionally, human nature being what it is.) patch attempts to swap each hunk around before applying it. Rejects
come out in the swapped format. The -R option does not work with ed diff scripts because there is too little
information to reconstruct the reverse operation.
If the first hunk of a patch fails, patch reverses the hunk to see if it can be applied that way. If it can, you
are asked if you want to have the -R option set. If it can't, the patch continues to be applied normally. (Note:
this method cannot detect a reversed patch if it is a normal diff and if the first command is an append (i.e. it
should have been a delete) since appends always succeed, due to the fact that a null context matches anywhere.
Luckily, most patches add or change lines rather than delete them, so most reversed normal diffs begin with a
delete, which fails, triggering the heuristic.)
If you apply a patch you've already applied, patch thinks it is a reversed patch, and offers to un-apply the patch.
This could be construed as a feature.
It looks like you're trying to patch a distro specific kernel with a vanilla patch, this is not a particularly good idea. The kernel you're trying to patch is somewhere in between 2.4.18 and 2.4.19, but the patch you're using applies only to 2.4.18, so you're going to have some troubles, but it is probably still possible to get the patch to merge if you really work at it, but I doubt it's worth it.
If you're looking for the 2.4.19 kernel, you can just grab the full source for 2.4.19 and compile that. Or if you really wanted to, you could get the full source for the vanilla 2.4.18 kernel and then patch it with that patch up to 2.4.19. Ideally, you'd just grab one of the newer stable kernels, such as 2.4.22, and compile that. Unless you've got a specific reason to stick with an older kernel, the newer ones are usually better.
Phew !!! Ok that clarifies LOTS of things --- thanks for answering
I am trying to patch simply so that I can understand the process and be able to do so. This is the same case for recompiling the kernel.
Is it ok to apply a vannila kernel to RedHat? I would of thought it would be but then what happens about patching after that? Once I have 'gone vanilla' ( ;-) ) do I have to stay on that road with my patches untill I recompile again?
If all the flavours of Linux are specific in some way (e.g RedHat, Debian etc.) then what is the point of a vanilla one ... ?
I guess the most sensible course of action is to upgrade using a RedHat Source RPM --- however I wanted to understand and be able to do a source recompile for the purpose of learning.