Slashdot Mirror
Linux Kernel 2.4.21 Released
An anonymous reader writes "After > 6 months of waiting, 2.4.21 is here. Lots of cleanups, and a patch which gives a MAJOR boost to the 'feel' of the system under heavy disk IO, especially on IDE systems. As usual, available from your local kernel.org mirror or ftp.COUNTRYCODE.kernel.org/pub/linux/kernel/v2.4/! Tidbit: 'Current bandwidth utilization 131.72 Mbit/s '." See the Changelog for new stuff.
Instead of downloading the entire kernel, download just the patch file if you are running the previous version. Then patch your source tree using:
/usr/src/linux /blah/patch-2.4.21.bz2|patch -p1
cd
bzcat
make oldconfig
http://www.de.kernel.org/pub/linux/kernel/v2.4/Cha ngeLog-2.4.21
for example.
ftp needs much more time and authentication stuff for login, commandos and so forth.
fr
jp
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.
-- taking over the world, we are.
$ 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
There is no patch for stupidity
Visit my blog
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.
:)
Sorry to burst your bubble...
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
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...
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
wget will work just as well for http and anonymous ftp transfers. even a little faster for ftp, since it's less letters :).
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.
Contact Me (got tired of viruses emailing me).
When is it worth upgrading kernel versions?
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..
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.
"Can of worms? The can is open... the worms are everywhere."
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)
"Some things have to be believed to be seen." - Ralph Hodgson
Did you mount your drives with defualt in the /etc/fstab file?
If so, use noatime, notail instead. it will prevent those lockups.
-Cnik
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.
signatures pending - ansa@kos.to - (dont mail there)
Yippie! 2.4.21 is finally here! :) (I got it about an hour before the /. story showed up.)
:)
:) I'm going to try to get Slackware running on it. :)
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.
Serious? Seriousness is well above my pay grade.
I've never done this before, but I thought I'd give it a shot:
n t
http://66.227.104.34/linux-2.4.21.tar.bz2.torre
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
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.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
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.
/boot/initrd-kernalversion.img kernelversion (yes this is odd but its the way until you hard code ext3 into the kernel) .img, usually you don't have to do this though
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
update grub if you used a different name to point to correct
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.
If you wanna get rich, you know that payback is a bitch
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.
-Cnik
http://osiris.978.org/~brianr/torrent/linux-2.4.21 .torrent
Just apply the Host AP patch and your Prism cards will work just fine.
Homepage
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.
Just apply security patches and don't tinker with anything else.
Sometimes the kernel needs security patches too.
The new kernel (well, 2.4.21-rc8) fixed that.
One workaround mentioned in the LKML is to disable IO-APIC.
Same here, well, downloaded the patch... .config ../ ../patch-2.4.21.bz2 | patch -p1 ../.config .
Control-C, lftp ftp.xx.kernel.org/pub/linux/kernel/v2.4/
cp -va
bzcat
cp -va
make oldconfig
make menuconfig
make...
New things are always on the horizon
distcc.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.
Get your own free personal location tracker
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...
Do not look at laser with remaining good eye.
What happened on thanksgiving?
Thanksgiving 2002 saw the 2.4.20 data corruption on umount 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.
Tarsnap: Online backups for the truly paranoid
The past two thanksgivings have seen kernels released (2.4.15 and 2.4.20) with serious data-corruption-on-umount bugs.
Tarsnap: Online backups for the truly paranoid
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 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.
.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.
If you install the
Do you care about the security of your wireless mouse?
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...