虚拟机里的dnf警告绝大多数时候不是病毒，也不是系统崩溃，而是dnf在虚拟化环境中拿不到部分硬件信息导致的误报，处理思路是先判断警告等级再对症下药。
为什么虚拟机里的 dnf 警告特别多
用过虚拟机的朋友基本都撞过这个场面：第一次运行dnf update，屏幕唰唰滚出一片黄色文字，中文互联网一搜“虚拟机 dnf警告”，满屏的“error”“failed”，吓人得很，其实拆开看，这些警告多半是同一个根源虚拟机缺少真实硬件层，让dnf的依赖检查脚本“破了防”。
dnf作为包管理器,执行更新时不仅要算软件包依赖，还会调用系统里的各种环境检测脚本，比如grub2-common要探测引导方式，kernel要检查固件接口，systemd要确认dbus状态，物理机上这些脚本跑得顺风顺水，一旦换到虚拟机里，EFI分区不存在、SMBIOS信息不完整、TPM设备缺失，脚本一跑就报warning，dnf本身没有失败，只是把脚本的抱怨原样转述给你。
行业共识认为,这类警告对系统运行没有实质影响，真正要警惕的是那些伴随着包安装失败、依赖冲突、进程中断的红色error，那些才需要动手干预。
虚拟机 dnf 运行报错时，先分清警告等级
很多教程把warning和error混在一起讲,看的人越看越慌，实际上dnf的输出等级非常明确，照着等级处理就不会跑偏。
可忽略的警告长什么样
- 文字以
warning:开头，后面跟着的通常是Could not、Failed to probe、Unable to detect这类表述 - 警告后面同一行或紧接着的几行，软件包依然显示
Installed或Updated - 警告期间没有任何retry、abort、interrupt提示
- 更新结束后
dnf history里能看到完整的事务记录
这类警告的来源高度集中在kernel-firmware、grub2、selinux-policy三个包上，以grub2为例，安装脚本要检测当前系统用的是BIOS还是UEFI引导，它在虚拟机里探测不到
/sys/firmware/efi目录，于是打印warning: failed to detect EFI但脚本随后会走默认的BIOS路径，事情照样办完。
需要干预的警告特征
error:或者Problem:前缀出现- 伴随
Nothing to do、Failed to download、Delta RPMs disabled等完整失败消息 dnf update在某个包上反复重试后终止- 提示依赖无法满足：
package X requires Y, but none of the providers can be installed
出现这些才需要查网络、查镜像源、查repo配置。网络源问题是error的头号来源，其次是第三方repo的GPG密钥失效，再往后才是真正的依赖冲突，统计来看，纯依赖冲突导致的dnf失败只占很小比例，多数人删掉第三方repo后问题就消失了。
虚拟机 dnf update 警告的高频场景与对策
不同虚拟化平台、不同镜像来源，撞见的警告内容虽然相似，但触发点各不相同，对照场景处理，比死记命令更管用。
从模板克隆出来的虚拟机首次update
这是最经典的一幕,模板机里预装好了系统，克隆出好几台新机器后，一跑dnf update，满屏警告，原因在于克隆机的D-Bus machine-id跟模板机完全一致，systemd脚本发现machine-id异常，立刻打出warning: Failed to connect to bus。
处理方法是重新生成machine-id：
rm -f /etc/machine-id systemd-machine-id-setup dnf clean all dnf makecache
这个操作在VMware和KVM的克隆场景下,能消掉大半看似吓人的warning。
老镜像遇到新版内核
多年来,不少人喜欢用某个“经典老版本”的ISO装虚拟机，装完联网更新，结果内核包从3.10跳到4.18，跨度大到让dnf的依赖解析器措手不及，典型警告是：
warning: /boot/grub2/grub.cfg created as a filewarning: %post(kernel-core) scriptlet failed
这些警告出现时,系统处于可用状态，只是引导配置没有自动更新，这时候补一刀重建initramfs和grub配置即可：
dracut -f grub2-mkconfig -o /boot/grub2/grub.cfg
国内云服务器上跑dnf时出现的慢速警告
用过国内云服务器的朋友常遇到：dnf update跑着跑着没动静，然后弹出一连串Could not retrieve mirrorlist警告，这不是虚拟机的问题，是镜像源连通性问题。
行业共识认为,国内云服务器上最稳妥的做法是换上国内镜像源，比如简米云、清华TUNA，具体操作路径：编辑/etc/yum.repos.d/下的.repo文件，把mirrorlist=注释掉，启用baseurl=指向国内镜像地址，然后dnf clean all && dnf makecache，这类处理方式普遍认为能显著改善更新速度和稳定性。
虚拟机 dnf 警告的表格速查
| 实际影响 | 建议操作 |
|—|—|—|
| Failed to connect to bus | 无，机器ID冲突所致 | 重建machine-id |
| Unable to detect EFI | 无，走BIOS引导 | 忽略 |
| Could not retrieve mirrorlist | 更新可能中断 | 换国内镜像源 |
| Delta RPMs disabled | 无，正常降级机制 | 忽略 |
| scriptlet failed | 可能影响内核引导 | 重建initramfs和grub配置 |
让 dnf 警告不再是麻烦：实操修复步骤
处理虚拟机里的dnf警告,顺序比技巧重要。先看日志，再清缓存，最后碰引导配置，乱来容易把系统搞到起不来。
第一步：看dnf的事务历史
dnf history list dnf history info <最近事务ID>
history里能看到每次事务的装包数、升级数、失败数，如果失败数是0，那眼前的warning多半都可以忽略，如果失败数大于0，用dnf history info查看具体是哪个包出了错。
第二步：清理缓存重建元数据
这一步能解决相当一部分莫名其妙的警告：
dnf clean all dnf makecache
clean all会清掉缓存里的包和元数据，makecache重新拉取repo数据，缓存损坏导致的下载校验失败、依赖解析异常，基本都能靠这两条命令解决。
第三步：修复引导相关警告
前面提到过grub2和kernel-core的警告，如果更新完内核后重启进不了系统，多半是引导配置没刷新，依次执行：
dnf reinstall kernel-core dracut -f grub2-mkconfig -o /boot/grub2/grub.cfg
这三条命令分别负责重装内核核心文件、重建initramfs镜像、重新生成grub配置，执行完重启，大部分引导类警告引发的后遗症就能消除。
第四步：关闭不必要的插件输出
dnf的某些插件天生话多,比如fastestmirror插件每次都会打印测速结果，langpacks在虚拟机里经常报地区化警告，在/etc/dnf/dnf.conf里加一行：
fastestmirror=0
再把/etc/dnf/plugins/下不需要的插件配置文件改名禁用。输出干净了，真正的问题也更容易看见。
Q&A：虚拟机 dnf 警告常见疑问
VMware虚拟机里的dnf警告可以无视吗
可以,前提是警告以warning:开头且事务最终成功，VMware虚拟机的硬件抽象层做得比较完善，绝大多数警告来自内核模块的探测脚本，对包本身没有任何影响，判断标准就一条：dnf history info里没有失败记录，就可以当无事发生。
dnf警告会不会影响后续的yum使用
dnf和yum在RHEL系的较新版本中是同一套底层实现,dnf的警告在yum里同样会出现，警告本身不影响yum的调用，yum install、yum update都能正常使用，但如果dnf警告伴随的是repo源不可达，那yum也会遇到相同的源错误，需要先修复repo配置再操作。
虚拟机里的dnf警告是否意味着系统存在安全漏洞
两者之间没有关联,dnf警告是包管理器执行环境检测时的提示信息，安全漏洞取决于已安装软件包的版本和CVE通告，更新系统时看到警告，说明dnf在尽力适配虚拟化环境，并不代表安全状态恶化，若要检查漏洞，正确做法是查看dnf updateinfo输出的安全公告列表，而不是逐条解读警告文本。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/665494.html
