Bug 815244 - Erasing some kernel with "yum erase ..." will not remove the specific subdir of /lib/modules
Erasing some kernel with "yum erase ..." will not remove the specific subdir ...
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Packaging Toolset Team
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2012-04-23 04:02 EDT by Joachim Backes
Modified: 2014-01-21 18:21 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-28 16:32:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Joachim Backes 2012-04-23 04:02:35 EDT
Description of problem:
If I erase some kernel with yum, all modules in /lib/modules/<kernelversion> made by dkms are removed too, but /lib/modules/<kernelversion> itself will remain, so I have to remove it manually.

Version-Release number of selected component (if applicable):

How reproducible:
Each time

Steps to Reproduce:
1.Remove a not active kernel by "yum erase..."
Actual results:
The kernel is removed and manually added kernel modules, but no /lib/modules/<kernelversion>

Expected results:
/lib/modules/<kernelversion> will be removed totally.

Additional info:
The only additional modules I have are those of VirtualBox from virtualbox.org
Comment 1 Fedora Admin XMLRPC Client 2012-04-27 11:23:54 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 2 James Antill 2013-05-28 16:32:02 EDT
 Yum doesn't do any of this. My guess is some %post scriptlet is removing the "external" modules ... but that happens after rpm checks to see if it's safe to remove the directory (and decides it isn't because it's not empty).
 Or rpm might be keeping it due to permission/owner changes ... or something else.

Note You need to log in before you can comment on or make changes to this bug.