Product: Red Hat Enterprise Linux 7
https://bugzilla.redhat.com/show_bug.cgi?id=922201
Bug ID: 922201
Summary: rmmod confused by built-ins
Product: Red Hat Enterprise Linux 7
Version: 7.0
Component: kmod
Severity: medium
Priority: medium
Assignee: kay(a)redhat.com
Reporter: bmr(a)redhat.com
CC: gansalmon(a)Gmail.com, itamar(a)ispbrasil.com.br,
jonathan(a)jonmasters.org, kernel-maint(a)redhat.com,
kmod-maint(a)lists.fedoraproject.org,
madhu.chinakonda(a)gmail.com, msivak(a)redhat.com
Depends On: 922187
+++ 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
--
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NR8Odg50eP&a=cc_unsubscribe
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=958340
Bug ID: 958340
Summary: mlx4_en module not being loaded automatically
Product: Fedora
Version: 18
Component: kmod
Severity: unspecified
Priority: unspecified
Assignee: kmod-maint(a)lists.fedoraproject.org
Reporter: jdy(a)cryregarder.com
QA Contact: extras-qa(a)fedoraproject.org
CC: jonathan(a)jonmasters.org,
kmod-maint(a)lists.fedoraproject.org, msivak(a)redhat.com,
vpavlin(a)redhat.com
Category: ---
This may be related to:
http://www.novell.com/support/kb/doc.php?id=7010836 and
https://bugs.launchpad.net/maas/+bug/1115710
For a MT26448 dual port 10gb ethernet card:
03:00.0 Ethernet controller: Mellanox Technologies MT26448 [ConnectX EN 10GigE,
PCIe 2.0 5GT/s] (rev b0)
the driver, mlx4_en, is not being loaded automatically. The mlx4_core module
is being loaded.
after doing a manual modprobe mlx4_en, the devices come up perfectly.
Suggestion on novell site is to force the load in /etc/modprobe.d.
Software:
kmod-12-3.fc18.x86_64
kmod-libs-12-3.fc18.x86_64
Linux r3 3.8.8-202.fc18.x86_64 #1 SMP Wed Apr 17 23:25:17 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=907581
Bug ID: 907581
Summary: [abrt] kmod-10-1.fc18: elf_get_mem: Process
/usr/bin/kmod was killed by signal 6 (SIGABRT)
Product: Fedora
Version: 18
Component: kmod
Severity: unspecified
Priority: unspecified
Reporter: bug-zilla(a)o2.pl
Version-Release number of selected component:
kmod-10-1.fc18
Additional info:
backtrace_rating: 4
cmdline: /sbin/depmod -a 3.7.4-204.fc18.x86_64
crash_function: elf_get_mem
executable: /usr/bin/kmod
kernel: 3.7.2-204.fc18.x86_64
remote_result: NOTFOUND
uid: 0
var_log_messages: Feb 4 19:30:56 localhost abrt[12775]: Saved core dump of pid
12774 (/usr/bin/kmod) to /var/spool/abrt/ccpp-2013-02-04-19:30:56-12774
(3887104 bytes)
Truncated backtrace:
Thread no. 1 (7 frames)
#4 elf_get_mem at libkmod/libkmod-elf.c:207
#5 elf_get_uint at libkmod/libkmod-elf.c:142
#6 kmod_elf_new at libkmod/libkmod-elf.c:315
#7 kmod_module_get_symbols at libkmod/libkmod-module.c:2458
#8 depmod_load_symbols at tools/depmod.c:1543
#9 depmod_load at tools/depmod.c:1733
#10 do_depmod at tools/depmod.c:2751
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=993071
Bug ID: 993071
Summary: nvidia-kmod.spec error
Product: Fedora
Version: 19
Component: kmod
Assignee: kmod-maint(a)lists.fedoraproject.org
Reporter: sean-clancy(a)gmx.net
QA Contact: extras-qa(a)fedoraproject.org
CC: jonathan(a)jonmasters.org,
kmod-maint(a)lists.fedoraproject.org, msivak(a)redhat.com,
vpavlin(a)redhat.com
Created attachment 782867
--> https://bugzilla.redhat.com/attachment.cgi?id=782867&action=edit
patch to partially fix the problem
akmod fails for a custom (vanialla) kernel if trying to build the nvidia
module.
command to build:
akmodsbuild -k $kernel_version /usr/src/akmods/nvidia-kmod.latest
version:
akmod-nvidia 319.32-2.fc19
kernel 3.10 vanilla (built with separat output directory O= )
problem:
in the file nvidia-kmod.spec (from the rpm
/usr/src/akmods/nvidia-kmod-319.32-2.fc19.src.rpm):
${kernel_version##*___} points to the kernel build directory instead of the
source.
fix:
the supplied patch fixes it, if SYSSRC is manually exported:
export SYSSRC="$kernel_source_dir"
akmodsbuild -k $kernel_version /usr/src/akmods/nvidia-kmod.latest
so the patch is only a partial fix, SYSSRC= should also be added to the .spec
file.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.