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!"
You're correct, it is regardless of filesystem. If you happen to be running 2.4.15 or 2.5.0, just remember to force a fsck for the next reboot (shutdown -F) that's the only way to clear the fs because it will be marked clean even if it's not). Right now, the developpers don't know how reseirfs would deal with this bug...
It afflicts every filesystem. However, rebooting with the file /forcefsck extant forces it to run an fsck (and fix the corruption) on boot.
Also of help might be the Alt+SysRq keys; if you sync the drives and unmount them in single user mode before reboot, you should reduce or eliminate the corruption.
Want Linux games? HERE.
This bug was introduced when the kernel coders were trying to fix a bug that existed earlier (but, AFAIK, didn't cause fs corruption). It was introduced in pre9, but the final kernel was released within a few hours, so I guess nobody caught it in time.
Want Linux games? HERE.
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?
(Inven: r-r, * to see, ESC) Wear/Wield which item? r
:)
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.
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
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
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.