https://bugzilla.suse.com/show_bug.cgi?id=1226811 https://bugzilla.suse.com/show_bug.cgi?id=1226811#c5 Michael Andres <ma@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(l_pat_s@hotmail.c | |om) | --- Comment #5 from Michael Andres <ma@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.