Slashdot Mirror
Linux 2.4.16 Released
tekniklr writes: "They just released Kernel 2.4.16. Download it
here, and you can read the changelog here. This hopefully fixes the error that 2.4.15 had of corrupting filesystems on unmount." Update: 11/26 14:14 GMT by T : p.s. Don't forget to look in the mirrors.
Current bandwidth utilization 96.75 Mbit/s
.tar.gz from the slashdot homepage was not a good idea, timothy.
Out of 100mbps..
Linking directly to the
You should have pointed to the mirrors, instead:
Alexis 'jeriqo' BRET
2^4 = 16
--
The Cap is nigh. Time to get a fresh new account.
I've been following all the kernel releses, and their bugs. I was just curious, what is the best way to tell which kernel is currently the most stable, without jumping immediately to the latest release? Obviously there is no way of knowing if it is, without it being out there for at least a couple of weeks.
I was hoping that kernel.org or somewhere would list what is currently the most stable. I know that from roughly 2.4.5 through to 2.4.11 or so suffer from some sort of swapping/memory leak, I can't remember. This is just from loosely following what has been posted to slashdot in the past few weeks.
Is there any resource tracking for this? What is the most stable of the latest kernels?
For those interested, the preemptable patch against 2.4.16-pre1 also applies cleanly to 2.4.16 final.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Which Apple partition destroying software would that be? I must have missed that one. I am only aware of two.
The iTunes partition destroyer was pulled in something like 24 hours and replaced not long after.
Some years ago there was a problem with certain models of hard drives (Quantums I believe) that didn't handle their write caches well on a scsi reset. That went on for quite a while, but was not an issue with supported Apple hardware, it was some 3rd party drives that had tweaks to enable write behind caching. (The very large Oracle installation on Alphas that I work with had the same problem with them. Unable to resolve it with the vendors we finally scrapped all the disks and replaced them with a different vendor's drives.)
Ok your problem is easy. That happens with the _new_ VM introduced in 2.4.10, with the _old_ ext3 patch. So I am assuming you used 2.4.10 - 2.4.14, and you applied the ext3 patch. This is a harmless reporting bug. When the ext3 patch was merged into mainstream it was fixed. Use 2.4.16, it's probably the most stable 2.4 release ever[1] (except for /possibly/ a redhat kernel).
[1] 2.4.15 would have been the most stable/robust kernel execpt for that inode bug. Looking at the changelog for 2.4.16 one can see that the only real change was the inode bug, and one can make a safe prediction that 2.4.16 will turn out to be the most stable kernel in 2.4 series so far.
At least with FreeBSD I never had to worry when I cvsup'd to the latest sources in the -stable branch and built a new world and kernel. If the Linux kernel people are going to bother to have separately labeled stable and development versions, they should do at least some rudimentary testing before slapping a stable version number on some code and pushing it to the mirrors. Sure, there's no rules to this game...nothing says they have to do that...but they better do it, if they want Linux to ever get anywhere.
And yes, using new stuff on production machines is a bad idea...doesn't change the fact that if Linux ever wants any sort of market respect, showstopper bugs like this can't be allowed to make it into versions that are indicated to be "stable".
"That's Tron. He fights for the Users."
Very simple: /dev/hdaX".
Compile ext3 into your kernel (make sure it's not a module, if you want to use it for your root file system).
Do a "tune2fs -j
Reboot.
That's it.
The help for the kernel option tells you which version of the ext2progrs you'll need (at least 1.20 ?).
Having just joined the x86 camp, I wondered whether running 2.4.15 within User Mode Linux would have been helpful in this case. For that matter, how large is the actual user-base for UML?
To-do List: Receive telemarketing call during a tornado warning. Check.
Kick back, relax, take it easy, and run some automated burn-in tests for the kernel. Releasing code doesn't need to be a strain, or rushed. Remember, you're not doing it for "them". There is no "them", except in Sci-Fi, or paranoid extremist literature. Rushing is a self-inflicted injury. If you need to do self-harm, use a rubber razor-blade or something.
Many of the major shifts in the kernel have been the Right Thing To Do(tm), but those are the times you need to relax -MORE-, not less. Anyone with a penguin as a mascot understands cool. Cool is good. Cool is exactly what that penguin needs. Cool is what YOU need. You can't run at top gear, indefinitely, and expect to be even close to 100% of your ability.
As I recall, we went through something in excess of 120 pre-releases for one early kernel, and other early kernels often went through 20-30 pre-releases. (Oh, for the days of using a-z for the pre-release number! Sometimes the kernel fell off the end of z, and I think that was part of the incentive to switch to numbers.)
When Alan Cox maintained his series, he would often get into the tens, I suspect much for the same reason. A kernel is a complex thing, and the interactions can be hideously obscure. It takes a lot of testing and validating to work even just the worst of these glitches out.
If we reach 2.5.0-pre100, with the understanding that 2.5.1 will be solid enough to do new work, without forever struggling to figure out if a bug is in new code or a cold kipper from 2.4.x, nobody is going to complain. Well, nobody with any sense. The rest we can secretly smuggle into Afghanistan, where nobody'll care what they think.
I'd rather see 2.5.1 for Thanksgiving -NEXT- year, than be unable to do any serious development work for it. A solid foundation and a late, but perfect structure, is a billion times better than a sky-scraper made from twigs and built on straw, even if the sky-scraper is built on time.
You, like anybody, are undoubtably feeling all sorts of pressures - from work, to the family, to the economy, etc. Many of those pressures are bogus. Worrying about job security won't give Transmeta a greater profit. If it itches, scratch it (just be careful what you scratch in public), and if it doesn't, forget about it. You don't need to go creating problems. We have a Government to do that for us.
None of what I've written is new to you. Little, if any, is probably new to anybody. But it's all stuff we need to hear, from time to time. And when I see someone who is no idiot repeatedly making some very basic coding errors over a relatively short time, I think it's not unreasonable to think that there's a guy who is burning themselves out in the hamster wheel of life, and that that guy might benefit from kicking back & kicking the wheel over. Sometimes we go the furthest by making the least effort.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
You need to get the latest e2fsprogs (1.22) and the latest util-linux (2.11). Don't install the
/dev/hdwhatever". Done! A journal will be created automatically. Remember to only run this on a clean ext2 partition (make sure you're not running 2.4.15! :) ). If you're going to convert over the boot volume, make sure ext3 is built into the kernel and not a module. You shouldn't have to set any particular LILO flags (I didn't & I'm typing this
/etc/fstab to show the new filesystem type.
login utils if you're installing from a source tarball instead of an rpm.
When done, type "tune2fs -j
on ext3/2.4.16pre1). Update your
Not sure about the Slackware stuff, but I doubt if there are any config file changes.
Andrew Morton's EXT3 page has all the details.
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
Would remounting the filesystems read-only help? Or would that also trigger the bug?
And, if your filesystems are reiserfs, do you need to worry too, or does this only affect the traditional filesystems.
Say no to software patents.
Since 99% of Linux users get their kernel from their distributer, who patches it and tests it thoroughly before giving it out, this unstable kernel business has zero with Linux's popularity or lack thereof.
If it ain't broke, you need more software.
The 2.4 series of kernels have been out for almost a year, which hardly makes them bleeding edge. There are plenty of things that make moving 2.4 compelling.
The last 8 or so kernel releases have been released largely in response to major bugs in crucial kernel areas like virtual memory management. Upgrading to fix these problems seems like a reasonable thing to do if you are crazy enough to run linux on production boxes that do anything besides run DNS, SMTP gateways or some similar purpose.
You can call me a troll if you wish, but the writing is on the wall. Linux is in serious trouble due to feature bloat and releasing too early. I for one am glad that the idea of Linux has motivated the Unix vendors to open up a bit, and has exposed some fresh blood to the advantages of Unix.
Unfortunately, the implementation of Linux is falling apart by trying to do too much.
After typing this I realized that I'm not talking to a troll, but a know-it-all 15 year old. So I'll post under my actual moniker.
Conformity is the jailer of freedom and enemy of growth. -JFK
0) Make sure you have compiled and installed a patched kernel.
/dev/partiton
1) "shutdown now" or "init 1" as root to go single-user.
2) sync
3) umount all non-busy filesystems (usually only root is busy for most people).
4) sync
5) mount -n -o remount,ro /
(so now the root filesystem is read-only -- this step *is* important).
6) e2fsck -f
(once for each partition, starting with root [/] device, substitute e2fsck with reiserfsck, etc., as necessary -- force a check on each filesystem)
7) sync, hit reset
8) make sure not to ever boot into the buggy kernel again!
STOP . AMERICA . NOW
You mean VMWare doesn't work with 2.4.14 yet. Not the other way around. Since VMWare is closed-source (yes there is an open-source shim layer but it is just a shim layer) it is their responsibility to make it work with Linux.
If a regular application breaks with a new kernel release, it is the responsibility of the kernel maintainers. (Oh, except that Java thing from 2.2.18 or so - the JRE was relying on undocumented behavior so too bad.) But VMWare is not a regular application, it is more of a kernel mod.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README