Kernel in Bootliste / grub ändern

[klaus-dieter]

Hallo,

nach dem letzten Kernel update bootet mein System nicht mehr. Ich habe dann über die advanced options den alten Kernel gebootet und im Yast dann gesagt dass dieser der neue Default sein soll. Jetzt bootet das System wieder.

Jetzt werden ja immer nur der neuste und der letzte Kernel aufgehoben. Wenn jetzt das nächste Kernel update rein kommt dann würde mein funktionierender Kernel ja nicht mehr vorhanden sein. Wenn das neue Update jetzt auch nicht funktioniert, was dann? Wie kann ich dem System sagen dass ich diesen Kernel behalten will?

a) Kann ich die Auswahl Liste von 2 auf 3 Einträge erhöhen?
b) Kann ich im File System irgendwas umkopieren dass der der nicht funktionierende Kernel mit dem alten überschrieben wird?
c) Sonstige / bessere Optionen?

Danke!

 

[Sauerland]

Du kannst aber den defekten kernel löschen, der ist "zurückgeholt" und wird beim Update nicht mehr installiert.

a: ja
Bei mir bleiben 3 Kernel installiert:

grep 'multiversion.kernels =' /etc/zypp/zypp.conf
multiversion.kernels = latest,latest-1,latest-2,running

b: nicht nötig
c: Löschen bitte nur über den Reiter Versionen.

 

[tomm.fa]

Man könnte auch eine bestimmte Version des Kernel ewig mit herumschleppen. Zum Beispiel, wenn du 5.14.21-150400.24.46.1 mit in die zypp.conf einträgst. Was ist denn auf dein verwendetes System eingetragen?
Du könntest die Ausgabe von

cat /etc/zypp/zypp.conf | grep -Ei -B4 -A7 "Keep kernel"

hier vorführen.

 

[klaus-dieter]

Hallo,

danke soweit, meine zypp.conf ist unten, habe dort per text editor latest-2 aufgenommen. Das sollte mir reichen. Einfach per Texteditor ändern reicht aus nehme ich.

@Sauerland Das mit dem Reiter Versionen habe ich nicht verstanden. In Yast --> Bootloader gibt es keinen Reiter mit Versionen. Du meinst in der Software Verwaltung nehme ich an.

Danke und Gruß,
D.

## Configuration file for software management
## /etc/zypp/zypp.conf
##
## Boolean values are 0 1 yes no on off true false


[main]

## Schnipp viele Kommentare gelöscht

##
## EXPERTS ONLY: TUNE DISTRIBUTION UPGRADE (DUP)
## Set whether to allow changing the packages vendor upon DUP. If you
## are following a continuous distribution like Tumbleweed or Factory
## where you use 'zypper dup --no-allow-vendor-change' quite frequently,
## you may indeed benefit from disabling the VendorChange. Packages from
## OBS repos will then be kept rather than being overwritten by Tumbleweeds
## version.
##
## Valid values:  boolean
## Default value: true
##
solver.dupAllowVendorChange = false

##
## EXPERTS ONLY: Cleanup when deleting packages. Whether the solver should
## per default try to remove packages exclusively required by the ones it'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

##
## 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

##
## This directory can contain files that contain requirements/conflicts
## which fulfill the needs of a running system (see checkSystemFile).
##
## Files are read in alphabetical order.
##
## Default value: {configdir}/systemCheck.d
##
# solver.checkSystemFileDir = /etc/zypp/systemCheck.d

##
## 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 option 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
##
## Note: This entry is not evaluated by libzypp, but by the
##       purge-kernels service (via /sbin/purge-kernels).
##
## Default: Do not delete any kernels if multiversion = provides:multiversion(kernel) is set
multiversion.kernels = latest,latest-1,latest-2,running

##
## Path to locks file. If not exist then is create.
## In this file is saved also UI locks.
##
## valid value: path to file or place where file can be created
## default value: {configdir}/locks
##
# locksfile.path = /etc/zypp/locks

##
## Whether to apply locks in locks file after zypp start.
##
## Valid values: boolean
## Default value: true
##
# locksfile.apply = true

##
## Where update items are stored
## (example: scripts, messages)
##
## Valid values: path to directory
## Default value: /var/adm
##
# update.datadir = /var/adm

##
## Where update messages are stored
##
## Valid values: path to directory
## Default value: {update.datadir}/update-messages
##
# update.messagesdir = /var/adm/update-messages

##
## Where update scripts are stored
##
## Valid values: path to directory
## Default value: {update.datadir}/update-scripts
##
# update.scriptsdir = /var/adm/update-scripts

##
## Command to be invoked to send update messages.
##
## Packages may leave an update message file in {update.messagesdir}.
## At the end of each commit, zypp collects those messages and may send
## a notification to the user.
##
## zypp will prepare the update messages according to the selected
## content format and pipe the content to the command.
##
## Format:
##     single - For each update message invoke the command and send
##              the message.
##     none   - For each update message invoke the command but don't
##              use a pipe to send any data. You probably want to pass
##              the message file on the commandline using %P (see
##              Substitutions).
##     digest - Single invocation of the command, sending the path
##              names of all update message. One per line.
##     bulk   - Single invocation of the command, sending the
##              concatenated content of all update messages, separated
##              by Ctrl-L.
##
## Substitutions:
##     %p     - package identification (name-version-release.arch)
##     %P     - full path to the update message file
##
## Valid values: The value is specified as "format | command".
##               An empty value will turn off any notification.
##
## Examples:     single | mail -s 'Update message from %p' root
##               none   | my-send-script -f %P
##
## Default value: <empty>
##
# update.messages.notify =

##
## Options for package installation: excludedocs
##
## Don't install any files which are marked as documentation.
##
## Valid values:  boolean
## Default value: no
##
# rpm.install.excludedocs = no

##
## Location of history log file.
##
## The history log is described at
## http://en.opensuse.org/Libzypp/Package_History
##
## Valid values: absolute path to a file
## Default value: /var/log/zypp/history
##
# history.logfile = /var/log/zypp/history

##
## Global credentials directory path.
##
## If a URL contains ?credentials=<filename> parameter, the credentials will
## be stored and looked for in a file named <filename> in this directory.
##
## Valid values: absolute path to a directory
## Default value: /etc/zypp/credentials.d
##
# credentials.global.dir = /etc/zypp/credentials.d

##
## Global credentials catalog file path.
##
## This file contains a catalog of all known user credentials which were
## not stored via the ?credentials=<filename> URL parameter, i.e. passed
## in URL as username:password component, or entered by user in
## an authentication dialog.
##
## Valid values: absolute path to a file
## Default value: /etc/zypp/credentials.cat
##
# credentials.global.file = /etc/zypp/credentials.cat

 

[Sauerland]

Du meinst in der Software Verwaltung nehme ich an.

Ja.