Results 1 to 7 of 7

Thread: Understanding YaST, zypper behaviour with respect to multiversion.kernels in /etc/zypp/zypp.conf

  1. #1
    Join Date
    May 2010
    Location
    Space Colony Lagrange Point 22° à, 77° Ƅ, 56° ɤ, 99° ɜ
    Posts
    3,166

    Default Understanding YaST, zypper behaviour with respect to multiversion.kernels in /etc/zypp/zypp.conf

    I want to understanding YaST, zypper behaviour with respect to multiversion.kernels entry in /etc/zypp/zypp.conf

    Is see the entry multiversion.kernels = latest,latest-1,running in my configuration but YaST/zypper is retaining only two versions of kernels.

    Shouldn't my system have three kernels I seem to have only two installed? There were 3 kernels releases for 12.3 if I am correct .

    System config in signature

    kernels retained
    Code:
    $dir /boot/vmlinux*
    -rw-r--r-- 1 root root 5814310 May 25 13:27 /boot/vmlinux-3.7.10-1.11-desktop.gz
    -rw-r--r-- 1 root root 5813683 Jun  7 15:58 /boot/vmlinux-3.7.10-1.16-desktop.gz
    $

    Content of /etc/zypp/zypp.conf
    Code:
    ## Configuration file for software management
    ## /etc/zypp/zypp.conf
    ##
    ## Boolean values are 0 1 yes no on off true false
    
    
    [main]
    
    
    ##
    ## Override the detected architecture
    ##
    ## Valid values:  i586, i686, x86_64, ppc, ppc64, ia64, s390, s390x, ..
    ## Default value: Autodetected
    ##
    ## ** CAUTION: Only set if you know what you're doing !
    ## ** Changing this needs a full refresh (incl. download)
    ## ** of all repository data.
    ##
    # arch = s390
    
    
    ##
    ## Path where the caches are kept.
    ##
    ## Valid values: A directory
    ## Default value: /var/cache/zypp
    ##
    # cachedir = /var/cache/zypp
    
    
    ##
    ## Path where the repo metadata is downloaded and kept.
    ##
    ## Valid values: A directory
    ## Default value: {cachedir}/raw
    ##
    ## Changing this needs a full refresh (incl. download) of all repository data
    ##
    # metadatadir = /var/cache/zypp/raw
    
    
    ##
    ## Path where the repo solv files are created and kept.
    ##
    ## Valid values: A directory
    ## Default value: {cachedir}/solv
    ##
    # solvfilesdir = /var/cache/zypp/solv
    
    
    ##
    ## Path where the repo packages are downloaded and kept.
    ##
    ## Valid values: A directory
    ## Default value: {cachedir}/packages
    ##
    # packagesdir = /var/cache/zypp/packages
    
    
    ##
    ## Path where the configuration files are kept.
    ##
    ## Valid values: A directory
    ## Default value: /etc/zypp
    ##
    # configdir = /etc/zypp
    
    ##
    ## Path where the known repositories .repo files are kept
    ##
    ## Valid values: A directory
    ## Default value: {configdir}/repos.d
    ##
    ## Changing this invalidates all known repositories
    ##
    # reposdir = /etc/zypp/repos.d
    
    ##
    ## Path where the known services .service files are kept
    ##
    ## Valid values: A directory
    ## Default value: {configdir}/services.d
    ##
    ## Changing this invalidates all known services
    ##
    # servicesdir = /etc/zypp/services.d
    
    
    ##
    ## Whether repository urls should be probed when added
    ##
    ## Valid values: boolean
    ## Default value: false
    ##
    ## If true, accessability of repositories is checked immediately (when added)
    ##   (e.g. 'zypper ar' will check immediately)
    ## If false, accessability of repositories is checked when refreshed
    ##   (e.g. 'zypper ar' will delay the check until the next refresh)
    ##
    # repo.add.probe = false
    
    
    ##
    ## Amount of time in minutes that must pass before another refresh.
    ##
    ## Valid values: Integer
    ## Default value: 10
    ##
    ## If you have autorefresh enabled for a repository, it is checked for
    ## up-to-date metadata not more often than every <repo.refresh.delay>
    ## minutes. If an automatic request for refresh comes before <repo.refresh.delay>
    ## minutes passed since the last check, the request is ignored.
    ##
    ## A value of 0 means the repository will always be checked. To get the oposite
    ## effect, disable autorefresh for your repositories.
    ##
    ## This option has no effect for repositories with autorefresh disabled, nor for
    ## user-requested refresh.
    ##
    # repo.refresh.delay = 10
    
    ##
    ## Translated package descriptions to download from repos.
    ##
    ## A list of locales for which translated package descriptions should
    ## be downloaded, in case they are availavble and the repo supports this.
    ## Not all repo formats support downloading specific translations only.
    ##
    ## Valid values:  List of locales like 'en', 'en_US'...
    ## Default value: RequestedLocales
    ##
    ## If data for a specific locale are not available, we try to find some
    ## fallback. Translations for 'en' are always downloaded.
    ##
    # repo.refresh.locales = en, de
    
    ##
    ## Maximum number of concurrent connections to use per transfer
    ##
    ## Valid values: Integer
    ## Default value: 5
    ##
    ## This setting is only used if more than one is possible
    ## Setting it to a reasonable number avoids flooding servers
    ##
    # download.max_concurrent_connections = 5
    
    ##
    ## Sets the minimum download speed (bytes per second)
    ## until the connection is dropped
    ## This can be useful to prevent security attacks on hosts by
    ## providing updates at very low speeds.
    ##
    ## 0 means no limit
    ##
    # download.min_download_speed = 0
    
    ## Maximum download speed (bytes per second)
    ## 0 means no limit
    # download.max_download_speed = 0
    
    ## Number of tries per download which will be
    ## done without user interaction
    ## 0 means no limit (use with caution)
    # download.max_silent_tries = 5
    
    ##
    ## Whether to consider using a .delta.rpm when downloading a package
    ##
    ## Valid values: boolean
    ## Default value: true
    ##
    ## Using a delta rpm will decrease the download size for package updates
    ## since it does not contain all files of the package but only the binary
    ## diff of changed ones. Recreating the rpm package on the local machine
    ## is an expensive operation (memory,CPU). If your network connection is
    ## not too slow, you benefit from disabling .delta.rpm.
    ##
    # download.use_deltarpm = true
    
    ##
    ## Whether to consider using a deltarpm even when rpm is local
    ##
    ## Valid values: boolean
    ## Default value: false
    ##
    ## This option has no effect unless download.use_deltarpm is set true.
    ##
    #  download.use_deltarpm.always = false
    
    ##
    ## Hint which media to prefer when installing packages (download vs. CD).
    ##
    ## Valid values:     download, volatile
    ## Default value:    download
    ##
    ## Note that this just a hint. First of all the solver will choose the 'best'
    ## package according to its repos priority, version and architecture. But if
    ## there is a choice, we will prefer packages from the desired media.
    ##
    ## Packages available locally are always preferred. The question is whether
    ## you prefer packages being downloaded via FTP/HTTP/HTTPS (download), rather
    ## than being prompted to insert a CD/DVD (volatile), in case they are available
    ## on both media.
    ##
    ##   Name             | Priority | URI
    ##   openSUSE-11.1    99       dvd:///
    ##   openSUSE-11.1-Oss    99       http://download.opensuse.org/distribution/11.1/repo/oss
    ##
    ## In the above example 2 repositories with similar content are used. Rather
    ## than raising the priority of one of them to 'prefer' a certain media, you
    ## should use the same priority for both and set download.media_preference
    ## instead.
    ##
    ## download.media_preference = download
    
    ##
    ## Commit download policy to use as default.
    ##
    ##  DownloadOnly,    Just download all packages to the local cache.
    ##            Do not install. Implies a dry-run.
    ##
    ##  DownloadInAdvance,    First download all packages to the local cache.
    ##            Then start to install.
    ##
    ##  DownloadInHeaps,    Similar to DownloadInAdvance, but try to split
    ##            the transaction into heaps, where at the end of
    ##            each heap a consistent system state is reached.
    ##
    ##  DownloadAsNeeded    Alternating download and install. Packages are
    ##            cached just to avid CD/DVD hopping. This is the
    ##            traditional behaviour.
    ##
    ##  <UNSET>        If a value is not set, empty or unknown, we pick
    ##            some sane default.
    ##
    ## commit.downloadMode =
    
    ##
    ## Defining directory which contains vendor description files.
    ##
    ## One file in this directory reflects a group of equivalent vendors. e.G.:
    ## (filename is "nvidia" but could be any other name):
    ## ------------------------- file contains begin -----------------------
    ## [main]
    ##
    ## vendors = nvidia,suse,opensuse
    ##
    ## ------------------------- file contains end -----------------------
    ## Libzypp makes an string comparision (like strncmp, case-insensitive)
    ## whereas the beginning of the strings are compared only.
    ## e.G. vendor "opensuse11.0" is compatible to "openSuSE".
    ##
    ## Valid values: A directory
    ## Default value: {configdir}/vendors.d
    ##
    # vendordir = /etc/zypp/vendors.d
    
    
    ##
    ## Whether required packages are installed ONLY
    ## So recommended packages, language packages and packages which depend
    ## on hardware (modalias) will not be regarded.
    ##
    ## Valid values: boolean
    ## Default value: false
    ##
    # solver.onlyRequires = false
    
    ##
    ## EXPERTS ONLY: Per default the solver will not replace packages of
    ## different vendors, unless you explicitly ask to do so. Setting this
    ## option to TRUE will disable this vendor check (unless the application
    ## explicitly re-enables it). Packages will then be considered based on
    ## repository priority and version only. This may easily damage your system.
    ##
    ## CHANGING THE DEFAULT IS NOT RECOMMENDED.
    ##
    ## Valid values:  boolean
    ## Default value: false
    ##
    # solver.allowVendorChange = false
    
    ##
    ## EXPERTS ONLY: Cleanup when deleting packages. Whether the solver should
    ## per default try to remove packages exclusively required by the ones he's
    ## asked to delete.
    ##
    ## This option should be used on a case by case basis, enabled via
    ## command line options or switches the applications offer. Changing
    ## the global default on a system where unattended actions are performed,
    ## may easily damage your system.
    ##
    ## CHANGING THE DEFAULT IS NOT RECOMMENDED.
    ##
    ## Valid values:  boolean
    ## Default value: false
    ##
    # solver.cleandepsOnRemove = false
    #solver.cleandepsOnRemove = true
    ##
    ## This file contains requirements/conflicts which fulfill the
    ## needs of a running system.
    ## For example the system would be broken if not glibc or kernel is
    ## installed.
    ## So the user will be informed if these packages will be deleted.
    ##
    ## Format: Each line represents one dependency:
    ##         e.g.
    ##         requires:kernel
    ##         requires:glibc
    ## Default value: {configdir}/systemCheck
    ##
    # solver.checkSystemFile = /etc/zypp/systemCheck
    
    ##
    ## When committing a dist upgrade (e.g. 'zypper dup') a solver testcase
    ## is written to /var/log/updateTestcase-<date>. It is needed in bugreports.
    ## This optin returns the number of testcases to keep on the system. Old
    ## cases will be deleted, as new ones are created.
    ##
    ## Use 0 to write no testcase at all, or -1 to keep all testcases.
    ##
    ## Valid values:    Integer
    ## Default value:    2
    ##
    # solver.upgradeTestcasesToKeep = 2
    
    ##
    ## Whether dist upgrade should remove a products dropped packages.
    ##
    ## A new product may suggest a list of old and no longer supported
    ## packages (dropped packages). Performing a dist upgrade the solver
    ## may try to delete them, even if they do not cause any dependency
    ## problem.
    ##
    ## Turning this option off, the solver will not try to remove those
    ## packages unless they actually do cause dependency trouble. You may
    ## do the cleanup manually, or simply leave them installed as long
    ## as you don't need the disk space.
    ##
    ## Valid values:    Boolean
    ## Default value:    true
    ##
    # solver.upgradeRemoveDroppedPackages = true
    
    ##
    ## Packages which can be installed in different versions at the same time.
    ##
    ## Packages are selected either by name, or by provides. In the later case
    ## the string must start with "provides:" immediately followed by the capability.
    ##
    ## Example:
    ##    kernel                - just packages whith name 'kernel'
    ##    provides:multiversion(kernel)   - all packages providing 'multiversion(kernel)'
    ##                      (kenel and kmp packages should do this)
    ## Valid values:
    ##    Comma separated list of packages.
    ##
    ## Default value:
    ##    empty
    ##
    multiversion = provides:multiversion(kernel)
    
    ##
    ## Defining directory which may contain additional multiversion definitions.
    ##
    ## If the directory exists, each file in this directory is scanned, expecting
    ## one valid multiversion list entry per line. Empty lines and lines starting
    ## with '#' are ignored.
    ## ------------------------- [/etc/zypp/multiversion.d/example file begin] -----------------------
    ## # An alternate way to enable kernel packages being
    ## # installed in parallel:
    ##
    ## provides:multiversion(kernel)
    ## ------------------------- [/etc/zypp/multiversion.d/example file end] -----------------------
    ##
    ## Valid values: A directory
    ## Default value: {configdir}/multiversion.d
    ##
    # multiversiondir = /etc/zypp/multiversion.d
    
    ## 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,latest-1,running
    GNOME Version 3.20.2
    openSUSE Leap 42.3 64-bit

    www.vazhavandan.blogspot.com

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,374
    Blog Entries
    3

    Default Re: Understanding YaST, zypper behaviour with respect to multiversion.kernels in /etc/zypp/zypp.conf

    Quote Originally Posted by vazhavandan View Post
    Is see the entry multiversion.kernels = latest,latest-1,running in my configuration but YaST/zypper is retaining only two versions of kernels.
    Two version seems correct in most cases.

    With what you listed, 3.7.10-1.16 would be the latest and 3.7.10-1.11 would be latest-1.

    The cleanup is done on the next boot, when you were probably running 3.7.10-1.16. So that is not an additional kernel to retain.
    openSUSE Leap 15.1; KDE Plasma 5;

  3. #3
    Join Date
    May 2010
    Location
    Space Colony Lagrange Point 22° à, 77° Ƅ, 56° ɤ, 99° ɜ
    Posts
    3,166

    Default Re: Understanding YaST, zypper behaviour with respect to multiversion.kernels in /etc/zypp/zypp.conf

    So most of the time latest==running
    GNOME Version 3.20.2
    openSUSE Leap 42.3 64-bit

    www.vazhavandan.blogspot.com

  4. #4
    Join Date
    Jun 2008
    Location
    Earth - Denmark
    Posts
    10,730

    Default Re: Understanding YaST, zypper behaviour with respect to multiversion.kernelsin /etc/zypp/zypp.conf

    On 07/08/2013 04:56 AM, vazhavandan wrote:
    >
    > _*Shouldn't_my_system_have_three_kernels_I_seem_to_have_only_two_installed?*_
    >
    > ## Default: Do not delete any kernels if multiversion = provides:multiversion(kernel) is set
    > multiversion.kernels = latest,latest-1,running



    not sure, but i think the doc says your conf is specifying to have
    the running kernel plus 1 (1+1=2 as you have)

    if you wanted to keep two old kernels your conf should reflect
    Code:
    multiversion.kernels = latest,latest-2,running
    and then you would have three, because 1+2=3

    and, if you wanted to keep ALL kernels, then just comment out the
    line (and it will revert to the default of delete none), like

    Code:
    ##multiversion.kernels = latest,latest-1,running

    but, read it yourself and see what you think:
    http://doc.opensuse.org/documentatio...ltikernel.html

    --
    dd
    http://tinyurl.com/DD-Caveat

  5. #5
    Join Date
    May 2010
    Location
    Space Colony Lagrange Point 22° à, 77° Ƅ, 56° ɤ, 99° ɜ
    Posts
    3,166

    Default Re: Understanding YaST, zypper behaviour with respect to multiversion.kernelsin /etc/zypp/zypp.conf

    Quote Originally Posted by DenverD View Post
    if you wanted to keep two old kernels your conf should reflect
    Code:
    multiversion.kernels = latest,latest-2,running
    and then you would have three, because 1+2=3
    That may again mean keep 2 after restart

    3 would probably mean,3 entries ,correction 4 entries
    Code:
    multiversion.kernels = latest,latest-1,latest-2,running
    GNOME Version 3.20.2
    openSUSE Leap 42.3 64-bit

    www.vazhavandan.blogspot.com

  6. #6
    Join Date
    Jun 2008
    Location
    Earth - Denmark
    Posts
    10,730

    Default Re: Understanding YaST, zypper behaviour with respect to multiversion.kernelsin /etc/zypp/zypp.conf

    On 07/08/2013 08:16 AM, vazhavandan wrote:
    >
    > That may again mean keep 2 after restart


    right, if you changed the 1 in your conf to 2 then _every_ time a new
    kernel was added and the machine rebooted, then there would be the
    new kernel running and TWO older kernels retained..

    for a total of three kernels installed..

    BUT, immediately after adding the next new kernel, and _before_
    booting (during which the oldest kernel is deleted) the system would
    be running an old kernel and have two other old kernels AND the new
    kernel...for a total of four (until the boot deletes the oldest _and_
    the system boots on the newest)


    > 3 would probably mean,3 entries ,correction 4 entries


    four entires? four kernels, after the boot deleted the oldest.

    --
    dd
    http://tinyurl.com/DD-Caveat

  7. #7
    Join Date
    May 2010
    Location
    Space Colony Lagrange Point 22° à, 77° Ƅ, 56° ɤ, 99° ɜ
    Posts
    3,166

    Default Re: Understanding YaST, zypper behaviour with respect to multiversion.kernelsin /etc/zypp/zypp.conf

    Quote Originally Posted by DenverD View Post
    On 07/08/2013 08:16 AM, vazhavandan wrote:
    >
    > That may again mean keep 2 after restart


    right, if you changed the 1 in your conf to 2 then _every_ time a new
    kernel was added and the machine rebooted, then there would be the
    new kernel running and TWO older kernels retained..

    for a total of three kernels installed..

    BUT, immediately after adding the next new kernel, and _before_
    booting (during which the oldest kernel is deleted) the system would
    be running an old kernel and have two other old kernels AND the new
    kernel...for a total of four (until the boot deletes the oldest _and_
    the system boots on the newest)


    > 3 would probably mean,3 entries ,correction 4 entries


    four entires? four kernels, after the boot deleted the oldest.

    --
    dd
    http://tinyurl.com/DD-Caveat
    multiversion.kernels = latest,latest-1,latest-2,running = 4 entries will keep 3 kernels after restart
    GNOME Version 3.20.2
    openSUSE Leap 42.3 64-bit

    www.vazhavandan.blogspot.com

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •