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 1279685 - Kdump should drop resolv.conf, if the network is DHCP mode
Summary: Kdump should drop resolv.conf, if the network is DHCP mode
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kexec-tools
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Xunlei Pang
QA Contact: Qiao Zhao
URL:
Whiteboard:
Depends On: 1332412 1332418
Blocks: 1295826 1296180 1313485
TreeView+ depends on / blocked
 
Reported: 2015-11-10 03:22 UTC by Minfei Huang
Modified: 2016-07-25 05:44 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-25 05:39:05 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Minfei Huang 2015-11-10 03:22:50 UTC
Description of problem:
The manual DNS entries in /etc/resolv.conf will work in 2nd kernel as welll, although the network is DHCP mode. DHCP client will retrieve DNS and append it to /etc/resolv.conf by itself, and kdump should not take care of /etc/resolv.conf.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Add DNS entry into /etc/resolv.conf manually
2. setup the network to retrieve the ip by DHCP
3. crash the kernel

Actual results:
The manual DNS entry is still existence in 2nd kernel

Expected results:
The /etc/resolv.conf only contains DNS entries which are retrieved by DHCP client.

Additional info:

Comment 4 Mike McCune 2016-03-28 23:46:11 UTC
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions

Comment 6 Xunlei Pang 2016-07-25 05:35:29 UTC
After some discussion, we decided not to touch the dns related code in kdump_setup_dns().

since /etc/resolv.conf is normally generated by Network Manager, and the user-added items will be discarded after each boot, we decide not to handle these cases.

After 1332412, 1332418 dracut bugs were merged in rhel7 dracut, the current kdump_setup_dns() status will be:
    Kdump uses both ifcfg files and "/etc/resolv.conf" to generate
    all the dns information via "nameserver=" dracut command into
    "${initdir}/etc/cmdline.d/42dns.conf"..
    
    "${initdir}/etc/cmdline.d/42dns.conf" will be used by dracut in
    kdump kernel to generate "/etc/resolv.conf": For the dhcp cases,
    dracut will firstly create dhcp dns items, then add all the input
    "nameserver=" items, then deduplicate the items. For static cases,
    dracut will simply add the "nameserver=" items, then deduplicate.
    
    As an example:
    1) dhcp cases
    Suppose enp0s25, the dhcped DNSes are stable: 10.72.17.5 and 10.68.5.26
    In ifcfg-enp0s25:
    DNS1: 8.8.8.8
    In 1st kernel, /etc/resolv.conf will contain:
    nameserver 10.72.17.5
    nameserver 10.68.5.26
    nameserver 8.8.8.8

    So "${initdir}/etc/cmdline.d/42dns.conf" will contain:
    nameserver=8.8.8.8
    nameserver=10.72.17.5
    nameserver=10.68.5.26
    nameserver=8.8.8.8
    
    In kdump dracut, after dhcp, we will get:
    nameserver 10.72.17.5 // added by dracut dhcp
    nameserver 10.68.5.26 // added by dracut dhcp
    nameserver 8.8.8.8    // from 42dns.conf
    nameserver 10.72.17.5 // from 42dns.conf
    nameserver 10.68.5.26 // from 42dns.conf
    nameserver 8.8.8.8    // from 42dns.conf

    But after dracut deduplicating, we will get:
    nameserver 10.72.17.5
    nameserver 10.68.5.26
    nameserver 8.8.8.8
    
    This is the same as that in 1st kernel.
    In case of different dhcp items, the final result still can work properly(just some stale items at the end).

    2) static cases
    Suppose enp0s25, in ifcfg-enp0s25:
    DNS1: 8.8.8.8
    In 1st kernel, /etc/resolv.conf will contain:
    nameserver 8.8.8.8
    after dracut deduplicating, we will get the same.

    So "${initdir}/etc/cmdline.d/42dns.conf" will contain:
    nameserver=8.8.8.8
    In kdump dracut, we will get:
    nameserver 8.8.8.8
    
    This is also the same as that in 1st kernel.
    
So, we can clearly see that the current implemenation is ok once with the two dracut fixes.

Comment 7 Dave Young 2016-07-25 05:39:05 UTC
Since all the cases have been taken care of in dracut and current kdump, closing it

Comment 8 Xunlei Pang 2016-07-25 05:44:53 UTC
Actually, it's a bug, and was resloved by the release dracut-033-449, see 1332412 and 1332418.

Mark it as CLOSED CURRENTRELEASE.


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