LWN: Comments on "Tips for Testing the 2.5 Kernel (Linux Journal)"

Not with all these security warnings

amosshapira — Tue, 15 Apr 2003 13:41:22 +0000

With an 11 day break (Jewish Passovah) coming up I though I might
find time to test 2.5 but I just read LWN about some known security
bugs not being fixed in 2.5 yet. Since I have only one system
at home to use regretfully I'll pass this opportunity until a more
secure 2.5 is available.

Tips for Testing the 2.5 Kernel (Linux Journal)

ludo — Tue, 15 Apr 2003 08:07:03 +0000

Hi,

I've been testing 2.5 on an older P2 system. Mostly it runs smoothly. Only two issues found:

-The new GLIBC threading library (NPTL) as shipped in Redhat 9 breaks with the vanilla 2.5.67. This affects some programs, most notably rpm. The workaround is: run "export LD_ASSUME_KERNEL=2.2.5" before using rpm.

-The system tends to lock-up during X shutdown.

I am especially happy with the inclusion of the KAME IPSec suite.

Tips for Testing the 2.5 Kernel (Linux Journal)

oak — Mon, 14 Apr 2003 19:43:39 +0000

Easiest way to test 2.5 kernel would be to compile it using the new User Mode Linux configuration option with which one can run the new kernel as one of the user space processes, see:
http://user-mode-linux.sourceforge.net/

(of course one can't test HW support or speed with this but for testing generic features or patches (e.g. secure linux) this is great)

Tips for Testing the 2.5 Kernel (Linux Journal)

allesfresser — Mon, 14 Apr 2003 19:20:30 +0000

I tried out 2.5.67 and it completely whacked my machine... wouldn't even POST. I got it back by resetting the CMOS, but then it said the processor was an Athlon XP 1500 instead of an XP 2200 until I let it reinitialize the DMI pool data and reboot again. Anybody have any idea on who I should talk to about this? I can send them the .config file for the options I used...

Tips for Testing the 2.5 Kernel (Linux Journal)

skybunny — Mon, 14 Apr 2003 16:44:16 +0000

I've actually been doing some 2.5 testing, in part inspired by the previous LinuxJournal article on this subject. I really really wish the What to expect from 2.5 document had been directly linked in the first article, because I had to learn a lot of the hints that document provides the hard way. It's just a sequential process - I found some of the extra help on my own, but not all.

Okay, now that you actually have been convinced to try the 2.5 Linux kernel (see previous article), how can you test this kernel out. And, what should you do if you have any problems?

Well...yeah. I wish all of this information had been provided in the first place. If the first article was meant to convince me to test and then wait for a second article on the best specifics of how, I would have waited to do so.

If you are familiar with building 2.4 kernels, don't jump straight in to a 2.5. The What to expect from 2.5 document is still a must-read. It will save you a lot of pain.

But, having said that, I've already submitted one bug to the kernel bugzilla database (looks like an ACPI issue). One big no-no I've found: don't install the new modutils RPM on a Redhat 9 machine and then do the kernel upgrade available on upgrades.redhat.com. The 'new' 2.4 kernel won't boot, complaining that it needs an old modutils and that /bin/insmod.old doesn't exist (of course it doesn't - and that lies in /sbin anyway). I haven't tried it yet, but perhaps building the Redhat kernel*.src.rpm will fix that problem.

Other observations:

2.4 works well with USB and an IBM docking station for a Thinkpad laptop. 2.5 has more trouble with the passthrough. It needs quantification.
ACPI is functional enough to work with most hardware devices, but not all, if enabled. The Thinkpad network card I have breaks if ACPI is enabled.
Be careful about using LABEL boot statements. Best to have LILO or Grub boot with device names instead, in my experience. LABEL statements have alternatively worked and broken for me.

My layman's observation is that with Redhat 9, the 2.5 kernel mostly works, but most of Redhat's automatic module loading is broken. (E.g., if you have a network device 'bound' to eth0, you will probably need to manually load the module in rc.local at the end, rather than rely on the net scripts to load them for you. Anybody get this autoloading to work?) A different Toshiba laptop of mine also seems to run hotter than under 2.4.x, so be careful if you use this on heat sensitive laptops - ACPI power management is still in testing.

I'm curious what other people's experiences, if any, have been...