Slashdot Mirror
Linux 2.4.16 Released
tekniklr writes: "They just released Kernel 2.4.16. Download it
here, and you can read the changelog here. This hopefully fixes the error that 2.4.15 had of corrupting filesystems on unmount." Update: 11/26 14:14 GMT by T : p.s. Don't forget to look in the mirrors.
Current bandwidth utilization 96.75 Mbit/s
.tar.gz from the slashdot homepage was not a good idea, timothy.
Out of 100mbps..
Linking directly to the
You should have pointed to the mirrors, instead:
Alexis 'jeriqo' BRET
I for one am not touching a new Linux kernel until other people have risked their systems with it and verified that it works fine. I will possibly stick with using an OS with proper quality control procedures (name your own out of FreeBSD, OpenBSD, NetBSD, Windows, etc...)
For those interested, the preemptable patch against 2.4.16-pre1 also applies cleanly to 2.4.16 final.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Which Apple partition destroying software would that be? I must have missed that one. I am only aware of two.
The iTunes partition destroyer was pulled in something like 24 hours and replaced not long after.
Some years ago there was a problem with certain models of hard drives (Quantums I believe) that didn't handle their write caches well on a scsi reset. That went on for quite a while, but was not an issue with supported Apple hardware, it was some 3rd party drives that had tweaks to enable write behind caching. (The very large Oracle installation on Alphas that I work with had the same problem with them. Unable to resolve it with the vendors we finally scrapped all the disks and replaced them with a different vendor's drives.)
...but it couldn't unmount filesystems without destroying them...
Ok, that's just plain false. The worst that could happen is you get a few stale lock files left over (sometimes a bunch) that are undeleteable, and can only be erased with a fsck. Not a huge deal. The problem is that when you unmounted a filesystem, if there was data that still needed to be synced, it could get garbled. No big deal. Do an fsck, and everything is restored. No offense, but did you even bother to read about the bug?
Ok your problem is easy. That happens with the _new_ VM introduced in 2.4.10, with the _old_ ext3 patch. So I am assuming you used 2.4.10 - 2.4.14, and you applied the ext3 patch. This is a harmless reporting bug. When the ext3 patch was merged into mainstream it was fixed. Use 2.4.16, it's probably the most stable 2.4 release ever[1] (except for /possibly/ a redhat kernel).
[1] 2.4.15 would have been the most stable/robust kernel execpt for that inode bug. Looking at the changelog for 2.4.16 one can see that the only real change was the inode bug, and one can make a safe prediction that 2.4.16 will turn out to be the most stable kernel in 2.4 series so far.
First of all, unless you've got some very specific requirements only satisfied by a 2.4 series kernel, if you're worried about stability then you should be running a 2.2 series kernel.
That said, if you must track 2.4, then you're best off tracking the changelogs and only upgrading when you see a fix for a problem likely to affect you. If the problem is minor, consider giving the new version a little time. There are enough version whores and neozealots out there that other people with gladly rush out and do the mine stomping for you.
Apple on the other hand released their partition destroying software and let it run rampant for weeks
[FUD ALERT]
... surely you mean less than 24 hours
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
Very simple: /dev/hdaX".
Compile ext3 into your kernel (make sure it's not a module, if you want to use it for your root file system).
Do a "tune2fs -j
Reboot.
That's it.
The help for the kernel option tells you which version of the ext2progrs you'll need (at least 1.20 ?).
You need to get the latest e2fsprogs (1.22) and the latest util-linux (2.11). Don't install the
/dev/hdwhatever". Done! A journal will be created automatically. Remember to only run this on a clean ext2 partition (make sure you're not running 2.4.15! :) ). If you're going to convert over the boot volume, make sure ext3 is built into the kernel and not a module. You shouldn't have to set any particular LILO flags (I didn't & I'm typing this
/etc/fstab to show the new filesystem type.
login utils if you're installing from a source tarball instead of an rpm.
When done, type "tune2fs -j
on ext3/2.4.16pre1). Update your
Not sure about the Slackware stuff, but I doubt if there are any config file changes.
Andrew Morton's EXT3 page has all the details.
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
Use the kernels from one of the vendors.. e.g.
Redhat.
If you'd seen the bugs found in aix and solaris
stable kernels, you'd probably get the hell
out of there...
And this is why the 2.4 kernel has had such a rough time. Please see the post on the linux kernel mailing list that has message id Pine.LNX.4.33.0111251946400.9764-100000@penguin.tr ansmeta.com
In it, Linus clearly states what the problem is with any major release... The people you really want to test it won't test it when its development.
The number of people testing a development release is sadly too small to catch some of the problems. The same is true in a lesser degree to -pre releases in regards to the final releases.
At any rate, if you really want to help, setup a test box and test the development releases and provide useful feedback, then the time to a really stable release will decrease.
init 1, sync then hit the reset button. Boot with your rescue floppy, (you have one right?) and force a fsck on your partitions. Note: The >/forcefsck will NOT work with reiserfsck. You must run reiserfsck manually.
Rich
ayottesoftware.com
From my understanding the bug affects all filesystem types.
/)
I patched my kernel to 2.4.16-pre1 yesterday in light of this bug, and here's what I did:
1) Compile kernel using my normal procedure
2) Switch to single user mode ('init 1')
3) 'sync' and 'umount' each partition (except
4) sync
5) shutdown -r -F now
No corruption, no problems (I'm on ext3 so the forced check wasn't even noticable).
You might be tempted to remount / read-only first, but if you do, first create '/forcefsck', which is exactly what the -F flag on 'shutdown' would do, but of course only if / was writable.
NGWave - Fast Sound Editor for Windows
0) Make sure you have compiled and installed a patched kernel.
/dev/partiton
1) "shutdown now" or "init 1" as root to go single-user.
2) sync
3) umount all non-busy filesystems (usually only root is busy for most people).
4) sync
5) mount -n -o remount,ro /
(so now the root filesystem is read-only -- this step *is* important).
6) e2fsck -f
(once for each partition, starting with root [/] device, substitute e2fsck with reiserfsck, etc., as necessary -- force a check on each filesystem)
7) sync, hit reset
8) make sure not to ever boot into the buggy kernel again!
STOP . AMERICA . NOW
You can get the patch here.
-Fialar