Is This The Proper Way to Disable All Nvidia/GPU Drivers?

Ask Fedora
, , , , ,
1

Greetings all. For context, I recently disabled my laptop’s GPU & Nvidia drivers so that it now only uses the Intel iGPU. The reason why is because when trying to install Fedora 40, something seemed to be wrong with the Nouveau drivers, and the OS would be unbootable if not run in safe-graphics mode. I don’t want to use Nvidia’s proprietary drivers to replace Nouveau, so my only option was to disable the Nvidia GPU and all of its drivers outright, and I figured out how to by using these two posts/guides as a reference:

Method to use Fedora Basic Graphic Mode install on Laptop with NVIDIA GPU and Enable Intel Graphics Only

Hybrid graphics - ArchWiki

Okay, so if I already solved the problem, why am I posting? Because I have no idea if I did this the right way or not. I’m fairly new to Linux and I’ve never touched the kernel, modules, etc. before, nor do I know how they work. I don’t know if the way I configured things is going to cause problems for my system down the road.

Adding to the concern, I’ve seen at least one other person mention problems reported with a setup like mine (an Optimus laptop with all Nvidia drivers disabled). I couldn’t find any of these reports myself on the forums, and he didn’t care to elaborate or tell me where he heard about these reported problems. There was also another person suggesting a different method to disabling drivers, since acc. to him, using “blacklist” in /etc/modprobe.d/ablacklistfile.conf (Which is what I did) doesn’t do any actual black-listing and that the GPU drivers can be re-enabled at any point by the system (If true, this is a big problem. Can’t the OS just suddenly brick itself one day if it decides to re-enable the GPU drivers as part of some automatic system maintenance, update, etc.?)

It’d be a great help if anyone who’s more familiar with the kernel/drivers could chime in.
This is the process I followed:

  1. Boot into installer in safe-graphics mode and go through installation
  2. After Fedora 40 is installed, reboot
  3. Connect to internet and “sudo dnf update”
  4. Reboot
  5. Remove “nomodeset” from the GRUB_CMDLINE_LINUX variable in /etc/default/grub
  6. Add “rd.driver.blacklist=nouveau modprobe.blacklist=nouveau” to GRUB_CMDLINE_LINUX instead
  7. Save that file and run “sudo grub2-mkconfig -o /boot/grub2/grub.cfg”
  8. Create the file /etc/modprobe.d/nvidiablacklist.conf with these lines:

blacklist nvidia
blacklist nouveau

  1. Save the file & reboot
  2. Make the file /etc/udev/rules.d/00-remove-nvidia.rules and copy all these lines into it:

# Remove NVIDIA USB xHCI Host Controller devices, if present
ACTION==“add”, SUBSYSTEM==“pci”, ATTR{vendor}==“0x10de”, ATTR{class}==“0x0c0330”, ATTR{power/control}=“auto”, ATTR{remove}=“1”

# Remove NVIDIA USB Type-C UCSI devices, if present
ACTION==“add”, SUBSYSTEM==“pci”, ATTR{vendor}==“0x10de”, ATTR{class}==“0x0c8000”, ATTR{power/control}=“auto”, ATTR{remove}=“1”

# Remove NVIDIA Audio devices, if present
ACTION==“add”, SUBSYSTEM==“pci”, ATTR{vendor}==“0x10de”, ATTR{class}==“0x040300”, ATTR{power/control}=“auto”, ATTR{remove}=“1”

# Remove NVIDIA VGA/3D controller devices
ACTION==“add”, SUBSYSTEM==“pci”, ATTR{vendor}==“0x10de”, ATTR{class}==“0x03[0-9]*”, ATTR{power/control}=“auto”, ATTR{remove}=“1”

  1. Reboot again

  2. Fedora appears to work well now without needing safe-graphics mode or proprietary GPU drivers, with the added benefit of longer battery life.

If you need this info too, I tried out several suggested ways to check if the Nvidia drivers & GPU are still running, such as:

  • Running “cat /sys/bus/pci/devices/0000:01:00.0/power/runtime_status”, as per the Arch Wiki. The output is “No such file or directory” instead of “active”
  • NVIDIA is no longer seen in “lspci” output
  • Nouveau is no longer seen in “lsmod” output
2

It looks to me that you have done a very thorough job of disabling your nvidia card. I think just rd.driver.blacklist=nouveau modprobe.blacklist=nouveau should have been sufficient, but I don’t see where what you’ve done would cause any problems. (As long as you don’t decide you want to re-enable the nvidia card in the future. If you do, you might have quite the time finding and undoing all the different places that you’ve blocked it! :smiley:)

Personally I prefer PCs with individual PCI cards that can be removed. Things were simpler in the good ol’ days. :slightly_smiling_face:

The only problem with using blacklist in /etc/modprobe.d is that, in some cases, it applies too late to be effective. There are a few drivers that load very early in the boot process (mostly storage and video drivers). If they load before the /etc/modprobe.d files are processed, then the blacklist will have no effect. Also, the contents of /etc/modprobe.d may or may not be integrated into your initramfs depending on when it was last built and what parameters were passed to dracut.

(There is an ongoing effort to move the video drivers to a later stage of the boot process, in which case putting rd.driver.blacklist=nouveau on the kernel command line may no longer be necessary.[1])

  1. ↩︎

1 Like
3

There may be malware installers that attempt to install Nvidia drivers, but in general it should not be necessary to blacklist Nvidia’s proprietary graphics drivers as you have to take several steps manually to install them. Nouveau comes with Fedora (there are systems that only have an Nvidia GPU), but there are efforts to develop open source drivers that support newer Nvidia GPU’s.

4

Thanks for the equally-thorough response! I’m glad to see that my config shouldn’t cause any future problems (unless if I want to re-enable the Nvidia card, but I don’t see that happening since I’m very already satisified with this setup + the extra battery life).
Just two more quick questions.

  1. When do the udev rules & grub variable/settings take effect in the boot process? Is it before the /etc/modprobe.d blacklists get loaded?
  2. I’ve seen some people suggesting this, adding another line after “blacklist nouveau”

blacklist nouveau
options nouveau modeset=0

What’s the point? Unless if I’m misunderstanding something here, is it not redundant to set an option for Nouveau after if it’s already been blacklisted?

5

It’s a somewhat complicated question. If you want to see a map of the bootup process, have a look at man bootup. There is a modprobe@.service that handles many (but not all) “modprobe” calls. It is set to run prior to sysinit.target.

$ systemctl cat modprobe@.service
...

[Unit]
Description=Load Kernel Module %i
DefaultDependencies=no
Before=sysinit.target
Documentation=man:modprobe(8)
ConditionCapability=CAP_SYS_MODULE
StartLimitIntervalSec=0

[Service]
Type=oneshot
ExecStart=-/sbin/modprobe -abq %i

...

Some kernel modules, however, are loaded in dracut scripts/modules.

$ grep -r 'modprobe' /usr/lib/dracut/modules.d/*
...
/usr/lib/dracut/modules.d/04watchdog/watchdog.sh:    modprobe ib700wdt
/usr/lib/dracut/modules.d/04watchdog/watchdog.sh:    modprobe i6300esb
...

Likewise, there is a systemd-udev-trigger.service.

$  systemctl cat systemd-udev-trigger.service
...

[Unit]
Description=Coldplug All udev Devices
Documentation=man:udev(7) man:systemd-udevd.service(8)
DefaultDependencies=no
Wants=systemd-udevd.service
After=systemd-udevd-kernel.socket systemd-udevd-control.socket
Before=sysinit.target
ConditionPathIsReadWrite=/sys

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-udevadm trigger --type=all --action=add --prioritized-subsystem=module,block,tpmrm,net,tty,input

...

It too runs before sysinit.target. udevadm trigger is also called directly by several dracut scripts/modules.

$ grep -r 'udevadm trigger' /usr/lib/dracut/modules.d/*
/usr/lib/dracut/modules.d/01fips/fips.sh:            udevadm trigger --action=add > /dev/null 2>&1
/usr/lib/dracut/modules.d/50plymouth/plymouth-pretrigger.sh:        udevadm trigger --action=add --attr-match=class=0x030000 > /dev/null 2>&1
/usr/lib/dracut/modules.d/50plymouth/plymouth-pretrigger.sh:        udevadm trigger --action=add \
/usr/lib/dracut/modules.d/90dmsquash-live/iso-scan.sh:            udevadm trigger --action=add > /dev/null 2>&1
/usr/lib/dracut/modules.d/99base/init.sh:udevadm trigger --type=subsystems --action=add > /dev/null 2>&1
/usr/lib/dracut/modules.d/99base/init.sh:udevadm trigger --type=devices --action=add > /dev/null 2>&1

So, both modprobe and udevadm trigger are run several times throughout the bootup process and there is an “interleaving” of when they are run. The answer to which will run first really depends on the specific udev rule and kernel module you are comparing. You’d have to dig into those scripts and services further to figure out which one ends up running first.

Yes, the second line in that file is redundant.

HTH,
gb

Edit: Assuming the module probe and udev trigger commands you are interested in relate to the same physical device, the device won’t “exist” (be accessible) until after the module is loaded. So the answer in that case is that the modprobe will happen before the udev rule matches/runs.

1 Like
6

I see, so it’s not like all the udev rules or kernel modules are handled at one point in the process. I took a look at the man-page myself and saw the several boot-up charts, and all I have to say is YIKES. This wasn’t as clean-cut as I hoped it’d be. Maybe one day I’ll be familiar enough with the kernel to understand everything that’s going on here. :sweat_smile:
Anyways, thanks again for taking the time out of your day to answer back. Cheers.

Edit: Yeah I’m talking about the same physical device. Gotcha, so the modprobe happens before the udev rule is applied.

1 Like