Debian Kernel Images

[Hero Zzyzzx]

Correct me if I'm crazy, but:

Wouldn't it save ServerBeach (and its users) a lot of support time if they installed a debian kernel image from the stable branch like kernel-image-2.4.18-1-k7 ?

Then these grub configuration problems would disappear and the recent local exploits would get closed on the next "apt-get upgrade" and reboot.

I don't know- I've tried a couple of times to get my box using the stable kernel image above and it's a real pain to debug boot problems from afar.

I'll submit a ticket, I guess.

Just seems like getting all the boxes running a standard kernel-image would save everyone time. The tweakers can still tweak, but I'd rather trust the debian project to manage my kernel images for me.

It doesn't make sense to me to let the debian project manage security updates for everything EXCEPT the kernel (unless, of course, the stable kernel really doesn't suit your needs). Why use debian then?

Is anyone running kernel-image-2.4.18-1-k7? If so, can you post your menu.lst here?

[knightfoo]

No one ever said that you had to use the ServerBeach kernel or depend on ServerBeach for kernel security updates. You can install the Debian kernel image as soon as you get your server, or wait until the next security update is released. The kernel we install is nearly identical to the default Debian kernel .. the only reason we don't use the default Debian kernel package is because of a bug in one of the post-install scripts that does not play nice with our installation system.

I've installed the kernel-image-2.4.18-1-k7 package on several ServerBeach servers. Here is the /boot/grub/menu.lst from one server:

timeout 10
default 0
splashimage (hd0,0)/grub/splash.xpm.gz

title Debian GNU/Linux (2.4.18-1-k7)
root(hd0,0)
kernel /vmlinuz-2.4.18-1-k7 root=/dev/hda3 devfs=mount
initrd /initrd.img-2.4.18-1-k7

title Debian GNU/Linux (2.4.23)
root(hd0,0)
kernel /vmlinuz-2.4.23 root=/dev/hda3 devfs=mount

Of course you should always leave the old kernel image and configuration in place just in case the new one doesn't work.

-knightfoo

[Hero Zzyzzx]

No luck. The machine wouldn't reboot via ssh or via the "rapid reboot" thingy.

This is my current menu.lst:

#/boot/grub/menu.lst

timeout 5
default 1
fallback 1
splashimage (hd0,0)/grub/splash.xpm.gz

title GNU/Linux (2.4.18-1-k7)
root(hd0,0)
kernel /vmlinuz-2.4.18-1-k7 root=/dev/hda3 ro devfs=mount
initrd /initrd.img-2.4.18-1-k7

title GNU/Linux (2.4.22)
root(hd0,0)
kernel /vmlinuz-2.4.22 root=/dev/hda3 ro devfs=mount


I've already installed the correct kernel-image referenced by entry 0. As far as I can tell, this *should* work. The initrd and kernel images exist.

Note: I changed the default to 0 and rebooted, it failed to fallback to 1 (the 2.4.22) image and to boot entry 0.

The machine essentially locked up and sat there doing I don't know what.

I've submitted a ticket (#68309) to have the default kernel changed, one of your techs changed the menu.lst default to 1 to get my machine to boot to the custom serverbeach 2.4.22 kernel.

Frustrating! It should work, but I can't get the darn thing to boot the kernel-image I want. /var/log/syslog and messages are no help.

Thought you'd like to know. . .

[Hero Zzyzzx]

I AM VINDICATED!!!! I'm not a blathering idiot!

menu.lst was fine- it turns out the RAM in the box was buggy, and booting to 2.4.18-1 would cause it to kernel panic, locking the box up completely.

One of the helpful techs at ServerBeach gave me the specifics of the kernel panic from the console, I googled and figured out it was probably a hardware issue, and, believe it or not, I've seen this before: linux machines that REFUSE to boot to an alternate kernel version because of buggy RAM.

Damn. It took a while, but I'm finally on a debian managed kernel-image, which was my ultimate goal.

Recompiling kernels, especially on boxes where it's not necessary, annoys me.

[cyb0rg]

I think there is a better way to fix this in the future.

When new kernel exploits come out serverbeach will need to create new kernel images for the new boxes the are deploying. Why not make those .deb's available to their customers?

They have to make and test them already, so there is no extra work to be done by them. Just put them up on a website somewhere that serverbeach customers could download from!

[Hero Zzyzzx]

Or even better, create a serverbeach apt repository that has the compiled "server beach" kernels that folks can add to their apt-sources.lst

Myself, I'd rather just use a debian-stable kernel-image.

This wouldn't have really solved my problem, but a serverbeach apt repository would still save everyone time, ESPECIALLY the serverbeach support team.

[cyb0rg]

I agree, that would be awesome. It would take a little more work on their part , however.

Now the question, how do we get them to implement it?

[Hero Zzyzzx]

Seems like a no-brainer to me. . . Let's see what Knightfoo thinks, though I don't know how high up the totem pole he is. NOT doing it is penny-wise, pound foolish, you know?

[knightfoo]

Well, considering the fact that the kernel-image package is the only Debian package that ServerBeach installs, the repository wouldn't be very large. :) The Debian installer no longer uses the custom ServerBeach kernel-image package. Those who have the custom ServerBeach kernel-image package installed can simply upgrade to the official Debian kernel-image packages or build their own kernel image.

-knightfoo

[cyb0rg]

Yea, its little things like this that can really distinguish a company from its competitors. Kernel upgrades are IMO the worst part about remote unmanaged hosting solutions like this.

If ServerBeach were to help mitigate that problem im sure it would make their customers very happy and probably be quite good for future business.

Edit: Doh, beat me to the post knightfoo

[Hero Zzyzzx]

Originally posted by knightfoo
The Debian installer no longer uses the custom ServerBeach kernel-image package.
-knightfoo

So you're saying if I get another server at some point it will have a default debian stable kernel-image on it? If that's so, then the problem is solved (for the new folks).

[knightfoo]

Yes, new Debian servers (as of a couple weeks ago) will have the latest kernel-image package available for Debian 3.0 (Woody) installed.

-knightfoo

[cyb0rg]

I just successfully downgraded to debian offical 2.4.18-1-k7 using the steps above

[Hero Zzyzzx]

Yeah, my problem wasn't that it's difficult to install new kernels or configure grub, it's that my box had faulty RAM in it. Glad to hear of your success!