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.
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.
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.
I distinctly remember seeing posts like this one a few years back, only it was "2.4" instead of "2.6". Funny how these things work.
Anyone else having problems with the
"Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)"?
It works fine with 2.4.21, but it's not properly recognized with 2.6-test4.
It's kind of hard to find out if there's anyone else with the same problem, since there are so many matches on "LNE100TX" and such on google. There seems to be quite a few revisions ov the said card.
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.
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
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 for bugs.
Lots of people test nightly builds of Mozilla; what's so different between Mozilla and the kernel which prevents kernel binaries from being downloadable?
I've been modded down for saying this before, but screw it....
What is so frigging hard for you people about installing Linux?
I've installed 5 different distros on about 10 computers. Gentoo and Debian gave me grief; there's no point pretending they didn't. But I wouldn't expect someone looking for a painless installation process to use them.
But RedHat, Mandrake and SuSE never caused me any problems. Ever. X worked. The mouse worked. The sound worked. The NIC worked. The internal modem didn't work, but I knew that going into it (and external modems are cheap, anyways). For these distros, I had to modify precisely 0 config files. I had to specify precisely 0 hardware specs; the "hardest" thing I had to do was choose my desktop resolution, which you have to do for Windows too.
Yes. So I attached my digital camera. RedHat and SuSE detected it and set it up for me without any input from me.Hmmm... noatun, xmms, and gnome-cd have always worked for me, without my messing with them. Windows Media Player 9 always seems to choke on weird codecs that it can't find; the Linux players seem to find them quite easily. That's exactly my point: the "easy" Linux distros have required less input and configuration from me than the comparable Windows software.
That's another good example. I use comcast cable for my ISP. I plugged the cable into my NIC, RedHat and SuSE both said something like "You appear to be connected to the Internet; would you like to use that connection to surf the web and check your email?" Click yes, and 2 seconds later I'm surfing with Mozilla. I'm not sure what you mean by "compatible"; the only compatability issues I've had are with DFAS which wants a browser version > 5 no matter the vendor.
Compare this to Windows, which made me open up "Network Connection 1", configure TCP/IP, and select a gateway and DNS server (it couldn't seem to find the DNS server automatically like it was supposed to; Linux had no problem).
Applications > Internet > Chat. Offered me GAIM, IRC, ICQ, and Jabber. Opened up GAIM; it asked me which network(s) I wanted to use. I selected the ones I had accounts on, logged in, and chatted. What's so hard about that?
What problems do people keep having that makes RedHat or SuSE so "difficult" to install and get running? Am I just exceptionally lucky in the hardware I came across? Why have RedHat and SuSE required less manual configuation on my part than Windows 2000 or XP?
Seriously, I'd like to hear from somebody who can't get Linux to install. Are you trying to install something like Debian or Gentoo? Do you have hardware produced only in Moldova? What's the issue?
All's true that is mistrusted
Actually, yes. Gentoo manages the update without much trouble, just emerge -pv development-sources and it will handle the module-init-tools downloading... you cd /usr/src/linux-beta (simlink), compile the kernel and shoot it...
It actually feels quite faster in desktop, in particular with things like compilling + listening to music + web browsing... And I didnt have much trouble in making it work... I have quite a particular config (nforce2, ice1712 soundcard...) and the only problem was finding the patch to compile the nvnet module...
Try it!