| Author |
Message |
caker
Joined: 15 Apr 2003
Posts: 2386
Location: Galloway, NJ
|
| Posted: Mon Nov 10, 2003 7:46 pm Post subject: Kernel 2.4.22-linode12-6um |
|
|
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 |
|
| Back to top |
|
sunny
Joined: 27 Jul 2003
Posts: 42
Location: New York, NY
|
| Posted: Mon Nov 10, 2003 8:22 pm Post subject: |
|
|
WOO!!!
the /dev/kmem bug is fixed !!
UPGRADE NOW!!!
Sunny Dubey |
|
| Back to top |
|
sunny
Joined: 27 Jul 2003
Posts: 42
Location: New York, NY
|
| Posted: Mon Nov 10, 2003 11:03 pm Post subject: |
|
|
Just tested it .... and it works!!
once again ...
UPGRADE NOW!!!! |
|
| Back to top |
|
bji
Joined: 27 Aug 2003
Posts: 182
|
| Posted: Mon Nov 10, 2003 11:25 pm Post subject: |
|
|
sunny wrote: WOO!!!
the /dev/kmem bug is fixed !!
UPGRADE NOW!!!
Sunny Dubey
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? |
|
| Back to top |
|
caker
Joined: 15 Apr 2003
Posts: 2386
Location: Galloway, NJ
|
| Posted: Tue Nov 11, 2003 12:16 am Post subject: |
|
|
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 |
|
| Back to top |
|
caker
Joined: 15 Apr 2003
Posts: 2386
Location: Galloway, NJ
|
| Posted: Tue Nov 11, 2003 2:00 pm Post subject: |
|
|
I just updated this kernel to fix the bogus reboot on shutdown.
-Chris |
|
| Back to top |
|
schof
Joined: 18 Sep 2003
Posts: 46
Location: Los Angeles
|
| Posted: Tue Nov 11, 2003 3:39 pm Post subject: |
|
|
caker wrote: 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? |
|
| Back to top |
|
caker
Joined: 15 Apr 2003
Posts: 2386
Location: Galloway, NJ
|
| Posted: Tue Nov 11, 2003 3:49 pm Post subject: |
|
|
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 |
|
| Back to top |
|
| |
