Bug 1279685

Summary:	Kdump should drop resolv.conf, if the network is DHCP mode
Product:	Red Hat Enterprise Linux 7	Reporter:	Minfei Huang <mhuang>
Component:	kexec-tools	Assignee:	Xunlei Pang <xlpang>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Qiao Zhao <qzhao>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	ccui, ruyang
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-07-25 05:39:05 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1332412, 1332418
Bug Blocks:	1295826, 1296180, 1313485

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 3 Xunlei Pang 2016-02-19 02:27:00 UTC

posted patch:
http://post-office.corp.redhat.com/archives/kexec-kdump-list/2016-January/msg00118.html

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.