Linux 2.4.19 Released

Adrian Voinea writes "The latest stable Linux kernel (2.4.19) is out. The somewhat massive changelog has the details. The patch file is here and the full source is here. If possible use a mirror."

Comments

If possible?

[SpamJunkie]

What do you mean, "if possible use a mirror.". Use a mirror. The only time it isn't possible is when, say, the main server gets slashdotted and there ARE no mirrors.

When will you ever learn?

Re:If possible?

[tunah]

Oh yeah, great. Why don't I just go and have a clove of garlic for breakfast while i'm at it? You want a silver stake? 'Cause I've got one right here that you can have. Honestly, you are a load of insensitive bastards.

Dracula

Re:neat

[morgajel]

....
apt-get kernel-source-2.4.19
unbzip2, untar etc...
make menuconfig
make dep clean bzImage modules modules install
cp arch/i386/boot/bzImage /boot/newkern
lilo
lilo -q

I've only had it fail on one machine, and it had a crappy mobo.

Does dump work yet

[mosch]

A fundamental question. Does this release of 2.4 make it so that dump is now reliable, or is dump deprecated as a method of backup forever?

If it's the latter, can any of you linux gurus tell me what is the current "accepted" solution for making backups. Not archives or images, backups.

For those of you who are going to say dump works fine on 2.4, please read this message from Linus Torvalds. I keep hoping he'll change his mind though, at least until a viable alternative arises.

Re:Does dump work yet

[Anonymous Coward]

Linus is unlikely to change his mind about dump being a stupid program, because the concept of dump is just plain broken.

If you want to back up raw devices, use dd.

If you want to back up filesystems, use tar, cpio, or similar programs. These tools will back up everything that the standard Unix APIs expose about files.

Dump, however, tries to do more. Since there isn't an API to get what it wants to know, it has to read the raw device and duplicate the kernel's interpretation of the raw data. Since the kernel is being bypassed, there's no way to ensure that the data is coherent; sooner or later, something will get out of sync and bite you.

You can make dump work right, if you add new hooks into the kernel, extending the API. So it may work fine on Solaris, for example. But I don't think that those hooks are part of the POSIX standard. Dump is always bound to a particular implementation, with zero portability.

Figure out what you really need. Most can get by with file backups. If you truly need to restore to the same block numbers, then use dd.

Re:Does dump work yet

[macshit]

Wonder when Linus will get tired of "tar"? After all, its about as standard as "dump" is in any UNIX distribution. Maybe some file buffer cache change will render tar unusable, and we'll be told to use say.. dd? Or maybe cat.

Um, do you understand the difference between dump and tar?

Tar (and cpio, etc.), works via the normal user filesystem interface, which is very stable and well-defined. Dump, on the other hand, looks at the underlying disk, and so is extremely sensitive to changes in the way the filesystem works. As a result, it's not very robust (though it can be speedy).

Linus's advice is very good. Hopefully dump will just go away altogether; its time has gone.

bout time.

[_pi-away]

When 2.4.18 came out, i thought to myself "well i'll just wait till 2.4.19 comes out to switch to 2.4, shouldn't be more than a month or so."

Since then i've had to renew my drivers license three times.

Longest . . . update . . . ever!

Hrm.

[Jonny 290]

Insert standard Darn-And-I-Just-Finished-Downloading-The-Last-One- Yesterday wisecrack...

ChangeLog summary anywhere?

[plaa]

Can anybody here summarize any important changes that went on between 2.4.18 and 2.4.19? This changelog is just a ton of bug fixes between prereleases. Did they do anything interesting with it?

This is exactly the thing I'd like to see someone make. A simple list of notable changes for the average kernel-compiling Linux user. I've been wanting such a list for several years now, but have never seen one.

Something in the form of, "If you which to use hardware X with option Y, you may wish to upgrade, as this version adds beta support for it. If you use option Z you should definately upgrade, there are many bugfixes. ..."

Is there any kind of ChangeLog summary available anywhere? And if not, why? I shouldn't think it would be such a big deal for someone with some knowledge of the kernel.

damn... did anyone else mis-read this?

[lingqi]

Since then i've had to renew my drivers license three times.

for about three minutes i sat wondering: who the fuck do you buy your hardware from that actually *license* their drivers, and requires you to *renew* them? I didn't know Microsoft started manufacturing important PC components...

then it hit me.

sigh... goes to show that friday evenings are best spent away from the computer for best results.

Re:damn... did anyone else mis-read this?

[Thyrsus]

A car returns the first element of a list. A cdr returns the remaining elements.

Re:damn... did anyone else mis-read this?

[affenmann]

> A car returns the first element of a list. A cdr returns the remaining elements.

And you need a license for this? Now I know why LISP is out fashion.

Anyone else notice that...

[randomErr]

Anyone else notice that in the last couple of days Microsoft's ad for Visual Studio .Net keeps coming up in the rotation when ever there is Linux story.

Wonder how much that cost them to buy those keywords? Could C. Taco be enjoying a quiet vacation on an island somewhere?

Re:On a more serious note...

[rakarnik]

Main important change would be the IDE updates from the -ac kernels which are in 2.4.19. These should support the new large disks and ATA133, AFAIK. Also, the Changelog is accurate: those were the patches from 2.4.18 to 2.4.19.

-Rahul

Directory name...

[Atzanteol]

Anybody notice? Whenever you *used* to untar a new kernel tarball, it created a directory 'linux'. Now it creates 'linux-2.4.19'.

'Bout time! I always hated creating a temporary directory to uncompress to...

Labels...

[anakog]

(02/06/06 1.537.2.10)
[PATCH] Re: mislabelled label patch

No pun intended...

Re:neat

[Spy Hunter]

Don't use LILO, use Grub! There is absolutely no reason for anyone to subject themselves to LILO any more now that we have Grub. Imagine: filename tab-completion, in a bootloader! Since grub can read your filesystems, you'll never be stuck needing to use a rescue disk if there is still a valid kernel somewhere on your HD. If you mess up the upgrade, you won't hose your system as long as you didn't delete your old kernel.

Re:On a more serious note...

[larry bagina]

yes!

pipe.c: ++i; changed to i++;
panic.c: printf("shit!\n"); changed to puts("shit!");

fix for broken PowerVR driver

[Nomad128]

Hey all,

Assuming someone else on this list was, like me, silly enough to buy a PowerVR Kyro-based graphics accelerator, here's a fix for a compile bug that I got w/ kernel 2.4.19 and gcc 3.1:

drm/pvr_drm_vm.h, line 138, change to:

physical = (unsigned long)page_address(pte_page( pte ));

For those wanting to build under debian

[Rufus211]

Well, I've seen a few instructions for debian, but they're either wrong or not comented, so I'll try my own also.

First, get the sources. I don't see them in the debian tree yet, so get them from kernel.org yourself. Put it in /usr/src/linux or whever your favorite place is.

To compile (all in /usr/src/linux):
# optional: tells debian to apply any debianized patches (eg. preempt, ReiserFS, XFS, whatever)
# very important to do *before* config, or else you'll be configuring and building different things
export PATCH_THE_KERNEL=yes
make-kpkg --append-to-version "-me" -rev test.1 --initrd debian
# configure the kernel as you chose
cp /boot/config-2.4.18 .config
make oldconfig # or x/menuconfig
# build the kernel image
make-kpkg --append-to-version "-me" -rev test.1 --initrd kernel_image
# optional: build debianized modules (eg. nvidia, lirc, alsa)
make-kpkg --append-to-version "-me" -rev test.1 --initrd modules_image
# install the resulting .deb's
cd ..
dpkg -i *2.4.19-me*.deb

Explination of make-kpkg options:
--apend-to-version: optional, but a good idea. Makes the kernel version into 2.4.19-me and avoids any conflicts by installing to /lib/modules/2.4.19-me, /boot/vmlinux-2.4.19-me, etc
-rev: needed for the debs. good as long as it has some number in it
--initrd: tell it to build the initial ram disk (/boot/initrd.img-2.4.19-me). Not sure if it's really needed, but all debian kernels have one so I figure might as well use it.

I'm aware that not all of the options are needed on all of the commands, but I figure for safty and consistency's sake, to just leave it as is.

Hope this helps someone.

Don't forget to check the signatures

[David McBride]

Having a trojaned SSH build script was bad enough.

You *really* don't want a compromised kernel. Use the signatures.

Re:Meanwhile...

[Alioth]

What do you expect?

Slashdot isn't about Windows. If Slashdot was a Windows-centric (not UNIX centric) site, it would be \. and not /.

Re:If linux is really not pro-terrorist, why the G

[mjh]

First you say

Because the GPL is so frequently misunderstood...

And then later...

As noted above, the use of GPL code with code licensed from another party could, under certain circumstances, arguably obligate you to sublicense the other party's code under the GPL.

Wow! Excellent example of misunderstanding the GPL! There are *NO RESTRICTIONS* on the use of GPL'd code. Don't believe me? Check the GPL:

Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

What this means is that the *only* thing the GPL applies to is redistribution of code. If you simply use the code, you're free to do with it whatever you want (except redistribute it). So I'd recommend that you take your own advice and read the GPL before you start spouting off about what it's implications are.