Hi Martin,

I see your test used the localhost as the ssh dump target, kexec-tools uses ethtool to check the driver which is used by the nic.
As far as I know, "ethtool -i lo" always fail with the following error message:
```
Cannot get driver information: Operation not supported
```
In my opinion, when using ssh, localhost is not a valid target, how about to re-test it by using the remote host as the dump target?

Thanks,
Lichen

Well, *shrug* it has worked with localhost for years. E.g. on the Testing Farm (Fedora/RHEL gating) it's not possible to spawn a second VM to talk to, and even in our upstream tests it's fairly expensive to do that. 
What we could do is to not literally talk to "localhost", but to the IP address of any "proper" eth iface:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 172.27.0.15/24 brd 172.27.0.255 scope global dynamic noprefixroute eth0
       valid_lft 86232sec preferred_lft 86232sec

and use

   ssh root.0.15

in kdump.conf instead. But that doesn't work either, same error message.

How do you test kdump ssh upstream/in RHEL? That could be interesting for us to look at.

Note that talking to a remote machine does not currently work either, see bug 2151504 (although that was for NFS, but it fails very early on during network configuration in initrd)

The system role kdump test https://github.com/linux-system-roles/kdump/blob/master/tests/tests_ssh.yml is also affected by this issue

(In reply to Martin Pitt from comment #2)
> Well, *shrug* it has worked with localhost for years. E.g. on the Testing
> Farm (Fedora/RHEL gating) it's not possible to spawn a second VM to talk to,
> and even in our upstream tests it's fairly expensive to do that. 

You use tmt to run tests, right? Yeah, supporting multihost tests is still an ongoing effort
https://github.com/teemtee/tmt/issues/726 for tmt.

> What we could do is to not literally talk to "localhost", but to the IP
> address of any "proper" eth iface:

> 
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
> group default qlen 1000
>     inet 172.27.0.15/24 brd 172.27.0.255 scope global dynamic noprefixroute
> eth0
>        valid_lft 86232sec preferred_lft 86232sec
> 
> and use
> 
>    ssh root.0.15
> 
> in kdump.conf instead. But that doesn't work either, same error message.

Yes, this is expected because it's still dumping to localhost thus still still using loopback device.

> 
> How do you test kdump ssh upstream/in RHEL? That could be interesting for us
> to look at.


We use own implemented framework for the tests. You can check https://src.fedoraproject.org/rpms/kexec-tools/blob/rawhide/f/tests.
For an example of triggering it in Github, you can also check out the experimental https://github.com/coiby/kexec-tools/tree/github_action/tests

> 
> Note that talking to a remote machine does not currently work either, see
> bug 2151504 (although that was for NFS, but it fails very early on during
> network configuration in initrd)

I've asked for some debugging logs as I failed to reproduce that bug.

Thanks Coiby! I replied to your proposed patch with a (successful) test result and a proposal how to make it more robust and generic. I probably can't post to the kexec-@ list, but you were in CC:.

> For an example of triggering it in Github, you can also check out the experimental https://github.com/coiby/kexec-tools/tree/github_action/tests

Interesting -- do you use self-hosted runners, or do you just suffer through the glacial speed of emulation? (As GitHub's runners don't have /dev/kvm)

> bug 2151504

Thanks for your debugging there, this seems well understood now.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (kexec-tools bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2463