Slashdot Mirror
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."
← Back to Stories (view on slashdot.org)
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?
http://atlantis1.prolixium.com/~prox/proserv/linux /kernel/v2.4/linux-2.4.19.tar.gz. it's 100mbit. so give kernel.org a break...
There should be much improved IDE support including much improved support for UDMA6/ATA133 especially on Promise cards. To me, this is the most important thing because I've been unable to use Linux on my main system due to spurrious lockups when my large UDMA6 disks are mounted (even without DMA turned on..). -- Dave
Actually:
/usr/src/kernel-source-2.4.19.tar.bz2 ../kernel*2.4.19*.deb
:)
apt-get install kernel-soruce-2.4.19
tar xvjf
cd kernel-source-2.4.19
make menuconfig
make-kpkg --rootcmd=fakeroot buildpackage
sudo dpkg -i
Easy
I just tried just the patch to .19, and it's blocking on this driver. Pulling the full code to confirm we need Alan again...
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
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
Genebrew
- Backing up without unmounting disks. Mondoarchive does fine with that.
- Altering atimes and ctimes. I haven't checked this so I don't know what Mondoarchive does with them.
Mondoarchive can do incremental backups. Internally it uses afio for all of its work.> 'cpio' is also a good choice, especially when capturing special files, like those in /dev. I trust this more than the system default tar on many systems (e.g. Solaris).
..just make sure not to try copying /proc ;-)
FYI, GNU's tar handles the special files just fine. I've used it to do partition-to-partition copies several times, all went well.
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...
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
Wrong bug. It compiled, but folks need to do a "make dep" after an "make oldconfig"
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
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.
gentoo-sources-2.4.19-r7 is based on a kernel prepatch, not the kernel that was released today.
However, an updated vanilla-sources ebuild has been in the Gentoo CVS repository for 25 minutes and should make it to the mirrors shortly, if it hasn't already. Then, you can grab the new source tree by typing "emerge vanilla-sources"; or, if you're already using it, emerge -u will fetch the new copy.
I can verify the Promise part. I've been using the new Promise Ultra ATA 133 controller on 2.4.19-rc1 for a little while, and it works great!
http://kt.zork.net/kernel-traffic/
If you are at a University, use a mirror located at another University. Chances are the traffic will travel over Internet2 at ridiculous speeds, and not strain your University's (usually) clogged commodity Internet link.
I got 1.42Mbytes/sec from U of Wisconsin to FIU, myself.
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.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
-- Alastair
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 ));
Well, I've seen a few instructions for debian, but they're either wrong or not comented, so I'll try my own also.
/usr/src/linux or whever your favorite place is.
/usr/src/linux): /boot/config-2.4.18 .config .deb's ..
/lib/modules/2.4.19-me, /boot/vmlinux-2.4.19-me, etc
First, get the sources. I don't see them in the debian tree yet, so get them from kernel.org yourself. Put it in
To compile (all in
# 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
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
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
-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.
Having a trojaned SSH build script was bad enough.
You *really* don't want a compromised kernel. Use the signatures.
We have been using BRU backup backup software on our Linux servers the last couple of years. Recommended. The price is right too. They have fully working demoes for download. http://www.tolisgroup.com/
The main reason that we chose a commercial package was, that backups, especially on DAT streamers, can be a nasty experience. After experiencing a couple of "write-only" backup incidents (on NT 4.0 using DAT 1 and 2 streamers), I wanted something that actually verified the backup, and had extremely good error-logging, and CLI/scripting facilities.
Since BRU probably is the oldest commecial Linux and BSD backup package, it was the best choice at the time. There are several other solutions now.
Some advanteges with BRU:
Good CRC-32 check to ensure that what you _try_ to back up, actually end up on the tape in a non-corrupted state.
Fast verify.
Excellent error-logging.
Back up of live filesystems, and special files like sparse files, pipes, special device links etc.
Excellent CLI options, like regex selecting files, or filesystems to backup.
We still use v.16. But v.17 has Quick File Access (QFA. It also has a better GUI, but BRUs real power is as CLI program.
They also have a free (QPL lince) program called CRU, that enables booting from tape (if the streamer supports it, like HP's), and making a complete restore of the OS and data, including fdisk'ing, in one go.
(You just press a button on the DAT streamer, while the server boots).
Ok, just my 2 cents.
r iver
Orinoco driver updated from 0.09b to 0.11b
If you are using wireless network card (specially lucent and similars), you could think about upgrading your kernel, there have been many improvements and bug fixes
More info: http://www.seattlewireless.net/index.cgi/OrinocoD
May a is on Linux, and I *think* that Lightwave is intended to g osoon.
Blender works well, but the UI paradigm is a little different.
No Linux kernel branch currently contains fixes for the issue you noted. Folks from SuSE, AMD, and Nvidia are working toward a solution that will, as another post mentioned, require major restructuring of how memory is mapped (not to mention the issue of cacheline flushes, etc.). I think you have a better chance of seeing a workaround in 2.5. (I doubt the "mem=nopentium" append fixes it, perhaps lessens the chance of an erroneous state in the cacheline. Search lkml archives for details.)
And then later...
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:
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.
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
Nothing's wrong with incremental backups. You can even do them through the file system layer, which is safe. But dump operates below that layer, which is dangerous.
Dump/restore have great features, are useful, etc. That's not the problem. The problem is that bypassing the kernel's file system code is an unsafe kludge. It's like jumping directly into the middle of the code for some function, because you want to access some internal variable that's not exposed through the normal interface.
The idea of using the raw device while it's mounted is what's wrong with dump. I have no objection to the rest of it.
The file system calls expose the data that most people need. Some of the file system internals aren't exposed, making things like sparse files hard to deal with. The right way to do dump would be to add calls that tell the kernel to expose that data, so that the kernel can do the needed synchronization. Doing that in user code that gets the file system structures by reading blocks straight off of the disk is just plain broken. It won't work in Linux, where dump/restore are not managed as part of the kernel release process. *BSD and commercial Unixes always include both the kernel and dump in any release, making it possible for it to work.
But the right way to get the data is to ask the kernel for it.
the reason is:
AMD + Nvidia = crash
unless you pass mem=nopentium to the kernel. and I couldn't figure out how to pass mem=nopentium with GRUB.
GRUB is _SO_ stupid it refuses to run if the parameter after an '=' sign is anything but a number.
What ? Me, worry ?