On Fri, Nov 05, 1999 at 05:57:58PM +0000, John wrote: > I couldn't get this to work. My patches were in /usr/src and I got 'no > such file or directory', so I moved them into the kernel source dir. > and did -p0 thinking that should be right. No luck, so I did -p1 - > there was action, but only 33 times 'Hunk xx failed at xxxx' and > quite a few 'succeeded' at xxxx with fuzz 1 or 2 and a final line > 'patch: **** malformed patch at line 2121: s'. Okay, it sounds like your kernel source isn't a pure one (I'm guessing here). Patch is quite smart, and can patch files even if they're different to what it's expecting, although it'll only work if they're a little different, not a huge amount. It might be easier to download a fresh kernel source tarball from one of the kernel.org mirrors and try from there. You could download the latest, so you don't have to do any patching - but if you want to learn to patch, download an older one and apply the patches you've got to it. The only problem is a kernel source tarball is about 13MB. I'm pretty sure the source you extracted from the Debian package should be a standard kernel though, so maybe there's something messed up. rm the source dir and extract it again, then try patching it... > After looking at the .rej's, which were enlightening but not helpful > with the problem, and not finding anything else to guide me, I tried > to apply patch 3 expecting some message indicating it was out of > order. It, in fact, worked partially and said '2 out of 11 hunks > failed'. Emboldened, I did patch 4 ( '1 out of 2 failed') and then 5 > which seemed OK except for a final 'malformed patch at line 146'. The problem with patch is if it fails, generally you can consider that kernel source trashed and kill it and start over. If you really know what you're doing, the above isn't true, but for most people it's far easier to just start over than try and reverse the failed patches and find out what's gone wrong... If you've only applied one patch and it failed, then you're pretty safe to reverse it (option -R). You could probably reverse all of the patches this way if you were patient, but it's easier to just reextract the source and start over. > My problem here is that I do not know what the patch is expecting. If > I renamed to 'Linux-2.2.1' would it affect other things, maybe > creating more difficulties? Normally the patches will expect /usr/src/linux to be your kernel source, but some patches will look elsewhere instead. It all depends on the struct of the filesystem where it was built. But that's what the '-p' option is for - to tell patch your structure is a little different. > Another mystery to me arises from the fact that the command lines > suggested in all the literature I've seem do not appear to say what is > to be patched. Yet, according to O'Reilly's Linux in a Nutshell it's > based on 'patch [options] [original [patchfile]]. That's for patching single files, e.g.: # patch hello.c hello-fix.patch Which will apply hello-fix.patch to the hello.c source. With the kernel sources (and most patches) you're applying it to a whole bunch of files. Inside the patch file is where patch finds out which files it's supposed to modified, all you need to do is be in the right directory and run patch. The reason we are piping the output of zcat to patch is two-fold. Firstly, it needs to uncompress the file so patch can read it, and you need to send the patch file to patch from STDIN for patches with multiple files. If the patch wasn't compressed, you could do something like: # patch -p1 < patchfile > Any suggestions where I should stumble next? Will the patches still be > OK after what I've tried so far. My installation is appears undamaged > - seems indestructible. I'd be pretty surprised if the kernel compiles now, since some parts of the patches you applied didn't work, so the kernel source is in quite a messy state now... If you do something like zcat patchfile | patch -Rp1 in *reverse* order from the order you applied them, it will try and remov the patches you've applied. At the end you should have a copy of the 2.2.1 sources exactly like you started with. > Grateful for any help. I could, despite the online time involved, > download 2.2.13 but would learn nothing further here and would have to > face the problem later 2.4 if I want to keep up to date. You could download something a wee bit earlier, like 2.2.9 and patch it up from there. It'll be quite tedious to apply all of the patches from 2.2.1 up to 2.2.13, which is what you're going to have to do otherwise... That way you get a 'clean' kernel source, you get to learn how to use patch, and you get an up-to-date kernel at the end of it. -- [ Matthew Gregan ] [ GPG ID: B63A1E95 ] [ kinetik@ihug.co.nz ] [ GPG fingerprint: FB83 2911 F170 B31C 9E4A E382 CA8A A2F6 B63A 1E95 ]
Attachment:
pgp33GhztX0vo.pgp
Description: PGP signature