Home Home > 2011 > 07 > 14 > Improved Kernel Package Retention in 12.1
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Improved Kernel Package Retention in 12.1

July 14th, 2011 by

A long awaited feature of the openSUSE update stack is finally here!
Since some time, it has been possible to tell libzypp to not delete old
kernels on update:

multiversion = provides:multiversion(kernel)

in /etc/zypp/zypp.conf. That way, you don’t have to worry that a
brand new -rc kernel from Factory makes your system unbootable. This however
solves one problem and brings another one – you have to manually delete the
old kernel so that your /boot partition does not fill up. openSUSE 12.1 will
provide a solution to this, you will be able to tell what kernels you want to
keep after an update, other kernels will be deleted. The configuration is the
same file, /etc/zypp/zypp.conf:

## Comma separated list of kernel packages to keep installed in parallel, if the
## above multiversion variable is set. Packages can be specified as
## 2.6.32.12-0.7 - Exact version to keep
## latest        - Keep kernel with the highest version number
## latest-N      - Keep kernel with the Nth highest version number
## running       - Keep the running kernel
## oldest        - Keep kernel with the lowest version number (the GA kernel)
## oldest+N      - Keep kernel with the Nth lowest version number
##
## Default: Do not delete any kernels if multiversion = provides:multiversion(kernel) is set
multiversion.kernels = latest,running

If you configure this and the above multiversion variable, then after each
kernel update, during a subsequent reboot, a script will compare the list of
installed kernels with the multiversion.kernels setting and delete those that
are no longer needed. Examples:

  • Keep the latest kernel and the running one if it differs. This is similar to
    no enabling the multiversion feature at all, except that the old kernel is
    removed after reboot and not immediatelly after installation. BTW, you
    probably always want to include “running”:

    multiversion.kernels = latest,running
  • Keep last two kernels and the running one:
    multiversion.kernels = latest,latest-1,running
  • Keep the latest kernel, the running and a my test kernel with a fancy
    patch:

    multiversion.kernels = latest,running,3.0.rc7-test

If you want to try it, it’s all in Factory already. Check if these packages are
recent enough and uncomment the two variables in zypp.conf:

$ rpm -q --changelog kernel-desktop mkinitrd libzypp | grep -B2 312018
* Fri Jun 17 2011 mmarek@suse.cz
- rpm/post.sh: Touch /boot/do_purge_kernels on package install
    (fate#312018).
--
- Add purge-kernels script to automatically delete old kernel packages
  on boot, based on configuration in /etc/zypp/zypp.conf, variable
  multiversion_kernels (fate#312018).
--
* Tue Jun 21 2011 dmacvicar@suse.de
- Add configuration template for automatic kernel
  purge (feature#312018) to zypp.conf
$ grep ^multiversion /etc/zypp/zypp.conf
multiversion = provides:multiversion(kernel)
multiversion.kernels = latest,running

Happy updating!

Both comments and pings are currently closed.

10 Responses to “Improved Kernel Package Retention in 12.1”

  1. W. MacKenzie

    but, but, but…it’s so fun rebooting off the rescue CD and re-creating a working kernel from scratch….;)

  2. Maico

    Good job!

    It will make my life more simple.

  3. T Guruswamy

    This is an awesome feature, great job everyone 🙂

  4. Bruno Friedmann

    Installed today, we will see if during the -rc7 process that will be handle smoothly.

    I’ve just a doubt, when we have several flavors installed (like for testing factory : a -desktop & normal ).

  5. Bruno Friedmann

    Hi Michal, you should tell us, that in fact if we want to stop that functionnality for any (bad?) reasons we can simply as
    ckconfig purge-kernels off

    That’s really cool!
    From what I’ve seen the first time I reboot with it installed it takes 10 secondes and throw a message that it didn’t know about lastest-1 (normal as not installed, but that what I’ve configured)

  6. Michal Marek

    Right, “latest-1” not available is not unexpected. I’ll change the script to only complain if “latest”, “oldest” or “running” cannot be matched to a kernel package. Thanks for testing.

  7. Bruno Friedmann

    Due to some hardware trouble, I’ve been requested to add kernel:HEAD

    Now I get this output
    /sbin/purge-kernels
    /sbin/purge-kernels: Running kernel 3.0.0-rc7-3-x86_64/desktop not installed.
    NOT removing any packages for flavor x86_64/desktop.
    /sbin/purge-kernels: Nothing to do.

    for those installed
    zypper se -si kernel
    Loading repository data…
    Reading installed packages…

    S | Name | Type | Version | Arch | Repository
    –+——————————–+———+————-+——–+——————–
    i | devel_kernel | pattern | 12.1-8.1 | x86_64 | factory-oss
    i | devel_kernel | pattern | 12.1-8.1 | i586 | factory-oss
    i | kernel-default-devel | package | 3.0.rc7-3.1 | x86_64 | factory-kernel-head
    i | kernel-default-devel | package | 3.0.rc6-2.2 | x86_64 | factory-oss
    i | kernel-desktop | package | 3.0.rc7-3.1 | x86_64 | factory-kernel-head
    i | kernel-desktop | package | 3.0.rc6-2.2 | x86_64 | factory-oss
    i | kernel-desktop-base | package | 3.0.rc7-3.1 | x86_64 | factory-kernel-head
    i | kernel-desktop-base | package | 3.0.rc6-2.2 | x86_64 | factory-oss
    i | kernel-desktop-base-debuginfo | package | 3.0.rc7-3.1 | x86_64 | factory-kernel-head
    i | kernel-desktop-debuginfo | package | 3.0.rc7-3.1 | x86_64 | factory-kernel-head
    i | kernel-desktop-devel | package | 3.0.rc7-3.1 | x86_64 | factory-kernel-head
    i | kernel-desktop-devel | package | 3.0.rc6-2.2 | x86_64 | factory-oss
    i | kernel-desktop-devel-debuginfo | package | 3.0.rc7-3.1 | x86_64 | factory-kernel-head
    i | kernel-devel | package | 3.0.rc7-3.1 | noarch | factory-kernel-head
    i | kernel-devel | package | 3.0.rc6-2.2 | noarch | factory-oss
    i | kernel-firmware | package | 2.6.38-2.2 | noarch | factory-oss
    i | kernel-source | package | 3.0.rc7-3.1 | noarch | factory-kernel-head
    i | kernel-source | package | 3.0.rc6-2.2 | noarch | factory-oss
    i | kernel-syms | package | 3.0.rc7-3.1 | x86_64 | factory-kernel-head
    i | kernel-syms | package | 3.0.rc6-2.2 | x86_64 | factory-oss
    i | kernel-xen-devel | package | 3.0.rc7-3.1 | x86_64 | factory-kernel-head
    i | kernel-xen-devel | package | 3.0.rc6-2.2 | x86_64 | factory-oss
    i | kerneloops | package | 0.12-45.1 | x86_64 | factory-oss
    i | kerneloops-applet | package | 0.12-45.1 | x86_64 | factory-oss
    i | kerneloops-applet-debuginfo | package | 0.12-45.1 | x86_64 | factory-debug
    i | kerneloops-debuginfo | package | 0.12-45.1 | x86_64 | factory-debug
    i | nfs-kernel-server | package | 1.2.3-26.2 | x86_64 | factory-oss
    i | patterns-openSUSE-devel_kernel | package | 12.1-8.1 | x86_64 | factory-oss

    Is the message running -destkop not installed is expected ?
    Seems confusing for me at least

  8. Zygnoliog

    Sorry, but all this is extremely late in coming. On a Suse 11.something I installed sometime on somebody’s machine, I finally just disabled updates altogether. Why?

    The update process rendered the system effectively unbootable if the user logged out / shut down just after the update of the kernel modules — but before the update of the kernel proper. Thus, no modules during next boot.

    Believe it or not, this happened twice. And that was the end of me using or recommending Suse.

  9. Freigeist

    Hello Michal,

    the script is working fine, removing older kernels as intended, except for two packages:

    The kernel-source-# and the kernel-devel-# packages are left on the disk and
    still have to be removed manually.