On Fri, Nov 10, 2023 at 09:46:03AM +0800, Dave Young wrote:
Hi Coiby,
Hi Dave,
Thanks for reviewing the patch!
On Fri, 10 Nov 2023 at 08:40, Coiby Xu <coxu(a)redhat.com> wrote:
>
> Some users may choose to manage /etc/resolve.conf manually. In this case,
> network dumping will not work because DNS resolution doesn't work. Copy
> /etc/resolve.conf to kdump initrd if this file is not managed by
> systemd-resolved or NetworkManager.
>
> Fixes: 63c3805c ("Set up kdump network by directly copying NM connection profile
to initrd")
> Reported-by: Curtis Taylor <cutaylor(a)redhat.com>
> Cc: Jie Li <jieli(a)redhat.com>
> Signed-off-by: Coiby Xu <coxu(a)redhat.com>
> ---
> dracut-module-setup.sh | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/dracut-module-setup.sh b/dracut-module-setup.sh
> index ff53d084..e6355973 100755
> --- a/dracut-module-setup.sh
> +++ b/dracut-module-setup.sh
> @@ -563,6 +563,19 @@ kdump_collect_netif_usage() {
> fi
> }
>
> +kdump_install_resolv_conf() {
> +
> + local _resolv_conf=/etc/resolv.conf
> +
> + # Some users may choose to manage /etc/resolve.conf manually.
> + #
> + # We can tell this case by confirming this file is not manged by
> + # systemd-resolved or NetworkManager.
> + if ! grep -qs "^nameserver 127.0.0.53" "$_resolv_conf"
&& ! grep -qs "^# Generated by NetworkManager"
"$_resolv_conf"; then
Is the 127.0.0.53, is it systemd-resolved specific? How about just
check the status of systemd-resolvd by checking return value of below:
systemctl -q is-active systemd-resolved
Yes, I think it's systemd-resolved specific according to "man
systemd-resolved". I've applied this suggestion in v3 as it's simpler.
Thanks!
Otherwise for NetworkManager setup, it could be that people just edit
the NM generated resolv.conf, but keep the comment line there:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
If we just blindly install the resolv.conf, I think it will be
overwritten by NM in kdump kernel initramfs during bootup if people
use NM, so it does not matter to have it copied without any checking.
Thanks for sharing the helpful doc which made I realize I missed the
case where users could also manually configure resolv.conf by using a
symbolic file. In v3, I've addressed this case. And yes, grep -qs "^#
Generated by NetworkManager" is unreliable and unnecessary, thanks for
pointing out it!
> + dracut_install "$_resolv_conf"
> + fi
> +}
> +
> # Setup dracut to bring up network interface that enable
> # initramfs accessing giving destination
> kdump_install_net() {
> @@ -575,6 +588,7 @@ kdump_install_net() {
> kdump_setup_znet
> kdump_install_nm_netif_allowlist "$_netifs"
> kdump_install_nic_driver "$_netifs"
> + kdump_install_resolv_conf
> fi
> }
>
> --
> 2.41.0
> _______________________________________________
> kexec mailing list -- kexec(a)lists.fedoraproject.org
> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/kexec@lists.fedoraproject.org
> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Thanks
Dave
--
Best regards,
Coiby