Slashdot Mirror
How To Upgrade Linux To The 2.6 Kernel
An anonymous reader writes "Here's a good computer project for the long labor-day weekend. KernelTrap has posted a howto detailing eight steps to upgrade your GNU/Linux OS from the 2.4 stable kernel to the 2.6.0-test development kernel. Complete with screen shots, the end result sounds to be well worth the effort." Since chances are most people will be upgrading anyway once 2.6 is deemed release-worthy, it's always worth learning the upgrade procedure well.
I followed all the steps, then this is what happened:
-bash-2.05b$ uname -a
Darwin Bruce 7.0.0b1 Darwin Kernel Version 7.0.0b1: Tue Jul 29 15:27:33 PDT 2003; root:xnu/xnu-470.obj~1/RELEASE_PPC Power Macintosh powerpc
I'm really confused, any ideas?
Is this a different numbering scheme?
"Since chances are most people will be upgrading anyway once 2.6 is deemed release-worthy,"
:) I've been using it ever since the first -test was released, patched it with Andrew Morton his -mm and it's fast and solid for me!
IMHO it already is
If you haven't tried it out already, go download -test4 now! Even if it's just to see if all your hardware works, if you report any problems now you don't have to deal with them when 2.6.0 is officially "stable".
I am a viral sig. Please help me spread.
Can't I just download one file, double-click on it to install, and re-boot the computer?
Anyone know why they still require gcc 2.95? Or is this a minimum? Will it compile and run with gcc 3.3.x without problems? I was under the impression they tried to target the current stable version of gcc on each new major release.
As noted in the article, the build output is much cleaner (simple status lines for each section/module being built, not the whole gcc cmdline), the make options are now fully documented (with make help), and make is simplified down to `make all' and `make install'/`make modules_install'.
I'm not particularly fond of the new make xconfig, but didn't give it much of a chance. I went with `make menuconfig' and ncurses instead.
Performance is noticably improved. Not just "some people told me it's better and well, maybe it is a little", but actual tangible improvements. Even typing into xterms seems faster. (I did enable the preemptible option, but this seems even better than when I did it with the old patch to 2.4.)
This is the most pleased I've been with a new kernel in ~6 years of using Linux. Highly recommended!
#19845
Bollocks, those steps are only intended for those who want to try the BETA kernel. End users will just use whatever kernel is provided by their distribution, and won't have to deal with any of that shit.
Don't forget that this is a lowest common denominator tutorial. The only people who will upgrade this way are hard-core geeks. Debian users will simply use apt to grab a package containing the latest kernel, RedHat users will use up2date to do the same thing. Of course the easiest way of upgrading will probably be to pop a RedHat 10 (or whatever) CD in your drive and click on the upgrade button...
I am TheRaven on Soylent News
Really? The two nicest desktop operating systems I've used are MacOS X and BeOS. OS X is based on the mach microkernel, while BeOS has its own microkernel. And before you say BeOS is dead, take a look at the new version (still in private beta).
Microkernels are still very much alive. They don't give quite the performance of macrokernels, but they have a number of advantages (like not needing a reboot to replace large portions of the kernel, and drivers not being able to crash the kernel). With current system speeds, the flexibility of a microkernel is well worth the speed trade-off, on the desktop at least. On a server / workstation I would probably still choose a macrokernel.
I am TheRaven on Soylent News
Perhaps it is release-worthy to those on an ix86 platform, but I had to modify include/smp.h to get it to compile on sparc, moving #include into the #ifndef __ASSEMBLER__ section to avoid the redefinition of ALIGN that caused compiling to fail.
I've been trying -test1 and -test4 on my desktop and laptop for some time now. It is perhaps hard to believe, but the new kernel is very much _noticeable_ on the desktop. How? Well, for instance, you can 'feel' it when moving the mouse and watching the pointer on your screen. The lag between the physical movement and the mouse pointer has become almost unnoticeably small, even when apps are hogging CPU. Another nice touch is that your desktop keeps this responsiveness with large processes (say, an 'emerge mozilla') running in the background. With 2.4, terminals would be a bit slow at starting and such, but that is all gone now. It is also very pleasant that ALSA is now in the kernel. It saves lots of hassle compared to 2.4, where you had to compile the modules separately. Low latency audio performance should be less of a black art too with this kernel.
Cons:
Some defaults were funny at first (like missing console drivers, etc.) and I've noticed the mouse being a little jumpy some times. Nothing big so far.
All things considered: great kernel! Thanks guys.
I have been useing the mm patch on every 2.6 kernel since test1. I have installed it on 3 machines (my desktop, my friends desktop and my laptop). It has been running rock solid for me. The sound quality is great due to the alsa integration, ACPI is working great on my laptop. Though some people complained about ACPI causing the kernel to crash on boot with test 4 I havn't encountered this with test 4 mm sources. Although I wouldn't put it on a server just yet it is definately the best desktop kernel release yet
History will be kind to me, for I intend to write it - Sir Winston Churchill
You can help the kernel developers immensely by testing your kernel methodically and thoroughly rather than just casually trying it out.
It's also important for you to test new kernels, even stable kernels, before putting them to use on a production machine. Even if they work well for everybody else, you may be blessed to discover your very own bug.
Also realize that because Linus can issue a new kernel anytime he feels like it, there is no particular requirement that a kenel be tested before its released. It's happened a number of times that "stable" kernels have been released that have turned out to be quite broken, especially on non-x86 architectures.
So please read, enjoy, and put to good use:
-
Why We Should All Test the New Linux Kernel
-
Using Test Suites to Validate the Linux Kernel
The OSDL kindly prepared Japanese translations but for some reason have taken them offline. I have copies though and will try to post them sometime soon.There are other articles on web application quality and C++ programming, with more to come. So far they are all under the GNU Free Documentation License.
I am actively seeking more translations if you want to help out.
Request your free CD of my piano music.
Well actually 'make xconfig' uses the Qt libraries. So 'make xconfig' is just as much KDE as 'make gconfig' is Gnome.
This seems to be yet another in the growing collection of mostly useless 2.6 "migration guides". It doesn't mention any of the common gotchas with configuration, its recommendation for invoking the build process is wrong, etc, etc.
A much better guide is Dave Jones's Post Halloween 2.5 document, which, although very slightly dated, does a much better job explaining how and why things have changed in 2.6 and their impact when upgrading from 2.4.
Lots of people test nightly builds of Mozilla; what's so different between Mozilla and the kernel which prevents kernel binaries from being downloadable?
Because there are simply too many variables for a manageable number of binary releases to cover. You have different CPU types -- and not just x86 ones -- to optimize for. Just the x86 ones alone would require half a dozen separate builds or more, without taking into account SMP or lack of SMP.
Then you have build tools. Different versions of the compiler, of binutils, of the module tools, etc, all can expose subtle bugs. And they can introduce incompatibilities -- third-party modules built with one version of gcc won't work with a kernel built with another.
Then you have the way the system is going to be used. If you have a desktop system with lots of RAM and disk space, great, build everything and have at it. But if you're targeting an embedded platform, you may not be able to do that, so you'd want to build a much smaller subset of the kernel, possibly with some core features removed, or a different scheduler than most desktop users would want to use, etc.
Simply put, the cross product of hardware platform, intended use of the system, and development tools, is too large for binary-only releases of test kernels to be a useful test article.
What you're arguing for makes sense at the distribution level. And in fact it's there already: there's never any reason for anyone to compile their own kernel, IF they stick to production kernels. But in a testing environment, there's no way that a manageable number of binary releases is going to cover all of the possibilities.