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
I was under the impression that the corruption could be corrected by an fsck, and that while the ext structure was invalid, the data was left intact, that the issue was more with lock files, so an fsck would restore a valid inode table, and the actual data should still be intact, did I misunderstand this? I didn't ever actually use the beast, so I could be wrong...
XML is like violence. If it doesn't solve the problem, use more.
for those who are brave enough to immediately try out fresh kernels that may break one's system so I don't have to - and for those responsible for putting the fix out so quickly.
"...today consumers have been conditioned to think of beer when they see a bullfrog..."
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?
Although I like to be as "leading edge" as everyone else, I've held back on migrating to the 2.4 kernel because of the sorts of things that have been happening to this release.
Although the 2.4 kernel seems to be overall a major step forward from the 2.2 kernel, there have been too many major changes with too little testing to make it a 'stable' kernel yet. It was only a couple of 'mod levels' ago that the VM was entirely rewritten to fix a performance problem that the original 2.4 VM (rewritten from 2.2) introduced. And, the 2.4 kernel (finally having been pronounced 'stable' by the kernel team) is discovered to have a major file corruption problem (now, apparently fixed in the +1 mod).
Not to disparage the kernel team (whom I think have done a wonderful job in giving us the next generation kernel), but I think I'll wait until this 'stable' kernel stabilizes a little more.
"values of beta will give rise to dom!"
It's time to admit that most people don't need the newest kernel, and should just run whatever their favorite distro has properly tested. Unless you enjoy pain and you have no data of consequence, chasing kernel versions is a losing proposition.
I looked at the 2.4.15 and 2.4.16 changelogs but I cannot understand if they fixed whatever problem happens with the disk cache. I often find myself with 2^32-1 Kb of RAM devoted to cache, which has some interesting results.... If you just ignore it goes away after a bit, so it's probably a counter somewhere which underflows. :)
But it's certainly fun, have you ever seen bubblemon turn pink? Or blood-red?
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
2^4 = 16
And this one is an even number, they are supposed to be stable.
2.2.x --> stable
2.3.x-> development
2.4.odd --> seems to heve unexpected bugs.
2.4.even --> might be stable. who knows?
2.5.0 --> unstable! it had to be. now everyone who said that 2.5.0 would be the last 2.odd stable one will be proven wrong.
Didn't this have to to do with the odd and even numbers of the start trek movies 8-). Or don't you think this is funny after downloading 2.15 just a few hours ago and syncing/fscking like hell now?
Seems that there's always a bug in every new kernel release lately and it either is so major that it warrants switching to a previous kernel lest I suffer catastrophic effects or its minor but it's still something that affects me (such as ntfs or emu10k support).
I somehow missed the 2.4.15 announcement so fortunately I wasn't hit by any problems (I also missed the 2.4.13 release, dunno how), but even though I normally pop in the newest kernel upon release I'm pondering waiting this one out.
STOP MISUSING APOSTROPHES, YOU MORONS!!!
Most people should wait a day or so to grab the latest kernel. As I'm finding (most of the US mirrors at least), 2.4.16 hasn't been mirrored to many of the mirrors yet :-)
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.)
Now ext3 is in the 'stable'-release, could someone please point me at a document describing
1) how to migrate the filesystems to ext3
2) what flags to set in lilo.conf so that I will be able to have the root-partition in ext3
3) tell what slackware boot-scripts I should change (and how)
4) what packages I should upgrade
I could find it out myself, but I'm convinced someone did all of that already
www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi
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."
Apple on the other hand released their partition destroying software and let it run rampant for weeks
[FUD ALERT]
... surely you mean less than 24 hours
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
Okay, isn't the convention supposed to be that even-numbered middle-dot releases (2.2, 2.4...) were supposed to be stable with the experimental stuff in odd-numbered (2.1, 2.3...)? While 2.4 in general has many nice things about it, the whole thing feels too much like a "2.3" series for my taste. This umount error is just one more example.
I note that 2.4.x broke my system badly -- it decided (as supplied with both Mandrake 8.1 and RedHat 7.2) that my ATAPI CD-RW was a DMA device, regardless of what I told the BIOS. With ide-scsi loaded over it, mounting caused kernel panic. An extremely helpful person on comp.os.linux.development.system helped me debug it with hdparm. But even building a custom 2.4.13 kernel didn't "solve" the problem (meaning that I have to leave hdparm in place and not use devfs). The kernel README is way, way out of date too. I'd expect this kind of stuff on an odd-numbered series. Perhaps even-numbered kernels need a bit more of a testing stage before release.
Wouldn't it be strange if 2.5 became the more stable one? At this rate, it could happen.
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)
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.
Alright. That's it!!! I'm sick of Apple's reckless behavior -- I finally have to agree that there's only one solution for all this!
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.
You know what? As Linus posted to LKML[1], it doesn't matter if there are a million pre releases, as long as it's a pre release, most people don't download it and run it on their hardware and workloads. Not to mention the fact that Linus doesn't like to maintain kernels and turns them over to other maintainers (Alan and Marcelo) for maintenance.
Hence, bugs don't turn up until after real releases are made.
Anyone who goes out and runs a shiny new kernel on a mission critical machine which was released 20 minutes ago is just asking for trouble. These kernels simply don't get the QA they need to be determined to be stable for a number of days after they're released.
If you want a QA tested kernel, go to RedHat, Suse or any of the other Linux distributions, shell out whatever they charge for bundling it up and use their kernel. When that kernel breaks, go whine to the distribution maintainers. (I've done this personally with RedHat, and found them to be very responsive to bug reports.)
Its either that, or fix it yourself, it's that simple. What, you want something for nothing? That's not how free software works.
Whining about the problem will not fix it. Going out and fixing it yourself, will.
1. See posts about Linus and maintaining stable kernels here and here.
init 1, sync then hit the reset button. Boot with your rescue floppy, (you have one right?) and force a fsck on your partitions. Note: The >/forcefsck will NOT work with reiserfsck. You must run reiserfsck manually.
Rich
ayottesoftware.com
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
Novices should be using a distribution. Those typically don't have a kernel-of-the-week phenomenon. A lot of people who are complaining about lack of QA, are bypassing QA.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
That's hardly the point. Anything to keep the blame off those we hold in high regard.
That even number in the middle is supposed to mean *stable*. Sure, there's always going to be a collection of minor bugs that'll get through just about any reasonable level of testing...but come on...this bug was simply huge. Even if you don't feel that it is necessarily the duty of kernel programmers to do extensive testing, I hope you do think they have enough ethics to do *some* testing before kicking a version out the door.
"That's Tron. He fights for the Users."
I know it's not the point, I was just commenting on it. I agree; it's terrible they would put out what is, in the eyes of most power-user types, a stable kernel with so little testing, and something should change in that respect. I was merely pointing out that while it's important, it's not going to have any effect on Linux's popularity as was implied, any more than IIS worms make desktop people switch from Windows.
If it ain't broke, you need more software.
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
(:
That doesn't explain 2.4.9 versus 2.4.10. I had such a bad experience with 2.4.10 that it scared me away from using the new VM until 2.4.15 (luckily I didn't upgrade to that either yet, but I will try 2.4.16 probably today).
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
You guys beta test and let me know, OK? :P
-Legion
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
no you dont have to. in fact I tell all my linux-newbie-converts. th NEVER EVER upgrade their kernel. even via the redhat up2date function unless I tell them to do so.
the only reason you need a bleeding edge kernel is for bleeding edge things like firewire.
right now witha redhat 7.1 it is prime for a linux-newbie to start playing and ditch windows. I dont reccomend redhat 7.2 due to problems with it. and hopefully I'll find a red-hat alternative to start giving away.
the Linux of today with the right distro is as easy as windows 2000/xp for the seasoned user.
anyone trying a simple 30 day no windows run will see this... (except for video editing people.... you're still stuck in the windows world due to the blinders worn by the management at AVID)
Do not look at laser with remaining good eye.
You can get the patch here.
-Fialar
Am I stupid? No. There is no better test of a kernel than a real situation. There never will be. Real Life will always throw up situations that can never be anticipated in the laboratory.
What else do I do? I compile patches. Pre-releases, new releases, ANY releases. I bundle them together, release them on Sourceforge, and watch the counters fly. You say that nobody would run a pre-release? 400-800 people regularly say otherwise, whenever I upload a new FOLK patch. That is as "pre-" as you can get, yet hundreds of people actually use it!
I have used Linux since 0.1, the BSD's since William Jolitz first ported the Berkeley tapes to the Intel, and I can tell you this from first-hand experience -- the BSD releases are damn-near rock solid, BECAUSE the people behind them insist on extensive pre-release cycles. HOWEVER, Linux overtook the BSDs within 2 years of coming out, because Linux development was open.
What I am asking for is to re-merge the two approaches. It's as simple as that. Re-merge? Yes! As I said in the letter, early Linux kernels went through tens, sometimes hundreds, of development itterations, before a release was made.
"Nobody uses pre-release versions"? Methinks you and he have forgotten that ftp.funet.fi was saturated, every pre-release that was made.
Sure, Linus can't QA a complete kernel. I wasn't asking him to. I don't even believe in the entire QA philosophy. Stoccastic testing is comparable to throwing darts in a map, in an effort to find gold. You =MIGHT= be lucky, but the odds are that you will miss the bloody obvious many times more.
To really test a kernel requires exhaustive testing of EVERY function call, under EVERY possible entry condition & state, OR a formal proof, neither of which is terribly practical, whether you're an individual or a distribution manufacturer. Red Hat may be rich, compared to Joe Average, but they still can't afford the 10,000 Ph.D mathematicians they'd need to check a kernel rigorously, in any realistic time-frame.
So, how do you achieve a decent quality? Easy! You run the program in much more compact cycles. By compacting the software life-cycle, and running many many more itterations, you can produce (in much less time, and for much less money) a quality comparable to having a few gigantic life-cycles of enormous cost.
Linus know this. He isn't an idiot. If he has to change the versioning, so that there isn't a "pre-" label, but rather a sub-sub version, to get people to run the kernel, then that's what he should do. There is NO excuse for umount() bugs in a 2.ANYTHING kernel. Development, pre, or otherwise. That kind of bug should not exist, even in the darkest imagination, beyond version 0.1
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)
Just take a look at the 2.4.16 changelog. There really weren't that many changes to the kernel, and this bug is a fairly troublesome one. I would only sit on 2.4.15 if I had a UPS and I touched the /forcefsck file in root (you should do that now, anyway).
There really is no reason NOT to install the new kernel. You probably haven't racked up much uptime anyway, and not that uptime on 2.4.15 is really worth bragging rights anyway.
Personally, I upgraded when 2.4.16-pre1 came out. I also converted many of my partitions to ext3 (finally). I've been waiting for ext3 to be merged in with stable for a very long time!
Another improvement that wasn't detailed because of the famous "...merge with Alan..." messages in the ChangeLog was that most of LVM is up to date in the stable kernel now. LVM has been at the 1.0.1rc4 release for some time now, and not having to patch my kernel is pretty nice (although, the LVM crew made creating patches quite simple). If you haven't checked out LVM yet, do so. It's quite sweet!
assert(expired(knowledge));
Not sure what it would do to a journaled ext3 fs. I was planning on moving on small partition over to ext3fs with 2.4.15, but I may wait till 2.4.16 or later to make sure that all is aoky.
Only 'flamers' flame!
Now, I've got Red Hat 7.2 on my machine, running the 2.4.7-10 kernel that came with the distro. All my partitions are ext3, and that's why I need a pretty recent kernel. Since ext3 was accepted by Linus in his tree, I figured I should upgrade, and indeed, I rushed to upgrade to 2.5.0 (cool, eh!) the minute it was released. Well, I got my file systems down apparently undamaged.
So, when you're saying
I'm happy for any advice I can get! :-)
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Leave RedHat out of that list...I've seen plenty of botched RedHat upgrades, and let's not forget that little problem they seem to have of requiring 2 iterations past each major version before they get it decently solid.
Maybe this is a level of abstraction that *should* be removed?
"That's Tron. He fights for the Users."
It will have a big effect on Linux's popularity.
IIS worms do not affect most Windows users directly.
The Kernel corrupting a volume while it gets unmounted affects every user using that kernel.
Linux is already considered a joke in many IT departments. These high-profile Linux bugs only make the joke funnier.
Conformity is the jailer of freedom and enemy of growth. -JFK
And neither do kernel bugs that never get to most Linux users. That was the point.
Oh, you're a troll. Never mind then.
If it ain't broke, you need more software.
It's typical for a slashbot loser to call anyone who thinks for themselves a troll. You are reminiscent of a fourth grader in the schoolyard.
The bug never got to most Linux users because the bug was so trivial it was discovered almost instantly.
Since the kernel coders apparently do no testing beyond trying to make everything compile, there are plenty of other, more subtle bugs waiting.
Large IT departments see Linux as a joke. As the price barriers to purchase commercial Unix systems drop, the incentive to use Linux drops with it. In smaller shops, there is more incentive to use Linux since they are more price-sensitive.
Conformity is the jailer of freedom and enemy of growth. -JFK
It's typical for trolls to think that just because they blindly follow a different groupthink, they "think for themselves."
If it ain't broke, you need more software.
http://saveie6.com/
so far it is better than 2.4.11 to 2.4.15. It has ext3fs support as well. Although I have not tested that yet. There are some bugs but only in the buggy hardware that I have.
Only 'flamers' flame!
Going back to FreeBSD...on my home machine, a machine that I used to run Linux for weeks (even months) on end on, I put FreeBSD stable on the machine...and had the machine freeze 3-4 times a day. That was this year. I put Slack on the box and haven't looked back since.
Stating on Slashdot that I like cheese since 1997.