Slashdot Mirror
Serious Bug In 2.4.15/2.5.0
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!"
When are we going to start giving kernels to a QA team before releasing them?
I am not a lawyer. Do not take my words as legal advice. If you need legal advice, consult an attorney.
...how something like this could have creeped in, and be missed? Was it a last-minute change that just didn't have time for testing, or was it (bad)luck-of-the-draw that no one noticed it?
The users are the QA (why do you think Linus moved to 2.4 so early? To get more testers). If you don't like being a guinea pig, then wait about a week before moving to the newest kernel. Seriously, 7 days isn't that long, and all show-stoppers will have shown up long before then.
Isn't the 2.4 branch supposed to be stable? You know, the one that doesn't eat your disk. I think that this kernel should have gotten a little more testing for bugs of the catastrophic nature before it was deemed fit for general consumption.
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.
Not going to flame you, just trying to amuse.
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)
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
Thats funny. I have been running Debian (stable) for a long time now, and I haven't had any filesystem corruption. In fact, I haven't had the OS crash either.
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.
that a successful reboot of the system running the kernel is not in the regression suite. Does this error occur on every architecture?
Come on guys, nobody is going to take linux seriously as long as problems like this -- or the VM saga -- keep popping up in supposedly stable kernels. FreeBSD has no trouble keeping separate -CURRENT and -STABLE trees; why can't linux do the same?
Tarsnap: Online backups for the truly paranoid
In your face! I sat here and read all the flames to apple about the iTunes screw up, and here we are with one just as big and glaring from the kernel developers themselves.
Hypocrites!!!!!!!
Can someone give a joe-user guide to helping test new kernels?
... is why there seems to exist this rampant tendency among Linux-folk to upgrade one's kernel constantly. Unless a new kernel solves a problem you have, there is no reason to upgrade.
If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
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.
------ 24.5% slashdot pure
If only this was Open Source Software, the source code could have been examined by thousands of highly motivated and intelligent hackers, who would have noticed the problem immediately. Wait....
Vintage computer games and RPG books available. Email me if you're interested.
It amazes me how big of a deal people make these types of issues out to be. I have heard of high standards but SH*T!. The more I read slashdot the more I realize that very few posters here actully work with much commerical grade software. These type of issues occure freqently with every software vendor I deal with professionally: Cisco, Microsoft, IBM, RedHat, Checkpoint ect.. ect.. The difference is when Cisco releases a new IOS image (which they do about twice as freqently as Linus does) They will quitely mark saym a 1/4th of them DF which stands for _DEFFERED_ i.e. SERIOUS BUG DON'T USE once it is discovered.
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).
-- You can be a geeklord too
I've seen lots of posts about 'We need to QA this!'
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.
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.
<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
Brian Voils
"A university is what a college becomes when the faculty loses interest in students."
MS has 36 billion bucks. Linux is a volunteer effort.
Why is is that they are even in competition, again? Why is it MS can't buy some fucking good PROGRAMMING???
People downloading kernels from kernel.org, particularly in the first few days of a release, are part of the QA process, not the ultimate beneficiaries of one.
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.
Boffoonery - downloadable Comedy Benefit for Bletchley Park