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.

Comments

Linking

[jeriqo]

Current bandwidth utilization 96.75 Mbit/s

Out of 100mbps..

Linking directly to the .tar.gz from the slashdot homepage was not a good idea, timothy.

You should have pointed to the mirrors, instead:

preemptable patch

[MartinG]

For those interested, the preemptable patch against 2.4.16-pre1 also applies cleanly to 2.4.16 final.

Re:Better than Apple ... ???

[victim]

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.)

Re:4Tb of cache fixed?

[barneyfoo]

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.

Re:What's the best kernel?

[Snowfox]

I've been following all the kernel releses, and their bugs. I was just curious, what is the best way to tell which kernel is currently the most stable, without jumping immediately to the latest release? Obviously there is no way of knowing if it is, without it being out there for at least a couple of weeks.

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.

Re:how to implement ext3

[willamowius]

Very simple:
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 /dev/hdaX".
Reboot.

That's it.
The help for the kernel option tells you which version of the ext2progrs you'll need (at least 1.20 ?).

Re:how to implement ext3

[Draoi]

You need to get the latest e2fsprogs (1.22) and the latest util-linux (2.11). Don't install the
login utils if you're installing from a source tarball instead of an rpm.

When done, type "tune2fs -j /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
on ext3/2.4.16pre1). Update your /etc/fstab to show the new filesystem type.

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.

2.4.16 and ALSA

[pwagland]

Well, this was posted for 2.4.15, but it is also relevant for 2.4.16:

While we are talking about incompatible kernel patches, please be aware that ALSA 0.5.12 does not work under 2.4.15. You need to get the CVS version, as described here . ALSA 0.5.12 compiles, but does not work.

Re:So, what's the best way to upgrade?

[sfe_software]

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.

9 paranoia-steps for upgrading out of the bug.

[aussersterne]

0) Make sure you have compiled and installed a patched kernel.

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 /dev/partiton
(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!