On Thu, 12 Dec 2002 00:26:41 +0000 (GMT) Gedi Gedi <gediintheuk@yahoo.co.uk> wrote:
I'm new to linux, only 2 weeks, and I need a little help with updating the kernel. I am running 8.0 on a i686 machine and I have a few questions.
My current kernel version is 2.4.18 and I thought I would have a bash at updating to 2.4.20. I used the following commands:
cd /usr/src gunzip -c 'patchfile' | patch -p0
everything seemed to go to plan and I verified that for rejected portions using 'find /usr/src/linux -follow -name "*.rej" -print
OK, all you did so far was patch the kernel source tree up to the 2.4.19 level. If you got the vanilla patches from kernel.org, I'm surprised you didn't get alot of .rej while trying to patch the suse kernel tree. This did not build any new kernel at all.
now if I enter the command 'uname -a' I get the following reply : Linux linux 2.4.18-64GB-SMP #1 SMP Wed Mar 27 13:58:12 UTC 2002 i686 unknown
That's right. You didn't build and install a new kernel, so your old one is still in effect in /boot.
However, if I give the command 'linux/scripts/patch-kernel' I get this : 'Current kernel version is 2.4.19' What is actually happeneing here? if I navigate to /usr/src, my symbolic link points to a folder named linux-2.4.18
Well, you asked what the patch level is after you applied the patch. As far as the directory name not changing, that is a minor point. Usually there is a symlink ~linux which points to your current kernel. The plain vanilla kernels from kernel.org will uncompress to /usr/src/linux, you can add -2.4.18 to help keep things from getting confused when you have a bunch of different kernels in there at the same time. The one linked to ~linux, is your currently assigned kernel. If the patch applied successfully, you can change the directory name to -2.4.19, or just change it to plain linux.
Also, assuming what I did was correct (which I am not entierly sure of) I tried to repeat this procedure with patchlevel 20. Now I get the following response which has caught me out: linux:/usr/src/linux # gzip -cd /home/****/patch-2.4.20.gz | patch -p0 can't find file to patch at input line 4 Perhaps you used the wrong -p or --strip option?
Yeah, like I said above, applying plain vanilla patches from kernel.org on a suse kernel source tree, will produce alot of errors. The suse kernels have had a whole bunch of patches applied previously to them, so the new vanilla patches are not finding things where they expect them. Get the suse kernel source rpm off of your cdset, and look at it. It contains the plain vanilla 2.4.18 kernel from kernel.org plus (I'm guesstimating) about 10 patch files to apply.
Any help would be appricieted, I am NOT going back to windows : )
You have some options. Get the current kernel source rpm for suse8.1 which has the vanilla 2.4.19 kernel and patches. Or switch over to using the plain vanilla kernels from kernel.org; but it will not be easy to do a "make cloneconfig" of a suse kernel and use it to configure your new kernel, unless you apply all the suse patches. The other option is to just get the latest mantel or andreas kernel, built by the suse people. Now these are pre-built with all the modules, so you don't get the whole kernel sources with them. I've been using my own kernels with SuSe for along time. I have certain patches which I like to apply, and I can use the patches from kernel.org to update. Even then it can be a real pain, you normally have to apply patches to the plain vanilla tree, to get to your desired version level, THEN apply any specialty patches designed for that level. Often, you are forced to manually apply patches, because a specialty patch is designed for say 2.4.18, but that causes the patch to go up to 2.4.19 to fail with a .rej somewhere. But luckily, most of the patch providers keep their patches up-to-date to the latest stable kernel. It's up to you which route you want to take.
btw, I also ran 'make mrproper' to remove any old .o files and dependencies.
-- use Perl; #powerful programmable prestidigitation