Bug 873220

Here's examples of the issues caused by this

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2545

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2559

After looking at 90kernel-modules/module-setup.sh, the dracut_install is only made in hostonly mode. So the initial report should be considered as NOTABUG.

Once that said I think the behavior has changed from initial dracut releases.

Now another related bug is located at the hook level from 90kernel-modules/parse-kernel.sh. The /etc/modprobe.d directory isn't available in the initramfs, so the initramfsblacklist.conf isn't created and the rd.driver.blacklist isn't honored.
 
Changing from /etc/modprobe.d to /lib/modprobe.d/ here restore the module blacklist behavior.

If I'm understanding this correctly, the issue is that dracut is ignoring the blacklist which is causing issues if a user is using graphics drivers from rpmfusion.

Does this cause problems if drivers from rpmfusion aren't used? How easy is this to hit if a user sticks to the fedora repos?

If this is limited to non-standard drivers, I'm -1 blocker on this. It doesn't hit any of the F18 release criteria, could be fixed with an update post-install and has a reasonable workaround in most cases: "don't use the binary drivers from rpmfusion".

However, I realize that there are many users who install the binary drivers from RPMFusion and am +1 NTH.

The point to focus is only that the rd.driver.blacklist behavior doesn't function at all. Whoever will need to use that for any reason will get rejected.
The same apply if one need to blacklist any module for security reason.

Also worth to notice that a patch was sent to the upstream dracut ml early this month.

(In reply to comment #3)
> If I'm understanding this correctly, the issue is that dracut is ignoring
> the blacklist which is causing issues if a user is using graphics drivers
> from rpmfusion.
> 
> Does this cause problems if drivers from rpmfusion aren't used? How easy is
> this to hit if a user sticks to the fedora repos?

It also affects any users expecting /etc/modprobe.d/blacklist.conf to work

> 
> If this is limited to non-standard drivers, I'm -1 blocker on this. It
> doesn't hit any of the F18 release criteria, could be fixed with an update
> post-install and has a reasonable workaround in most cases: "don't use the
> binary drivers from rpmfusion".

hwdata is also broken by the dracut change

hwdata-0.241-1.fc18.noarch : Hardware identification and configuration data
Repo        : fedora
Matched from:
Filename    : /etc/modprobe.d/blacklist.conf




> 
> However, I realize that there are many users who install the binary drivers
> from RPMFusion and am +1 NTH.

I wonder if these packages are affected as well?

b43-openfwwf-5.2-8.fc18.noarch : Open firmware for some Broadcom 43xx series WLAN chips
Repo        : @fedora
Matched from:
Filename    : /etc/modprobe.d/openfwwf.conf



systemd-195-8.fc18.x86_64 : A System and Service Manager
Repo        : @fedora
Matched from:
Filename    : /etc/modprobe.d/udlfb.conf

note that this only affects the *dracut* layer, as I read it. blacklisting also applies to module-init-tools - modules that get loaded post-dracut. so those blacklists may still be fulfilling their intended purpose. I'm +/-0 here, I'd need more precise data that this was actually breaking something specific to be +1.

+1 
I have to  "rm  nouveau.ko"
 
locate nouveau.ko
rm /usr/lib/modules/3.6.7-5.fc18.x86_64/kernel/drivers/gpu/drm/nouveau/nouveau.ko

before do:
dracut -f /boot/initramfs-$(uname -r).img $(uname -r)

I'm with Adam. I'm +1 NTH for sure, but 0 on blocker.

+1 NTH, +0 blocker, but might lean towards blocker depending on answers below... would mostly like more info.

Curious as to level of "brokenness" of hwdata.

I noticed that the ovirt project folks did some workarounds within ovirt (as I was looking at what hwdata possibly affects) to work around the dracut directory changes, and remove dracut blacklisting.  Not sure about the overall implications in that case (or if it even remotely matters here) but linking for info's sake:

http://gerrit.ovirt.org/#/c/7932/

Adding mburns as well just in case he has any thoughts :)

We seem to have a lot of +/-0 votes here, so I don't think that the in-bug voting is going to make a decision. Will discuss in a blocker review meeting.

I count +4 NTH, though. Moving to accepted nth.

Discussed at 2012-12-05 blocker review meeting - http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-05/f18final-blocker-review-2.2012-12-05-17.01.log.txt . We agreed that on the face of it this doesn't seem serious enough to merit blocker status, there has been no indication that it actually breaks anything release blocking and it looks like it could be fixed post-release in any case. For now it is rejected as a blocker, it could be re-proposed if anything new comes to light.

Harald, please note that the blocker list is not a to-do list and cannot be used as such - if you need a tracker bug for 'things you aim to work on for f18 final', please create your own tracker bug.

(In reply to comment #12)
> Discussed at 2012-12-05 blocker review meeting -
> http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-05/f18final-
> blocker-review-2.2012-12-05-17.01.log.txt . We agreed that on the face of it
> this doesn't seem serious enough to merit blocker status, there has been no
> indication that it actually breaks anything release blocking and it looks
> like it could be fixed post-release in any case. For now it is rejected as a
> blocker, it could be re-proposed if anything new comes to light.
> 
> Harald, please note that the blocker list is not a to-do list and cannot be
> used as such - if you need a tracker bug for 'things you aim to work on for
> f18 final', please create your own tracker bug.

I thought, I can only fix blocker bugs now. So, I marked those as blocker, which seem to be most important for the final release.

No, please see https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process and https://fedoraproject.org/wiki/QA:SOP_nth_bug_process .

Blocker bugs are just that: blockers. A bug's only going to be accepted as a blocker if it should actually block the release.

The NTH process is what you wanted here: essentially it's the process for requesting a freeze exception. An NTH bug is a bug we will pull a fix for through the freeze, but we won't delay the release if there is no fix.

Hi,
So what is the workaround to blacklist nouveau and let us use nvidia kmods ?

The workaround I use is the following.

As this bug report suggests, regardless of how well you blacklist the module, it will still be loaded via initramfs. The straightforward way is to remove the module entirely and rebuild initramfs.

Backup module and initramfs, if needed.

1. Remove the module for your current kernel:
 rm /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/nouveau/nouveau.ko

2. Rebuild initramfs for your current kernel (it should complain about missing moudule which is OK):
 dracut -vf /boot/initramfs-$(uname -r).img $(uname -r)

* You can list module paths for any kernel version, verify that nouveau is missing and repeat the steps above for each of them:
 rpm -qvV kernel | grep nouveau.ko

I use NVIDIA driver which cannot be even built while nouveau module is loaded. But as soon as initramfs is rebuilt and machine is rebooted, I don't need to care about nouveau anymore even without blacklisting - it simply does not exist.

The issue is that I have to repeat the steps every time the kernel is updated. And I have a couple of machines which multiplies the task.

I haven't investigated thoroughly yet but I suspect I am hitting
this also.  At least there's some boot-time message which flies
by too fast for me to read as I am doggedly trying to debug my
video problems -- or at least come up with a workaround.  (It is
maybe a dracut script which parses the kernel line.)

Anyway, my question is: why don't I see this listed in
http://qa.fedoraproject.org/blockerbugs/milestone/18/final/buglist
given that I see "Whiteboard: AcceptedNTH" up above?  Thanks.

CONTAINS WORKAROUND :)

Please note that blacklisting using kernel command line option rdblacklist or rd.blacklist doesn't seem to work either. 

Doing so, I get

/etc/initrdblacklist.conf: file not found

Could be related.

As a workaround I was able to exclude the nouveau module by giving the omit-drivers option to dractut which works at least until the next kernel upgrade

Linking the blacklist file to /usr/lib/modprobe.d/ works for me.


ln -s /etc/modprobe.d/blacklist-nouveau.conf /usr/lib/modprobe.d/

dracut-024-18.git20130102.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/dracut-024-18.git20130102.fc18

(In reply to comment #20)
> dracut-024-18.git20130102.fc18 has been submitted as an update for Fedora 18.
> https://admin.fedoraproject.org/updates/dracut-024-18.git20130102.fc18

@Harold, this package will indeed probably workaround the issue with rd.driver.blacklist, but with further investigation I wonder if that directory shoudn't be created during the initramfs creation insteaf of at boot time.
That way, files distributed into /etc/modprobe.d such as anaconda.conf  blacklist.conf dist-alsa.conf dist.conf  dist-oss.conf and others will be copied into the initramfs.

Thx for the update on this topic.

Package dracut-024-18.git20130102.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-024-18.git20130102.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-0082/dracut-024-18.git20130102.fc18
then log in and leave karma (feedback).

(In reply to comment #19)
> Linking the blacklist file to /usr/lib/modprobe.d/ works for me.
> 
> 
> ln -s /etc/modprobe.d/blacklist-nouveau.conf /usr/lib/modprobe.d/

yeah move /etc/modprobe.d/blacklist-nouveau.conf /usr/lib/modprobe.d/
dracut seems works just fine .

you should move all kmod blacklist to /usr/lib/modprobe.d/ ? 

Don't understand why /etc/modprobe.d/ is not a symbol link of /usr/lib/modprobe.d/, is dracut different that we don't need old blacklist ?

1. all packages shipping modprobe conf files should do that in /usr/lib/modprobe.d

2. dracut in generic mode will only pick /usr/lib/modprobe.d

3. dracut in host-only mode will also pick /etc/modprobe.d, because that is host-only

If you want to configure the generic dracut image, do it via "rd.driver.blacklist=<driver>" on the kernel command line

(In reply to comment #24) 
> 3. dracut in host-only mode will also pick /etc/modprobe.d, because that is
> host-only
> 
> If you want to configure the generic dracut image, do it via
> "rd.driver.blacklist=<driver>" on the kernel command line

what is dracut in host-only ? 
and rd.driver.blacklist=<driver> doesn't worked  at least before last update of dracut , that was the problem ...

dracut-024-18.git20130102.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

(In reply to comment #25)
> (In reply to comment #24) 
> > 3. dracut in host-only mode will also pick /etc/modprobe.d, because that is
> > host-only
> > 
> > If you want to configure the generic dracut image, do it via
> > "rd.driver.blacklist=<driver>" on the kernel command line
> 
> what is dracut in host-only ? 

google and the man page are your friends :)

# man dracut
       -H, --hostonly
           Host-Only mode: Install only what is needed for booting the local 
           host instead of a generic host and generate host-specific
           configuration.


# man dracut.conf
       hostonly="{yes|no}"
           Host-Only mode: Install only what is needed for booting the local 
           host instead of a generic host and generate host-specific
           configuration.


> and rd.driver.blacklist=<driver> doesn't worked  at least before last update
> of dracut , that was the problem ...

Yeah, and this was fixed with the update.