Slashdot Mirror
Linux 2.6.0-test9 Released
keesh writes "Linux kernel 2.6.0-test9 is now out. Changes include SATA support and XFS and CIFS fixes. Because of the change freeze, this is a fairly minor update. In the announcement, Linus suggests that -test10 will be the final release before 2.6.0-final. Don't forget to use a mirror."
Although mirrors will probably be faster, if anyone wants the torrent, I set one up:
r ent
http://69.56.172.70/linux-2.6.0-test9.tar.bz2.tor
SATA = Serial ATA, a replacement for the old Parallel ATA.
XFS = SGI's high-performance filesystem.
CIFS = Common Internet File System, otherwise known as SMB. The Microsoft networked filesystem emulated by Samba. A misnomer in that it isn't generally used over the Internet (except for worms, ha ha).
RedHat 10 (aka Fedora Linux, has a 2.6 kernel on their roadmap. Essentially they say that if 2.6 is officially released before they officially release RH10, and the switch will not cause delays, then they will ship 10 with 2.6, otherwise they will ship an updated version ASAP after the release of 2.6.
It doesn't build for the x86-64 platform, and doesn't boot on "white box" Alphas (ones only intended to run NT). So my 64-bit machines are feeling a bit left out.
At least patches for both problems are available, but need to be merged.
As a fairly new GNU/Linux user myself, I've found compiling and running new kernels to be quite easy. I should mention, though, that my early efforts failed completely. This was when I was running Red Hat 9. I guess RH needs something special; at any rate I never got 2.6.0-testX to run on it. I am now using Gentoo, and everything seems to be working extremely well, and I'm currently running test8-mm1. I recommend you read this tutorial written for the 2.6 kernel: http://kerneltrap.org/node/view/799. Good luck. :)
-M
Can I put a 2.6 kernel in a 2.4 distro?
Should not be a problem. I have a debian/testing installation with a self-compiled stock 2.6.0-test1 from www.kernel.org. It has been running crash free since end of July now.
For a complete list of minimal requirements, look into the Documentation/Changes file in the kernel sources. At least 2.6.0-test1 has no extreme requirements, as far as I can tell.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
I downloaded and was compiling the sources when the story broke on Slashdot.
When Pat said that Slackware 9.1 was 2.6 ready, he wasn't kidding. So far, so good. Not a glitch during the compile or boot-up. I plan to stress test it as much as possible to see if I can tell the difference between 2.4.22.
I can't wait until Linux 2.6 final is out.
Alsa sound drivers are built right in. So now I don't need to copile them separately. The oss support for my sound card was very half ass, it didn't even support full duplex and hardware mixing.
Also, i2c and the lm sensors interface is built right in as well. So now I don't have to compile i2c and lm sensors to know how hot my mobo and cpu are running. They have saved my computer at least once. My cpu fan died on me, I wouldn't have known if I didn't have it graphed.
Also there's pre-emptible kernel option. It makes X more responsive, especially noticeable under heavy load and on slower computers. Supposedly better memory management as well, but as I have 768 megs of ram, I probably won't ever notice that.
There's also USB 2.0 support, and support for USB type removeable drivers. I think both of those are new.
There's probalby more, but those are the ones I know off hand.
Just to clear up a little thing about Debian, yea, stable is some pretty old packages/versions, but it is very well tested, and rock solid.
Debian unstable, however, is fairly close to bleeding edge... I mean, Mozilla 1.5 hit a day or two after it was released, Gnome 2.4 took oh, probably a few weeks... And really, the packages are quite stable, sometimes the upgrading/installing of them isn't, however. (but that's what happens when you're using bleeding edge stuff)
And, if you don't want to deal with uninstallable packages occasionally(haven't seen that in months) or your compiler being upgraded at weird times, testing is right between the two.
If I was that drunk, I would have remembered it -- H. Simpson
The most "extreme" change is the modutils to module-init-tools. But the module-init-tools provide wrapper support and call the old modutils when booting back to a 2.4 kernel.
Things to watch:
/etc/modules.conf file will likely need to be updated because of differences in the module names.
/dev layout may look different, possibly breaking some scripts.
/proc may not be the same, so things that rely on cat'ing files in /proc might break. For these use applications like lspci instead of reading proc directly.
Build your root fs models statically into the kernel.
Your
Some init scripts will need to be modified.
None of these are fatal errors but will cause some failure messages as the system comes up. This can be a little disconcerting but shouldn't do any harm.
If you're running things like NVidia binary drives, VMWare, or any applications that build kernel modules specific to the running kernel you will need to rebuild those hooks.
Some USB devices may magically start working!
Your
Some parts of
Um, I think you misread that. The Fedora Core 1 that is coming out in a couple weeks has no plans whatsoever for supporting kernel 2.6. The following Fedora Core (what you would call RH11) will come with kernel 2.6 if it's ready. If it seem stable enough, they'll hurry up and get the new release out there, but if not, they won't delay the release just to get the new kernel in.
No matter what, they won't be shipping a kernel unless they've been able to test it thoroughly. And it'll probably take several kernel releases before it's ready to be shipped with a distro.
Looking for a computer support specialist for your small business? Check out
Does anyone know if the conflicts between ACPI and USB have been fixed yet? Basically, if ACPI is enabled in the kernel, it will mess with USB--for instance, my USB mouse will suddenly stop working (no errors in /var/log/messages or syslog) and won't work again until I 'rmmod ohci_hcd' and modprobe it back again. My laptop (which is currently running -test8) has this problem, and it is very annoying (although at least APM works).
One big improvement in 2.6 will be with handling of CD and CD-RW drives. CD audio extraction will be able to use DMA, which should speed it up a lot. Also, CD writing will be possible using the regular IDE driver, so it won't be necessary to use SCSI emulation anymore.
For a really comprehensive description of the changes with 2.6, you might want to look at The Wonderful World of Linux 2.6, which goes into much more detail than anyone on /. is likely to be able to.
There's no point in questioning authority if you aren't going to listen to the answers.
Didn't think so.
Um, I think you misread that. The Fedora Core 1 that is coming out in a couple weeks has no plans whatsoever for supporting kernel 2.6.
Which is a good reason to try Slackware again. 9.1 was just released, with 2.4.22, and support for 2.6. Which means they already did the dirty work of making sure mod-init-tools was on the machine, along with other necessities. Not to mention it comes with Gnome 2.4 and KDE 3.1.4
I've tried 2.6.0-test4 on Slackware 9, and it made a difference in desktop usability and responsiveness.
-- If we don't stand up for our rights, now, there will be no right to stand up for them later.
Read the documentation in the kernel. There is a file in the kernel Documentation subdirectory called Changes. In it are versions of various software tools you will need to build the kernel properly. If something is deficient, update it before compiling. Reguardless of your system, loader (lilo or grub), don't overwrite your old kernel! Keep it around in case something goes wrong with your new one. When compiling, use a build script (there is an option to save your configuration to a file...do it so that you can use it again later). After building, check to see how many modules your system built. Go to the directory /lib/modules. There will be different modules for different kernels (and the directory names are for the various kernels). Get a rough idea of how many modules were built. Look in /boot and look for vmlinuz-(new system) or vmlinux-(new system). That is your new compressed kernel (with the z) or your new kernel. There are different instructions for modifying the bootloader for grub/lilo (read them carefully and follow the instructions). Also, for 2.6 you will need new tools for loading kernel modules. Go get the latest version of module-init-tools and install it carefully. (And on RedHat 9.0 like what I use, you have to modify a startup script...(and the information for what to change is in the FAQ..search for RedHat). I've been building kernels since 1.2.13 on Slackware (95), so some of this isn't quite that new to me. Good Luck!
The "latest RPM" is, by definition, not stable. It has not had the testing period that a "stable" package has.
If you want a more recent version than is available in stable, pin your machine at stable and install the "testing" package(which satisfies dependancies), or run testing itself.
You can also find a third-party debian source(eg http://marillat.free.fr), or compile it yourself, though that also defeats the testing period.
Check out http://www.apt-get.org/ for all your unofficial debian source needs.
The mailing list post that is linked to in the headline, if you'd read it, mentions that Linus doesn't want to do anything major before release. I'd consider "bug changes" critical, personally. Linus is only taking bug fixes for major issues. Witness:
"So guys, let's work on this even more for test10. I'm going to _totally_ ignore patches that aren't for major bugs. Don't send me anything that _others_ wouldn't consider horribly critical."
Take a look at http://people.redhat.com/~arjanv/2.5/ they have unofficial, precompiled 2.6 kernels there, last one is test8. Kernel is working just fine on my T23, minor bootup issues with USB, otherwise no problems. Only other thing is, you have to update your modutils and initscripts.
For the admins:
Watch out, if you use several ethernet-cards. The PCI-scanning-routines have changed which result in different enumeration and thus:
cards get different device-names than before!
When switching from 2.4 to 2.6 I had to exchange my ethernet-cables between cards.
This may be with all multi-card-setups.
Keep an eye open.
Just to clear up a little thing about Debian, yea, stable is some pretty old packages/versions, but it is very well tested, and rock solid.
i keep hearing this about Debian, and indeed it's true. however, i run redhat 9 on all my production servers using the latest packages from the apt-get repository from freshrpms. i have zero stability problems and my servers run rock solid as well.
even though i run redhat systems, i still use vi for every configuration; that's one of the things i like about redhat is you can configure the machine with gui tools or you can do it the old fashioned way (i prefer the old way myself).
besides my redhat experience, i am also the sysadmin for 5 debian (latest stable) boxes at another company. just about every package on there are full point releases behind that latest release (some are 2 year old packages, look at the old clunky vi for an example).
the debian machines are rock solid and i don't have any problems with them at all. of course, the redhat machines are problem free as well.
with my experience, my distro of choice for a production platform? redhat. it has all the great features of debian, plus.
i geuss my point is that debian folks are always saying how stable debian is, but i find that other distros are just as rock solid.
No. Linux has supported SATA drives for ages. It now supports the additional SATA extensions, which, BTW, win* doesn't use.
Ok, before you read any further remember that this is NOT accurate, tested or anyhow valid information. Some of this is purely psychological and has got NOTHING to do with real benchmarks.
.20-ck6. Didn't switch back just yet because I had compiled in some stuff I needed and it takes a while to compile a new kernel with this hardware.
.22-ck1, and it has seemed even more responsive in normal use (IRC, web surfing, MP3s etc) than .20-ck6 which I was already happy with. Responsiveness shows in switching desktops when browser is doing things, starting things and playing MP3s at the same time.
I've been running 2.4 series with CK [1] patches. I'm unfortunately using somewhat low-end hardware (P200MHz) and hence I really appreciate performance. I switched to linux-2.6.0-test8 only a week ago, so again this isn't really the best source of information.
Anyhow, I'm so far REALLY happy with performance of 2.6.0-test8. Before the switch, I was using 2.4.22-ck1 which was a lot worse performance-wise than my previous kernel,
Linux-2.6.0-test8 has done A LOT better than
And yes, as I said in the beginning, most of this is purely psychological and inaccurate. Slower hardware of course benefits more even from smallest performance gains. Then again, I don't believe that 2.6 will be The Thing for serious production enviroments for a while, it's not mature enough yet. But for me -- for desktop use -- great!
[1] http://members.optusnet.com.au/ckolivas/kernel/ (Con Kolivas' kernel patches that aim to a more responsive system)
Theres a valid torrent link at http://www.distributedbandwidth.info/torrentmap/ex plorer.jsp?cat=Lin260.
It's got the patch & the full kernel.
Al Sutton
You're using sawfish, right? I am, and I tracked down the problem to a line in librep. I mailed John Harper just now about it. If you're not using sawfish, you can ignore the rest of this message.
It all has to do with the following lines from unix_processes.c:
The call to select() on kernel 2.6 causes the timeout to be fully expired every time. This code is in the parent branch after the fork() (right before it starts waitpid() on the child), so everything freezes for at least 1 full second. Dropping this timeout to 1 usec causes the problem to go away.