[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: kernel upgrade options



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


Reply to: