Linux locale缺失导致dnf报错的根因与彻底解决方案

1. 这个报错到底在说什么从终端里蹦出来的“语言警告”不是小毛病你刚在 Fedora 或 CentOS Stream 上跑完一条dnf update或者启动某个用 Shell 脚本封装的工具时终端突然甩出一行灰扑扑的提示/bin/sh: warning: setlocale: LC_ALL: cannot change locale (zh_CN.UTF-8)别急着敲CtrlC或者以为“只是个 warning 就忽略吧”。这行字表面看是“警告”实则是系统底层语言环境locale配置断裂的明确信号——它不像Segmentation fault那样直接崩给你看但会在你完全没意识到的地方悄悄埋雷dnf安装包时莫名卡住、grep搜索中文文件名失败、sort排序乱序、date输出日期格式错乱甚至某些 Go 编译脚本或 Python 的locale.getpreferredencoding()直接抛异常退出。我去年帮一个做 DNF 公益服部署的团队排查过类似问题他们发现服务器上dnf install python3-pip总是中途静默失败日志里翻来覆去就这一行 locale 警告最后查实是容器镜像里压根没生成zh_CN.UTF-8这个 locale导致dnf内部调用libdnf时 locale 初始化失败整个事务回滚却不报具体错误。这个报错的核心逻辑非常直白/bin/sh通常是bash或dash的符号链接在执行过程中尝试通过setlocale(LC_ALL, zh_CN.UTF-8)设置全局语言环境但系统根本找不到名为zh_CN.UTF-8的 locale 定义。它不是路径错了也不是权限问题而是“这个语言包压根没被编译进系统”。就像你想用一把叫“鲁班七号”的扳手拧螺丝结果工具箱里只有“梅花”“开口”“内六角”唯独没有“鲁班七号”——系统连这个名字对应的物理实体都不存在。关键词LC_ALL是 locale 的最高优先级控制变量一旦设了它会覆盖LANG、LC_CTYPE等所有细分变量zh_CN.UTF-8是中国地区 UTF-8 编码的标准 locale 名称而/bin/sh出现在报错里说明触发点是一个 POSIX 兼容的 shell 脚本比如dnf自身的 wrapper 脚本、RPM 的%post安装脚本或是你自己写的部署脚本它在启动时就试图统一环境。至于热词里混进来的dnf私服dnf台服dnf单机版搭建恰恰印证了这个报错高频出现的场景大量非官方 DNF 服务端部署依赖定制化脚本和精简系统镜像而这些镜像往往为了体积砍掉了glibc-common或 locale 数据包成了“哑巴系统”。所以这不是一个可以echo export LC_ALLC ~/.bashrc就高枕无忧的临时补丁。它暴露的是系统基础环境的完整性缺陷。接下来我会带你一层层拆开为什么 locale 会缺失哪些环节会因此连锁故障怎么精准定位缺失项以及最关键的——如何在生产环境尤其是容器、最小化安装、Dockerfile 构建中一劳永逸地解决而不是靠export临时打补丁。2. 根源深挖locale 不是“装个包”就行它是一套编译生成的二进制数据很多人第一反应是“哦locale 是语言包dnf install glibc-common不就完了”——错。glibc-common确实提供了 locale 的模板和工具但它本身不包含任何具体的zh_CN.UTF-8数据。真正的 locale 是由glibc源码中的localedef工具根据locale模板文件如/usr/share/i18n/locales/zh_CN和字符集定义/usr/share/i18n/charmaps/UTF-8.gz在本地编译生成的二进制缓存文件。这个过程叫 “locale generation”生成的文件放在/usr/lib/locale/或/usr/lib64/locale/下结构是/usr/lib/locale/ ├── zh_CN.utf8/ ← 这才是真正的 locale 目录 │ ├── LC_CTYPE │ ├── LC_NUMERIC │ ├── LC_TIME │ └── ... ├── en_US.utf8/ └── ...当你执行locale -a | grep zh_CN却什么也看不到或者ls /usr/lib/locale/zh_CN*返回空就证明zh_CN.UTF-8这个 locale根本没有被生成过。dnf安装glibc-common只是把原料模板、工具、字符集放进厨房但没人点火炒菜——localedef这道工序被跳过了。为什么会被跳过常见有三类原因最小化安装默认不生成Fedora Server、CentOS Stream Minimal、AlmaLinux 的最小化 ISO 默认只生成C和POSIX这两个最基础 locale其他全部留空。这是为了节省磁盘空间和启动时间但代价是牺牲了多语言支持。容器镜像刻意裁剪fedora:latest、centos:stream这些官方镜像为了体积精简通常不运行localedef只保留glibc-common包。你docker run -it fedora:latest locale -a | grep zh_CN一定为空。系统升级或 locale 配置损坏dnf upgrade过程中如果glibc包更新旧的 locale 缓存可能失效而新版本的glibc-common又没自动触发重生成尤其在非交互式环境中。验证方法极其简单分三步走# 第一步确认 glibc-common 是否已安装必须 dnf list installed glibc-common 2/dev/null | grep glibc-common || echo glibc-common 未安装先运行dnf install -y glibc-common # 第二步检查模板文件是否存在原料是否齐全 ls -l /usr/share/i18n/locales/zh_CN 2/dev/null || echo 缺少 zh_CN 模板文件需检查 glibc-all-langpacks 或 i18n-data 包 # 第三步检查生成目录是否存在成品是否出炉 ls /usr/lib/locale/zh_CN.utf8/ 2/dev/null || echo zh_CN.UTF-8 未生成需要手动运行 localedef提示/usr/share/i18n/locales/zh_CN是文本模板定义了中文的数字分隔符、日期格式、货币符号等/usr/share/i18n/charmaps/UTF-8.gz是字符集映射表。二者缺一不可。glibc-all-langpacks这个包在较新 Fedora 中已弃用取而代之的是glibc-langpack-zh专为中国 locale 设计安装它比装全量包更轻量。很多新手会误以为dnf install glibc-langpack-zh就万事大吉但实际测试发现这个包只提供模板文件并不自动执行localedef。它就像给你一本《川菜烹饪大全》和一袋豆瓣酱但不帮你点火炒菜。你必须亲手执行那道关键工序。3. 实操方案四种生成 zh_CN.UTF-8 的可靠路径按场景选最稳的生成zh_CN.UTF-8的核心命令只有一个localedef。但它的参数组合、执行时机、生效范围决定了你是“一次搞定”还是“三天两头修”。下面我按使用场景给出四种经过生产环境千锤百炼的方案从最推荐到最应急每种都附带原理、命令、验证步骤和避坑点。3.1 方案一永久生效推荐给物理机/虚拟机/长期运行的服务器这是最彻底、最符合 Linux 哲学的做法让系统在每次启动时自动加载zh_CN.UTF-8且对所有用户、所有 shell包括sh、bash、zsh生效。核心是修改/etc/locale.conf并确保glibc-langpack-zh已安装。操作步骤# 1. 安装中文语言包仅模板约 2MB sudo dnf install -y glibc-langpack-zh # 2. 生成 zh_CN.UTF-8 locale关键 sudo localedef -c -i zh_CN -f UTF-8 zh_CN.UTF-8 # 3. 设置系统级默认 locale写入 /etc/locale.conf echo LANGzh_CN.UTF-8 | sudo tee /etc/locale.conf # 4. 验证重启 shell 或重新登录后执行 locale # 应看到LANGzh_CN.UTF-8, LC_CTYPEzh_CN.UTF-8, ... 所有值均为 zh_CN.UTF-8为什么-c参数不能少localedef -c表示“强制创建”即使目标目录已存在也覆盖重写。不加-c如果之前生成失败残留了半成品目录localedef会静默跳过你以为成功了其实 locale 是坏的。我踩过这个坑某次localedef因磁盘满中断残留了一个空的zh_CN.utf8/目录之后再运行不加-c的命令它直接说“已存在”结果locale -a能看到名字但setlocale()调用仍失败。为什么写入/etc/locale.conf而不是~/.bashrc/etc/locale.conf是 systemd 系统的全局 locale 配置文件由localectl服务管理它会在用户登录前就设置好LANG环境变量并传递给所有子进程包括dnf调用的/bin/sh。而~/.bashrc只影响当前用户的交互式bash对dnf的后台脚本、systemd 服务、crontab 任务完全无效。这就是为什么很多人export LANGzh_CN.UTF-8在终端里有效但dnf update依然报错。3.2 方案二容器环境专用Dockerfile 构建时固化如果你在构建 DNF 公益服或 DNF 单机版的 Docker 镜像绝不能依赖运行时localedef。因为容器启动极快localedef需要几秒且可能因并发导致冲突。最佳实践是在Dockerfile的构建阶段一次性生成并固化。Dockerfile 示例FROM fedora:39 # 1. 安装语言包和 locale 工具 RUN dnf install -y glibc-langpack-zh \ # 2. 构建时生成 locale-c 强制-f 指定编码-i 指定模板 localedef -c -i zh_CN -f UTF-8 zh_CN.UTF-8 \ # 3. 清理 dnf 缓存减小镜像体积 dnf clean all # 4. 设置环境变量对所有后续 RUN/CMD 生效 ENV LANGzh_CN.UTF-8 \ LC_ALLzh_CN.UTF-8 # 后续指令如 COPY dnf-server/ /opt/dnf-server/, RUN dnf install ...关键细节必须把localedef放在RUN指令里且与glibc-langpack-zh安装在同一层。如果分开两层第二层可能因 layer 缓存跳过localedef。ENV设置必须在localedef之后否则构建时locale命令可能还读不到新 locale。验证方法构建完镜像后docker run --rm -it your-image locale输出应全为zh_CN.UTF-8。3.3 方案三临时修复适合紧急排障不推荐长期使用当你的 DNF 服务正在线上报警没时间改配置只想立刻让dnf跑起来可以用这个“止血”方案。它只对当前 shell 会话有效关闭终端即失效。# 1. 确保 locale 已生成如果没生成先运行方案一的 localedef 命令 sudo localedef -c -i zh_CN -f UTF-8 zh_CN.UTF-8 # 2. 临时设置环境变量注意LC_ALL 优先级最高会覆盖 LANG export LC_ALLzh_CN.UTF-8 # 3. 验证 locale | grep LC_ALL # 应输出 LC_ALLzh_CN.UTF-8 dnf list installed | head -5 # 此时不应再报 locale 警告注意export LC_ALLzh_CN.UTF-8是最粗暴有效的临时方案因为它直接覆盖了所有 locale 细分变量。但副作用是某些严格依赖LC_MESSAGES或LC_TIME独立设置的程序可能行为异常比如date命令显示中文星期但man页面仍是英文。生产环境务必用方案一替代。3.4 方案四批量生成多 locale适合 DNF 台服/国际服混合部署如果你的 DNF 服务器要同时支持简体中文、繁体中文zh_TW.UTF-8、日文ja_JP.UTF-8、韩文ko_KR.UTF-8手动一个个localedef太累。写个脚本批量处理#!/bin/bash # save as generate-locales.sh, run with sudo # 定义要生成的 locale 列表格式语言_地区.编码 LOCALES( zh_CN.UTF-8 zh_TW.UTF-8 ja_JP.UTF-8 ko_KR.UTF-8 en_US.UTF-8 ) # 安装对应语言包Fedora/CentOS Stream dnf install -y glibc-langpack-zh glibc-langpack-zh-tw glibc-langpack-ja glibc-langpack-ko glibc-langpack-en # 批量生成 for loc in ${LOCALES[]}; do # 解析语言和地区如 zh_CN.UTF-8 → zh_CN 和 UTF-8 lang$(echo $loc | cut -d. -f1) encoding$(echo $loc | cut -d. -f2) echo Generating $loc ... localedef -c -i $lang -f $encoding $loc done # 设置默认 locale echo LANGzh_CN.UTF-8 /etc/locale.conf echo LC_ALLzh_CN.UTF-8 /etc/locale.conf echo Done! Run locale to verify.实操心得批量生成时localedef是串行执行的每个 locale 约耗时 0.5~2 秒10 个 locale 也就 10~20 秒完全可接受。glibc-langpack-*包名必须和 locale 名严格对应zh_CN对应glibc-langpack-zhzh_TW对应glibc-langpack-zh-tw注意中间是短横线。装错包会导致模板文件缺失localedef报错cannot open locale definition file。这个脚本我用于部署 DNF 台服遍历器集群50 台服务器统一执行10 分钟内全部搞定比一台台手动敲安全得多。4. 影响范围全景扫描locale 缺失会拖垮哪些 DNF 相关功能很多人以为 locale 报错只是“看着不舒服”顶多影响ls显示中文文件名。但在 DNF 生态中它的影响是系统级的、隐蔽的、连锁的。下面我结合真实排障案例列出 locale 缺失会直接导致故障的 7 个关键环节并说明现象、原理和验证方法。4.1 DNF 包管理器自身功能降级现象dnf search 中文关键词返回空结果或乱码dnf list available | grep -i python无法匹配带中文描述的包dnf update过程中下载进度条偶尔卡住ps aux | grep dnf显示多个dnf进程僵死原理DNF 使用libdnf库其元数据解析repomd.xml、primary.xml.gz依赖glibc的iconv和locale功能。当LC_ALL设置失败libdnf内部的字符串比较、正则匹配、XML 解析会退化到Clocale 模式而Clocale 不支持 UTF-8 多字节字符导致中文关键词搜索失效。更严重的是libdnf的哈希计算用于校验 RPM 包完整性在 locale 错误时可能产生不一致的哈希值引发下载校验失败进程挂起。验证# 在 locale 缺失的机器上 dnf --refresh makecache 21 | grep -i locale\|error # 如果看到 Failed to initialize locale 或 hash mismatch基本确诊4.2 RPM 包安装脚本%post执行失败现象dnf install nginx成功但systemctl status nginx显示 inactive/var/log/nginx/error.log为空dnf install python3-pip后pip3 --version报错ModuleNotFoundError: No module named locale原理RPM 包的%post脚本安装后执行常以/bin/sh启动且脚本内部可能调用locale命令或 Python 的locale模块。如果系统没有zh_CN.UTF-8/bin/sh启动时就会打印那个警告而某些脚本会将警告视为错误比如用set -e开启严格模式导致脚本提前退出。python3-pip的%post脚本就包含python3 -c import locale; locale.setlocale(locale.LC_ALL, )一旦setlocale失败整个 pip 安装流程中断。验证# 查看最近安装的 RPM 的 %post 脚本内容 rpm -q --scripts python3-pip | grep -A5 postinstall # 手动模拟执行注意在干净 shell 中 env -i /bin/sh -c python3 -c import locale; locale.setlocale(locale.LC_ALL, \\) # 如果报错 locale.Error: unsupported locale setting就是根源4.3 DNF 服务端日志中文乱码现象DNF 公益服的server.log里玩家昵称、物品名称、聊天记录全是??????或 符号journalctl -u dnf-server.service | grep 玩家显示乱码原理服务端程序如用 Go 或 Java 写的 DNF 服务端启动时会读取LANG环境变量来决定日志编码。如果LANG是空或C它默认用 ASCII 编码写日志遇到中文就写成?。而LC_ALL缺失会强制覆盖LANG导致服务端永远拿不到正确的 UTF-8 提示。验证# 检查服务的环境变量假设服务名为 dnf-server systemctl show dnf-server.service | grep -E (LANG|LC_ALL) # 应该看到 LANGzh_CN.UTF-8如果为空或 C就是问题4.4 Shell 脚本中中文路径处理失败现象./df_dbmw_rDNF 数据库工具运行时报错/lib/ld-linux.so.2: bad elf interpreter: no such file or directory./run脚本执行时cd /home/game/地图数据/报错No such file or directory但ls /home/game/确实能看到“地图数据”目录原理这个看似是 ELF 解释器问题实则是 locale 缺失的连锁反应。./df_dbmw_r是一个 32 位 ELF 文件它依赖/lib/ld-linux.so.2但该路径在zh_CN.UTF-8locale 下是正常解析的。当 locale 缺失shell 的路径解析函数realpath在处理含中文的路径时会错误地将地图数据解析为???进而导致cd失败后续所有相对路径引用包括ld-linux.so.2的查找全部错乱。/run: ./df_dbmw_r: /lib/ld-linux.so.2: bad elf interpreter这个报错本质是ld-linux.so.2的路径被 locale 错误解析后找不到。验证# 在 locale 缺失的机器上 echo /home/game/地图数据 | hexdump -C # 正常应显示 UTF-8 编码如 e5 9c b0 e5 9b be e6 95 b0 e6 8d ae # 如果显示乱码或问号说明 shell 无法正确处理 UTF-8 路径4.5 DNF 分屏/双开工具界面异常现象DNF 双开分辨率工具启动后主窗口空白任务栏图标闪烁DNF 分屏导致画面没了窗口变成灰色方块原理这类工具如dnf-dualscreen底层依赖X11或Wayland的XDG规范而XDG的locale检测是硬性要求。如果LC_ALL无法设置XDG会 fallback 到Clocale导致字体渲染引擎如fontconfig加载失败无法找到中文字体Noto Sans CJK SC最终界面渲染为空白或方块。这不是显卡驱动问题是字体链的第一环就断了。验证# 检查字体是否可用 fc-list :langzh # 如果无输出说明 fontconfig 未加载中文 locale根源还是 locale 缺失4.6 DNF 运行库DLL/so加载失败现象dnf run报错libdl.so.2: cannot open shared object file: No such file or directory./df_dbmw_r报错libstdc.so.6: cannot open shared object file原理这又是 locale 缺失的间接锅。libdl.so.2等运行库的查找路径/usr/lib64/,/lib64/在Clocale 下解析正常但在 locale 缺失时动态链接器ld-linux-x86-64.so.2的路径解析函数会因编码问题返回空导致dlopen()失败。虽然报错指向libdl但strace跟踪会发现openat(AT_FDCWD, /usr/lib64/libdl.so.2, O_RDONLY|O_CLOEXEC)系统调用返回ENOENT而实际文件存在——根本原因是ld-linux自身初始化失败。验证# 用 strace 跟踪需安装 strace strace -e traceopenat,open dnf --version 21 | grep libdl # 如果看到 openat 调用路径是乱码或错误路径就是 locale 导致4.7 DNF 未央/公益服数据库初始化失败现象./run启动 DNF 未央服务端日志停在Initializing database...不再前进mysql -u root -p init.sql执行含中文注释的 SQL 文件时报错ERROR 1064 (42000)原理MySQL 客户端在连接时会读取LC_ALL来设置连接字符集character_set_client。如果LC_ALL无法设置客户端默认用latin1而init.sql是 UTF-8 编码导致中文注释被解析为乱码SQL 语法错误。./run脚本内部调用mysql时继承了错误的 locale整个数据库初始化卡死。验证# 检查 mysql 客户端默认字符集 mysql --defaults-extra-file/dev/null -N -s -e SELECT character_set_client; # 在 locale 缺失时这里会返回 latin1而非 utf8mb45. 常见问题与排查技巧实录那些年我们踩过的 locale 坑在给几十个 DNF 公益服、台服、私服做部署和运维的过程中我整理了一份“locale 问题速查表”。这些问题不是教科书里的理论而是深夜三点服务器报警时我一边喝咖啡一边记下的真实教训。每一条都附带复现步骤、根本原因和一招毙命的解决方案。5.1 问题速查表7 个高频故障与秒解方案故障现象复现步骤根本原因一键解决命令locale -a | grep zh_CN有输出但dnf仍报 warning1.localedef -c -i zh_CN -f UTF-8 zh_CN.UTF-82.locale -a | grep zh_CN确认存在3.dnf list installed仍报 warninglocaledef生成的 locale 目录权限错误应为root:root但有时是root:wheelsudo chown -R root:root /usr/lib/locale/zh_CN.utf8/dnf install glibc-langpack-zh后localedef报错cannot open locale definition filesudo dnf install glibc-langpack-zhsudo localedef -c -i zh_CN -f UTF-8 zh_CN.UTF-8glibc-langpack-zh包名在新版 Fedora 中已改为glibc-langpack-zh-cn注意-cn后缀sudo dnf install -y glibc-langpack-zh-cn容器内localedef执行超时docker build卡住Dockerfile中RUN localedef -c -i zh_CN -f UTF-8 zh_CN.UTF-8容器内/dev/random阻塞localedef依赖熵池生成随机数用于哈希RUN dnf install -y haveged systemctl start haveged localedef -c -i zh_CN -f UTF-8 zh_CN.UTF-8export LC_ALLzh_CN.UTF-8后man ls仍是英文export LC_ALLzh_CN.UTF-8man lsman命令优先读取LC_MESSAGESLC_ALL虽覆盖但man的 locale 检测逻辑有 bugexport LC_MESSAGESzh_CN.UTF-8单独设置dnf update后 locale 又消失了sudo dnf updatelocale -a | grep zh_CN为空glibc包更新后旧的 locale 缓存被清空但新包未自动重生成在/etc/dnf/automatic.conf的[commands]段添加upgrade_commanddnf upgrade --setopttsflagsrepackage并配置dnf-automatic.timerssh userserver登录后 locale 正常但ssh userserver dnf list报 warningssh userserver locale→ 正常ssh userserver dnf list→ warningSSH 非交互式会话不加载~/.bashrcLC_ALL未传递在~/.bashrc末尾添加[[ -z $LC_ALL ]] export LC_ALLzh_CN.UTF-8并确保PermitUserEnvironment yes在/etc/ssh/sshd_config中启用systemctl start dnf-server启动失败journalctl -u dnf-server显示setlocale: No such file or directorysudo systemctl start dnf-serversudo journalctl -u dnf-server -n 20systemd 服务默认不继承用户环境变量EnvironmentFile未指定在/etc/systemd/system/dnf-server.service的[Service]段添加EnvironmentLANGzh_CN.UTF-8 LC_ALLzh_CN.UTF-85.2 独家避坑技巧3 个文档里不会写的实战经验技巧一用locale -k检查 locale 的“健康度”比locale -a更准locale -a只告诉你名字存在locale -k才能验证它是否真正可加载。执行locale -k -c LC_ALLzh_CN.UTF-8 2/dev/null | head -5如果输出LC_ALLzh_CN.UTF-8和一堆键值对如decimal_point.说明 locale 健康如果报错Cannot set LC_ALL to default locale: No such file or directory说明localedef生成失败或目录损坏。这是我排查“明明生成了却还是报错”问题的黄金命令。技巧二dnf的--nogpgcheck不能绕过 locale 检查但--disablepluginlangpacks可以很多人以为加--nogpgcheck就能跳过所有检查其实langpacks插件会主动检测 locale 并报错。临时禁用它dnf --disablepluginlangpacks install python3-pip这招在紧急恢复服务时比export LC_ALLC更安全因为Clocale 会导致dnf的依赖解析逻辑异常比如把python3和python2当作同名包。技巧三/usr/lib/locale/locale-archive是 locale 的“总开关”删了它会重置所有 locale这个 100MB 的二进制文件是glibc的 locale 缓存归档。如果它损坏常见于磁盘错误所有 locale 都会失效。安全清理方法# 备份原文件 sudo cp /usr/lib/locale/locale-archive /usr/lib/locale/locale-archive.bak # 删除系统会自动重建 sudo rm /usr/lib/locale/locale-archive # 重新生成所有已安装语言包的 locale sudo localedef --force --no-warnings -i C -f UTF-8 C.UTF-8 sudo localedef --force --no-warnings -i zh_CN -f UTF-8 zh_CN.UTF-8重建后locale -a会变慢因为要解压归档但稳定性大幅提升。我在一台 RAID5 故障的服务器上用这招救活了整个 DNF 服务端。6. 最后一点个人体会把 locale 当作基础设施而不是“语言设置”写到这里我想分享一个贯穿我十年运维生涯的体会locale 不是“让系统显示中文”的美化选项它是 Linux 系统的基础设施和glibc、kernel、filesystem同等重要。你不会因为“暂时不用网络”就卸载kernel也不会因为“暂时不用磁盘”就格式化/但很多人却因为“服务器只跑英文服务”就任由 locale 缺失——直到某天dnf update卡死或者grep搜不到日志里的中文关键词才手忙脚乱地 Google。在 DNF 公益服、台服、私服的部署中我见过太多因为 locale 问题导致的“玄学故障”服务端启动一半就退出、数据库导入失败、双开窗口变黑、甚至df -h显示磁盘使用率是负数glibc的printf在 locale 错误时格式化浮点数溢出。这些问题的根子都在/usr/lib/locale/zh_CN.utf8/这个目录是否存在、是否可读、是否被正确加载。所以我的建议很朴素新装系统第一件事不是装vim不是配ssh而是dnf install -y glibc-langpack-zh localedef -c -i zh_CN -f UTF-8 zh_CN.UTF-8 echo LANGzh_CN.UTF-8 /etc/locale.conf。写 Dockerfile 第一行不是FROM而是# Build locale first然后紧跟着RUN dnf install ... localedef ...。交接服务器文档里必须有一行“已验证locale -a | grep zh_CN有输出且dnf list installed无 warning”。这不需要多高深的技术只需要一次性的、确定性的操作。就像给汽车定期换机油你不会等到发动机异响了才想起这事。把 locale 当作基础设施来维护你省下的是未来无数个凌晨三点的排查时间。