Linux 2.4.19 Released 367
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."
This discussion has been archived.
No new comments can be posted.
Linux 2.4.19 Released
Related Links Top of the: day, week, month.
Time is nature's way of making sure that everything doesn't happen at once. Space is nature's way of making sure that everything doesn't happen to you.
If possible? (Score:5, Informative)
When will you ever learn?
use this mirror (Score:3, Informative)
Re:On a more serious note... (Score:3, Informative)
Re:neat (Score:3, Informative)
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
Adaptec AIC7xxx driver broken with patch. (Score:1, Informative)
Re:On a more serious note... (Score:4, Informative)
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
Re:Does dump work yet (Score:3, Informative)
- 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.Re:Does dump work yet (Score:1, Informative)
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.
Directory name... (Score:5, Informative)
'Bout time! I always hated creating a temporary directory to uncompress to...
Not broken, but must "make dep" before anything. (Score:3, Informative)
Re:Does dump work yet (Score:5, Informative)
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:funny. I have been using it for days (Score:3, Informative)
However, an updated vanilla-sources ebuild has been in the Gentoo CVS repository [gentoo.org] 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.
Re:On a more serious note... (Score:2, Informative)
Re:Adaptec AIC7xxx driver broken with patch. (Score:3, Informative)
Care to give details? Do you have a console log by chance? I'm slowly taking on maintenance of this driver, so please feel free to contact me with these kinds of problems. My email is available from my URL.
Re:ChangeLog summary anywhere? (Score:2, Informative)
Also... (Score:3, Informative)
I got 1.42Mbytes/sec from U of Wisconsin to FIU, myself.
Re:neat (Score:5, Informative)
Re:Adaptec AIC7xxx driver broken with patch. (Score:2, Informative)
It may be a bore but here are some things to check:
- termination - using proper terminators for LVD? for SE? Both ends of bus terminated? only ends of
the bus terminated?
- cables - quality cables of proper impedance? correct cables for LVD, for SE?
- general - are you mixing LVD and SE? is bus length too long? all jumpers settings configured correctly on
all devices on SCSI bus? bus speed set too fast for length?
- connectors - properly and tightly seated? oxidized connectors? remove and re-seat them a couple
times to break oxidation.
- term power - are you sure that your bus is getting termination power? Check term power voltage
at each end of the bus? are term power fuses blown on controller or external devices (yes, it happens )?
You may be in denial. But it is not the kernel that is broken. Somewhere there is a fault in your SCSI hardware configuration. I tell this to you as a grizzled SCSI veteran. I've blamed software and various kernels and *always* in the end it turned out to be a problem with *my* configuration. There are a whole lot of variables. It sometimes takes a little more effort to run SCSI. . But IDE is not without its own set of problems either.Use your best debugging skills. You can do it!
Re:Does dump work yet (Score:3, Informative)
Re:Does dump work yet (Score:1, Informative)
fix for broken PowerVR driver (Score:5, Informative)
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 (Score:5, Informative)
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.
Don't forget to check the signatures (Score:5, Informative)
You *really* don't want a compromised kernel. Use the signatures [kernel.org].
Re:Does dump work yet (Score:3, Informative)
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).
Re:ChangeLog summary anywhere? (Score:2, Informative)
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
Re:Directory name... (Score:3, Informative)
Re:Meanwhile... (Score:1, Informative)
Blender works well, but the UI paradigm is a little different.
Re:Does this fix the nvidia/amd lockup? (Score:3, Informative)
Re:If linux is really not pro-terrorist, why the G (Score:4, Informative)
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: [gnu.org]
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.
Re:Adaptec AIC7xxx driver broken with patch. (Score:2, Informative)
Certainly not. A driver's response to broken hardware should never be to segfault. Sounds like both the configuration and the driver need work. Sounds also like this person is a good one to speak to regarding testing which improves the driver.
Cheers,
Ian
Re:Does dump work yet (Score:3, Informative)
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.
There IS a reason to use lilo (Score:3, Informative)
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.