Instead of downloading the entire kernel, download just the patch file if you are running the previous version. Then patch your source tree using:

cd /usr/src/linux
bzcat /blah/patch-2.4.21.bz2|patch -p1
make oldconfig

http://www.de.kernel.org/pub/linux/kernel/v2.4/Cha ngeLog-2.4.21 [kernel.org]

for example.

ftp needs much more time and authentication stuff for login, commandos and so forth.

fr [kernel.org]

jp [kernel.org]

and so on...

Actually, that was released May 27th.

Bit torrent works best on large files. The source is only like 20megs. They could do it, but people should be only downloading the patch anyway.

$ cd /path/to/kernel
$ make menuconfig # Replace menuconfig with xconfig if you want
-Select the options you need in your kernel and save it
$ make dep bzImage
-Look in arch//boot/ for the bzImage file
-Install it for your favourite bootloader (grub/lilo) and reboot machine
-gloat :)

just for information according to the changelogs:

final:

- 2.4.21-rc8 was released as 2.4.21 with no changes.

dont upgrade if u have RC8 running already

$ cp linux-2.4.20/.config linux-2.4.21/
$ cd linux-2.4.21
$ make oldconfig

Actually, it does [sourceforge.net].

Sorry to burst your bubble... :)

Im using a 2.4.20-rc7.

Well, the 2.4.21 kernel was (in reality) the RC-8. Look at the changelog and see if any of that applies to you. If so then yes, it's would be wise to upgrade. If not, then it's your call. This is why the changlog exists...

Whatever happened to "make modules" and "make modules_install"? ;)

wget will work just as well for http and anonymous ftp transfers. even a little faster for ftp, since it's less letters :).

Did you try backing up your /usr/src/linux-2.4*/.config file and then run:

make oldconfig

That will only prompt you for new stuff, rather than go back through every single option.

Grsecurity has released a version for 2.4.21. I highly recommend it, especially for production environments with multiple users. I have found the ability to limit outgoing sockets by group invaluable.

<i>When is it worth upgrading kernel versions?</i>

This seems to be frequent question. I'd say that you don't need to compile new kernel until the old one doesn't have the xyz feature that you need and/or you feel that the new kernel is far more reliable and faster.

In other words: some still use 2.2 series because there is no reason (for them) to upgrade.

Remember that you can use modules to get that xyz feature..

# cd /usr/src/linux
# make menuconfig
# make dep clean modules bzImage
(assuming all's good)
make modules_install install


The scripts have been able to install the kernel itself by itself for quite a while and also detect lilo or grub or whatever. I have no idea why people keep telling the n00bs to cp ./arch/what/ever/

Is there a way I can easily use the old configuration? Any HOW-TO on this?

Copy the old arch/$(ARCH)/config.in file to the new tree and 'make oldconfig'

Im in charge of keeping production servers up to date. Im using a 2.4.20-rc7.
should I go up tp 2.4.21

If stability is important to you, you should only use proven, stable kernels on a production server.

Unless there is some new feature that you absolutely need RIGHT NOW and cannot wait, it is very bad to use 2.4.20-rc7 on a production server. The "rc" stands for "release candidate", which means that the kernel is almost ready to be used by the public, but needs people to test it first.

If you care about system stability, you should not be testing the kernel on a production machine. If you do want to test the kernel, do so on a test machine that is not a mission critical machine.

On several occasions in the past, a release-candidate kernel introduced new code which would crash or corrupt systems that used the kernel.

However, if 2.4.20-rc7 is not crashing on you, you don't need to upgrade to 2.4.21 right away. Review the kernel changelog, and see if any of the changes apply to you. Wait a few days (or weeks), and upgrade to 2.4.21 when it's convenient to you.

Personally, unless there is some urgent fix that I need in the new kernel, I always wait a few weeks or months before upgrading the kernel, just in case some wierd bug was introduced into the new kernel version. During those weeks or months, I usually test the new kernel on a test machine and see if anything wierd happens.

I can't believe some still don't get this:

As long as it's not available from ftp://ftp.kernel.org or http://www.kernel.org, there is no newer version of the linux kernel.

The same applies to the ftp://gcc.gnu.org and GCC (not the website, they are always a little bit lame updating it).

So if you say

'Mandrake has already put the "2.4.21" kernel in their 9.1 release'

your are wrong! They didn't. They lied to you. Or you are mistaken. Or they used a prerelease and renamed it 2.4.21.

And no, 2.4.21 it's not 'too late'. Look at the Changelog and what huge amount of bugfixing has been done. And all those updates to the drivers!

True, 2.6 will feature a log of nice extra stuff, but I guess 99.9% of all linux users are happy with just the features 2.4 has. They simply don't need support for NUMA, 64bit dev_t or Zero-copy NFS.

Red Hat 9 back-ported a disk scheduler which is a dog. either download this 2.4.21 vanilla kernel and compile it or recompile the default RH9 kerenl and remove the scheduler (I believe it is under General, been a while since I looked at this...the option right after the CPU info)

Did you mount your drives with defualt in the /etc/fstab file? If so, use noatime, notail instead. it will prevent those lockups.

If the following are true, then the high CPU usage is expected:
-You have an IDE CD burner
-You are using IDE-SCSI emulation
-You are burning a CD with a blocksize other than 2048 (such as redbook audio, or (S)VCD, etc..)

If the above are all true, the ide-scsi emulation reverts to PIO mode. Supposedly this will be fixed for 2.6

From the Release notes:

> o [Bluetooth] Use very short disconnect timeout for SCO connections.
> o [Bluetooth] Kill incoming SCO connection when SCO socket is closed.
> o [Bluetooth] Support for SCO (voice) over HCI USB

Are these the lines SCO's bitching about?

Nope. SCO in the bluetooth world means Synchronous Connection Oriented link.
Used mostly with bluetooth wireless handsfree devices. [phonearena.com]

Yippie! 2.4.21 is finally here! :) (I got it about an hour before the /. story showed up.)

They now have Opteron support in there.. I knew it was in the pre, I was just wondering if the new kernel or the rest of my hardware would show up first. I have everything for a dual Opteron system, except the processors and case. I'm so anxious, I'm going to burst. :)

( ) 386
( ) 486
( ) 586/K5/5x86/6x86/6x86MX
( ) Pentium-Classic
( ) Pentium-MMX
( ) Pentium-Pro/Celeron/Pentium-II
( ) Pentium-III/Celeron(Coppermine)
( ) Pentium-4
( ) K6/K6-II/K6-III
( ) Athlon/Duron/K7
(X) Opteron/Athlon64/Hammer/K8
( ) Elan
( ) Crusoe
( ) Winchip-C6
( ) Winchip-2
( ) Winchip-2A/Winchip-3
( ) CyrixIII/VIA-C3
( ) VIA-C3-2

I'm going to be a compiling fool when the rest of the parts show up. :) I'm going to try to get Slackware running on it. :)

I've never done this before, but I thought I'd give it a shot:

http://66.227.104.34/linux-2.4.21.tar.bz2.torren t

It's been six months! The only people who don't have 2.4.20 sources are people who don't compile kernels...

...or have uptimes >= 6 months.

linux-2.4.21.tar.gz.torrent [digitalpipe.com]

Far from dead...hell, the 2.2 kernel is still being maintained and patched (mostly by Alan Cox, but still...it's active)

Even 2.0.X is still maintained. It currently stands at 2.0.40-rc6 (almost one year old).

Obviously "oohp" didn't read the post you responded to. That said, it is not inappropriate to use a release candidate on production servers, especially when the rate of rc releases was a slow as it was. If the RC fixes a specific problem you are having, or offers a specific improvement you could really use, it is worth investigating. There are also issues of security to be concerned about; the iperm and networking bugs that exist in 2.4.20.

The main point is that one should do a small test deployment, and some heavy testing, before a wider deployment. There a probably few, if any, user mode level compatibility problems between 2.4.20 and 2.4.21, so reverting back to 2.4.20 should be fairly easy if there are problems. It all depends on the situation.

So your saying the alternative Windows doesn't run like shit once a heavy disk task starts? That's sure not my experience. I just posted this in another thread, but once you start any heavy disk task under Windows you an forget about doing anything else with the OS as you get to watch everything slow to a crawl.

Try out this newest kernel or the preempt patches. ALso like someone else said make sure you have the right hard drive flags set. After making sure your hdparm setting are correct tune ext3 as well.

to change ext3

add data=writeback to the mount points you want to be writeback not data=ordered in fstab
mkinitrd /boot/initrd-kernalversion.img kernelversion (yes this is odd but its the way until you hard code ext3 into the kernel)
update grub if you used a different name to point to correct .img, usually you don't have to do this though

My experience with RH 8.0 after upgrading to 2.4.20, making sure hdparm was correct, and change the ext3 journal type improved dramitically.

I don't see it exactly as a problem, more like a result of a setting that allows the system to constantly update the drive info with file access time and tail info (which can require loads of extra io's when loading a file). when you set the system to not update access time and tail info on a drive, it removes this extra io taskload.

http://osiris.978.org/~brianr/torrent/linux-2.4.21 .torrent [978.org]

Just apply the Host AP [epitest.fi] patch and your Prism cards will work just fine.

For those not in the know, treacle is British for 'molasses.' Welcome to America.

Why are you running a release candidate on a production server?

Uh, because there were several vulnerabilities found in the 2.4.20 kernels which were only fixed in the -rc's? See this summary [lwn.net].

Just apply security patches and don't tinker with anything else.

Sometimes the kernel needs security patches too.

I had a similar problem. Under heavy I/O, my system locked up for some seconds and complained about lost interrupts.

The new kernel (well, 2.4.21-rc8) fixed that.

One workaround mentioned in the LKML is to disable IO-APIC.

Instead of downloading the entire kernel, download just the patch file if you are running the previous version.

But, is anyone actually running vanilla 2.4.20, or keeping it in /usr/src/linux? Odds are that most people are running vendor kernels (even in Slackware the usually virgin kernel has been slightly violated this time ;), or at least applied the ptrace hole fix. As that fix is implemented differently in 2.4.21 it would be enough to keep the patch from applying cleanly.

Of course, you might still have the official linux-2.4.20.tar.bz2 tarball sitting around somewhere, and if you do you can use that and the patch-2.4.21.

Same here, well, downloaded the patch...
Control-C, lftp ftp.xx.kernel.org/pub/linux/kernel/v2.4/
cp -va .config ../
bzcat ../patch-2.4.21.bz2 | patch -p1
cp -va ../.config .
make oldconfig
make menuconfig
make...

Something better than that is a distributed C compiler.

distcc.samba.org [samba.org]. It's another fine piece of coding from the Samba team. It uses your standard gcc, and does parallel builds on other machines. Really speeds things up.

The Linux Progress Patch for 2.4.20 still works with this IF you do the following....

Use 2.4.20 source
patch for LPP
patch to 2.4.21

Voila... that nice Purdy linux boot screen is still there for your relatives that ball up on the floor crying when the boot messages start flying...

What happened on thanksgiving?

Thanksgiving 2002 saw the 2.4.20 data corruption on umount [kerneltrap.org] kernel released; thanksgiving 2001 saw the famous 2.4.15 "greased turkey" data corruption on umount kernel released.

There have been other kernels with problems, but it seems that the data corruption bugs tend to arrive with thanksgiving.

The past two thanksgivings have seen kernels released (2.4.15 and 2.4.20) with serious data-corruption-on-umount bugs.

If you do then you should also get Jeff Garzik's new sata as scsi stack patch and use that.

The module-init-tools link is valid, but you really should read this [codemonkey.org.uk] if you want to try 2.5 and haven't been following the development.

Having said that, I agree that it's highly unlikely that the patch will cleanly install against a vendor kernel, since they usually have lots of little mods in them.

If you install the .src.rpm for the RedHat kernel, you will actually get the original .tar.bz2 file and all the individual patches. So it would be no problem to patch against that.

When I can double-click an icon and click OK and have it install the updates give me a call.

Sorry I cannot help you there. RedHat has something very similar, but you only have to click once on the icon not doubleclick.

Slightly OT; I was using 2.4 kernel mostly because of nvidias drivers not compiling for 2.5.x. Then I found this site [minion.de] that provides up-to-date nvidia driver patches for 2.5.x including 2.5.70. (I had found patches before but they were always not-so-fresh)

One can download the nvidia driver from ftp://download.nvidia.com (the website only seems to link an "installer" version, which was irritating)

Now I'm happily runny mozilla-xft without those buggy artifacts the nv driver has-- and GL is always nice...