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!"
...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?
I recomment turning your computer off with the power switch or by unplugging it, after you've made sure you can boot an older kernel. Since umounting is done when you shut down cleanly, you don't want to do that.
They that quote Benjamin Franklin on liberty and safety deserve neither.
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...
Also, straight out of alans diary:
:)
September 29th - Much kernel patching going on. The -ac kernel tree seems to be turning into the stable tree as Linus merges odder, weirder and more alarming things. I just hope he knows what he is doing.
---
Sounds like confidence to me
You can find Andrea Arcangeli's fix at:n drea/kernels/v2.4/2.4.15aa1/00_iput-unmount-corrup tion-fix-1
ftp://ftp.us.kernel.org/pub/linux/kernel/people/a
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.
I hope /. dosent mangle this up too bad, but if it does:
0 658174003122&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=10
List: linux-kernel
Subject: Re: 2.4.15-pre9 breakage (inode.c)
From: Linus Torvalds
Date: 2001-11-24 5:55:42
[Download message RAW]
On Sat, 24 Nov 2001, Andrea Arcangeli wrote:
>
> --- 2.4.15pre9aa1/fs/inode.c.~1~ Thu Nov 22 20:48:23 2001
> +++ 2.4.15pre9aa1/fs/inode.c Sat Nov 24 06:30:20 2001
> @@ -1071,7 +1071,7 @@
> if (inode->i_state != I_CLEAR)
> BUG();
> } else {
> - if (!list_empty(&inode->i_hash) && sb && sb->s_root) {
> + if (!list_empty(&inode->i_hash)) {
> if (!(inode->i_state & (I_DIRTY|I_LOCK))) {
> list_del(&inode->i_list);
> list_add(&inode->i_list, &inode_unused);
I have to say that I like this patch better myself - the added tests are
not sensible, and just removing them seems to be the right thing.
Linus
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?
yes this is quite a serious bug, but 2 things set this apart from MS. It will be fixed within 24-48 hours. The frequency of these bugs are a bit smaller than MS's bug of the day (which very often are large holes).
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
(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.
Can someone give a joe-user guide to helping test new kernels?
The last post in that thread is this one by Andrea Arcangeli sometime this morning and from the looks of things (if you read the entire thread) there is conflict between Alexander Viro and Andrea on which is the better solution.
Linus saying he prefers a patch on an initial viewing isn't the end of the situation for now. I'd suggesting waiting a week and revisiting the thread to find out what the final word was.
... 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.
The mailing list converted tabs into spaces, causing patch to choke. Get the patch here.
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.
> So who else is downloading 2.5 (Score:5, Funny)
> by Chuck Chunder on Friday November 23, @02:23AM
>
> so they can be cool and trendy and be on the development tree while it's still stable?
>
> The Great Chunder Page - Alcohol Induced Fun!
If you didn't think it was funny before, admit it -- it's pretty damn funny now.
Maybe, just maybe, that's because the iTunes player was an end-user product, and the kernel source is intended for adventerous users, developers, and distributions. If the default RedHat kernel of a stable RedHat release had a FileSystem corruption error, that would be something to write home about - this isn't.
------ 24.5% slashdot pure
Is there any project to create a set of regression tests for the Linux kernel? This is not the first serious bug that would have been found with even the most basic set of regression tests.
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.
First: This linux bug does not the loss of the ENTIRE FILE SYSTEM. It leaves .lock files with invalid INODES which can be repaired by manully running fsck. As to you're challenge, these are just a few corruption problems with windows 2000 that I found doing a simple search on www.microsoft.com.
s /Q 268/8/97.ASP
s /Q 258/0/75.ASP
s /Q 273/2/45.ASP
s /Q 298/9/36.ASP?LN=EN-US&SD=gn&FR=0&qry=file%20system %20corruption&rnk=16&src=DHCS_MSPSS_gn_SRCH&SPR=WI N2000
s /Q 261/1/22.ASP?LN=EN-US&SD=gn&FR=0&qry=file%20system %20corruption&rnk=19&src=DHCS_MSPSS_gn_SRCH&SPR=WI N2000
s /Q 255/5/69.ASP?LN=EN-US&SD=gn&FR=0&qry=file%20system %20corruption&rnk=23&src=DHCS_MSPSS_gn_SRCH&SPR=WI N2000
http://support.microsoft.com/support/kb/article
http://support.microsoft.com/support/kb/article
http://support.microsoft.com/support/kb/article
http://support.microsoft.com/support/kb/article
http://support.microsoft.com/support/kb/article
http://support.microsoft.com/support/kb/article
-- You can be a geeklord too
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