Charles Lockhart wrote:
Any advice on what to do when you're trying to patch a kernel that's
already been patched, which causes the new patch to fail? In
particular, how about patching the kernel versions that come with the
main distros like RedHat? Do you just have to knuckle down and do a
line by line edit?
-Charles
Pretty much.
Generally, you can apply the patch and then just go take a look at the .rej
files and hand edit them in. However, every once in a while, another change
made that wasn't near a patch chunk will still cause your patch to break.
Generally you'll see this either when compiling the file or during the final
link. Either way, the compiler/linker will issue an error telling you where to
go look (get out grep, it'll help).
I have the problem quite frequently trying to make older patches work on newer
kernels (example: RML's network devices contribute to /dev/random entropy pool;
made against 2.4.18, doesn't apply at all cleanly against 2.4.20+ due to
numerous driver changes, most of which are almost identical).
The only thing to watch out for is similar patches. For example, attempting to
apply SGI's full XFS patch (with ACLs) and grsecurity's full patch (which ALSO
has ACLs) will tend to cause so much trouble that it's not worth trying to make
it work (you'd have to know quite a bit about the kernel internals, and then
you'd just end up with two things that do almost the same thing).
It may be worth using patch's "--dry-run" option first to see how much work
you'll be in for then evaluate that against how big your need for the patch is.
In the case of distro kernels, it may help to just start with a vanilla kernel
and grab their list of patches. You can then apply only the patches you
actually need/want, as well as your own. This may fix some problems with
conflicting patches (such as my XFS and grsecurity example). It will also allow
you to patch in whatever order you please, rather than having all the distro
patches applied already. Sometimes this can help too.
--MonMotha
