RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 922201 - rmmod confused by built-ins
Summary: rmmod confused by built-ins
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kmod
Version: 7.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Václav Pavlín
QA Contact: Madper Xie
URL:
Whiteboard:
Depends On: 922187
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-15 17:36 UTC by Bryn M. Reeves
Modified: 2014-06-18 08:52 UTC (History)
9 users (show)

Fixed In Version: kmod-12-3.fc19
Doc Type: Bug Fix
Doc Text:
Clone Of: 922187
Environment:
Last Closed: 2014-06-16 10:21:10 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Bryn M. Reeves 2013-03-15 17:36:40 UTC
+++ This bug was initially created as a clone of Bug #922187 +++

Description of problem:
Attempting to rmmod something that's not actually built as a module now gives a slightly confusing error:

# rmmod loop
libkmod: kmod_module_get_holders: could not open '/sys/module/loop/holders': No such file or directory
Error: Module loop is in use

Previously rmmod from module-init-tools gave a still vague but better "not found" message:

# rmmod ext2
ERROR: Module ext2 does not exist in /proc/modules

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

How reproducible:
100%

Steps to Reproduce:
1. compile something that can be built as a module as a built-in 
2. rmmod $thing


Actual results:
# rmmod loop
libkmod: kmod_module_get_holders: could not open '/sys/module/loop/holders': No such file or directory
Error: Module loop is in use

Which isn't really true: it's not in use, it's simply built in to vmlinuz so unloading makes no sense.

Expected results:
modprobe does the right thing:

# modprobe -r loop
FATAL: Module loop is builtin.


Additional info:
I know rmmod is the low-level tool and users should be using modprobe -r (or just not messing with this in the first place.. :) but knowledge of modprobe to load and rmmod to unload seems much more widespread among admins and the current behaviour looks at first like a kernel bug (if you didn't realise that there are paths directories missing in /sys/modules/$thing and the module name isn't present in /proc/modules you might think some refcount was broken etc.).

--- Additional comment from Bryn M. Reeves on 2013-03-15 13:12:04 EDT ---

Error is slightly different from 0:12-1.fc18 but same basic problem:

# rmmod loop
rmmod: ERROR: could not open '/sys/module/loop/holders': No such file or directory
rmmod: ERROR: Module loop is in use

Comment 2 Josh Boyer 2013-03-18 15:28:30 UTC
Fixed in Fedora 19.  Should get included with the next sync.

Comment 5 Ludek Smid 2014-06-16 10:21:10 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


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