Bug 8600

Summary:	Unable to patch 2.2.12-20 kernel to 2.2.13
Product:	[Retired] Red Hat Linux	Reporter:	Ian Jones <ian.jones>
Component:	kernel	Assignee:	Michael K. Johnson <johnsonm>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	high	Docs Contact:
Priority:	medium
Version:	6.1	CC:	rhw
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2000-01-19 17:48:26 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ian Jones 2000-01-19 10:29:38 UTC

I'm probably doing something wrong here, but I need someone to point the
way.

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...

     ftp://ftp.kernel.org/pub/linux/kernel/v2.2/

...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...