Serious Bug In 2.4.15/2.5.0 498
John Ineson writes: "There is a bug in the latest kernel releases, that causes fs corruption on umount. A lot of people have already been hit by this, so for now I suggest you hold fire on booting those new kernels. More dead-duck than greased-turkey. Two possible fixes are being discussed on linux-kernel."
Colin Bayer adds links to a story at the Register and Al Viro's fix. Update: 11/25 00:39 GMT by T : Tarkie writes "Linux 2.4.16-pre1 is out, as detailed at NewsForge. If you've been having the filesystem corruptions, might be worth a try so that 2.4.16 can be out ASAP!"
quality assurance (Score:1, Insightful)
Does anyone know... (Score:4, Insightful)
"QA" (Score:2, Insightful)
Really... (Score:2, Insightful)
Don't throw stones in Glass Houses (Score:1, Insightful)
Yet there's no snide commentary from the editors whenever something like this happens with Microsoft (M$ to all the haters) software.
Maybe you zealots will realize that nobody is perfect, and open-source is not necessarily better than closed-source.
This also makes a case for not announcing new kernels not slashdot (aka not freshmeat). Most people here are linux newbie wannabees so they're not the most qualified people to be running the latest and greatest kernels.
Re:FS corruption? (Score:2, Insightful)
I thought the reason for installing *nix's was so you'd never have to shut down? Therefore this should not be a problem.
Now does this occur during *any* unmounting operation? Manually vs Shutdown?
Oh, and be-fan, don't install XP and use Ext3 (hey, that rhymes) because if XP uses your Ext3 as swap space and 2.4.15 corrupts itself...woah, double whammy.
Hey, any chance of getting iTunes 2.0 on Linux and Windows? Wanna play Russian Roulette...with an Uzi?
Whip me, beat me, make me write bad checks (or install windows...same same)
Re:FS corruption? (Score:5, Insightful)
Its better to compare Windows 2000 to another complete operating system, NOT a bleeding edge kernel. Compare Windows 2000 to Debian (stable), and Windows 2000 will look like a house of cards.
Strange (Score:5, Insightful)
This is why I use FreeBSD (Score:4, Insightful)
Ok so Apple isn't the only one to screw up (Score:1, Insightful)
Hypocrites!!!!!!!
Re:Really... (Score:5, Insightful)
You are wielding a Rant Stick (1d2) (+0,+0) (*slay* kernel developer)(a).
It's not so much that it wasn't stable enough when it was released, but rather that they keep messing with 2.4 instead of making a 2.5. I think maybe Linus had this idea (at the end of 2.3) that the developers could focus on fixing bugs and make 2.4 really great. Unfortunately, they're volunteer developers, so they're working on things that excite them, which means insane stuff like VM rewrites and other "hey, let's try this" changes.
This is why I still use 2.2 and will until there has been a 2.5 for a while (so the developers have a place to try their unstable new ideas) and 2.4 has gone into "bug-fix" mode (like 2.2 is now). It's really annoying, because I want some of the new features of 2.4 (the ones introduced back in 2.3), but can't afford to have the thing crashing on me, and don't want to spend a long time looking for a stable 2.4.X.
Maybe next time, Linus won't wait so long to introduce a development version, or will at least refuse anything but bugfixes in so-called "stable" branches. Still, despite my complaining, I am happy that people have gone through all the trouble to write the Linux kernel, and will try to remember that.
How can this be avoided in the future? (Score:3, Insightful)
What I don't get ... (Score:3, Insightful)
Things are working right not wrong: (Score:5, Insightful)
This is one reason why distributions are so important. They do the QA, they make sure packages are stable, they apply the patches. If you want to download and run the latest edition of every package out, including the kernel, then you should expect some bumps in the road, because you are beta testing - even on a "stable" kernel series. Remember: release early, release often. You will have to do the QA, you will have to apply the patches, you will be burned. Some people like doing this to stay on the bleeding edge, others are a bit more cautious.
If you want stable, solid kernels, that are heavily QA'd wait for packages to come out. Otherwise, post a bug report, and quit whining.
See? (Score:4, Insightful)
Re:quality assurance (Score:2, Insightful)
I have a response to those who have said that the open source QA process is to release early and let early adopters suffer the consequences. Are you sure? Are you saying this is good example of open source development? Are you saying this is the exemplar of the open source development process? This is a data loss bug.
In the open source development process, it's not a problem if the new release of Mozilla has a small problem with frames in XHTML, or if the new Linux kernel breaks support for USB joysticks. These are problems that can be fixed.
Some bugs are so serious, however, that they deserve extra attention. These are the "showstoppers." In every kernel release, Linux says something about not finding any showstoppers. That is, there are no data loss bugs or other serious bugs that he knows of. He wouldn't release it if he thought it had such a serious problem.
All I am saying is have a process that can perform rudimentary checks on the kernel to pick up any showstoppers. This process would take a few hours or at most a day. It would prevent situations like this, where the Linux community opens itself up for attack by all the brainwashed Microsoft zealots. Is this really flamebait?
Re:Things are working right not wrong: (Score:4, Insightful)
Actually, I do "roll-my-own" and maintain a Linux distribution.I was not burned by this, because like other people "rolling their own/maintaining a distro" I do keep track of LKM posts.
Anyone else doing this type of work, will hopefully learn from this - and NOT install the latest kernel the day after it's out. This type of thing has happened in EVERY series of stable kernels I can remember. And it will happen again.
Big deal. (Score:5, Insightful)
This is why production implentations of software go through testing before deployment when at all possible. If you are running Cisco IOS that is say less then a month old you are taking a risk that there will be a serious bug that will hurt you. The same holds true for Linux kernels or any other peice of software. The more complicated the software the harder it is to keep serious bugs from slipping through the cracks, It is _AMAZING_ that Linux has a few major issues as it does.
Here is an exercise for you all: Go to www.microsoft.com go to their support section and read through all of the changelogs (they are hard to find) for all of the hot fixes, service packs and general software updates and you will see what I mean (And yes you will find file system corruption there too).
QA/Release cycles/et al (Score:2, Insightful)
and 'Are there any projects to try and QA the kernel releases?' Both of these miss the point. While we do need more people running the tests which do exist on the -pre releases, it comes down to Linus having an itchy trigger finger, so to speak. 2.4.15 in it's final form did exist for a little while, but it wasn't long enough for anyone to go and give it a good test. There's often been requests for Linus to wait a few days from the last -pre to -final so other arches and sync up (2.4.15 only compiles on x86/sparc64/arm and alpha). If this was released on monday, none of this would happen.
That is a cop-out (Score:5, Insightful)
The real problem is that new functionality is being added to the stable branch.
The solution to this type of problem is simple, when a stable kernel is released, an unstable branch should be created immedately. New functionality was being added to the 2.4 branch by developers simply because there is nowhere else to put it.
New functionality should never be added to a stable branch in a piece of software as mission-critical as a kernel, that is what the unstable/development branch is for.
If the kernel maintainers want to accelorate the pace at which new functionality gets into a stable branch then they should increase the frequency with which development branches become stable.
Re:Big deal. (Score:3, Insightful)
Now you can sit there and say "If Linus would of waited _blank_ period of time someone would of caught the problem before the release and this wouldn't of happend. You could also says that if Linus would just release -pre kernels and only release -stable kernels once a year we would have a REALLY stable kernel... the problem is thats not how the release early/release often model of development works. If you want that model use Microsoft we all know how stable their software is.
If you want serious QA use redhat.. they do serious QA.. If you are running 0day software you get burned.. wether its the latest linux kernel, the latest microsoft service pack or the latest Cisco IOS.
Question: what is your example of software that is released "AFTER it's been tested". I can't wait to go read through the change logs and find some bugs that should of been caught by this software superior QA.
2.4 seems to have had some serious problems (Score:2, Insightful)
<pseudo-rant>
maybe there's a good side to your ISP going out of business and qwest dsl fscking you over changing your isp, making it harder to update your kernel 8)
</pseudo-rant>
but ultimately, i can't see its all that big of a deal. all you have to do is take a couple of weeks to get to the newest kernel. wait till its been out a fortnight, and you're golden
Re:Does anyone know... (Score:2, Insightful)
On the contrary... Pro-OSS folks who know what they're talking about will say that one of the benefits of the OSS model is "release early, release often". They'd also point out that while really show stopping bugs will make their way in to a stable release (of whatever project we're talking about), just as they'll make their way into the stable releases of closed-source projects, with OSS software you're not forced to wait till some company finally decides to admit there's a problem and release a patch.
Anyone who says that all releases of OSS software are inherently more stable and secure than closed source software is a moron. And anyone who says that all releases of closed source software are inherently more stable and secure than OSS software is also a moron.
Dinivin
why can't MS buy some quality?? (Score:1, Insightful)
Why is is that they are even in competition, again? Why is it MS can't buy some fucking good PROGRAMMING???
I think you missed his point a bit. (Score:4, Insightful)
The Open Source (or more correctly, bazaar or distributed) development model also distributes responsibility. If the possibility of losing your data is something you can't afford then you simply shouldn't be sitting on the cutting edge of kernel development.