Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 611427 - nouveau module loaded, although blacklisted
nouveau module loaded, although blacklisted
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
12
All Linux
low Severity high
: ---
: ---
Assigned To: X/OpenGL Maintenance List
Fedora Extras Quality Assurance
: Reopened, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-05 04:33 EDT by stef
Modified: 2010-12-03 08:30 EST (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-03 08:30:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
my nouveau blacklist file in /etc/modprobe.d/ (18 bytes, text/plain)
2010-07-08 05:46 EDT, stef
no flags Details
my grub configuration (1.12 KB, text/plain)
2010-07-08 05:47 EDT, stef
no flags Details

  None (edit)
Description stef 2010-07-05 04:33:54 EDT
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 :
rdblacklist=nouveau

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 2.6.32.14-127.fc12.x86_64  (a FC12 distro after yum upgrade)

How reproducible:
always

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
  
Actual results:
nouveau is loaded

Expected results:
nouveau does not load

Additional info:
Comment 1 Harald Hoyer 2010-07-07 04:14:04 EDT
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
Comment 2 stef 2010-07-07 04:22:34 EDT
Oh µI see, my bad then

However, do you mean :

# echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
Comment 3 Harald Hoyer 2010-07-07 04:40:41 EDT
(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    
hwdata-0.229-1.fc13.noarch

blacklist.conf is already owned by hwdata.
Comment 4 stef 2010-07-07 07:30:00 EDT
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.
Comment 5 Harald Hoyer 2010-07-07 09:19:43 EDT
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)
with:

# dracut -f
Comment 6 stef 2010-07-07 10:13:26 EDT
"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.
Comment 7 Harald Hoyer 2010-07-08 04:47:50 EDT
show me your blacklist file please!
Comment 8 stef 2010-07-08 05:46:19 EDT
Created attachment 430285 [details]
my nouveau blacklist file in /etc/modprobe.d/
Comment 9 stef 2010-07-08 05:47:45 EDT
Created attachment 430286 [details]
my grub configuration
Comment 10 Harald Hoyer 2010-07-08 05:54:48 EDT
what's your xorg.conf ? /etc/X11/xorg.conf
Comment 11 stef 2010-07-08 07:36:50 EDT
(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
Comment 12 Eric Hopper 2010-07-09 13:50:26 EDT
I have the exact same problem and have taken the exact same steps with the same lack of results.
Comment 13 Eric Hopper 2010-07-09 14:13:41 EDT
(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.
Comment 14 stef 2010-07-12 03:07:04 EDT
(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
Comment 15 Harald Hoyer 2010-07-12 05:12:20 EDT
ok, all in all, it's not a dracut nor udev problem... reassigning to Xorg
Comment 16 Ben Skeggs 2010-07-12 18:34:14 EDT
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.
Comment 17 stef 2010-07-13 03:18:23 EDT
(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.
Comment 18 Ben Skeggs 2010-07-14 00:22:01 EDT
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.
Comment 19 Eric Hopper 2010-07-14 02:36:55 EDT
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.
Comment 20 MarcH 2010-07-20 07:40:40 EDT
> (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.
Comment 21 stef 2010-07-20 08:03:07 EDT
(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.
Comment 22 stef 2010-07-20 08:13:51 EDT
(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 :

Section "Device"
    Driver        "vesa"
    BusID        "PCI:1:0:0"
EndSection

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"
EndSection

So that whatever happens 'nouveau' won't be loaded.
Comment 23 Eric Hopper 2010-07-20 16:55:54 EDT
(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"
> EndSection
> 
> So that whatever happens 'nouveau' won't be loaded.    

Why not instead just remove the xorg-x11-drv-nouveau package?
Comment 24 Eric Hopper 2010-07-20 16:59:15 EDT
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.
Comment 25 stef 2010-07-21 03:02:44 EDT
(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.
Comment 26 Eric Hopper 2010-08-05 19:59:20 EDT
(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.
Comment 27 Bug Zapper 2010-11-03 08:28:28 EDT
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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 28 David Ward 2010-11-19 13:10:40 EST
Please change revision to Fedora 14.  Issue still applies.
Comment 29 David Ward 2010-11-19 13:30:41 EST
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 1.8.99.904, 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 1.8.99.904, 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."
Comment 30 Ben Skeggs 2010-11-20 03:54:37 EST
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.
Comment 31 Bug Zapper 2010-12-03 08:30:18 EST
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.

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