RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 971017 - "/sbin/mkdumprd" is not handling "blacklist <directory>" statement in "/etc/kdump.conf" properly
Summary: "/sbin/mkdumprd" is not handling "blacklist <directory>" statement in "/etc/k...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kexec-tools
Version: 6.7
Hardware: Unspecified
OS: Linux
unspecified
low
Target Milestone: rc
: ---
Assignee: Minfei Huang
QA Contact: Qiao Zhao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-05 13:19 UTC by Vladis Dronov
Modified: 2018-12-01 14:39 UTC (History)
4 users (show)

Fixed In Version: kexec-tools-2.0.0-283.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-22 06:00:22 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
A patch to /sbin/mkdumprd (839 bytes, patch)
2013-06-05 13:19 UTC, Vladis Dronov
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 300773 0 None None None Never
Red Hat Product Errata RHBA-2015:1271 0 normal SHIPPED_LIVE kexec-tools bug fix and enhancement update 2015-07-20 17:49:23 UTC

Description Vladis Dronov 2013-06-05 13:19:00 UTC
Created attachment 757183 [details]
A patch to /sbin/mkdumprd

Description of problem:
"/sbin/mkdumprd" is not handling "blacklist <directory>" statement in "/etc/kdump.conf" properly when building "/boot/initrd-$(kernelversion)kdump.img".
The list of the kernel modules under <directory> specified in "/etc/kdump.conf" gets into "<initrd>:/etc/blacklist-kdump.conf" but the modules are still loaded by insmod in "<initrd>:/init".


Version-Release number of selected component (if applicable):
Latest kexec-tools-2.0.0-258.el6 and earlier. Blacklisting modules functionality was added in Bug 596439 but blacklisting directory is not working as intended


How reproducible:
Any time, configure blacklisting of a directory and rebuild crashdump initrd.


Steps to Reproduce:
1. Add "blacklist jbd2 kernel/net/ipv6" in "/etc/kdump.conf"
2. Rebuild crashdump initrd by "service kdump restart"


Actual results:
Check that "<initrd>:/etc/blacklist-kdump.conf" is fine, but "<initrd>:/init" still does insmod on the modules filtered out by directory (still file with filter-by-module-name):

    <no jbd2.ko, as intended, but...>
    echo "Loading ip6_tables.ko module"
    insmod /lib/modules/2.6.32-358.el6.x86_64/ip6_tables.ko 
    echo "Loading ipv6.ko module"
    insmod /lib/modules/2.6.32-358.el6.x86_64/ipv6.ko


Expected results:
No modules filtered out by "blacklist <directory>" statement are insmod-ed in "<initrd>:/init".

Additional info:
I am proposing a simple patch to "/sbin/mkdumprd" script which just adds filtering-by-blacklist-directory to the code which builds "<initrd>:/init" file.

Comment 1 RHEL Program Management 2013-10-14 03:25:01 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 3 Minfei Huang 2014-12-09 06:36:16 UTC
(In reply to Vladis Dronov from comment #0)
> Created attachment 757183 [details]
> A patch to /sbin/mkdumprd
> 
> Description of problem:
> "/sbin/mkdumprd" is not handling "blacklist <directory>" statement in
> "/etc/kdump.conf" properly when building
> "/boot/initrd-$(kernelversion)kdump.img".
> The list of the kernel modules under <directory> specified in
> "/etc/kdump.conf" gets into "<initrd>:/etc/blacklist-kdump.conf" but the
> modules are still loaded by insmod in "<initrd>:/init".
> 
> 
> Version-Release number of selected component (if applicable):
> Latest kexec-tools-2.0.0-258.el6 and earlier. Blacklisting modules
> functionality was added in Bug 596439 but blacklisting directory is not
> working as intended
> 
> 
> How reproducible:
> Any time, configure blacklisting of a directory and rebuild crashdump initrd.
> 
> 
> Steps to Reproduce:
> 1. Add "blacklist jbd2 kernel/net/ipv6" in "/etc/kdump.conf"
> 2. Rebuild crashdump initrd by "service kdump restart"
> 
> 
> Actual results:
> Check that "<initrd>:/etc/blacklist-kdump.conf" is fine, but
> "<initrd>:/init" still does insmod on the modules filtered out by directory
> (still file with filter-by-module-name):
> 
>     <no jbd2.ko, as intended, but...>
>     echo "Loading ip6_tables.ko module"
>     insmod /lib/modules/2.6.32-358.el6.x86_64/ip6_tables.ko 
>     echo "Loading ipv6.ko module"
>     insmod /lib/modules/2.6.32-358.el6.x86_64/ipv6.ko
> 
> 
> Expected results:
> No modules filtered out by "blacklist <directory>" statement are insmod-ed
> in "<initrd>:/init".
> 
> Additional info:
> I am proposing a simple patch to "/sbin/mkdumprd" script which just adds
> filtering-by-blacklist-directory to the code which builds "<initrd>:/init"
> file.

The blacklist only supports particular module in modprobe.conf manpage. And It only supports module in RHEL7 too. 

So keep same behavior with RHEL7, we can modify the kdump manpage about blacklist to claim it only supports module. And the rhel6 kdump code shows it only support module too.

Comment 4 Vladis Dronov 2014-12-09 09:33:39 UTC
Hello,
Excuse me for not agreeing here.

> The blacklist only supports particular module in modprobe.conf manpage.
I'm not sure how 'blacklist' option in 'modprobe.conf' is related to 'blacklist' option in 'kdump.conf'. These are different entities, though have the same name.

> And It only supports module in RHEL7 too.
I'm not sure why RHEL6 should follow RHEL7 here, as 'kexec-tools' and dependant code (dracut) were rebased and reworked significantly in RHEL7.

> we can modify the kdump manpage about blacklist to claim it only supports module.
[man kdump.conf] says:
    blacklist <module|directory>
    A specific module or a  directory  can  be specified.
    In  the  latter  case,  all modules found below the
    specified directory will be excluded.
Well, yes, surely we can change the manpage to match the non-functional code behaviour instead of fixing the non-functional code, but I still would prefer fixing the code.

> And the rhel6 kdump code shows it only support module too.
I believe, RHEL6 kdump code shows there was an attempt to implement blacklisting by directory, but the piece of code implementing this was not complete. That's why exactly this BZ was raised and the patch proposed to fix this and to make the code to work correctly.

Comment 5 Minfei Huang 2014-12-09 10:25:23 UTC
(In reply to Vladis Dronov from comment #4)
> Hello,
> Excuse me for not agreeing here.
> 
> > The blacklist only supports particular module in modprobe.conf manpage.
> I'm not sure how 'blacklist' option in 'modprobe.conf' is related to
> 'blacklist' option in 'kdump.conf'. These are different entities, though
> have the same name.

RHEL7 installs the module by using command modprobe. In order to make the kexec-tools clear within the different RHLE versions, we need to make some behavior between them. Due to compliance behavior of RHEL7, we should not support the specified blocklist directory.

> 
> > And It only supports module in RHEL7 too.
> I'm not sure why RHEL6 should follow RHEL7 here, as 'kexec-tools' and
> dependant code (dracut) were rebased and reworked significantly in RHEL7.
> 
> > we can modify the kdump manpage about blacklist to claim it only supports module.
> [man kdump.conf] says:
>     blacklist <module|directory>
>     A specific module or a  directory  can  be specified.
>     In  the  latter  case,  all modules found below the
>     specified directory will be excluded.
> Well, yes, surely we can change the manpage to match the non-functional code
> behaviour instead of fixing the non-functional code, but I still would
> prefer fixing the code.
> 
> > And the rhel6 kdump code shows it only support module too.
> I believe, RHEL6 kdump code shows there was an attempt to implement
> blacklisting by directory, but the piece of code implementing this was not
> complete. That's why exactly this BZ was raised and the patch proposed to
> fix this and to make the code to work correctly.

Maybe the kdump want to implement the specified blocklist blacklist at the first time. But the kdump code confuses to install the module in the initramfs, and there are lots of dead code need to be removed.

Comment 11 errata-xmlrpc 2015-07-22 06:00:22 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-1271.html


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