*** Bug 1226812 has been marked as a duplicate of this bug. ***

(In reply to Lawrence Somerville from comment #0)
> error: package kernel-default-devel-5.14.21-150500.55.49.1.x86_64 is not
> installed
> ( 1/24) Removing kernel-default-devel-5.14.21-150500.55.49.1.x86_64
> .....[error]
> Removal of (877)kernel-default-devel-5.14.21-150500.55.49.1.x86_64(@System)
> failed:
> Error: Subprocess failed. Error: RPM failed: Command exited with status 1.
> Abort, retry, ignore? [a/r/i] (a):  a
> Problem occurred during or after installation or removal of packages:
> Installation has been aborted as directed.
> Please see the above error message for a hint.

That looks odd.  Something wrong rather in zypper side?
Reassigned.

It looks like kernel-default-devel-5.14.21-150500.55.49.1 is listed in the rpmdb's index tables, but in fact not installed according to the master index.

Please do a
> rpm --rebuilddb

and retry.

Thank you, poster Michael Andres, for kindly taking the time to post your analysis of my situation here.  I tried what you suggested and gratefully had some success in doing so!

But first I want to explain that in Leap 15.6 as a “guest” operating system in VirtualBox 7.0.18 r162988 (Qt5.15.2)
I have had some better functionality with kernel-default-5.14.21-150500.55.65.1.x86_64, which had been “passed along” from my Leap-15.5 to my Leap-15.6 installation, than I have had with kernel-default-6.4.0-150600.23.7.3.x86_64; therefore I did not want to lose my installation of kernel-default-5.14.21-150500.55.65.1.x86_64 via my entering a

zypper purge-kernels

command as a “root” user.  To protect against such a loss as a “root” user I entered the file /etc/zypp/zypp.conf in my installation of the text editor KWrite.  Already uncommented within that file was the statement

multiversion = provides:multiversion(kernel)
.
Further down in the file /etc/zypp/zypp.conf I modified the statement

multiversion.kernels = latest,latest-1,running

to instead read as

multiversion.kernels = 5.14.21-150500.55.65.1,latest,latest-1,running

and then saved the file /etc/zypp/zypp.conf.

(SUBTLE, BUT VERY IMPORTANT:  When preparing to “boot” into Leap 15.6 the version “5.14.21-150500.55.65.1” of the software package kernel-default was not immediately visible among the options for “booting” after clicking on “Advanced options for openSUSE Leap 15.6” in the GRand Unified Bootloader 2 (GRUB2) screen!   But after that clicking on “Advanced options for openSUSE Leap 15.6”, by pressing down a few times on my computer keyboard’s cursor key with a downward-pointing symbol of an arrow on top of it I could gratefully eventually see “openSUSE Leap 15.6, with Linux 5.14.21-150500.55.65-default” listed as the next-to-last entry in a list of options on my computer screen!  With that kernel selected and after perhaps pressing down on my computer keyboard’s “Enter” key, “booting” into Leap 15.6 using that version of kernel-default could gratefully continue.)

Continuing as a “root” user I entered the commands

zypper refresh

and

zypper purge-kernels
.
Gratefully this time kernel-default-5.14.21-150500.55.65.1 or kernel-default-5.14.21-150500.55.65 was not scheduled to be purged from my Leap-15.6 installation.  So I entered “y” for probably “yes” to allow some other, old versions of kernels to be purged from my Leap-15.6 installation.

Then I “rebooted” into my Leap-15.6 installation and found some subfolders within the directory /lib/modules, with several of those subfolders having the designations of old versions of Linux kernels.  So there was more “cleaning up” regarding Linux kernels to do within my Leap-15.6 installation.  But it needed to be performed with some assurance of not “messing up” some functionality within my Leap-15.6 installation.

Poster Stephen Kitt’s posting on https://unix.stackexchange.com/questions/605806/can-i-remove-all-the-recent-kernel-versions-at-lib-modules and poster Claudio Kuenzler’s posting under “rpm vs. dpkg command comparison” in the line reading “Show to which package a file belongs” on 
https://www.claudiokuenzler.com/blog/354/yum-dnf-zypper-apt-rpm-dpkg-command-comparison-suse-debian on the Internet were helpful to provide for me a way to have such assurance.  The first one of those Web pages provided a command by which to check whether any other software package owned the directory I considered removing.  But it began with

dpkg -S /lib/modules/*
.
And “dpkg” was apparently not “recognized” in my openSUSE, Leap-15.6 installation.  The second one of the above two Web pages gave an equivalent command which can be used in an openSUSE installation.  So here is how I could use it in my Leap-15.6 installation:

rpm -qf /lib/modules/5.14.21-150500.53.default
.
In my case the “response” to this command of mine was

virtualbox-kmp-default-7.0.8_k5.14.21_150500.53-lp155.1.6.x86_64
,
which I think meant that /lib/modules/5.14.21-150500.53.default belonged to virtualbox-kmp-default-7.0.8_k5.14.21_150500.53-lp155.1.6.x86_64.  That software package appeared to be associated with VirtualBox 7.0.8…, which I quit using quite a while ago.  So according to Stephen Kitt’s instructions on https://unix.stackexchange.com/questions/605806/can-i-remove-all-the-recent-kernel-versions-at-lib-modules I should first remove or delete virtualbox-kmp-default-7.0.8_k5.14.21_150500.53-lp155.1.6.x86_64 and afterward remove /lib/modules/5.14.21-150500.53.default.  I think that those activities in that order would then have been acceptable.  But instead I decided to issue the commands

rpm -qa virtualbox-kmp-default

and

rpm -qa kernel-default

to see what versions of virtualbox-kmp-default and kernel-default I still had installed in my Leap-15.6 installation.  It was then obvious by then, if not also earlier, that kernel-default-5.14.21-150500.55.65.1.x86_64 did not have a correspondingly numbered virtualbox-kmp-default-7.0.18_k5.14.21_150500.55.65.1-lp155....x86_64 software package installed; but instead there was the software package virtualbox-kmp-default-7.0.18_k5.14.21_150500.55.59-lp155.2.24.1.x86_64 installed.  So my notion that it would have been okay to uninstall any version of virtualbox-kmp-default which did not include the VirtualBox version number 7.0.18 in it or any of the remaining version numbers of kernel-default in it was not good because I suppose that kernel-default-5.14.21-150500.55.65.1.x86_64 needed virtualbox-kmp-default-7.0.18_k5.14.21_150500.55.59-lp155.2.24.1.x86_64 for its function in Leap 15.5 and therefore I suppose needs it in Leap 15.6 as well.  (Note the subtle difference between “55.65” in the first version designation and “55.59” in the second version designation.)

The command of

rpm -qf 5.14.21-150500.55.59-default

as a “root” user in the directory /lib/modules and obtaining the “response” of

virtualbox-kmp-default-7.0.18_k5.14.21_150500.55.59-lp155.2.24.1.x86_64

, shows that

/lib/modules/5.14.21-150500.55.59-default

belonged to

virtualbox-kmp-default-7.0.18_k5.14.21_150500.55.59-lp155.2.24.1.x86_64
.
So I left /lib/modules/5.14.21-150500.55.59-default undisturbed and did not remove it.  If I would instead have delayed upgrading Leap 15.5 to Leap 15.6 long enough into the future, perhaps an openSUSE, Leap-15.5, online repository would eventually release a virtualbox-kmp-default-7.0.18_k5.14.21_150500.55.65.1-lp155....x86_64 to work with kernel-default-5.14.21-150500.55.65.x86_64.  But since I did not delay upgrading Leap 15.5 to Leap 15.6 long enough for that to occur, I probably need to keep virtualbox-kmp-default-7.0.18_k5.14.21_150500.55.59-lp155.2.24.1.x86_64 installed for anytime I would want to “boot” into Leap 15.6 with kernel-default-5.14.21-150500.55.65.1.x86_64.

So then via the “Start” button on the left side of my Leap-15.6 taskbar or widget, then “Systems, Administration, YaST” (Yet another Software Tool) “Software”, performing a search for “virtualbox-kmp-default”, and then on the “Versions” tab for it clicking on six check boxes to change black check marks to red “X”s in those check boxes for the installed versions of virtualbox-kmp-default other than versions 7.0.18_k5.14.21_150500.55.59-lp155.2.24.1-x86_64 and 7.0.18_k6.4.0_150600.21-lp156.1.4-x86_64.  (It appears that virtualbox-kmp-default-7.0.18_k6.4.0_150600.21-lp156.1.4-x86_64 has been used with the following versions of kernel-default: 6.4.0-150600.23.7.3.x86_64 and one or both of 6.4.0-150600.21.2.x86_64 and/or 6.4.0-150600.21.3.x86_64.) Then I think clicking on “Accept” accomplished the removals or deletions of those six versions of virtualbox-kmp-default.

It appears that the command

zypper purge-kernels

does not always include removing versions of virtualbox-kmp-default corresponding to versions of kernel-default and subfolders of /lib/modules which belong to those versions of virtualbox-kmp-default.  So after removed the instances of virtualbox-kmp-default I wanted to remove, probably including virtualbox-kmp-default-5.14.21-150500.53-default, the next “step” was to remove the subfolders of /lib/modules which corresponded to those removed instances of virtualbox-kmp-default.  Toward that goal as a “root” user in the directory /lib/modules my issuance of the command

rm 5.14.21-150500.53-default

failed because the subfolder /lib/modules/5.14.21-150500.53-default was not an empty subfolder.  But from “Linux - How To Delete A Directory That Is Not Empty – YouTube”, or https://www.youtube.com/watch?v=GXfJKlVmJgs on the Internet, by a kind poster unknown by me, I learned that I could use the command as a “root” user in the directory /lib/modules of

rm -rf 5.14.21-150500.53-default

to remove the non-empty subfolder entitled 5.14.21-150500.53-default of /lib/modules.

Similarly as a “root” user in /lib/modules I entered

rpm -qf 5.14.21-150500.55.22-default

and received a “response” including “not owned by any package.”  So with some corresponding confidence that I would likely not be “messing up” some other computer software in the process, I then continued in /lib/modules and entered

rm -rf 5.14.21-150500.55.22-default

to remove that non-empty subdirectory entitled 5.14.21-150500.55.22-default of /lib/modules.

Similarly as a “root” user in /lib/modules I entered

rpm -qf 5.14.21-150500.55.7-default

and received a “response” including “is not owned by any package.”  So I then continued in /lib/modules and entered

rm -rf 5.14.21-150500.55.7-default

to remove that non-empty subdirectory of /lib/modules.

But you might wonder and I did wonder why I deleted six versions of virtualbox-kmp-default, but correspondingly removed only three instead of six subdirectories of /lib/modules.--Perhaps I much earlier deleted some subdirectories of /lib/modules without deleting some corresponding installations of virtualbox-kmp-default.

Now here is an interesting phenomenon:

linux-hdi0:/lib/modules # rpm -qf 5.14.21-150500.55.65-default
kernel-default-optional-5.14.21-150500.55.65.1.x86_64
kernel-default-extra-5.14.21-150500.55.65.1.x86_64
kernel-default-5.14.21-150500.55.65.1.x86_64
kernel-default-devel-5.14.21-150500.55.65.1.x86_64
linux-hdi0:/lib/modules # rpm -qf 5.14.21-150500.55.59-default
virtualbox-kmp-default-7.0.18_k5.14.21_150500.55.59-lp155.2.24.1.x86_64
linux-hdi0:/lib/modules #  

The above “responses” show that the subfolder 5.14.21-150500.55.65-default of /lib/modules belongs to the software packages

kernel-default-optional-5.14.21-150500.55.65.1.x86_64,
kernel-default-extra-5.14.21-150500.55.65.1.x86_64,
kernel-default-5.14.21-150500.55.65.1.x86_64, and
kernel-default-devel-5.14.21-150500.55.65.1.x86_64,

while the subfolder 5.14.21-150500.55.59-default of /lib/modules belongs to

virtualbox-kmp-default-7.0.18_k5.14.21_150500.55.59-lp155.2.24.1.x86_64. 

So not all of the subfolders of /lib/modules were owned by versions of virtualbox-kmp-default.

(In reply to Lawrence Somerville from comment #4)
> But you might wonder and I did wonder why I deleted six versions of
> virtualbox-kmp-default, but correspondingly removed only three instead
> of six subdirectories of /lib/modules.

While rpm packages OWN FILES exclusively, the same is not true for directories. 

'Owning' a directory is the advice to rpm to try to remove the directory along with the package (if the package is the last owner and the directory is empty). It's just a kind of cleanup directive.

Sharing directories between packages is common. Also 'owning' directories without content or providing content in a directory a package does not 'own'.

/lib/modules e.g. is owned by the filesystem package. The content inside is provided by kernel and kmps. If you'd remove the filesystem package (which is not recommended), /lib/modules would be 'not owned by any package'. But it would still exist as a directory on disk and it's content would still be important for your system (unless you removed all packages providing content within lib/modules beforehand).

In general the package maintainers are responsible for the design of directory structure and ownership within their packages. For the installer (libzypp,rpm) a package is a package. No matter what content it has or how important it is, the rules are always the same.



Regarding your system, it's in fact hard to judge which inconsistencies were caused by the inconsistent rpmdb tables.

> zypper verify [--dry-run]
This command helps to repair any broken hard requirements. The command will suggest to install missing requirements. 

> zypper inr --no-recommends [--dry-run]
This command helps to identify recommended packages supporting your hardware, filesystems and selected languages.


Regarding the virtualbox-kmp-default you are right. A KMP usually carries the version of the kernel it was built for in it's own version:
    Name     virtualbox-kmp-default
    Version  -7.0.18_k5.14.21_150500.55.59  
                           ('-' in the kernel version is replaced by a '_')
    Release  -lp155.2.24.1
    Arch     .x86_64
The KMP was built for kernel 5.14.21-150500.55.59. 

If this kernel is no longer installed the KMP may be obsolete. 'zypper purge-kernel' however will not remove KMPs which are not associated with a kernel the command is about to remove. If the maintainer of the KMP allowed to install the KMP without requiring this kernel it may be intentional. The installer can not judge this. 

And it may be required to manually install the virtualbox-kmp-default for the installed kernel if it is missing but needed. The installation of the kernel package is the trigger to install the KMPs. If this trigger was missed (due to the broken rpmdb) 'zypper inr' may trigger it again.

Claonig it.