How to get Leap 15.6 grub advanced options to show the specific kernels?

Folks:

Posting a new thread to see if I could get some hints on how to get the grub menu to show specific kernels to choose from in Leap 15.6?

In TW when I select “advanced options” I can clearly see now three different kernels listed, so I know which one I want to boot.

However, in Leap 15.6, where I continue to have a problem with reviving from suspend, when I select Leap 15.6 advanced options it shows me ten lines, all saying the same thing, not showing specific kernels. When I choose some of the lines it doesn’t boot, but I can’t tell what those lines are for?

I have regular default kernels && backport “lp” kernels installed, as historically this “non-revival from suspend” problem continues to show up every few kernel upgrades. In TW I found that rolling back to 6.12.6.1 restores the revival function, but the newer 6.12.8 & 6.12.9??? do not. I might have the 6.12.10.lp kernel installed in Leap, but that did not fix the problem. I’d like to try to roll Leap back in kernel time, but with advanced options showing each line identical, something like “leap 15.6” I wouldn’t be able to know how to get to the kernel I want to test.

Any way to get grub to see or list the specific kernels in Leap 15.6??

Hm, strange. A Leap 15.6 (no snapper config) shows the kernel versions by default.

2 Likes

Hmm . . . don’t think I have snapper going in Leap 15.6 . . . more or less “stock” but here is my cell shot of my choices . . . .

Hmmm. That is odd.

Boot into your system, then provide the output of:

# cat /etc/zypp/zypp.conf

Be sure to use the Preformatted Text </> option on the taskbar, to paste results.

1 Like

Are those 9 all there are, or can you scroll farther down to find more? If more, have you made changes to defaults in /etc/grub.d/ anywhere, or created /boot/grub2/custom.cfg with custom stanzas?

Does your /boot/ contain any files you put there rather than the system itself? If yes, show here ls -l /boot/.

1 Like

Thanks for the replies.

# cat /etc/zypp/zypp.conf
## 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

##
## Path where custom repo variable definitions are kept
##
## Valid values: A directory
## Default value: {configdir}/vars.d
##
## Changing this undefines all custom repo variables. Built-in
## variables (like '$arch', '$basearch' or $releasever) are not
## affected, but reset to their default values.
##
## A custom repo variable is defined by creating a file inside the
## directory. The variable name equals the file name. The files fist
## line (up to but not including the newline character) defines the
## variables value.
##
# varsdir = /etc/zypp/vars.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 opposite
## 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 available 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

##
## Maximum time in seconds that you allow a transfer operation to take.
##
## This is useful for preventing your batch jobs from hanging for hours due
## to slow networks or links going down. Limiting operations to less than a
## few minutes risk aborting perfectly normal operations.
##
## Valid values:  [0,3600]
## Default value: 180
##
# download.transfer_timeout = 180

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

##
## Path where media are preferably mounted or downloaded
##
## Valid values: 	A (writable) directory
## Default value:	/var/adm/mount
##
## The media backend will try to organize media mount points and download areas
## below this directory, unless a different location is requested by the application.
##
## If the directory is not accessible and read/writable for a specific user,
## the fallback is to use /var/tmp.
##
## download.media_mountdir = /var/adm/mount

##
## Signature checking (repo metadata and downloaded rpm packages)
##
##   boolean	gpgcheck	(default: on)
##   boolean	repo_gpgcheck	(default: unset -> according to gpgcheck)
##   boolean	pkg_gpgcheck	(default: unset -> according to gpgcheck)
##
## Explicitly setting 'gpgcheck', 'repo_gpgcheck' 'pkg_gpgcheck' in a
## repositories .repo file will overwrite the defaults for this specific
## repo.
##
## If 'gpgcheck' is 'on' (the default) we will check the signature of repo metadata
## (packages are secured via checksum inside the metadata). Using unsigned repos
## needs to be confirmed.
## Packages from signed repos are accepted if their checksum matches the checksum
## stated in the repo metadata.
## Packages from unsigned repos need a valid gpg signature, using unsigned packages
## needs to be confirmed.
##
## The above default behavior can be tuned by explicitly setting 'repo_gpgcheck'
## and/or 'pkg_gpgcheck':
##
##   'repo_gpgcheck = on' same as the default.
##
##   'repo_gpgcheck = off' will silently accept unsigned repos. It will NOT turn off
##   signature checking on the whole. Nevertheless, it's not a secure setting.
##
##   'pkg_gpgcheck = on' will enforce the package signature checking and the need
##   to confirm unsigned packages for all repos (signed and unsigned).
##
##   'pkg_gpgcheck = off' will silently accept unsigned packages. It will NOT turn off
##   signature checking on the whole. Nevertheless, it's not a secure setting.
##
## If 'gpgCheck' is 'off' (not recommended), no checks are performed. You can still
## enable them individually by setting 'repo_gpgcheck' and/or 'pkg_gpgcheck' to 'on'.
##
##   DISABLING GPG CHECKS IS NOT RECOMMENDED.
##   Signing data enables the recipient to verify that no modifications
##   occurred after the data were signed. Accepting data with no, wrong
##   or unknown signature can lead to a corrupted system and in extreme
##   cases even to a system compromise.
##
# repo_gpgcheck = unset -> according to gpgcheck
# pkg_gpgcheck =  unset -> according to gpgcheck

##
## 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.
##
## Each file in this directory defines a (comma separated) list of
## equivalent vendors string prefixes (case-insensitive comparison):
## ------------------------- file begin -----------------------
## [main]
## vendors = MyVendor,AlternateName
## ------------------------- file end -----------------------
## By this vendor strings starting with "MyVendor" or "AlternateName"
## are considered to be equivalent. Packages from equivalent vendors
## may replace each other without being considered as a 'vendor change'.
##
## NOTE: Within the "opensuse*" namespace exact matches (case insensitive)
## are required. "vendors = suse,opensuse" will allow switching between
## "suse*" and "opensuse", but not e.g. "opensuse build service".
##
## Valid values: A directory
## Default value: {configdir}/vendors.d
##
# vendordir = /etc/zypp/vendors.d


##
## The solver's general attitude when resolving jobs.
##
## Valid values:
##
##   Job       - Focus on installing the best version of the requested packages.
##               Add missing dependencies as needed. This is the solver's default.
##
##   Installed - Focus on applying as little changes to the installed packages
##               as needed. Choosing an older version of a package is valid if
##               its dependencies require less changes to the system.
##
##   Update    - Focus on updating requested packages and their dependencies as
##               much as possible.
##
##   Default   - If the value is not set, empty or unknown, we use the default.
##
# solver.focus =

##
## Whether only required packages are installed.
##
## Recommended packages, 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.
##
## Valid values:  boolean
## Default value: false
##
# solver.allowVendorChange = false

##
## EXPERTS ONLY: TUNE DISTRIBUTION UPGRADE (DUP)
## Set whether to allow package version downgrades upon DUP.
##
## Valid values:  boolean
## Default value: true
##
# solver.dupAllowDowngrade = true

##
## EXPERTS ONLY: TUNE DISTRIBUTION UPGRADE (DUP)
## Set whether follow package renames upon DUP.
##
## Valid values:  boolean
## Default value: true
##
# solver.dupAllowNameChange = true

##
## EXPERTS ONLY: TUNE DISTRIBUTION UPGRADE (DUP)
## Set whether to allow changing the packages architecture upon DUP.
##
## Valid values:  boolean
## Default value: true
##
# solver.dupAllowArchChange = true

##
## 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,latest-3,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

@mrmazda

To answer your questions, 1. Those 9 are it, nothing more. 2. No, I have not done anything custom in grub. I believe that Leap 15.6 does not have a working grub bootloader. The bootloader + osprober are handled by TW for the 7 or so linux installs in three drives. Looks like I originally installed Leap some time back in the iterations with a bootloader, but over time and with guidance here, removed them from all but one, TW.

For the most part I am not getting under the hood on any of them, but as you and I have discussed “this is a mac” . . . . After checking your question about the “only 9 listed” in Leap’s advanced options I scrolled back up to the top line, usually which is what is in the regular “Leap 15.6” line, but this time it did not boot, it went to the “crng init done” and then it stopped. Just a minute before I had booted cleanly to Leap 15.6 from the regular Non-advanced line.

I’m mentioning this because I have an intermittent boot problem with my Mint LMDE install, and I’m thinking that in LMDE’s advanced options I also can’t see specific kernels in grub, just a list of the same names like now in Leap AND LMDE hangs in various places, most commonly at the “crng init done” line, but also emergency shell, etc.

In GParted in openSUSE, the installs like Leap & TW are installed in sda8 & sda6 (doesn’t entirely matter) & LMDE in that GParted is in sdb8 . . . and from memory, in LMDE GParted it sees itself installed in “sda8”??? (so sda & sdb installs are flipped) but Grub sees LMDE where it is, in sdb8. Often times when booting to LMDE I will see in the dmesg “Leap 15.6” and then it says, something like “sdb8 not found” . . . so LMDE can’t find itself? I checked the UUID numbers of all of the partitions and everybody agrees on where they are . . ./etc/fstab all checks out as well . . . .

But, generally I don’t have a problem, ever, except today, booting Leap, it’s only LMDE that is the problem child . . . . It’s only because of this recurrence of the non-revival from suspend problem in Leap that I am having to try to move to another kernel, largely Leap is fairly “stable” and fairly “low maintenance.”

# ls -l /boot/.
total 410408
-rw-r--r-- 1 root root   285891 Jan 19 01:12 config-6.12.10-lp155.2.ga1e0c36-default
-rw-r--r-- 1 root root   285829 Dec 19 11:48 config-6.12.6-lp155.2.gfb072de-default
-rw-r--r-- 1 root root   285825 Jan  6 23:14 config-6.12.8-lp155.7.ge4ae43b-default
-rw-r--r-- 1 root root   285825 Jan 10 07:36 config-6.12.9-lp155.2.g0ae2136-default
drwxr-xr-x 3 root root     4096 Dec 31  1969 efi
drwxr-xr-x 6 root root     4096 Nov  9  2023 grub2
lrwxrwxrwx 1 root root       39 Jan 19 17:13 initrd -> initrd-6.12.10-lp155.2.ga1e0c36-default
-rw------- 1 root root 66127975 Jan 19 17:13 initrd-6.12.10-lp155.2.ga1e0c36-default
-rw------- 1 root root 66129828 Jan 15 07:43 initrd-6.12.6-lp155.2.gfb072de-default
-rw------- 1 root root 66127032 Jan 15 07:43 initrd-6.12.8-lp155.7.ge4ae43b-default
-rw------- 1 root root 66131210 Jan 15 07:44 initrd-6.12.9-lp155.2.g0ae2136-default
-rw-r--r-- 1 root root  1672305 Jan 19 01:41 symtypes-6.12.10-lp155.2.ga1e0c36-default.gz
-rw-r--r-- 1 root root  1672274 Dec 19 12:25 symtypes-6.12.6-lp155.2.gfb072de-default.gz
-rw-r--r-- 1 root root  1672303 Jan  6 23:50 symtypes-6.12.8-lp155.7.ge4ae43b-default.gz
-rw-r--r-- 1 root root  1672315 Jan 10 08:03 symtypes-6.12.9-lp155.2.g0ae2136-default.gz
-rw-r--r-- 1 root root   383481 Jan 19 01:41 symvers-6.12.10-lp155.2.ga1e0c36-default.gz
-rw-r--r-- 1 root root   383410 Dec 19 12:24 symvers-6.12.6-lp155.2.gfb072de-default.gz
-rw-r--r-- 1 root root   383463 Jan  6 23:49 symvers-6.12.8-lp155.7.ge4ae43b-default.gz
-rw-r--r-- 1 root root   383463 Jan 10 08:03 symvers-6.12.9-lp155.2.g0ae2136-default.gz
-rw-r--r-- 1 root root      569 Jan 19 01:41 sysctl.conf-6.12.10-lp155.2.ga1e0c36-default
-rw-r--r-- 1 root root      569 Dec 19 12:24 sysctl.conf-6.12.6-lp155.2.gfb072de-default
-rw-r--r-- 1 root root      569 Jan  6 23:49 sysctl.conf-6.12.8-lp155.7.ge4ae43b-default
-rw-r--r-- 1 root root      569 Jan 10 08:03 sysctl.conf-6.12.9-lp155.2.g0ae2136-default
-rw-r--r-- 1 root root  8480526 Jan 19 01:35 System.map-6.12.10-lp155.2.ga1e0c36-default
-rw-r--r-- 1 root root  8479851 Dec 19 12:18 System.map-6.12.6-lp155.2.gfb072de-default
-rw-r--r-- 1 root root  8477307 Jan  6 23:43 System.map-6.12.8-lp155.7.ge4ae43b-default
-rw-r--r-- 1 root root  8477780 Jan 10 07:59 System.map-6.12.9-lp155.2.g0ae2136-default
-rw-r--r-- 1 root root 12864032 Jan 19 01:42 vmlinux-6.12.10-lp155.2.ga1e0c36-default.xz
-rw-r--r-- 1 root root 12893912 Dec 19 12:26 vmlinux-6.12.6-lp155.2.gfb072de-default.xz
-rw-r--r-- 1 root root 12856028 Jan  6 23:51 vmlinux-6.12.8-lp155.7.ge4ae43b-default.xz
-rw-r--r-- 1 root root 12853812 Jan 10 08:04 vmlinux-6.12.9-lp155.2.g0ae2136-default.xz
lrwxrwxrwx 1 root root       40 Jan 19 17:13 vmlinuz -> vmlinuz-6.12.10-lp155.2.ga1e0c36-default
-rw-r--r-- 1 root root 15226936 Jan 19 03:20 vmlinuz-6.12.10-lp155.2.ga1e0c36-default
-rw-r--r-- 1 root root       65 Jan 19 03:20 .vmlinuz-6.12.10-lp155.2.ga1e0c36-default.hmac
-rw-r--r-- 1 root root 15226936 Dec 19 13:39 vmlinuz-6.12.6-lp155.2.gfb072de-default
-rw-r--r-- 1 root root       65 Dec 19 13:39 .vmlinuz-6.12.6-lp155.2.gfb072de-default.hmac
-rw-r--r-- 1 root root 15218744 Jan  7 05:04 vmlinuz-6.12.8-lp155.7.ge4ae43b-default
-rw-r--r-- 1 root root       65 Jan  7 05:04 .vmlinuz-6.12.8-lp155.7.ge4ae43b-default.hmac
-rw-r--r-- 1 root root 15218744 Jan 10 09:44 vmlinuz-6.12.9-lp155.2.g0ae2136-default
-rw-r--r-- 1 root root       65 Jan 10 09:44 .vmlinuz-6.12.9-lp155.2.g0ae2136-default.hmac
lrwxrwxrwx 1 root root       46 Jan 19 17:13 .vmlinuz.hmac -> .vmlinuz-6.12.10-lp155.2.ga1e0c36-default.hmac

So, after posting the previous data I saw there were a few packages to upgrade in Leap, including the 6.13 lp . . . ran them through and updated the bootloader in TW and back over to Leap . . . . And seemingly it is again reviving from suspend.

~> uname -r
6.13.0-lp155.2.g1513344-default

I still wouldn’t mind being able to see the specific kernels available, but now less reason for it . . . if it “ain’t broke” and so forth . . . .

While the Grub menu remains broken you should nevertheless be able to choose which kernel using the E key, proceeding to boot the selection if it’s the one you want, and if not, ESCing back into the Grub menu to E on another to evaluate.

1 Like

You tagged your topic with leap-156. Why do you show the output from within Leap 15.5?

1 Like

He is probably using a kernel from “Kernel:/stable:/Backport/standard/” and those kernels still have “lp155” as part of their version name.

1 Like

Thanks for that hint . . . just for kicks I did reboot to “advanced options” for Leap and arrowed down to the third line and hit e . . . and in the data it showed “6.12.6 lp xxxx” which is what it working (more or less) in TW . . . . Hit esc and then booting that kernel, as before, fails to boot . . . and today went to “kernel panic” . . . . I ctrl +c and a few seconds later it rebooted.

I went back to adv options, hit the top line with e . . . showed no kernel, just the proper “sda8”??? location, yesterday that line also did not boot, but today it did.

Typing now in Leap . . . the “oddity” seems to remain. I’ll check it again for revival from suspend, which is the primary concern.

Alrighty, I had marked this thread as “solved” but then today running 44 package upgrades, one of them “firmware-nvidia” . . . the problem of non-revival from suspend is again, back.

Since we never really figured out why the problem keeps happening, or why it happened lately . . . nothing new to check. Lsmod shows nouveau all over the place.

The Leap saga continues . . . now after today’s zypper up the previous booting, there were some new “lp” kernels but after updating bootloader Leap boots to 6.4-default.

And in the “advanced options” list, where they all look the same the third item from the top boots to “kernel panic” line 4 boots to “initramfs” shell . . . and the bottom line, now booted to 6.12.10-lp155 . . . .

So condition has gone “worse” rather than better?? as far as having options to boot under grub’s “advanced options” . . . now there are less bootable kernels.

@non_space You need to tell the system what kernels your wanting to keep by configuring /etc/zypp/zypp.conf and multiversion.kernels = ....

Thanks kindly for stopping by, that was previously mentioned in this thread, by myself and others. I am having problems with both TW & Leap with reviving from suspend, in Leap I expanded the number of kernels some months back, but not in TW.

Leap seems to be now having more problems than TW, in that, as per the cell shot I took of grub advanced option menu, the “9” lines of kernels is still there, but selecting them in many cases now does not boot that kernel, but boots to kernel panic or ER shell.

Other stuff going on such that I haven’t had time to identify each line’s kernel and find out which are booting, seems like the top/regular line is 6.4, whereas previously it was 6.13xxxxlp . . . and the bottom line is 6.12xxxlp . . . . In the kernels are the reg main kernel && the Backport kernels . . . but something in yesterday’s zypper seems to have created more problems rather than less . . . .

Based upon what I see in this image, I have to wonder what GRUB_DISABLE_SUBMENU= contains in /etc/default/grub on this installation. It looks like GRUB_DISABLE_SUBMENU=“true”, and the consequence of it has mangled something. What happens if you use GRUB_DISABLE_SUBMENU=“false”, regenerate grub.cfg, then reboot? Do you get expected boot menu selections showing kernel version numbers that way?

If you wish to make one particular menu selection stand out from the others, make one yourself manually with a plain text editor and superuser permission, titled however you want, to clearly distinguish it from all the auto-generated others. If you copy /etc/grub.d/40_custom to /etc/grub.d/06_custom, and put a valid Grub stanza in 06_custom before your next boot, that very stanza should be at the top of the menu, if GRUB_DISABLE_SUBMENU=“true”. With GRUB_DISABLE_SUBMENU=“false” I’ve never tried this. I would expect same, but I suppose it could wind up in the advanced submenu. As an alternative to [06,40]_custom, copy 41_custom to 07_custom instead, but instead of editing 07_custom, create /boot/grub2/custom.cfg to put your custom stanza(s) within. This alternative works the same whether /boot/ is on a separate filesystem or not. Whether [06,40]_custom mods would take effect when using a separate partition for /boot/ I doubt and never tried.

1 Like

@mrmazda

Appreciate the thoughts on it . . . but perhaps not applicable because on this machine TW is the only install that has grub + osprober.

I checked in Leap the /etc/default/grub is empty. Leap & also Mint LMDE are I believe the only two installs where the >options menu just shows the same data for each line.

Since TW is the grub “handler” I rebooted to TW, selected Advanced options and in there it shows the four available kernels by specific name.

I then ran cat /etc/default/grub in TW . . . and there does not appear to be a “submenu” line. Since it is working fine in TW, not sure why I would add it for Leap??

:~> sudo cat /etc/default/grub
GRUB_DISABLE_OS_PROBER="false"
GRUB_TERMINAL="gfxterm"
GRUB_HIDDEN_TIMEOUT="0"
GRUB_TIMEOUT="8"
GRUB_ENABLE_CRYPTODISK="n"
GRUB_GFXMODE="auto"
GRUB_DISABLE_RECOVERY="true"
GRUB_DISTRIBUTOR=
GRUB_DEFAULT="saved"
SUSE_BTRFS_SNAPSHOT_BOOTING="true"
GRUB_USE_LINUXEFI="true"
GRUB_CMDLINE_LINUX_DEFAULT="quiet mitigations=auto"
GRUB_CMDLINE_XEN_DEFAULT="vga=gfx-1024x768x16"
GRUB_BACKGROUND=
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt

There were 7 new packages in Leap, including a “6.13. xx devel xxxx” kernel that were installed. Had to reboot over to TW to update-bootloader, so I’m pasting this post from TW . . . to now reboot back over to Leap to see if now it will pick up the newest, most freshest kernel, or whether it will drop to 6.4 . . . .

Latest update: Leap 15.6 and kernels seems to be in more of a mess than TW. Today’s updates brought new 6.13.1 lp156 kernel . . . that still does not revive the display from suspend.

If I choose grub advanced options any other choice from the 9 lines other than the top line goes to “kernel panic” . . . .

Latest update in Leap, the 6.13.2-lp156.5 xxxx kernel seems to be reviving from suspend, and pretty quickly. I tested it 3 times . . . maybe this will pull Leap 15.6 back from the eve of destruction . . . . Further testing in order, and then checking to see if TW will pull in that newer kernel for the fix there??