Bug 873220 - dracut ignores /etc/modprobe.d blacklist
dracut ignores /etc/modprobe.d blacklist
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: dracut-maint
Fedora Extras Quality Assurance
AcceptedNTH RejectedBlocker
:
Depends On:
Blocks: F18Beta-accepted/F18BetaFreezeExcept
  Show dependency treegraph
 
Reported: 2012-11-05 06:26 EST by leigh scott
Modified: 2013-04-14 19:17 EDT (History)
23 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-03 23:58:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description leigh scott 2012-11-05 06:26:11 EST
Description of problem: dracut ignores /etc/modprobe.d blacklist

  
Actual results: blacklisting radeon or nouveau in /etc/modprobe.d/blacklist.conf
fails


Expected results:

I expect it to work


Additional info:

Why impose this restriction on drivers just to get some crappy eyecandy to work?

/usr/lib/dracut/modules.d/50plymouth/module-setup.sh
Comment 1 leigh scott 2012-11-05 07:11:54 EST
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
Comment 2 Nicolas Chauvet (kwizart) 2012-11-05 17:25:23 EST
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.
Comment 3 Tim Flink 2012-11-30 13:28:38 EST
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.
Comment 4 Nicolas Chauvet (kwizart) 2012-11-30 13:40:17 EST
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.
Comment 5 leigh scott 2012-11-30 14:12:40 EST
(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.
Comment 6 leigh scott 2012-11-30 15:04:08 EST
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
Comment 7 Adam Williamson 2012-12-01 03:21:18 EST
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.
Comment 8 Sergio Monteiro Basto 2012-12-03 23:48:57 EST
+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)
Comment 9 Kevin Fenzi 2012-12-04 18:45:22 EST
I'm with Adam. I'm +1 NTH for sure, but 0 on blocker.
Comment 10 Robyn Bergeron 2012-12-04 23:56:10 EST
+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 :)
Comment 11 Tim Flink 2012-12-05 10:22:16 EST
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.
Comment 12 Adam Williamson 2012-12-05 12:30:57 EST
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.
Comment 13 Harald Hoyer 2012-12-19 07:48:13 EST
(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.
Comment 14 Adam Williamson 2012-12-19 17:51:39 EST
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.
Comment 15 Sergio Monteiro Basto 2012-12-21 13:06:44 EST
Hi,
So what is the workaround to blacklist nouveau and let us use nvidia kmods ?
Comment 16 Alexey Pakseykin 2012-12-21 14:33:48 EST
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.
Comment 17 Paul Franklin (RHlists) 2012-12-24 14:45:28 EST
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.
Comment 18 Christian Kalkhoff 2012-12-26 07:21:39 EST
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
Comment 19 leigh scott 2012-12-26 07:35:21 EST
Linking the blacklist file to /usr/lib/modprobe.d/ works for me.


ln -s /etc/modprobe.d/blacklist-nouveau.conf /usr/lib/modprobe.d/
Comment 20 Fedora Update System 2013-01-02 08:23:49 EST
dracut-024-18.git20130102.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/dracut-024-18.git20130102.fc18
Comment 21 Nicolas Chauvet (kwizart) 2013-01-02 08:54:16 EST
(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.
Comment 22 Fedora Update System 2013-01-02 15:20:27 EST
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).
Comment 23 Sergio Monteiro Basto 2013-01-02 22:44:52 EST
(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 ?
Comment 24 Harald Hoyer 2013-01-03 08:49:54 EST
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
Comment 25 Sergio Monteiro Basto 2013-01-03 13:47:49 EST
(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 ...
Comment 26 Fedora Update System 2013-01-03 23:58:38 EST
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.
Comment 27 Harald Hoyer 2013-01-04 05:59:38 EST
(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.

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