kdump不会自动上传vmcore，必须在/etc/kdump.conf中显式配置网络目标（如net user@host:/path）并确保ssh免密、远程目录可写、驱动可用，否则默认仅本地保存至/var/crash。
Linux 本身没有“系统崩溃上传功能”这个内置开关，kdump 生成的 vmcore 不会自动上传——它默认只保存到本地路径（如 /var/crash/），上传必须显式配置传输方式和目标。所谓“配置上传”，本质是配置 kdump 的转储目标为网络路径，并确保链路可用。
为什么 kdump 不传文件？检查 /etc/kdump.conf 的 target 设置
kdump 是否上传，完全取决于 /etc/kdump.conf 中的 path 和 net 行。常见错误是只改了 path /var/crash 却没启用网络目标：
- 要上传到远程服务器，必须注释掉所有本地
path行，启用类似net user@192.168.1.100:/crash或net root@backup.example.com:/var/crash -
net后面的地址必须能被捕获内核访问：不能依赖 DNS（得用 IP），SSH 必须免密（ssh-copy-id提前配好），且远程目录需存在、有写权限 - 如果同时写了
path和net，kdump会优先走path（即本地保存），上传被静默忽略
上传失败时常见的报错和对应动作
崩溃后发现 /var/crash/ 有新目录但远程没收到，大概率是捕获内核环境缺失依赖：
-
*** ERROR *** unable to open ZMODEM session—— 这不是kdump的错，是误把sz/rz错觉成上传机制；kdump用的是 SSH 或 NFS，跟 ZModem 无关 -
ssh: connect to host x.x.x.x port 22: No route to host—— 捕获内核未加载网卡驱动，需在/etc/kdump.conf中加dracut_args --regenerate-all并重建 initramfs -
Permission denied (publickey)—— 捕获内核使用的 SSH key 不是用户主目录下的那个，它只认/usr/share/kdump/ssh_id_rsa，必须把私钥放这里并chmod 600
云服务器或跳板机环境下上传更易失败
公有云实例（AWS/Azure/阿里云）或经跳板机中转的场景，kdump 上传失败率显著升高，因为：
- 云厂商的定制内核可能未编译
CONFIG_NET_9P或CONFIG_NFS_FS，导致 NFS/9P 协议不可用，只能靠 SSH - 跳板机或防火墙会拦截 SSH 连接握手包，捕获内核超时后直接 fallback 到本地保存，不报错也不重试
- 某些云实例的网卡是 virtio 类型，但捕获内核 initramfs 里没包含
virtio_net驱动，ip link看不到任何接口
这种情况下，别硬调上传，先确认 kdump 能否至少本地落盘成功（systemctl status kdump + 崩溃后查 /var/crash/），再考虑用 scp 在重启后手动传出去——比在捕获内核里折腾网络稳定得多。
