Red Hat Bugzilla – Bug 611427
nouveau module loaded, although blacklisted
Last modified: 2010-12-03 08:30:18 EST
Description of problem:
I want to use the vanilla proprietary NVidia kernel module, to do so I have added the following parameter un the grub config :
But even after doing so I still can see the nouveau module being loaded in the system by doing lsmod, making impossible to run the NVidia installer, the nvidia.ko module refusing to load.
I even started system with runlevel 3 from grub but the kernel module still loads.
Version-Release number of selected component (if applicable):
kernel 188.8.131.52-127.fc12.x86_64 (a FC12 distro after yum upgrade)
Steps to Reproduce:
1.have a NVidia hardware for video card
2.add the rdblacklist=nouveau in grub config to prevent nouveau from loading
3.reboot the system and do a lsmod
nouveau is loaded
nouveau does not load
rdblacklist only prevents loading of the module in the rd=ramdisk. If you want to prevent it to be loaded as soon as your root device is mounted, you also have to do:
# echo "blacklist nouveau" >> /etc/modprobe.d/blacklist-nouveau.conf
Oh µI see, my bad then
However, do you mean :
# echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
(In reply to comment #2)
> Oh µI see, my bad then
> However, do you mean :
> # echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
no... you better create your own custom conf file..
$ rpm -qf /etc/modprobe.d/blacklist.conf
blacklist.conf is already owned by hwdata.
Okay, the case isn't closed apparently.
I added the grub kernel parameter rdblacklist=nouveau
I created the blacklist file with
# echo "blacklist nouveau" >> /etc/modprobe.d/blacklist-nouveau.conf
BUT, it doesn't help.
the system boots and arrives on the GDM prompt, then when I issue a lsmod to see what's being loaded I get this :
Module Size Used by
nouveau 333778 2
ttm 49268 1 nouveau
drm_kms_helper 24584 1 nouveau
drm 171002 4 nouveau,ttm,drm_kms_helper
i2c_algo_bit 5005 1 nouveau
i2c_core 26956 4 nouveau,drm_kms_helper,drm,i2c_algo_bit
nfs 266829 2
lockd 66124 1 nfs
fscache 43557 1 nfs
nfs_acl 2357 1 nfs
auth_rpcgss 38108 1 nfs
sunrpc 193817 13 nfs,lockd,nfs_acl,auth_rpcgss
ipv6 279495 0
cpufreq_ondemand 8793 2
acpi_cpufreq 7627 0
freq_table 3947 2 cpufreq_ondemand,acpi_cpufreq
dm_multipath 14558 0
uinput 7228 0
snd_hda_codec_realtek 279639 1
snd_hda_intel 24000 0
snd_hda_codec 71956 2 snd_hda_codec_realtek,snd_hda_intel
snd_hwdep 6446 1 snd_hda_codec
snd_seq 52773 0
snd_seq_device 6151 1 snd_seq
i82975x_edac 3053 0
snd_pcm 78247 2 snd_hda_intel,snd_hda_codec
iTCO_wdt 11118 0
snd_timer 19840 2 snd_seq,snd_pcm
snd 62376 8 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer
soundcore 6271 1 snd
edac_core 39597 1 i82975x_edac
iTCO_vendor_support 2547 1 iTCO_wdt
snd_page_alloc 7389 2 snd_hda_intel,snd_pcm
ppdev 7925 0
parport_pc 21189 0
tg3 101714 0
parport 31685 2 ppdev,parport_pc
hp_wmi 4984 0
rfkill 16966 1 hp_wmi
wmi 6872 1 hp_wmi
floppy 54666 0
nouveau is here and gets in the way to install the NVidia proprietary driver.
If I try to rmmod it I get that it's being used.
One solution is at boot time modify the Grub kernel line to add "3" to start in runlevel 3 then issue "init 5" to go back to runlevel 5 but it's a pain.
nouveau shouldn't be able to be loaded at all and X automaticaly switch to another video driver like "svga", I checked that there was no /etc/X11/xorg.conf file existing to force the nouveau X driver.
maybe it's loaded in the initramfs?
add "rdblacklist=nouveau" to the kernel command line or rebuild the initramfs (which will add your /etc/modprobe.d/blacklist-nouveau.conf to the image)
# dracut -f
"rdblacklist=nouveau" is already in the kernel command line, I tryed to rebuild the initramfs with your command
# dracut -f
but it doesn't change a thing.
I tryed to do so also on the system booted in runlevel 3 (with no nouveau module loaded) and no luck either.
It seems X starting completely bypass the blacklist mechanism and does load a module we want out.
show me your blacklist file please!
Created attachment 430285 [details]
my nouveau blacklist file in /etc/modprobe.d/
Created attachment 430286 [details]
my grub configuration
what's your xorg.conf ? /etc/X11/xorg.conf
(In reply to comment #10)
> what's your xorg.conf ? /etc/X11/xorg.conf
There's no xorg.conf, everything X related is autoconfig
Therefore the system decides that nouveau is the appropriate driver
I have the exact same problem and have taken the exact same steps with the same lack of results.
(In reply to comment #12)
> I have the exact same problem and have taken the exact same steps with the same
> lack of results.
And I figured it out. I had two identical copies of /boot with the same UUID. One on /dev/sda1 and the other on /dev/sdb1. The system booted from /dev/sda1 and mounted the one from /dev/sdb1, so any changes I made were not made to the filesystem being booted from.
This happened because I initially tried to set my system to use software RAID for /boot and grub choked on that. So (short version that elides details) changed the partitions to ordinary partitions and dd'ed them to each other.
(In reply to comment #13)
> And I figured it out. I had two identical copies of /boot with the same UUID.
Good for you that you spotted this mistake.
However what are the results after you've done the changes?
Does nouveau still gets loaded after Xorg starts?
For me I do not have such mistake, the grub conf and the booted system and mounted partitions are those really used.
I'd like a word from some dev leader at Fedora to confirm a little thought :
the rdblacklist kernel parameter and the blacklist files in modprobe.d does indeed prevent the kernel to load the nouveau module therefore you don't boot on the framebuffer.
However does this mechanism can really prevent any loading of the module afterward by a separate process or service like Xorg ?
That's what I want to achieve and it seems to fail on this regard.
Is there another way to do so?
A quick and dirty way would be to rename the nouveau.ko module so that the system can't find it, but it's ... dirty :-p
ok, all in all, it's not a dracut nor udev problem... reassigning to Xorg
If you haven't modified your xorg.conf to specify a driver other than nouveau, it's your own fault.
Yes, when the nouveau 2D driver loads, the *X server* does load nouveau's kernel module. One would assume that if they're trying to use the nouveau 2D driver, that its kernel module should be loaded.
(In reply to comment #16)
Hi Ben, thanks for your answer.
> If you haven't modified your xorg.conf to specify a driver other than nouveau,
> it's your own fault.
Well, I must say that I agree on the process but I disagree with your point of view on this issue.
For many years now lots of people in the community made an impressive job to automatize as far as possible the starting of the Xorg server, the core point of these improvements are related to a close relationship with components like udev and a fistfull of kernel changes.
The result is to be completely freed from any need of a xorg.conf file and still having a Xorg running.
So, if it is still true that creating a xorg.conf file will give you the possibility to change and adjust lots of things around, having an explicit configuration of module blacklisted in grub and in modprobe completely ignored is a non-sense.
> Yes, when the nouveau 2D driver loads, the *X server* does load nouveau's
> kernel module. One would assume that if they're trying to use the nouveau 2D
> driver, that its kernel module should be loaded.
That's the point.
Xorg should (no, MUST) see that this module is blacklisted and must not be loaded even if its detection system says that it look like the most appropriate video driver.
It just have to skip it and go to the next one (very likely the previously used 'nv' driver or a generic driver like 'svga').
This should be a source of reflexion for a next version of Xorg.
My point is, if you're using the NVIDIA binary driver, you have to create one anyway. There's no support in the auto-selecting proprietary drivers.
Anyhow, I'll reassign to the server and see what others think about "fixing" it to obey modprobe's blacklist is something that should be done.
The rpm for xorg-x11-drv-nvidia from rpmfusion should install /etc/init.d/nvidia and set it to run at run levels 2, 3, 4, and 5. This script should check to see if the nvidia driver can be loaded, and if it can it should create the appropriate xorg.conf script. It relies on /usr/sbin/nvidia-config-display to actually create the file.
> (In reply to comment #16)
> having an explicit configuration of module blacklisted in grub and in
> modprobe completely ignored is a non-sense.
A big part of the problem is that the "blacklist" feature is misnamed. Just have a look at "man modprobe.conf": blacklisting does NOT prevent a module from being loaded, it is much more subtle than that.
(In reply to comment #18)
> There's no support in the auto-selecting proprietary drivers.
This issue does not look specific to _proprietary_ drivers.
By the way, is there some kind of "xforcevesa" boot param or is Fedora lagging behind? Manually creating a xorg.conf file is extremely cumbersome for installers and other live images.
(In reply to comment #19)
> The rpm for xorg-x11-drv-nvidia from rpmfusion should install
Yup, but it's not what I want to achieve, the fusion RPM is faulty for my use.
See here : https://bugzilla.rpmfusion.org/show_bug.cgi?id=1298
I have a bunch of Scientific closed-source softwares to run and the RPM from fusion does not give the same behaviour as the proprietary driver you have to install by hand.
that's when doing this install that I ran into the present 'bug' or more specifically behavior from nouveau.
(In reply to comment #20)
> (In reply to comment #18)
> > There's no support in the auto-selecting proprietary drivers.
> This issue does not look specific to _proprietary_ drivers.
Do you think it would be possible in the future to have a reversed declaration for video driver in Xorg ?
Here's an example :
one of the solutions for my problem would be to add this in a minimalist xorg.conf :
however I want to make an install with kickstart for A LOT (around 1000 workstations, I work in an uni) of workstations and I have not only workstations with NVidia cards but also with intel on-board cards and so on, on those the 'intel' driver is fine so I don't want to switch to 'svga' for everyone unnecessarily.
So what would be nice would be something like this :
So that whatever happens 'nouveau' won't be loaded.
(In reply to comment #22)
> however I want to make an install with kickstart for A LOT (around 1000
> workstations, I work in an uni) of workstations and I have not only
> workstations with NVidia cards but also with intel on-board cards and so on, on
> those the 'intel' driver is fine so I don't want to switch to 'svga' for
> everyone unnecessarily.
> So what would be nice would be something like this :
> Section "Device"
> Blacklist "nouveau"
> So that whatever happens 'nouveau' won't be loaded.
Why not instead just remove the xorg-x11-drv-nouveau package?
And yes, that package is a dependency of xorg-x11-drivers, but xorg-x11-drivers is just a 'placeholder' package that's there to force all of the xorg-x11-drv packages to be installed.
(In reply to comment #24)
> And yes, that package is a dependency of xorg-x11-drivers, but xorg-x11-drivers
> is just a 'placeholder' package that's there to force all of the xorg-x11-drv
> packages to be installed.
So you're telling me to do a :
rpm -e xorg-x11-drivers xorg-x11-drv-nouveau
is that right ?
If I don't remove xorg-x11-drivers as well it will reinstall nouveau when it's being updated since it's a dependency.
(In reply to comment #25)
> rpm -e xorg-x11-drivers xorg-x11-drv-nouveau
> is that right ?
This answer is a couple of weeks late, but yes, that is what I'm telling you to do.
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Please change revision to Fedora 14. Issue still applies.
After uninstalling xorg-x11-drv-nouveau, the 'nouveau' driver did not load. However xorg seems to have autoselected the 'vesa' driver now over the 'nvidia' driver. From /var/log/Xorg.0.log:
[ 23.563] (==) Matched nouveau as autoconfigured driver 0
[ 23.563] (==) Matched vesa as autoconfigured driver 1
[ 23.563] (==) Matched fbdev as autoconfigured driver 2
[ 23.563] (==) Assigned the driver to the xf86ConfigLayout
[ 23.564] (II) LoadModule: "nouveau"
[ 23.576] (WW) Warning, couldn't open module nouveau
[ 23.576] (II) UnloadModule: "nouveau"
[ 23.576] (EE) Failed to load module "nouveau" (module does not exist, 0)
[ 23.576] (II) LoadModule: "vesa"
[ 23.576] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so
[ 23.582] (II) Module vesa: vendor="X.Org Foundation"
[ 23.582] compiled for 184.108.40.2064, module version = 2.3.0
[ 23.582] Module class: X.Org Video Driver
[ 23.582] ABI class: X.Org Video Driver, version 8.0
[ 23.582] (II) LoadModule: "fbdev"
[ 23.583] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
[ 23.589] (II) Module fbdev: vendor="X.Org Foundation"
[ 23.589] compiled for 220.127.116.114, module version = 0.4.1
[ 23.589] ABI class: X.Org Video Driver, version 8.0
[ 23.589] (II) VESA: driver for VESA chipsets: vesa
[ 23.589] (II) FBDEV: driver for framebuffer: fbdev
[ 23.589] (++) using VT number 1
[ 23.594] (WW) Falling back to old probe method for fbdev
[ 23.594] (II) Loading sub module "fbdevhw"
[ 23.594] (II) LoadModule: "fbdevhw"
[ 23.595] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so
[ 23.596] (II) Module fbdevhw: vendor="X.Org Foundation"
[ 23.596] compiled for 1.9.1, module version = 0.0.2
[ 23.596] ABI class: X.Org Video Driver, version 8.0
[ 23.596] (EE) open /dev/fb0: No such file or directory
[ 23.596] (II) Loading sub module "vbe"
[ 23.596] (II) LoadModule: "vbe"
[ 23.597] (II) Loading /usr/lib64/xorg/modules/libvbe.so
[ 23.598] (II) Module vbe: vendor="X.Org Foundation"
[ 23.598] compiled for 1.9.1, module version = 1.1.0
[ 23.598] ABI class: X.Org Video Driver, version 8.0
[ 23.598] (II) Loading sub module "int10"
[ 23.598] (II) LoadModule: "int10"
[ 23.599] (II) Loading /usr/lib64/xorg/modules/libint10.so
[ 23.601] (II) Module int10: vendor="X.Org Foundation"
[ 23.601] compiled for 1.9.1, module version = 1.0.0
[ 23.601] ABI class: X.Org Video Driver, version 8.0
[ 23.601] (II) VESA(0): initializing int10
[ 23.607] (II) VESA(0): Primary V_BIOS segment is: 0xc000
[ 23.617] (II) VESA(0): VESA BIOS detected
To back this up, running 'nvidia-settings' returns: "You do not appear to be using the NVIDIA X driver."
The NVIDIA binary driver will *never* be autoselected by Xorg, it's *not* a supported driver. This is *not* a bug. If you want to use the NVIDIA binary driver make an xorg.conf, the end.
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.