Bug 1279685 - Kdump should drop resolv.conf, if the network is DHCP mode
Kdump should drop resolv.conf, if the network is DHCP mode
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kexec-tools (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Xunlei Pang
Qiao Zhao
Depends On: 1332412 1332418
Blocks: 1295826 1296180 1313485
  Show dependency treegraph
Reported: 2015-11-09 22:22 EST by Minfei Huang
Modified: 2016-07-25 01:44 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-07-25 01:39:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Minfei Huang 2015-11-09 22:22:50 EST
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 19:46:11 EDT
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune@redhat.com with any questions
Comment 6 Xunlei Pang 2016-07-25 01:35:29 EDT
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" 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: and
    In ifcfg-enp0s25:
    In 1st kernel, /etc/resolv.conf will contain:

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

    But after dracut deduplicating, we will get:
    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:
    In 1st kernel, /etc/resolv.conf will contain:
    after dracut deduplicating, we will get the same.

    So "${initdir}/etc/cmdline.d/42dns.conf" will contain:
    In kdump dracut, we will get:
    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 01:39:05 EDT
Since all the cases have been taken care of in dracut and current kdump, closing it
Comment 8 Xunlei Pang 2016-07-25 01:44:53 EDT
Actually, it's a bug, and was resloved by the release dracut-033-449, see 1332412 and 1332418.


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