This new kernel contains only the new UML patch, and uses the same .config from the previous kernel.

Changelog is here.

"Latest 2.4" now points to this kernel. If you have "Latest 2.4 Series" selected for your kernel in your configuration profile (which is the default), your Linode will use this kernel next time you reboot. "uname -a" will tell you which version you are currently running under.

Thanks!
-Chris

WOO!!!

the /dev/kmem bug is fixed !!

UPGRADE NOW!!!

Sunny Dubey

Just tested it .... and it works!!

once again ...

UPGRADE NOW!!!!

How exactly does this /dev/kmem bug manifest itself?

I haven't had any problems with my Linode, about a month and a half of uptime, is there any reason that I should upgrade the kernel? I'm think that with everything working well, the only reason would be a security problem. Does this patch fix any security problems? *Are* there any known security problems with UML?

The bug is the result of the Linux kmem driver expecting the range of usable memory to start at address 0, but to this isn't the case within UML. In this latest UML patch, Jeff Dike included a fix to the kmem driver (which I'm assuming is not UML specific) to handle UML's special case.

I don't know the exact point when this bug was introduced, I believe it was somewhere during 2.4.21's UML patches.

If a program tried to open /dev/kmem it would result in a kernel panic (termination). Example ways to crash and burn are "strings /dev/kmem" or "less -f /dev/kmem".

It's worth a reboot.

-Chris

I just updated this kernel to fix the bogus reboot on shutdown.

-Chris

What problem does this refer to? I just tested, and a reboot given on the command-line still does a shutdown. Were you talking about a different problem?

_________________
John Schofield
Apple Certified Technical Coordinator
Office Mechanic Consulting
Mac, Unix, and PC Computer Support
www.officemechanic.com

I initially released the kernel without making the "reboot actually performs a poweroff" patch. So, issuing a reboot from your Linode ACTUALLY rebooted.

Even worse, issuing a reboot from the LPM would put in a shutdown job, which issues CAD (control-alt-delete) which your /etc/inittab is set to reboot, and so it would reboot back online while the shutdown job would timeout and perform a sync;sync;halt, and finally a kill. Does that make any sense?

Reboot seems to be the theme of the day

-Chris