-
Bug
-
Resolution: Not a Bug
-
Normal
-
None
-
rhel-9.2.0
-
None
-
Moderate
-
rhel-sst-kernel-debug
-
ssg_core_kernel
-
None
-
False
-
-
None
-
None
-
None
-
Automated
-
If docs needed, set a value
-
-
Unspecified
-
None
Description of problem:
The kdump cannot save vmcore via ssh if the network was configured via ifcfg format of network-scripts
Version-Release number of selected component (if applicable):
RHEL-9.2.0-20230411.14_x86_64
5.14.0-284.10.1.el9_2.x86_64
kexec-tools-2.0.25-13.el9_2.x86_64
hyperv-daemons-0-0.41.20190303git.el9.x86_64
NetworkManager-1.42.2-1.el9.x86_64
How reproducible:
100%
Steps to Reproduce:
1. Create two VMs: VMa and VMb, and add an Internal NIC for each VM
2. Config the added Inernal NIC (eth1 here) as below:
VMa:
cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
NAME=eth1
BOOTPROTO=static
IPADDR=9.0.0.10
NETMASK=255.255.255.0
ONBOOT=yes
- ip link set dev eth1 up
- ip addr add 9.0.0.10/255.255.255.0 broadcast 9.0.0.255 dev eth1
VMb:
- ip addr add 9.0.0.11/255.255.255.0 broadcast 9.0.0.255 dev eth1
- ping 9.0.0.11
PING 9.0.0.11 (9.0.0.11) 56(84) bytes of data.
64 bytes from 9.0.0.11: icmp_seq=1 ttl=64 time=0.264 ms
- ping 9.0.0.10
PING 9.0.0.10 (9.0.0.10) 56(84) bytes of data.
64 bytes from 9.0.0.10: icmp_seq=1 ttl=64 time=0.486 m
3. Configure the kdump as below:
VMa: ($vm2ipv4 here is 9.0.0.11)
Edit /etc/kdump.conf:
ssh root@$vm2ipv4
sshkey /root/.ssh/id_rsa
path /var/crash
core_collector makedumpfile -F -l --message-level 1 -d 31
exit | ssh -o StrictHostKeyChecking=no root@$vm2ipv4
kdumpctl propagate
kdumpctl restart kdump
service kdump restart
4. Trigger kdump:
- echo c > /proc/sysrq-trigger
Actual results:
VMa will hang and cannot save vmcore, console log as below:
Starting Kdump Vmcore Save Service...
Kdump is using the default log level(3)
Bad kdump network destination: 9.0.0.11
Bad kdump network destination: 9.0.0.11
Bad kdump network destination: 9.0.0.11
......
Expected results:
Can save kdump vmcore successfully
Additional info:
1. This issue doesn't occur on RHEL9.1 with the same steps
5.14.0-162.6.1.el9_1.x86_64
NetworkManager-1.40.0-1.el9.x86_64
kexec-tools-2.0.24-5.el9.x86_64
2. This issue doesn't occur on RHEL8.8 with the same steps
4.18.0-452.el8.x86_64
kexec-tools-2.0.25-5.el8.x86_64
NetworkManager-1.40.10-1.el8.x86_64
3. Check kdump img included the eth1 configuration as below, and found autoconnect=false
[root@LISAv2-OneVM-xxq-9 ~]# lsinitrd /boot/initramfs-$(uname -r)kdump.img | grep eth1
rw------ root/root 276 2023-04-14 11:56 squashfs-root/etc/NetworkManager/system-connections/eth1.nmconnection
[root@LISAv2-OneVM-xxq-9 ~]# cat /etc/NetworkManager/system-connections/eth1.nmconnection
cat: /etc/NetworkManager/system-connections/eth1.nmconnection: No such file or directory
[root@LISAv2-OneVM-xxq-9 ~]# mkdir tmp && cd tmp && lsinitrd -unpack /boot/initramfs$(uname -r)kdump.img && unsquashfs squash-root.img
Parallel unsquashfs: Using 2 processors
649 inodes (1043 blocks) to write
[=======================================================================================================================================================================================|] 1043/1043 100%
created 485 files
created 135 directories
created 158 symlinks
created 5 devices
created 0 fifos
created 0 sockets
[root@LISAv2-OneVM-xxq-9 tmp]# cat squashfs-root/etc/NetworkManager/system-connections/eth1.nmconnection
[connection]
id=eth1
uuid=455e75b1-f366-4ef0-ab60-2b4f1684c977
type=ethernet
autoconnect=false
wait-device-timeout=60000
[ethernet]
mac-address=00:15:5D:C4:17:C5
[ipv4]
address1=9.0.0.10/24
may-fail=false
method=manual
[ipv6]
addr-gen-mode=default
method=disabled
[proxy]
[root@LISAv2-OneVM-xxq-9 tmp]#
4. This issue not occurs if replace step 2 as below:
nmcli con add type ethernet con-name eth1 ifname eth1 ipv4.addresses 9.0.0.10/24 ipv4.method manual
nmcli connection reload
nmcli connection up eth1