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.
"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.
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
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.
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.
/proc/version
bwindle@morpheus:~$ cat
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
The security system should be stronger integrated into the kernel. Yes there is PAM these days, but a real secure system will have authentification and verification added at kernel level to make it trust-worthy and tamper-proof.
Security should be enforced in the kernel but should not be put in the kernel. Here's what I mean, I do not want a kernel that performs authentication, but when authenticated it should stick it to it. I believe that is how the kernel works, and its much better than putting "PAM", SASL or Kerberos or Login into the kernel. I don't even think SELinux even tries to do authentication in the kernel.
Grid access. Given the exciting new development of grid computing,
Grid computing has been around since the 60's. I actually don't see where the kernel can use grid computing (meanwhile you can do what we do and use openMosix to get many of the same benefits). All you really need to impliment grid computing is SSH, RSH or even telnet and none of those things are really kernel worthy either.
Given to above grid access all journaled file system should be made grid aware and supporting distributed storaging.
Check out NFS, then AFS, then CODA and finally intermezzo depending on the level of local caching you wish for your grid.
More modular kernel design. While device drivers can be loaded at run-time, a fully modular kernel design is still missing. Yes, the micro-kernel is quite dead, but a decent modular design can be quite powerful as well-used system like Windows NT and successors show.
You mean, reboot every IP change NT? How about reboot every program install XP? The modularity in NT is not very good at all. XP is much better, but still not the keen level that Linux achieved back in 1996.
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.
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.
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.
Have you got your LWN subscription yet?
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
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.
I didn't do this, now did I?
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 find Redhat 9 rpms of the 2.6-test series at http://people.redhat.com/arjanv/2.5/RPMS.kernel/. 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.
Two possibilities:
/dev/pts /etc/fstab file:
/dev/pts devpts mode=620 0 0
/dev/pts devpts gid=5,mode=620 0 0
1) You didn't compile in devpts
- Solution: Compile in devpts support.
2) You didn't mount
- Solution: Add a line like this to your
none
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
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.
-- Having a Creationist Museum is like having an Atheist place of worship
Check the readme for the apt or yum lines to add to your configs.
I used apt4rpm to easily install 2.6pre4 yesterday.
mr.
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.
emerge -s genkernel.
How in the world is posiible, that no KDE user has been whining yet that there's no make kconfig
They did not whine, because "make xconfig" == "make kconfig" ;-)
You can save space. Or you can save time. Don't ever count on saving both at once. -- First Law of Algorithmic Analisys
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.
The ratio of people to cake is too big
Erm, you have NEVER EVER EVER had to reboot to change a setting like this in any release of linux.
The ONLY thing you have to reboot for is a kernel upgrade, new hardware that you can't hotplug, or fucked hardware ( IE shitty nVidia drivers just raped the AGP bus. )
All of your attacks seem to be based on Windows 95. Some are still valid with Win2k, but none seem valid directed against linux.
that why it's called 2.6.0-test4
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
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.
Under Gentoo doing something like "emerge genkernel kernel-2.6; genkernel" would suffice, AFAIK (don't use Gentoo). Makeing a shortcut-icon that does this after asking the root password is possible.
And in general, I do hope kautoconfigure get's some attention from developers (shameless plug).
It only requires that you patch util-linux which kerneli also requires. So your choice is to use loop-aes or kerneli with the main difference being a single up to date patch (for each new kernel) with loop-aes or you can be confused why kerneli doesn't even have patches for the last FOUR kernels in the 2.4.x branch.
;-p
Kerneli isn't a worth while choice anymore and it hasn't been as long as jari has been working on the AES(blowfish, serpent,twofish,etc) support. I suggest you stop trolling and use it
"Not my manner of thinking but the manner of thinking of others has been the source of my unhappiness." - M
You still need the patch, look at cryptoapi.org.
loop-aes is faster. Ask the mailing lists if you want someone to explain the reasons. loop-aes has other neat crypto projects like aespipe as well. In genereal I agree with the framework, I however don't think that I trust it yet. If it's better, I will hear a great deal about it and I imagine, jari would merge or do something like that.
"Not my manner of thinking but the manner of thinking of others has been the source of my unhappiness." - M