dnf install卡在“解决依赖关系”本质是元数据过期或仓库配置异常，需先dnf makecache刷新元数据，再检查repo可用性、禁用插件或强制ipv4解析。
dnf install 为什么卡在“解决依赖关系”不动
本质是元数据过期或仓库配置异常，不是网络慢导致的假死。dnf 默认启用 fastestmirror 插件，若镜像列表陈旧或某源不可达，会反复重试直到超时。
- 先运行
dnf makecache强制刷新本地元数据，比直接dnf install更快暴露真实问题 - 检查
/etc/yum.repos.d/下 repo 文件，确认baseurl或mirrorlist可访问（用curl -I测试） - 临时禁用插件试试：
dnf --noplugins install <pkg></pkg>，如果成功，说明是fastestmirror或generate_sqlite插件拖慢 - 某些企业内网环境禁用了 IPv6，但默认 repo 含 IPv6 地址，加
--setopt=ip_resolve=ipv4可跳过 DNS 轮询
yum update 和 dnf upgrade 的行为差异在哪
yum update 在 RHEL 8+/centos 8+ 实际是 dnf 的符号链接，但语义不同：update 只升级已安装包，upgrade 还会移除被替代的旧包（如 kernel 升级后自动清理旧内核）。
-
dnf upgrade是推荐命令，它等价于dnf --best --allowerasing upgrade，能处理包冲突和废弃依赖 -
yum update在较新系统上默认不带--allowerasing，遇到需删除包才能升级的情况会报错：Problem: package xxx requires yyy, but none of the providers can be installed - 升级内核时，
dnf upgrade kernel会保留旧版本，而dnf remove kernel-5.14.*才真正清理——别指望 upgrade 自动删
如何安全回滚一个刚用 dnf 安装错误的包
dnf 自带事务历史，但默认不开启自动保存，得靠 dnf history 查最近操作，再用 undo 回退。前提是没执行过 dnf history rollback 或清空过 /var/lib/dnf/history.sqlite。
- 列出最近事务：
dnf history list，找到对应 ID（比如123） - 查看该次操作详情：
dnf history info 123，确认它只改了你要撤的包 - 执行回滚：
dnf history undo 123；若提示 “No transaction with ID 123”，说明历史已被裁剪（history_record=0在/etc/dnf/dnf.conf中关闭了记录） - 如果历史不可用，只能手动卸载：
dnf remove <pkg-name></pkg-name>，但注意依赖可能已被其他包拉入，卸载时会连带提示要删哪些，别盲目确认
dnf search 搜不到明明存在的包怎么办
默认只搜已启用仓库中的包名和摘要，不索引文件路径或二进制名。比如想装 gcc 但搜 dnf search gcc 返回空，其实是包名叫 gcc-toolset-12-gcc 或属于 PowerTools 仓库（默认禁用）。
- 先确认仓库是否启用：
dnf repolist --enabled，常见遗漏的是epel、powertools、crb - 搜文件而非包名：
dnf provides "*/bin/gcc"或dnf provides "libssl.so.1.1"，这会触发文件数据库匹配 - 模糊搜索加通配符：
dnf search "python3*flask*"，注意引号防止 shell 展开 - 某些包被
modular流控制，需先dnf module list flask再dnf module install flask:2.0
事情说清了就结束。最常被忽略的是：dnf 的“智能”行为高度依赖元数据新鲜度和仓库状态，而不是命令本身多强大；一次 makecache 往往比反复重试 install 更省时间。