blacklist 不生效的根本原因是它仅阻止 modprobe 直接加载，无法阻断依赖链、firmware 请求、内置模块或 initramfs 中的加载；彻底禁用需用 install module /bin/false 或内核级 sysctl 开关。
blacklist 为什么有时不生效？
加了 blacklist module_name 却发现模块还是被加载了，这是最常遇到的“失效”现象。根本原因在于：blacklist 只阻止**直接触发**的加载，不阻断依赖链。比如 nouveau 被 drm_kms_helper 声明为 optional dep，内核在初始化 DRM 子系统时仍会调它。
- blacklist 实际作用是让
modprobe忽略该模块名，但不影响其他模块内部硬编码的request_module()调用 - 某些驱动（如网卡、声卡）会在 probe 阶段按需加载 firmware 或辅助模块，这类加载绕过 modprobe 配置
- 若模块已编译进内核（built-in，非
.ko），blacklist 完全无效——它只对可加载模块起作用
install /bin/false 是更彻底的禁用方式
想真正切断所有路径（包括依赖触发），必须用 install 指令覆盖模块安装行为。它让每次尝试加载该模块时都执行 /bin/false，立刻返回失败码 1，内核会放弃后续动作。
- 在
/etc/modprobe.d/nvidia.conf中写入：install nvidia /bin/false - 注意不是
blacklist nvidia+install nvidia /bin/true—— 后者反而可能成功加载 - 该写法也会阻止依赖它的模块（如
nvidia-uvm）正常初始化，适合彻底隔离场景 - 如果模块名含下划线或短横线（如
usb-storage），modprobe会自动归一化，但配置中建议保持原始拼写一致
kernel.modules_disabled 和 kernel.modprobe 的底层开关
blacklist 和 install 都属于用户态策略，而这两个 sysctl 项是内核级熔断点，影响更广、也更危险。
-
kernel.modules_disabled = 1：永久禁止任何模块加载（包括 root 用户的insmod），且不可逆——需重启生效，一旦设错会导致无法恢复驱动 -
kernel.modprobe空值（echo "" > /proc/sys/kernel/modprobe）：关闭 usermodehelper，内核将不再调用用户态程序自动加载模块，但手动insmod仍有效 - 云服务器（如 AWS EC2、Azure Gen2）常默认启用 secure boot 或 modules_disabled，此时即使配置了 blacklist 也无响应
- 修改前务必确认：
sysctl kernel.modules_disabled和cat /sys/module/<module_name>/initstate</module_name>是否显示live，否则模块压根没机会被 blacklist 干预
为什么 reboot 后模块又回来了？
常见于未更新 initramfs 或 depmod 缓存，导致旧配置未注入启动镜像。
- 修改
/etc/modprobe.d/*.conf后，必须运行：depmod -a（刷新模块依赖索引）update-initramfs -u（Debian/Ubuntu）或dracut -f（RHEL/Fedora） - 某些发行版（如 openEuler）的 initramfs 默认不包含 modprobe 配置，需检查
/etc/dracut.conf.d/或重建时加--force - systemd 系统还可能从
/etc/modules-load.d/自动加载模块，这里写的模块名不受 blacklist 影响，需同步清理 - 虚拟机环境（如 KVM）有时会通过 qemu guest agent 注入模块，这种加载完全绕过 host 的 modprobe 配置
真正可靠的禁用，从来不是只改一行 blacklist，而是得看清楚模块是从哪条路径进来的：是 udev 规则触发？是内核子系统自动 request？还是 initramfs 里自带？漏掉任一环节，它都会在你重启后安静地出现在 lsmod 里。
