Configuring the 2.6 Linux Kernel
An anonymous reader writes "This article is the first in a series by William von Hagen on using the new Linux 2.6 kernel, with a special emphasis on the primary issues in migrating existing drivers, applications, and embedded Linux deployments to a Linux distribution based on the 2.6 kernel. Bill is the author of Linux Filesystems, Hacking the TiVo, SGML for Dummies, Installing Red Hat Linux 7, and is the coauthor of The Definitive Guide to GCC (with Kurt Wall) and The Mac OS X Power Users Guide (with Brian Profitt)." This looks to be a good series for anyone planning to migrate to Linux 2.6, and having done just that myself, I'll attest to wanting more documentation along the way.
Mandrake 10 will be the first major distro use Kernel 2.6. Download the beta here.
Easy to install, just download the ISOs, burn to disk, reboot and the installer will appear.
Make sure to REPORT ALL BUGS, unless you want to see the LG incident again.
I found this sticky at linuxquestions.org's forums to be most helpful in doing an easy and straightforward 2.6 compile on a slackware system. LinuxQuestions.org
the 'funky X configuration interfaces' you talk about are nothing more than GUI applications
Did you RTFA? The article basically stated some obvious changes, and talked up the new GUI configuration interface as if it was the best thing ever since sliced bread.
Nothing interesting in this article, IMHO. I hope the subsequent articles will be more informative.
Yes, that's what the "make oldconfig" is for. You need to overwrite the .config file first. This goes for the 2.4 series kernels - I don't know if it has changed in the 2.6 series?
zWhat would an EWOULDBLOCK block, if an EWOULDBLOCK could block would? -- me
copy your /boot/config-2.x.y to the source directory as ./.config and then make oldconfig. It will go through all the old options setting them and present you with only the new options. Its a text only interface, but its pretty simple to choose between y/n/m/? and each option is pretty self explanitory. I think you can also step back a version using the same method, but Im not sure about that.
"We Don't Need No Truthless Heros!" - Project 86
Yeah, if you copy over .config and run "make oldconfig" it'll only ask you new questions - could be problematic for large changes, but for little kernel upgrades it's worked fine for me (2.4.22 -> 23 -> 24; 2.6.0 -> 6.1 -> 6.2)
IANAKH, so feel free to correct me.
I am one of many. My idea is not unique, nor do I expect my voice alone to sway you. I speak in a chorus of opinion.
Well, nVidia has support for their graphics cards on 2.6. As for the other hardware you'll have to google yourself. The nVidia link wasn't paticularily hard to find.
by the way, while you're at it, there is an option to have a compressed configuration file included inside the kernel image itself, and to be read from /proc/config.gz ( applies only to 2.6 kernels and some patched 2.4 kernels only )
This is just a very loosly disguised advert for TimeSys Linux
Nothing any monkey cant work out in about five minutes (and if they cant they should not be cross compiling for embedded devices)
Since most people dont RTFA this isnt a problem, if you are one of the many... dont bother - its S**T
It wont solve the main problem, but you can enable the /proc/config.gz option in the 2.6 kernel, so you can access the old config at any time through the /proc interface.
I've used 2.6.0 through 2.6.2 on my machine with a KVM for a while now, never had an issue.
Probably just a problem with your KVM or setup.
I've used a KVM w/ both 2.6.0 and 2.6.1 and have had no problems. The trick was to use "IMPS/2" as the mouse protocol instead of "Auto". That, along with your ZAxisMapping option should be all you need to get it to work. Assuming of course your KVM is ps/2.
The default x86 kernel config always used to be Linus's machine; I don't know if this is still the case. =)
You can always include almost everything as modules.
Or alternatively you can take a kernel configuration of your favorite distribution and tweak it to your liking. Most distributions will include drivers for all common hardware as modules.
Kernel 2.6 is very usable and stable. I've been running mm-sources since 2.5.5x and haven't had any major problems with it. There's hardly any need for recompiling packages (there are few exceptions though, mostly packages that install some kind of kernel module, svgalib for example). One thing you must do is to replace modutils with module-init-tools.
Gentoo forums are relly your friend. There are tons of threads concerning 2.4 to 2.6 upgrade, including some howtos.
The 2.6 kernel is noticeably faster on my dual Athlon 2100+mp, at the user interface; X is faster than I've ever seen it before; the realtime scheduling is awesome.
In short, as soon as you can reasonably do so, I recommend you migrate to the 2.6.x kernel.
Thinking outside my Head
There is a 2.6 Input Drivers Faq . It covers some of the more common issues, including some KVM problems.
Be kind. There are too many mean people out there already.
In sum, yes. As with any major kernel update you have to have the matching user space parts or many devices will not work. Required documentation is included with the kernel;
README (case sensitive) and
./Documentation/Changes (as noted in README)
Keep in mind that if you don't need support for specific hardware -- say, ISDN or PC-Card/PCMCIA -- you can skip updating those packages.
Specific comment: Alsa is now the default sound system, and it needs updated supporting tools if you want to get a peep out of your audio. Point for point comments;
Normal precautions, nothing special.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
When you add new hardware that is not needed at boot (e.g not a bood device), simply build the kernel feature to support your new device as a module. Install the module and you are ready to go. No rebuild or reboot needed. You don't throw away config files. You save them for later use. The config procedure gives an option to save your config to an alternate location.
UNIX/Linux Consulting
Speaking from experience (P1 100MHz, no MMX, 16MB RAM, 500MB disk), going from 2.4 to 2.5 was a beautiful, beautiful thing. Sure, it'll give you a ton more performance on a high-end box, but it makes a low-end box much more usable.
--
Given enough personal experience, all stereotypes are shallow.
The foremost problem I had in migration was that SCSI emulation with ide-scsi is no longer used for CD burning. I expect many people making the upgrade will run into a problem with that.
You can use the standard ATAPI ide-cdrom driver now to burn your CDs, but the userspace programs haven't caught up to this in all distros, especially the GUI ones. cdrdao just doesn't work last I checked, and while cdrecord works alright in the newer versions, many GUI frontend burners simply use cdrdao too much to be useful.
Other problems I had were that lm_sensors changed a bit and I didn't find it important enough to upgrade to newer userspace stuff, but anyone who's relying on them for anything will likely want to know that it's changed and upgrades to userspace are necessary. The only other issue, which was fixed by a quick Googling was that the module system is changed and module-init-tools is now necessary for loading and unloading kernel modules.
-N
I've nothing to say here...
Well, you can still use the ide-scsi emulation in 2.6, although it's not optimal. Recently there have been some fixes to ide-scsi in 2.6, that have made it usable again.
Ultimately, it was upgrading to XFree86 4.3.0-rc3 that magically solved the problem for me.
I'm using kernel 2.6.x and gentoo 1.4, and I'm fairly new to linux. All my h/w (nvidia, sblive, adaptec-compat scsi, usb mouse + mp3 player) works very well.
/proc/meminfo has changed (the first few summary lines have been removed) -- fixes for this don't seem to exist yet.
It wasn't as smooth an upgrade as I'd've liked, but, like I said, I'm fairly new to all this.
When I first upgraded, I did get a lot of errors/warnings on boot, but I have since fixed them all.
Ensuring you have the latest versions of hotplug and module-init-tools will help your migration to 2.6, as there are changes to h/w detection and module loading.
Take care when doing make oldconfig from an earlier gentoo kernel - gentoo kernels have had various performance patched in them for some time, but -- if I recall -- these settings didn't all magically migrate across, as the gentoo kernel build flags and the official kernel build flags have differing names for these features between 2.4 and 2.6. Just remember to check all your options with make menuconfig or similar. Some other build flags have changed names too, including stuff for usb devices and (IIRC) framebuffers -- this will probably only catch you out if you're migrating settings from an older kernel.
After building and installing my 2.6 kernel, I also installed the latest nvidia package from nvidia's website, and alsa-lib and alsa-utils (both 1.0.2, from portage)
Also, there are changes to how some system stats/info is handled/reported - ensure you have an up-to-date version of procps, or top might give some cranky info... some tools that monitor memory levels (gkrellm, various gdesklets) will stop working because the output of
Other than the meminfo issue, kernel 2.6 hasn't broken anything (that I've noticed) on my gentoo system, and it appears to work very well.
(Oh, kernel 2.6 did cause one of my drives to give warnings about unexpected DMAs every few mins, but that totally fixed itself once I stopped overclocking the CPU. The drive was running slower with a mis-firing DMA, but other than the warnings, no problems occured (YMMV). Something in 2.6 must be more timing sensitive or less tolerant of overcranked h/w speeds. NBD: my system is a few years old, the extra ~20% speed increase cannot is insignificant when compared to speeds of a modern CPU - it seemed a lot at the time!)
While you do need to edit the registry to enable it for all sessions you can use
/f:on
cmd
Then...
ctrl-f for filename completion
&
ctrl-d for directories
on a per session basis.
If you are upgrading an NForce-based machine to 2.6.x, save yourself some headaches and add "noapic nolapic" to the Kernel append string. I experienced repeatable hard lockups when doing disk intensive I/O until adding those parameters.
Also, NVIDIA's nforce package is no longer necessary. The experimental forcedeth driver in 2.6.2 works quite well in my experience, and apparently an Intel sound driver works for the NForce onboard sound.
See my latest journal entry for my account of migrating MDK 9.1 to a vanilla 2.6.1 kernel.