Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 8600 - Unable to patch 2.2.12-20 kernel to 2.2.13
Summary: Unable to patch 2.2.12-20 kernel to 2.2.13
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 6.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-01-19 10:29 UTC by Ian Jones
Modified: 2008-05-01 15:37 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2000-01-19 17:48:26 UTC

Attachments (Terms of Use)

Description Ian Jones 2000-01-19 10:29:38 UTC
I'm probably doing something wrong here, but I need someone to point the

I am having major corruption problems on the filesystem (similar symptoms
to bug 8474, and then some..) and I have not been able to retain my Oracle
8.1.5 database in an uncorrupt state for any length of time.  Having read
the patch documentation for 2.2.14, it indicates that there are quite a
few fixes which may address my problems.  Hence, I downloaded the 2.2.13
and 2.2.14 patches.

When I tried to apply the 2.2.13 patch to my existing source tree, using
the command line invocation, or the patch-kernel script, I appear to have
over 300 .rej files in the tree.  I restored the tree from the rpm and had
the same problem.  As this may be expected (assumption on my part that
the -20 suffix to the current kernel indicates that it may have been
partially patched) I tried to make the image.  Make clean - OK; make dep;
OK, make zImage:

    Everyting OK until the final link, when it complains about function
mem_init in mm.o
    undefined reference to i386_endbase

Now, this is indeed the case that mm/init.o has a reference to
i386_endbase and there is no other reference to that.  Greping through the
source, there would have been a reference in setup.c, but this change was
rejected in the patch execution.  The only other reference is in smp.c
(but I'm only a lonely single processor.  So, should I run the patch
again, and this time insist that it is applied everywhere, or should I
just insist against setup.c, or ????

Thanks for your help

When this is sorted, onto 2.2.14 !!!!

Comment 1 Riley H Williams 2000-01-19 12:58:59 UTC
As you state, the kernel in the 2.2.12-20 rpm package is heavily patched, and
the kernel patches can't be applied against it. You would need to download the
full kernel source from...


...or from one of its mirrors, then configure and compile that.

I've been looking at producing a kernel-source-2.2.14-1.i386.rpm consisting of
the raw 2.2.14 kernel source with the relevant patches from the 2.2.12 rpm
applied to it, but that appears to be extremely tricky to get right as several
of the patches therein have been partly applied in the 2.2.14 source and also
partly not applied, whilst others appear to have been replaced by alternative
patches that fix the same problem.

I just wish that RedHat would produce such an RPM, but they apparently choose
not to do so.

Comment 2 Jeff Johnson 2000-01-19 15:26:59 UTC
You might try kernel-2.2.14-1.2.0 from Raw Hide. Dunno if it will fix your
problem since I know not what patches you are questing after.

Comment 3 Ian Jones 2000-01-19 17:48:59 UTC
Thanks for your help.

I've downloaded 2.2.14 from ftp://ftp.kernel.org/pub/linux/kernel/v2.2/
and hope this will fix the problems.  If not, I'll be back...

Note You need to log in before you can comment on or make changes to this bug.