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 升级后自动清理旧内核）。

Linux Security Scanner

Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...

下载

• 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 更省时间。