Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
GNU is Not Unix Software Linux

How To Upgrade Linux To The 2.6 Kernel 351

Posted by CowboyNeal from the practice-makes-perfect dept.
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.
This discussion has been archived. No new comments can be posted.

How To Upgrade Linux To The 2.6 Kernel More

How To Upgrade Linux To The 2.6 Kernel

Comments Filter:

  • I'm having trouble!!! (Score:5, Funny)

    by Anonymous Coward on Saturday August 30, 2003 @08:33AM (#6832468)
    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?

  • My kernel is 8.0 (Score:4, Funny)

    by Dancin_Santa ( 265275 ) <DancinSanta@gmail.com> on Saturday August 30, 2003 @08:37AM (#6832481) Journal
    Is this a different numbering scheme?

  • release-worthy? (Score:5, Informative)

    by geeveees ( 690232 ) on Saturday August 30, 2003 @08:37AM (#6832483) Homepage Journal
    "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".

  • Seems complicated (Score:5, Funny)

    by Anonymous Coward on Saturday August 30, 2003 @08:38AM (#6832484)
    Can't I just download one file, double-click on it to install, and re-boot the computer?
  • ... don't forget to buy your license from SCO before using the kernel.

  • gcc 2.95? (Score:5, Interesting)

    by Psiren ( 6145 ) on Saturday August 30, 2003 @08:43AM (#6832506)
    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? (Score:3, Informative)

      by bwindle2 ( 519558 )
      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
    • Hmm... 2.95 is far more mature than 3.3

      2.95 had fewer bugs. It's also a common denominator. Distros have had gcc2.95 for a while. Or 2.93 or whatever that was. I just upgraded recently by libc, gcc, kernel, and recompiled almost 50 slackware distro included libs. That freaking sucked. I had to comile X, Qt, and KDE. Oh my freaking god. Just those three combined was over 3GB. My poor computer had been compiling non stop for 3 weeks. I highly recommend those who are new or aren't masochistic like me to just
      • Redhat is using a 2.4 kernel compiled with 3.2-something right now... as am I

        I'd say it's just paranoia (the kernel of course being the most important thing to compile correctly, next to glibc, and gcc itself).

    • Re:gcc 2.95? (Score:5, Informative)

      by Daniel Phillips ( 238627 ) on Saturday August 30, 2003 @09:17AM (#6832639)
      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.

      • Re:gcc 2.95? (Score:3, Informative)

        by acidrain69 ( 632468 )
        Kernel 2.4.20 fails to compile on my alpha using Gcc 3.3, 2.95 works though. I'm sure it's fine for x86, but I find the ports lacking in refinement.
        • Kernel 2.4.20 fails to compile on my alpha using Gcc 3.3, 2.95 works though. I'm sure it's fine for x86, but I find the ports lacking in refinement.

          This would be because (some of) the 2.4 ports haven't been cleaned up, and possibly never will be. I should have mentioned, I was talking about 2.6. Though to be sure, it's important that 2.4/x86 just works, so the vast majority of users can use gcc 3.2+ without worrying. Since it's installed by default on most distributions, you have to go out of your way

  • 2.6 ROCKS (Score:5, Informative)

    by Quinn ( 4474 ) on Saturday August 30, 2003 @08:44AM (#6832510) Homepage
    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!

  • Question (Score:2, Interesting)

    by Anonymous Coward
    Are traditional pseudoterminals still supported or the Unix98 scheme the only thing available? I built
    the kernel successfully, but found that xterm and
    rxvt didn't work because they didn't have pty's.

    • Re:Question (Score:3, Informative)

      by BJH ( 11355 )
      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

    • That is one of two items that he missed in the article. Indeed, in the 2.4.x kernels if you used devfs you did not need to enable /dev/pts file system support but you do with 2.6. Interestingly, now that devfs is officially in the kernel they are thinking of replacing it with udev.

      Also, it is not mentioned that you need to create the /sys directory. It apparently has something to do with sysfs which I don't quite understand yet, but it was necessary to get all my sensors reading correctly.

  • alsa? (Score:3, Insightful)

    by Al Al Cool J ( 234559 ) on Saturday August 30, 2003 @09:07AM (#6832605)
    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? (Score:2, Informative)

      by Elm0 ( 599465 )
      Don't fear: I am using via82xx ALSA driver built as modules in 2.6-test4 with no problems. My distro is gentoo, if that has any bearing. You may be interested to look at this post if you are having the awful 'scratchy output' problem (in reference to your 'finicky via82xx driver' comment) http://forums.gentoo.org/viewtopic.php?t=73692

    • Re:alsa? (Score:3, Informative)

      by Spider[DAC] ( 129824 )
      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 (Score:4, Informative)

    by irexe ( 567524 ) on Saturday August 30, 2003 @09:10AM (#6832615)
    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'll just use the distro build which is packaged properly. That's not to say I'm not excited by the new features, etc., but I've long ago decided my life should not be spent compiling and tweaking things in which I have no particular expertise or passion. Those with expertise and passion are going to do a better job.

  • My experiances with 2.6 (Score:4, Informative)

    by Vilim ( 615798 ) <ryan @ j abberwock.ca> on Saturday August 30, 2003 @09:40AM (#6832739) Homepage
    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
  • You can find Redhat 9 rpms of the 2.6-test series at http://people.redhat.com/arjanv/2.5/RPMS.kernel/ [redhat.com]. There are also rpms for all the necessary packages that the 2.6 kernel requires. I've tried out 2.6test4 on my machine and it works quite well.
  • ... it's still a sexy task for developers to track down kernel bugs and stabalize their work.

    Anybody start thinking about Austin Powers at this point?

    FatBastard: I'm Sooooo Sexxxxxxyyy.

  • Unofficial Redhat Kernel 2.6 RPMS (Score:3, Informative)

    by mrpull ( 112590 ) on Saturday August 30, 2003 @10:27AM (#6832959)
    Unofficial Redhat Kernel RPMS [redhat.com] are here.
    Check the readme [redhat.com] for the apt or yum lines to add to your configs.

    I used apt4rpm to easily install 2.6pre4 yesterday.

    mr.

  • Here's Two Kernel Testing Articles for You (Score:5, Informative)

    by MichaelCrawford ( 610140 ) on Saturday August 30, 2003 @10:34AM (#6832995) Homepage Journal
    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:

    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 [sunsite.dk] 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.

  • kernel.org (Score:2, Funny)

    by geekfiend ( 448150 )
    Anyone else getting timeouts for kernel.org? Have we slashdotted linux?
    )
  • as a Gnome user

    make config
    make menuconfig
    make xconfig
    make gconfig

    How in the world is posiible, that no KDE user has been whining yet that there's no make kconfig

    Does that mean that THE G/K Cold War is over???
  • The best I can describe the Radeon Framebuffer Console in 2.6 is "Whacked."

    It's like it puts the console on 1/4 of the display, and it "bleeds" one vc onto another.
    Sorry that's the best I can describe it.

  • Tao (Score:4, Insightful)

    by Brian Kendig ( 1959 ) on Saturday August 30, 2003 @11:10AM (#6833193)
    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 (Score:4, Interesting)

      by Phaid ( 938 ) on Saturday August 30, 2003 @11:27AM (#6833277) Homepage
      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 (Score:3, Interesting)

        by Brian Kendig ( 1959 )
        No, I'm not trolling. I know why people should test pre-release kernels. What I *don't* know is why people should have to compile them on their own.

        How hard is it to automatically, each night, roll the latest test kernel into a Debian package and a Redhat RPM? That way, people don't have to go to the trouble of compiling their own copy of it -- and, more importantly, they don't run the risk of screwing up the compile and making their system unbootable and/or introducing problems which might be mistaken

        • Re:Tao (Score:5, Informative)

          by Phaid ( 938 ) on Saturday August 30, 2003 @12:25PM (#6833689) Homepage
          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 (Score:5, Interesting)

    by Phaid ( 938 ) on Saturday August 30, 2003 @11:18AM (#6833223) Homepage
    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 [kernel.org] 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... (Score:4, Interesting)

    by jd ( 1658 ) <imipak AT yahoo DOT com> on Saturday August 30, 2003 @11:23AM (#6833253) Homepage Journal
    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.

  • uh.. that doesn't cover everything (Score:3, Informative)

    by Cthefuture ( 665326 ) on Saturday August 30, 2003 @11:29AM (#6833290)
    There are tons upon tons of "other" stuff that goes into upgrading the kernel.

    For example, no official nVidia drivers for the 2.6 kernel yet. It's patch city for you, good luck.

    No VMware modules either. Again, good luck.

    Not that it can't be done, but it takes a whole lot of time and your system will be very fragile.

    Personally, I'm waiting till the new kernel is supported by the software I use. I actually use my Linux system for real work so I can't have much down time.

  • kernel upgrades as a major turnoff (Score:3, Insightful)

    by binarybum ( 468664 ) on Saturday August 30, 2003 @12:17PM (#6833633) Homepage
    Doesn't it seem that a lengthy eight-step process for an OS upgrade could be one of linux's major pitfalls when it comes to targeting new users?

    I'm not complaining, but shouldn't this be easier if linux is ever going to make it into the realm of familiarity?
    • Doesn't it seem that a lengthy eight-step process for an OS upgrade could be one of linux's major pitfalls when it comes to targeting new users?

      Isn't having to fix some things by delving into an arcane database noone understands using "regedit" a turnoff for new windows users? New users should just use the kernel that comes with their distro. Theres no reason anyone _has_ to compile their own shiny new 2.6 kernels. Once it's out of the -test phase, the distros will pick it up, and the users will get

Slashdot Top Deals

...there can be no public or private virtue unless the foundation of action is the practice of truth. - George Jacob Holyoake

Close