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!"
Re:Alan Cox (Score:4, Interesting)
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
Re:Filesystems (Score:5, Interesting)
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.
FS corruption? (Score:2, Interesting)
PS> Don't flame me please. I just wiped Win2K off my harddrive this morning. Luckily, I downloaded the 2.4.15 tree but have been too lazy to compile it yet.
Re:quality assurance (Score:0, Interesting)
Re:Really... (Score:2, Interesting)
The "stable" tree (which has an even minor version number), and the "development" tree (which has an odd minor).
When kernel 2.2n.0 (n being a non-negative integer, in this case, 2) is released, development stops on 2.2n-1.x, and all newly-submitted-and-approved-by-Linus patches are applied to the 2.2n.x tree (because 2.2n-1.x is out of date). While 2.2n.x is still called the stable tree, it becomes the development tree (because some of the newly-patched stuff is untested, and there's no "development" tree to put it in). The "stable" role falls back to 2.2(n-1).0, in this case, the 2.2.x tree.
As far as this goes, it was a stroke of bad luck and hurried timing that this bug wasn't ironed out in 2.4.15-pre9 before it went final (and somewhat of a stroke of stupidity on the parts of the early adopters, myself included).
When 2.2n+1.0 is released, 2.2n continues development, making it the stable tree. Any fixes to bugs found in the 2.2n+1.x tree are back-merged to the current stable tree so that end-users can enjoy a stable, debugged kernel without riding the bleeding edge.
The problem with the Linux kernel numbering system is that the "stable" tree is only stable when there's a "development" tree to test the uncharted waters for it... if there isn't one, it's best to stay back a few revisions unless you like running fsck.
Re:Don't throw stones in Glass Houses (Score:3, Interesting)
Re:A Workaround (Score:3, Interesting)
Comment removed (Score:2, Interesting)
grre (Score:1, Interesting)
And would it kill them to use a versioning system ??? - CVS is great, but there's other options, too...
This sort of thing is NOT good, in a supposedly "stable" tree, and gives MS, BSD, and proprietary Unix folk lots of Ammo against Linux.
To be fair, people adminning production boxes should be using the kernels from their Distro's site, since, really, it's the distro that is the OS, and RH, SuSe, and Mandrake all heavily regression-test and fine tune their kernel, it's not necessary to be on the bleeding-edge.
Re:Does anyone know... (Score:2, Interesting)
Why the rush between the pre9 and final versions? Why the lack of QA? Are the kernel developers rushing to meet a deadline or something?
Alot of people complain that Open Source projects develop too slowly, and cite the slow pace of Mozilla and Gnome as an example.
Pro-OSS folks say "That's a BENEFIT to the OSS model, we don't rush things through the door before they are ready, therefore there are less bugs in our released products.
But here we are, with a product that was rush, and that was released with a serious bug.
Re:quality assurance (Score:2, Interesting)
message but it's too late now.
I would point out that this bug does not turn up readily.
This bug allows a system to boot up normally, run fine, and then when you
reboot (and only when you reboot) some files are missing if (and only
if) their buffers were dirty when you rebooted.
This is NOT easy to catch. The average Linux system has upwards of 50,000
files. A few disappearing is not easy to notice. In addition, buffers
tend to get flushed pretty well during the shutdown process, so it
wouldn't show up too often either (I avoided on accident it due to a
peculiar RAID shutdown script I have that sync's and sleep's for a bit).
For the M$ zealots out there be careful to practice what you preach. One
of the core arguements of the Slaves of the Empire is that the Linux
zealots bash M$ but can't take criticism themselves. If you'll check your
precious windowsupdate.microsoft.com on a fresh Win98 install, you'll find
the IDE Hard Drive Cache Update. For the uninitiated, this patch fixes a
problem where Windows doesn't write all of the data to disk on
shutdown. Ironically, this tended to completely hose Win98 systems
beyond fixing by Scandisk (usually registry damage).
So, Win98 and Linux have similar problems. In a week, the Linux bug will
be history, but the M$ one is still being minted on CD and requires an
Internet download (because it's a "minor problem", the fix is to "wait
before shut down so the data is written"). I don't remember too much
babbling on Slashdot about that bug and it's been there for YEARS.
Gosh, I guess I should write this off as being dribble by "Linux
Bashers".
Oh, and to completely trash my karma, I've had disk corruption in a stable
FreeBSD due to a bug in FreeBSD code, so don't get too high on your own
superiority yet. You've got older code--sometimes it's a strength,
sometimes it's a weakness. Like the FreeBSD development process isn't
ever rocky.
Re:Please spare us (Score:2, Interesting)
Windows 2000
Take this post as a challenge. Reply with a link that shows that there is/was a bug in Windows 2000 that caused the loss of a ENTIRE FILE SYSTEM ala Linux or Apples iTunes.