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.

Comments

I'm having trouble!!!

[Anonymous Coward]

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?

Re:I'm having trouble!!!

[TheOtherChimeraTwin]

Me too! I carefully followed all the steps. There were a few errors, but nothing that looked important.
This is what I get:

C:\WINNT\system32>uname -a
'uname' is not recognized as an internal or external command, operable program or batch file.

My kernel is 8.0

[Dancin_Santa]

Is this a different numbering scheme?

release-worthy?

[geeveees]

"Since chances are most people will be upgrading anyway once 2.6 is deemed release-worthy,"

IMHO it already is :) 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!

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

Re:release-worthy?

[Overly Critical Guy]

There are build problems if you compile serial devices as modules. You have to compile them into the kernel or hand-edit the build process after the "make menu" step.

Seems complicated

[Anonymous Coward]

Can't I just download one file, double-click on it to install, and re-boot the computer?

Re:Advantage: Bill

[Baron_Yam]

Oh, of course there's also the "Give up obscene amounts of cash" and "Tolerate large numbers of security holes"

gcc 2.95?

[Psiren]

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.

Re:gcc 2.95?

[bwindle2]

2.95 is a known-good version. The newer GCC seems to work just fine, but it might have some quirky bugs that causes it to miscompile.

bwindle@morpheus:~$ cat /proc/version
Linux version 2.6.0-test3 (root@morpheus) (gcc version 3.2.3 20030415 (Debian prerelease)) #29 Mon Aug 11 11:56:22 EDT 2003

Re:gcc 2.95?

[Daniel Phillips]

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.

There is still an architecture or two that requires gcc 2.95 to compile properly (unless you're running Sparc 32 you are probably OK) and there are some developers still fond of it because of 20% or so faster build speed. The cord will likely be cut in the next cycle.

Gcc 3.x has worked just fine for me for the past couple of years. I switched at 3.0.7 and didn't have any problems with kernel builds, though 3.2+ is recommended, because of C++ binary compatibility.

Debian Sid has gcc 3.3.2 at the moment, and Redhat switched to the 3 series a year or so ago.

2.6 ROCKS

[Quinn]

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!

Re:2.6 ROCKS

[JonTurner]

>> Even typing into xterms seems faster.

Hey, just wait 'till 2.6 Release is available -- The case fan will spin faster, the speakers will be louder, and the "on" LED will glow brighter, too!

Re: You actually prefer...

[botzi]

....going out and enjoying the shiny day with your friends, maybe doing some sport etc, instead of crawling down to the basement and recompiling kernels for several hours????
You're officialy banned from visiting /. you freak!!!!!;o))))))

Re:Advantage: Bill

[Nicolas MONNET]

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.

Re:Advantage: Bill

[TheRaven64]

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

Re:I think Linus was too fast ...

[TheRaven64]

Yes, the micro-kernel is quite dead,

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.

Re:release-worthy? - Not quite there on SPARC!

[TheScienceKid]

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.

Re:thor's howto:

[dzym]

Of course, that would be:

apt-get install kernel-image-2.6

Might as well get it right, eh? :)

Microkernels

[Anonymous Coward]

While Linus's opinion on the matter is well known, Microkernels are far from dead. It's just that Mach gave them a bad name. Mach was too bloated and too slow, while the new breed of microkernels have unbelievably fast IPC primitives and therefore the potential to revolutionize the way operating systems are built. Mach sucks != Microkernels suck.

See, for example, the L4 project.

alsa?

[Al Al Cool J]

The one thing not mentioned in the article, and the one thing that has me nervous about trying 2.6-test is the changes to alsa. With 2.6, alsa is built into the kernel, so presumably this makes it easier to set up in the first place. But I already have alsa set up perfectly in 2.4, complete with OSS emulation and artsd sound mixing, so that all my apps play nice and just work. How much deconfiguring and reconfiguring am I going to have to do if I'm going to be jumping back and forth between 2.4 and a possibly unstable 2.6? Especially since I have the rather finicky via82xx driver. I'm really keen to try out 2.6, but not if I end up breaking sound in the process.

Re:alsa?

[Spider[DAC]]

if you already have alsa installed for 2.4 its a breeze, just tag the 2.6 kernel to build the alsa sound stuff as modules (include oss emulation) and remove the native OSS support.

Well need to note, you still need the alsa-lib, but they don't need to be changed just because you are bouncing kernels.

Another positive recommendation

[irexe]

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.

Re:Advantage: Bill

[swtaarrs]

Yes, I've seen this problem a lot. People are comparing the ease of use of Windows to the ease of use of Gentoo or similar, in which case Windows is a whole lot easier (don't get me wrong, I love Gentoo). If you're going to compare the ease of use of Windows with linux, compare it with a distro that's designed for ease of use, like Mandrake.

My experiances with 2.6

[Vilim]

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

Re:Question

[BJH]

Two possibilities:

1) You didn't compile in devpts
- Solution: Compile in devpts support.
2) You didn't mount /dev/pts
- Solution: Add a line like this to your /etc/fstab file:

none /dev/pts devpts mode=620 0 0

Depending on your distribution, you might need to fiddle around with the owner of that - if you have a tty group defined, add a gid=[tty gid] option in, so it looks like this:

none /dev/pts devpts gid=5,mode=620 0 0

Here's Two Kernel Testing Articles for You

[MichaelCrawford]

Back around when 2.4 was released I wrote two articles about how to help test the kernel.

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.

Re:Advantage: Bill

[N1KO]

You mean the windows kernel is easier to recompile?

Re:I wonder

[Johan Veenstra]

Well actually 'make xconfig' uses the Qt libraries. So 'make xconfig' is just as much KDE as 'make gconfig' is Gnome.

Tao

[Brian Kendig]

The Tao says: the perfect piece of paper is unmarked by pen; the perfect flower is unpruned by shears; the perfect operating system is untouched from its default installation.

I've had to support, debug, fix, and otherwise un-screw-up many computers in my time. Inevitably, the closer a system is to what everybody else is using, the more likely it is that any problems with it will have been seen and solved countless times before.

That's why the idea of countless legions of users out there each recompiling his own kernel just makes my blood run cold. This is the twenty-first century, peoples! Why is it necessary for anyone other than a kernel developer to compile the kernel sources? Why haven't all the optional pieces been broken out into modules yet?

Re:Tao

[Phaid]

Granted, you're mostly just trolling, but someone might seriously ask those questions. So:

Why is it necessary for anyone other than a kernel developer to compile the kernel sources?

Because this is still a development kernel. No Linux distribution ships with binaries of this kernel. So if you want to run it, you have to download the source and compile it yourself.

Why would anyone want to do that then? Because this is an open source project, and by running the test kernels, you help expose any lurking bugs so that they can be fixed. Once they're all fixed, the kernel can then be formally released. Distributions will ship with it, and people will then be able to run this kernel without the need to compile it themselves.

Should just anyone do this? No. This kernel isn't yet fit for a production environment. But people with spare machines, or who want to experiment, can do this if they want to contribute.

Why haven't all the optional pieces been broken out into modules yet?

Oh, they have been. Take a look at any of the major distributions. They ship with standard kernels, in which support for pretty much everything that can be modularized, is. That way it's as close as possible to a one-size-fits-all kernel and most users have no need to recompile it. About the only thing that can't be taken into account by this approach is CPU optimization, which is why a lot of distros ship with a set of otherwise identically configured kernels, each optimized for a particular CPU type.

Re:Tao

[Phaid]

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.

A much better guide

[Phaid]

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.

Something We Can All Do To Help...

[jd]

Not all architectures will work as well as the Intel architecture, simply because of the lack of developers. (There aren't as many PPC64 kernel hackers as there are for the ix86, for example.)

However, that doesn't mean we can't all contribute a little for these architectures. The PC has SPARC and ARM emulators, for example, which are about as close to the real thing as you're likely to get.

Even if only a handful of Slashdot readers who don't normally do kernel work just grab an emulator, cross-compile 2.6 for it, and see what breaks -- hey, it might make all the difference between a working 2.6 and another Brown Paper Bag release, for those architectures.

"Why go to all the effort? It sounds hard work!"

It really isn't. Arcem is pretty much complete, and even comes with a Linux image. As I'm suggesting a cross-compile, you don't have to worry about 90% of the "requirements". The filesystem tool is about all you absolutely need to update on the Arcem image.

"What do I get out of it? I don't even use this processor!"

Finding a single bug - even a single mis-placed #ifdef, as in the SPARC architecture, mentioned elsewhere - and getting a fix submitted, would earn you a place in the CREDITS file. You get to add the emulated architecture to your resume (if it's fashionable, such as the PPC64, SPARC64 or IX64). You also get "bragging rights" as an OS kernel developer.

That's not bad personal compensation for the effort needed. Linux itself gains, by getting more extensive testing on lesser-used architectures, where it has a good chance of cornering the market.

actually, it's even simpler

[penguin7of9]

Once the kernel has been officially released, all you need to do is type:

# apt-get install kernel-image-2.6

See, isn't that even simpler than to "download one file, double-click on it to install, and re-boot the computer"?