How to manage Debian kernel updates?

How are security updates and new kernel versions handled on a Debian Linode installation?

Is it possible to have the Debian packaging system manage the kernel version/security updates for a Debian linode installation? How would I go about changing a new installation to allow the Debian packaging system to manage changes to the kernel?

Thanks!

Mark

22 Replies

http://www.linode.com/wiki/index.php/PV-GRUB

If you are not using pv_grub, you have no control over the kernel - it's managed and upgraded by linode (althoigh you do get a choice of the version).

Thanks.

Does Linode patch the kernel as new security updates are generated? What is the process for me to upgrade my kernel to a patched kernel from Linode?

Thanks,

Mark

@mark:

Does Linode patch the kernel as new security updates are generated? What is the process for me to upgrade my kernel to a patched kernel from Linode?
Keep an eye on this page, and look for kernel announcements. Once you see a new kernel that you want to run, switch to it and reboot. Voilà.

If you want your own kernel, you'll have to look at pv_grub as another poster said…and that is a relatively unsupported approach.

It may be relatively unsupported, but it does work great. I've used it for exactly what you're looking for: to run stock Debian Lenny, and get the kernel updates as they're released. Had no problems getting it set up or working.

I read through the pv-grub wiki article. If I understand the article correctly, I can run a stock Debian kernel and do not have to compile my own. Is this correct? Are these the steps I go through:

1. Install a stock Debian kernal

apt-get install linux-image-xen-686

2. create /boot/grub/menu.lst and fill it with

default 0
timeout 5
title Debian GNU/Linux 2.6.26-2-xen-686
root (hd0)
kernel /boot/kernel-2.6.26-2-xen-686 root=/dev/xvda ro

3. Install grub:

apt-get install grub
mkdir -p /boot/grub
update-grub

What am I missing? Do I have to compile my own kernel?

I have separate partitions (i.e. disk images) for /tmp, /home, /var, and /opt - will this be a problem?

Thanks!

Mark

That should be fine.

However, remove any refrences to UUIDs in menu.1st, it seems that pv_grub doesn't like them.

I have to use "root=ca00" in Grub ….

I am having a small problem getting my linode to boot. This is my menu.lst

default 0
timeout 5
title Debian GNU/Linux 2.6.26-2-xen-686 (2.6.26-15)
root (hd0)
kernel /boot/vmlinuz-2.6.26-2-xen-686 root=ca00 ro

I also tried

kernel /boot/vmlinuz-2.6.26-2-xen-686 root=/dev/xvda ro

with the same results - kernel panic:
> Showing last 100 lines from current boot

–---------------------------------------

[ 0.004000] fixmap : 0xf5555000 - 0xf57ff000 (2728 kB)

[ 0.004000] pkmap : 0xf5000000 - 0xf5200000 (2048 kB)

[ 0.004000] vmalloc : 0xd7800000 - 0xf4ffe000 ( 471 MB)

[ 0.004000] lowmem : 0xc0000000 - 0xd7000000 ( 368 MB)

[ 0.004000] .init : 0xc038f000 - 0xc03c0000 ( 196 kB)

[ 0.004000] .data : 0xc02ccfe8 - 0xc03868a0 ( 742 kB)

[ 0.004000] .text : 0xc0100000 - 0xc02ccfe8 (1843 kB)

[ 0.004000] Checking if this processor honours the WP bit even in supervisor mode…Ok.

[ 0.224022] Calibrating delay using timer specific routine.. 5006.56 BogoMIPS (lpj=10013133)

[ 0.224085] Security Framework initialized

[ 0.224095] SELinux: Disabled at boot.

[ 0.224100] Capability LSM initialized

[ 0.224118] Mount-cache hash table entries: 512

[ 0.224232] Initializing cgroup subsys ns

[ 0.224240] Initializing cgroup subsys cpuacct

[ 0.224244] Initializing cgroup subsys devices

[ 0.224270] CPU: L1 I cache: 32K, L1 D cache: 32K

[ 0.224275] CPU: L2 cache: 6144K

[ 0.224287] Checking 'hlt' instruction… OK.

[ 0.224607] SMP alternatives: switching to UP code

[ 0.239536] Brought up 1 CPUs

[ 0.241355] net_namespace: 660 bytes

[ 0.241494] NET: Registered protocol family 16

[ 0.242912] SMP alternatives: switching to SMP code

[ 0.256016] Initializing CPU#1

[ 0.256016] CPU: L1 I cache: 32K, L1 D cache: 32K

[ 0.256016] CPU: L2 cache: 6144K

[ 0.258164] Initializing CPU#2

[ 0.258164] CPU: L1 I cache: 32K, L1 D cache: 32K

[ 0.258164] CPU: L2 cache: 6144K

[ 0.260514] Initializing CPU#3

[ 0.260514] CPU: L2 cache: 6144K

[ 0.260612] 1 2 3 0

[ 0.260673] Brought up 4 CPUs

[ 0.261177] PCI: Fatal: No config space access function found

[ 0.261183] PCI: setting up Xen PCI frontend stub

[ 0.262073] ACPI: Interpreter disabled.

[ 0.262081] Linux Plug and Play Support v0.97 © Adam Belay

[ 0.262113] pnp: PnP ACPI: disabled

[ 0.262343] suspend: event channel 19

[ 0.262639] xen_mem: Initialising balloon driver.

[ 0.266842] PCI: System does not support PCI

[ 0.266847] PCI: System does not support PCI

[ 0.269997] NET: Registered protocol family 2

[ 0.277428] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)

[ 0.277676] TCP established hash table entries: 16384 (order: 5, 131072 bytes)

[ 0.277730] TCP bind hash table entries: 16384 (order: 5, 131072 bytes)

[ 0.277780] TCP: Hash tables configured (established 16384 bind 16384)

[ 0.277785] TCP reno registered

[ 0.277894] NET: Registered protocol family 1

[ 0.278450] platform rtc_cmos: registered platform RTC device (no PNP device found)

[ 0.280163] audit: initializing netlink socket (disabled)

[ 0.280192] type=2000 audit(1241617070.387:1): initialized

[ 0.281117] VFS: Disk quotas dquot_6.5.1

[ 0.281151] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)

[ 0.281183] msgmni has been set to 720

[ 0.281361] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)

[ 0.281368] io scheduler noop registered

[ 0.281372] io scheduler anticipatory registered

[ 0.281375] io scheduler deadline registered

[ 0.281405] io scheduler cfq registered (default)

[ 0.285445] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled

[ 0.289403] brd: module loaded

[ 0.289403] Xen virtual console successfully installed as hvc0

[ 0.289403] Event-channel device installed.

[ 0.355513] netfront: Initialising virtual ethernet driver.

[ 0.356146] xen-vbd: registered block device major 202

[ 0.356169] blkfront: xvda: barriers enabled

[ 0.356581] xvda: unknown partition table

[ 0.361060] blkfront: xvdb: barriers enabled

[ 0.361511] xvdb: unknown partition table

[ 0.391305] blkfront: xvdc: barriers enabled

[ 0.391305] xvdc: unknown partition table

[ 0.410345] blkfront: xvdd: barriers enabled

[ 0.410345] xvdd: unknown partition table

[ 0.421659] blkfront: xvde: barriers enabled

[ 0.421659] xvde: unknown partition table

[ 0.476417] blkfront: xvdf: barriers enabled

[ 0.476644] xvdf: unknown partition table

[ 0.495036] PNP: No PS/2 controller found. Probing ports directly.

[ 0.495036] i8042.c: No controller found.

[ 0.495036] mice: PS/2 mouse device common for all mice

[ 0.495036] rtccmos rtccmos: rtc core: registered rtc_cmos as rtc0

[ 0.495036] No iBFT detected.

[ 0.495036] TCP cubic registered

[ 0.495036] NET: Registered protocol family 17

[ 0.495036] Using IPI No-Shortcut mode

[ 0.495036] registered taskstats version 1

[ 0.592634] XENBUS: Device with no driver: device/console/0

[ 0.592645] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

[ 0.592704] List of all partitions:

[ 0.592711] ca00 1024000 xvda driver: vbd

[ 0.592716] ca10 1024000 xvdb driver: vbd

[ 0.592721] ca20 2048000 xvdc driver: vbd

[ 0.596008] ca30 2048000 xvdd driver: vbd

[ 0.596013] ca40 2048000 xvde driver: vbd

[ 0.596018] ca50 524288 xvdf driver: vbd

[ 0.596022] No filesystem could mount root, tried:

[ 0.596028] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(202,0)

[linode20747@fremont86 lish]#
I would appreciate any suggestions for getting my dead linode to boot using the debian xen kernel as described in the PV-GRUB instructions (http://www.linode.com/wiki/index.php/PV-GRUB).

Thanks!

Mark

Tried

kernel /boot/vmlinuz-2.6.26-2-xen-686 root=/dev/ca00 ro

I had the same problem a while ago, changing root to "/dev/ca00" or "ca00" solved it.

@mark:

I am having a small problem getting my linode to boot. This is my menu.lst

default 0
timeout 5
title Debian GNU/Linux 2.6.26-2-xen-686 (2.6.26-15)
root (hd0)
kernel /boot/vmlinuz-2.6.26-2-xen-686 root=ca00 ro

I also tried

kernel /boot/vmlinuz-2.6.26-2-xen-686 root=/dev/xvda ro

with the same results - kernel panic:
Is your root filesystem on xvda, or did you make an image that just holds your kernel on xvda?

Yes, my root file system on xdva. I alos have separate partitions/disk images for /tmp, /opt, /var, and /home. Everything worked before I tried to setup the kernel as per this post - i.e. stock debian image from linode booted and mounted my separate partitions/disk images just fine.

I have tried root=/dev/xvda, root=ca00, root=/dev/ca00 in menu.lst and I get the same result at boot - the kernal panic described above.

I don't use Debian, so I'm just guessing here, but does the stock Debian kernel need an initrd to mount your root filesystem? The linode kernels have all the filesystems built-in, but maybe debian has them built as modules?

Stever,

I don't know the answer to your question. The Linode wiki article http://www.linode.com/wiki/index.php/PV-GRUB does not mention anything about that. It says the stock Debian xen kernal should work out of the box, with a few mods to menu.lst and grub.

I am still stuck with a DOA linode.

any updates? I seem to be stuck in a similar situation, except perhaps that my knowledge is very limited when it comes to xen and kernels…

I'm running Debian 5 lenny on linode and things are working great, but I just did an apt-get update, apt-get upgrade, and all of a sudden it seemed to have upgraded my kernel to 2.6.26-1-686 and gave me a message about initrd

"You are attempting to install an initrd kernel image… this will not work unless the boot loader is configured to use an initrd…"

I OK'd it (not being too sure what to do otherwise)

apt-get upgrade ended with some note about initrd:

"update-initramfs: Generating /boot/initrd.img-2.6.26-1-686"

Now I'm scared to try to boot my machine. Will I get a kernel panic?? Will it upgrade and keep working?? The machine is running fine now, but I'm guessing nothing will happen until a reboot.

This is a production host, and I'd be in a bit of mess if it goes down for too long. I emailed support, but haven't heard back yet.

Any ideas / insights will be more than welcome. I'm happy to do some reading and learn more, but I honestly don't know where to even start.

@yoav:

Are you running pv-grub or a Linode kernel? If it's the latter, the host completely ignores any kernels installed on your node, so it doesn't matter what Debian did.

I was reading through the PV_Grub link and got lost at the beginning…

On my linode configuration profile, the kernel is listed as 'Latest 2.6 Series (2.6.18.8-linode16)' so I guess it means I'm not using pv-grub.

So if I boot my virtual host now it won't boot into something else or try to replace the kernel or some kernel-panic like mark described??

That is certainly a relief. No plans on rebooting soon, but I hope there will be no surprises when I do.

Thanks mnordhoff!!

I finally solved the problem of the kernel panic. My menu.lst file was not correct. Here is what I am using - YMMV depending on your setup:

# Manual entries from Linode Wiki
default 0
timeout 5

### BEGIN AUTOMAGIC KERNELS LIST
## lines between the AUTOMAGIC KERNELS LIST markers will be modified
## by the debian update-grub script except for the default options below

## DO NOT UNCOMMENT THEM, Just edit them to your needs

## ## Start Default Options ##
## default kernel options
## default kernel options for automagic boot options
## If you want special options for specific kernels use kopt_x_y_z
## where x.y.z is kernel version. Minor versions can be omitted.
## e.g. kopt=root=/dev/hda1 ro
##      kopt_2_6_8=root=/dev/hdc1 ro
##      kopt_2_6_8_2_686=root=/dev/hdc2 ro
# kopt=root=ca00 ro

## default grub root device
## e.g. groot=(hd0,0)
# groot=(hd0)

## should update-grub create alternative automagic boot options
## e.g. alternative=true
##      alternative=false
# alternative=true

## should update-grub lock alternative automagic boot options
## e.g. lockalternative=true
##      lockalternative=false
# lockalternative=false

## additional options to use with the default boot option, but not with the
## alternatives
## e.g. defoptions=vga=791 resume=/dev/hda5
# defoptions=

## should update-grub lock old automagic boot options
## e.g. lockold=false
##      lockold=true
# lockold=false

## Xen hypervisor options to use with the default Xen boot option
# xenhopt=

## Xen Linux kernel options to use with the default Xen boot option
# xenkopt=console=tty0

## altoption boot targets option
## multiple altoptions lines are allowed
## e.g. altoptions=(extra menu suffix) extra boot options
##      altoptions=(single-user) single
# altoptions=(single-user mode) single

## controls how many kernels should be put into the menu.lst
## only counts the first occurence of a kernel, not the
## alternative kernel options
## e.g. howmany=all
##      howmany=7
# howmany=all

## should update-grub create memtest86 boot option
## e.g. memtest86=true
##      memtest86=false
# memtest86=true

## should update-grub adjust the value of the default booted system
## can be true or false
# updatedefaultentry=false

## should update-grub add savedefault to the default options
## can be true or false
# savedefault=false

## ## End Default Options ##

title           Debian GNU/Linux, kernel 2.6.26-2-xen-686 (2.6.26-15)
root            (hd0)
kernel          /boot/vmlinuz-2.6.26-2-xen-686 root=ca00 ro 
initrd          /boot/initrd.img-2.6.26-2-xen-686

title           Debian GNU/Linux, kernel 2.6.26-2-xen-686 (single-user mode)
root            (hd0)
kernel          /boot/vmlinuz-2.6.26-2-xen-686 root=ca00 ro single
initrd          /boot/initrd.img-2.6.26-2-xen-686

### END DEBIAN AUTOMAGIC KERNELS LIST

Most of the lines were created by update-grub command. I had to remove the root=UUID= with root=ca00 in all places where it occured.

Thank-you everyone for your help!

Mark

@mark:

Most of the lines were created by update-grub command. I had to remove the root=UUID= with root=ca00 in all places where it occured.
Didn't I specifically state that UUIDs should be removed, and that "root=ca00" should be used instead, a while ago? People, READ!
@saman007uk:

That should be fine.

However, remove any refrences to UUIDs in menu.1st, it seems that pv_grub doesn't like them.

I have to use "root=ca00" in Grub ….

saman007uk: Yes, I did read your posts, and followed them. If you had READ my posts, you would have noticed the following:
* I tried both root=ca00 and root=/dev/ca00, as suggested by another poster, and still encountered a kernel panic. * I posted the contents of my menu.lst file, and there were no UUIDs in that file. * My menu.lst file was missing several settings that have to be there (I assume, since it now works) that were inserted by update-grub. If someone had seen that, my problem would have been solved many days ago.
The point of my last post was to recap what finally worked for future readers who may have the same issues as I did. When one runs update-grub, it generates UUIDs in the menu.lst file, so I wanted to make sure any future readers caught that and fixed it.

Thank you for your help.

Mark

No need to install grub on the debian system, our boot loader is pv-grub on the linode host. The only thing you need is a correct menu.lst

A typical menu.lst would be :

default 0
timeout 5

title Debian (xen kernel)
root (hd0)
kernel /boot/vmlinux-2.6.26-xxxx root=/dev/xvda ro
initrd /boot/initrd.img-xxxx

The only thing you had missing at first was the initrd part.

Glad you got it working. I love being able to use pv-grub in such a painless way. Linode really rocks :D

tin0x3cc, thanks for the clarification. I was wondering what lines in my menu.lst were really necessary, but I have not had the time to remove them one at a time to see where my configuration breaks.

An interesting point about grub. I started this journey of discovery with Linux kernels, grub, and menu.lst because I wanted to get updated kernels and kernel security patches using Debian apt. I see now that I still may not need grub, but if my assumptions are correct, it will make updating the system easier, since all I will have to do is apt-get install a new kernel and run update-grub to boot with the new kernel.

If I did not use grub, I would have to edit by hand menu.lst each time I installed a new kernel. If I want to boot to a previous kernel, I just log in using Lish, run boot 1, and then select the previous version from the grub menu.

Is there an easier way to accomplish what I want?

Thanks!

Mark

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct