Thanks for the doc update.
On Thu, Feb 18, 2021 at 4:42 PM Hari Bathini <hbathini(a)linux.ibm.com> wrote:
While fadump-howto.txt talks about what happens to network interface
name on setting up a remote dump target in FADump mode, it doesn't
explicitly specify the negative consequences of it. Make it explicit
and provide a recommendation to overcome the same.
Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com>
fadump-howto.txt | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/fadump-howto.txt b/fadump-howto.txt
index 5360f3d..433e9a6 100644
@@ -224,12 +224,16 @@ Things to remember:
dracut_args --add "network"
4) If FADump is configured to capture vmcore to a remote dump target using SSH
- or NFS protocol, the network interface is renamed to kdump-<interface-name>
- if <interface-name> is generic, for example, *eth#, or net#. This problem
- occurs because the vmcore capture scripts in the initial RAM disk (initrd)
- add the kdump- prefix to the network interface name to secure persistent
- naming. As the same initrd is used for production kernel boot, the interface
- name is changed for the production kernel too.
+ or NFS protocol, the corresponding network interface '<interface-name>'
+ renamed to 'kdump-<interface-name>', if it is generic (like *eth# or
+ It happens because vmcore capture scripts in the initial RAM disk (initrd)
+ add the 'kdump-' prefix to the network interface name to secure persistent
+ naming. And as capture kernel and production kernel use the same initrd in
+ case of FADump, the interface name is changed for the production kernel too.
+ This is likely to impact network configuration setup for production kernel.
+ So, it is recommended to use a non-generic name for a network interface,
+ before setting up FADump to capture vmcore to a remote dump target based on
+ that network interface, to avoid running into network configuration issues.
Dump Triggering methods:
Acked-by: Kairui Song <kasong(a)redhat.com>