1. 项目概述为什么离线环境下的依赖包安装是运维人员的“硬核基本功”在某高校数据中心的一次例行系统升级中我接手了一台部署在物理隔离网络中的 CentOS 7 服务器——它既没有外网访问权限也无法挂载任何外部存储设备唯一可用的介质是一张空白U盘。任务很明确将一台全新安装的最小化 CentOS 系统完整升级至生产环境所需状态包括 Python 3.9、Nginx 1.22、OpenSSL 1.1.1w、以及一整套用于日志分析的 ELK 组件依赖链。这不是简单的yum install能解决的问题而是一场对 Linux 包管理机制、RPM 依赖图谱、构建工具链和系统底层逻辑的综合实战检验。“rehat\centos离线安装系统所有依赖包”这个标题看似直白实则暗含三层关键挑战第一层是依赖关系的不可见性——yum deplist只能告诉你“需要什么”却无法自动告诉你“去哪里找”第二层是包版本的强耦合性——CentOS 7 的 glibc 2.17 与 CentOS 8 的 2.28 完全不兼容一个包名相同但构建环境不同就可能引发段错误第三层是离线环境的零容错性——你只有一次U盘拷贝机会漏掉任何一个.so文件或perl-libs子包整个安装流程就会卡死在error: Failed dependencies的报错里而你连 Google 报错信息的机会都没有。我之所以把这件事称为“硬核基本功”是因为它绕不开 RPM 的四元组name-version-release-arch校验机制、YUM 的元数据仓库结构repodata、以及createrepo工具如何将一堆.rpm文件组织成可被yum识别的本地源。这不是靠背命令就能搞定的活儿而是要真正理解当你敲下yum install httpd时系统其实在后台做了三件事——解析httpd的 Requires 字段、递归检索所有被依赖的包比如systemd,apr,pcre、再根据baseurl拼出每个包的完整下载路径。离线场景下这三步全部要人工完成、手动验证、逐层打包。关键词“rehat\centos”不是指两个发行版混用而是强调 Red Hat 系生态RHEL/CentOS/AlmaLinux/Rocky共享同一套构建规范和 ABI 兼容策略这意味着你在 RHEL 7 构建的包只要架构一致x86_64就能直接在 CentOS 7 上安装——这是离线方案可行性的底层基石。适合阅读本文的绝不是刚学 Linux 的新手而是已经能熟练配置 Nginx、写 Shell 脚本、甚至会编译过内核模块的中级以上运维或 DevOps 工程师。如果你还在为No package nginx available报错而反复百度那建议先补一补rpm -qpi和yum repolist的基础用法但如果你已经经历过在客户机房里面对一台没联网的服务器手心冒汗地翻查yumdownloader --resolve帮助文档那你就是本文最精准的目标读者。这篇文章不讲概念只讲我在五次真实离线部署中踩过的坑、验证过的路径、以及最终沉淀下来的、可直接复制粘贴执行的完整工作流。2. 整体设计思路为什么必须放弃“一键下载所有依赖”的幻想很多人第一次尝试离线安装时会本能地搜索“centos 一键下载所有依赖包”然后找到yumdownloader --resolve这个命令。听起来很美一条命令自动拉取目标软件及其全部依赖打包带走。但实操下来你会发现它在真实环境中几乎必然失败。原因不在命令本身而在我们对“依赖”的认知偏差。2.1 依赖的三重嵌套结构Runtime、Build、Meta一个典型的httpd包在yum deplist httpd输出中会列出几十行依赖项但这些依赖并非平级存在而是分属三个完全不同的生命周期层级Runtime 依赖运行时依赖这是yumdownloader --resolve能抓到的部分比如libapr-1.so.0()(64bit)、systemd-units。它们是程序启动后实际加载的动态库或服务单元属于“必须安装才能运行”的硬依赖。Build 依赖构建时依赖这类依赖在yum deplist中根本不会出现因为它们只在 RPM 打包阶段起作用。例如httpd的 SPEC 文件中定义了%build阶段需要gcc,make,autoconf但这些工具在运行httpd时完全不需要。然而当你试图离线安装一个从源码编译的定制版httpd比如打了 patch 的版本时它的 RPM 包头里可能通过BuildRequires字段声明了openssl-devel 1.1.1——这个openssl-devel就是 Build 依赖yumdownloader默认不会下载它但如果你后续要重新编译其他组件就会因缺少头文件而失败。Meta 依赖元数据依赖这是最容易被忽略的一层。比如epel-release包本身不提供任何可执行文件但它向/etc/yum.repos.d/写入了一个.repo文件从而让yum知道去哪里找nginx。在离线环境中你不仅需要epel-release-7-11.noarch.rpm这个包还需要把它安装后生成的 repo 配置内容手动复制到目标机器的对应目录下并确保baseurl指向你准备好的本地路径如file:///mnt/usb/epel。否则yum install nginx会直接报No package nginx available因为它根本不知道 EPEL 源的存在。提示yumdownloader --resolve只处理 Runtime 依赖且默认只下载当前系统架构uname -m的包。如果你在 x86_64 主机上为 aarch64 目标机下载它不会自动识别并切换架构必须显式指定--archlistaarch64。2.2 为什么“全量镜像”方案在实践中不可行另一个常见误区是既然单个包依赖复杂那不如直接下载整个 CentOS Base 和 Updates 仓库的 ISO 镜像比如CentOS-7-x86_64-DVD-2009.iso。这个想法很直观但存在三个致命缺陷体积失控一个完整的 CentOS 7 DVD 镜像约 4.5GB其中包含超过 8000 个 RPM 包。而你实际需要的可能只是其中 200 个。U盘空间有限更关键的是createrepo为整个镜像生成元数据repodata需要数小时且生成的repomd.xml文件巨大yum解析时内存占用飙升老旧服务器极易 OOM。版本污染风险DVD 镜像是某个时间点的快照如 2009 版本而你的目标系统可能已通过yum update升级到最新内核如kernel-3.10.0-1160.118.1.el7。如果你用旧镜像作为源yum update会强制降级内核导致系统无法启动。离线环境没有回滚机制一次降级等于重装系统。安全更新缺失DVD 镜像不含任何 Security Errata安全公告对应的更新包。例如 CVE-2021-41773Apache 路径遍历漏洞的修复包httpd-2.4.6-97.el7_9.1不在原始 DVD 中必须单独从 CentOS 官方 Updates 仓库下载。而 Updates 仓库是持续滚动更新的其 URL 结构为http://mirror.centos.org/centos/7/updates/x86_64/Packages/无法用固定 ISO 覆盖。因此我的设计思路非常明确放弃“全量”幻想拥抱“精准外科手术”。核心原则是“三不”——不下载未声明的包、不引入未验证的版本、不依赖未确认的源。具体拆解为四个步骤环境测绘在一台与目标机完全一致同版本、同架构、同已安装包集合的联网机器上精确测绘出目标软件的完整依赖树包源锁定为每一个依赖包确定其唯一、稳定、可追溯的下载来源官方 Base/Updates/EPEL或可信第三方仓库增量打包仅下载测绘结果中列出的包按源分类存放并为每个源独立生成轻量级 repodata原子化部署将 U 盘划分为多个逻辑分区如/mnt/usb/base,/mnt/usb/epel在目标机上通过yum-config-manager --add-repo动态挂载实现“按需启用”。这个方案的优势在于总包体积可控制在 200MB 以内典型 Web 服务栈createrepo生成元数据耗时小于 30 秒且每个源的更新可独立进行——今天更新 EPEL明天更新 Updates互不影响。3. 核心细节解析从测绘到打包的七步实操铁律离线依赖包的准备工作本质上是一场精密的“数字考古”。你需要在联网环境中像考古队员清理文物一样一层层剥离出目标软件的真实依赖轮廓。下面是我经过五次迭代验证的七步标准流程每一步都附有原理说明和避坑要点。3.1 第一步构建纯净测绘环境Why避免污染依赖图谱在任意一台联网的 CentOS 7 机器上不要直接在生产环境测绘。必须创建一个与目标机完全一致的干净沙箱。最佳实践是使用docker启动一个最小化容器# 拉取官方 CentOS 7 镜像确保与目标机 minor version 一致 docker pull centos:7.9.2009 # 启动容器挂载一个空目录用于存放下载的 RPM docker run -it --rm -v $(pwd)/rpm_cache:/rpm_cache centos:7.9.2009 /bin/bash进入容器后首先禁用所有非必要仓库只保留base和updates# 备份原始 repo 配置 mv /etc/yum.repos.d/*.repo /tmp/ # 创建精简版 base.repo cat /etc/yum.repos.d/base.repo EOF [base] nameCentOS-$releasever - Base baseurlhttp://mirror.centos.org/centos/7/os/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled1 [updates] nameCentOS-$releasever - Updates baseurlhttp://mirror.centos.org/centos/7/updates/$basearch/ gpgcheck1 gpgkeyfile:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 enabled1 EOF注意这里baseurl必须使用http://而非https://。某些老旧 CentOS 7 容器的curl或libcurl版本过低不支持 SNI 或 TLS 1.2访问https会报Peers Certificate issuer is not recognized错误导致yum makecache失败。这不是安全妥协而是离线部署的现实适配。3.2 第二步精确测绘目标软件的 Runtime 依赖Whyyum deplist是唯一权威来源假设我们要部署nginx。执行# 清理缓存确保元数据最新 yum clean all yum makecache # 获取 nginx 的完整依赖列表文本格式便于后续处理 yum deplist nginx | grep provider: | awk {print $2} | sort -u /rpm_cache/nginx_deps.txt这条命令的输出就是nginx在当前仓库状态下所有被声明的 provider 包名。例如centos-logos epel-release glibc libcrypt libpcre ...关键点在于yum deplist的结果是动态的它取决于你当前启用的仓库。如果你之前启用了 EPEL那么nginx的 provider 就是epel-release如果没启用yum会告诉你No package nginx available。因此测绘前必须确保base.repo中已正确配置了所有目标软件所在的源。实操心得我曾在一个项目中漏掉了epel-release的测绘导致离线安装时yum install nginx一直失败。排查了两小时才发现epel-release包本身也需要被下载并安装它才是解锁 EPEL 源的“钥匙”。所以测绘清单里必须包含所有*-release类包。3.3 第三步递归测绘所有依赖包的依赖Why依赖存在传递性上面得到的nginx_deps.txt只是第一层依赖。glibc自身又依赖glibc-commonlibpcre依赖pcre这些都需要被纳入。执行递归测绘# 创建一个脚本自动递归获取所有依赖 cat /rpm_cache/dep_resolver.sh EOF #!/bin/bash INPUT_FILE/rpm_cache/nginx_deps.txt OUTPUT_FILE/rpm_cache/all_deps.txt touch $OUTPUT_FILE while IFS read -r pkg; do if [ -z $pkg ]; then continue; fi # 跳过 release 包它们不依赖其他包 if echo $pkg | grep -q release$; then echo $pkg $OUTPUT_FILE continue fi # 获取该包的 provider 列表并去重追加 yum deplist $pkg 2/dev/null | grep provider: | awk {print $2} | sort -u $OUTPUT_FILE done $INPUT_FILE # 最终去重并排序 sort -u $OUTPUT_FILE /rpm_cache/all_deps_final.txt EOF chmod x /rpm_cache/dep_resolver.sh /rpm_cache/dep_resolver.sh运行后all_deps_final.txt就是完整的、无重复的依赖包名列表。注意这个列表里可能包含kernel、grub2等系统核心包它们通常不应被离线安装风险极高需要人工审查剔除。3.4 第四步为每个包名解析出完整 RPM 文件名Whyyumdownloader需要精确的 name-version-release.arch 格式yum deplist只给包名如glibc但下载时需要完整文件名如glibc-2.17-325.el7_9.x86_64.rpm。这一步必须借助repoquery工具# 安装 yum-utils它提供了 repoquery yum install -y yum-utils # 为 all_deps_final.txt 中的每个包查询其最新可用的 RPM 文件名 while IFS read -r pkg; do if [ -z $pkg ]; then continue; fi # --qf 指定输出格式%{name}-%{version}-%{release}.%{arch}.rpm repoquery --qf %{name}-%{version}-%{release}.%{arch}.rpm --pkgnarrowall $pkg 2/dev/null | head -n1 done /rpm_cache/all_deps_final.txt | sort -u /rpm_cache/rpm_list.txtrepoquery的强大之处在于它能穿透仓库元数据直接返回Packages/目录下实际存在的文件名。head -n1是为了防止同一个包名在不同仓库如 base 和 updates中存在多个版本时只取最新一个。例如glibc在 base 中是2.17-323在 updates 中是2.17-325我们只取后者。提示repoquery默认只查询已启用的仓库。如果你的nginx来自 EPEL必须先在base.repo中添加 EPEL 源或者单独为 EPEL 创建一个epel.repo并启用它。3.5 第五步批量下载 RPM 包并按源分类Why避免源冲突便于后续 createrepo现在有了rpm_list.txt开始下载。但不能一股脑全塞进一个文件夹必须按来源base/updates/epel分开# 创建目录结构 mkdir -p /rpm_cache/{base,updates,epel} # 读取 rpm_list.txt根据包名判断来源并下载 while IFS read -r rpm; do if [ -z $rpm ]; then continue; fi pkg_name$(echo $rpm | cut -d- -f1) # 简单规则以 epel- 开头的或名字在知名 EPEL 包列表里的归入 epel if [[ $pkg_name epel-release ]] || [[ $rpm *epel* ]]; then target_dir/rpm_cache/epel elif [[ $rpm *el7_9* ]]; then # el7_9 是 updates 的典型 release tag target_dir/rpm_cache/updates else target_dir/rpm_cache/base fi # 使用 yumdownloader 下载到指定目录 yumdownloader --destdir$target_dir $rpm 2/dev/null done /rpm_cache/rpm_list.txt这个分类逻辑虽简单但足够可靠。el7_9是 CentOS 7.9 Updates 仓库的标准 release 标签epel-release是 EPEL 的入口包抓住这两个锚点就能覆盖 95% 的场景。3.6 第六步为每个源目录生成轻量级 repodataWhyyum必须有 repomd.xml 才能识别本地源这是离线方案的“临门一脚”。createrepo是yum-utils的一部分它会扫描目录下的所有.rpm文件生成repodata/子目录其中最关键的是repomd.xml——yum就是靠它来索引包的依赖关系的。# 为每个源目录单独生成 repodata for dir in /rpm_cache/{base,updates,epel}; do if [ -d $dir ] [ $(ls -A $dir/*.rpm 2/dev/null) ]; then echo Generating repodata for $dir... createrepo --workers2 --database --update $dir fi done--workers2限制并发数避免在低配虚拟机上卡死--database启用 SQLite 数据库加速查询--update表示如果repodata已存在则只更新变化的部分极大提升二次打包效率。注意createrepo生成的repomd.xml文件里每个data节点的type属性如primary,filelists,other必须与yum期望的一致。如果yum报Error: Cannot retrieve repository metadata (repomd.xml) for repository大概率是repomd.xml中的 checksum 与实际文件不匹配此时只需删除repodata/目录重新运行createrepo即可。3.7 第七步U盘分区与目录结构规划Why物理介质的组织方式决定部署效率U盘不是简单地把所有 RPM 拷进去就行。我推荐采用以下分区方案分区挂载点用途内容示例/mnt/usb/baseCentOS Base 源Packages/所有 base 包repodata//mnt/usb/updatesCentOS Updates 源Packages/所有 updates 包repodata//mnt/usb/epelEPEL 源Packages/所有 epel 包repodata//mnt/usb/scripts部署脚本install_all.sh,enable_repos.sh这样做的好处是在目标机上你可以用yum-config-manager --add-repo file:///mnt/usb/base精确启用某个源而不会因为baseurlfile:///mnt/usb/指向根目录导致yum错误地将scripts/目录也当作一个源来解析从而报Cannot find a valid baseurl for repo。最后将/rpm_cache/下的base/,updates/,epel/三个目录完整拷贝到 U 盘的对应分区即可。总大小通常在 150-300MB 之间一张 4GB 的老式 U 盘绰绰有余。4. 实操过程详解在目标离线机上的五步原子化部署当 U 盘插到那台没有网络的 CentOS 7 服务器上时真正的考验才开始。部署过程必须像手术一样精准任何一步出错都可能导致系统进入半瘫痪状态。以下是我在某金融客户现场实测通过的五步法每一步都有明确的验证点。4.1 第一步挂载 U 盘并验证文件完整性Why硬件读取错误是离线部署的第一大杀手首先确认 U 盘被正确识别# 查看磁盘列表 lsblk # 假设 U 盘是 /dev/sdb1创建挂载点并挂载 mkdir -p /mnt/usb/{base,updates,epel,scripts} mount /dev/sdb1 /mnt/usb/base # 验证挂载是否成功且 repodata 存在 ls -l /mnt/usb/base/repodata/repomd.xml # 应该输出类似-rw-r--r--. 1 root root 3240 Jan 15 10:23 /mnt/usb/base/repodata/repomd.xml最关键的验证是检查repomd.xml的完整性。如果ls报No such file or directory说明createrepo步骤失败或者 U 盘拷贝时文件损坏。此时不要继续应立即在测绘机上重新生成repodata并重拷。提示lsblk有时无法显示 U 盘可尝试dmesg | tail -20查看内核日志确认 USB 设备是否被识别。老旧服务器的 USB 2.0 控制器可能存在兼容性问题此时可换用 USB 3.0 接口或在 BIOS 中开启 XHCI Hand-off 选项。4.2 第二步动态添加本地仓库Whyyum-config-manager是最安全的启用方式不要手动编辑/etc/yum.repos.d/下的文件。使用yum-config-manager可以确保语法正确且支持--save参数自动保存# 启用 base 源 yum-config-manager --add-repo file:///mnt/usb/base # 启用 updates 源 yum-config-manager --add-repo file:///mnt/usb/updates # 启用 epel 源 yum-config-manager --add-repo file:///mnt/usb/epel # 查看当前启用的仓库 yum repolist enabled # 应该看到 base, updates, epel 三个仓库的状态为 enabledyum-config-manager --add-repo会在/etc/yum.repos.d/下生成形如generated-repo-XXXX.repo的文件其内容类似[generated-repo-12345] nameadded from: file:///mnt/usb/base baseurlfile:///mnt/usb/base enabled1 gpgcheck0注意gpgcheck0—— 因为我们没有同步 GPG 密钥离线环境下验证签名不现实。这是权衡安全与可用性的必要妥协但前提是你信任测绘机的网络环境且所有 RPM 都来自官方镜像。4.3 第三步构建本地缓存并验证依赖解析Whyyum makecache是离线部署的“压力测试”这一步至关重要它会触发yum解析所有repomd.xml构建本地数据库。如果这一步失败后面所有install都会报错# 清理旧缓存强制重建 yum clean all yum makecache # 验证 nginx 是否能被正确识别 yum list available nginx # 应该输出nginx.x86_64 1:1.20.1-10.el7.ngx epel # 验证其依赖是否全部可满足 yum deplist nginx | grep provider: | head -10 # 应该能看到 libpcre, openssl 等包名且它们都来自 file:///mnt/usb/... 的路径如果yum makecache报错Cannot retrieve repository metadata请立即检查/mnt/usb/*/repodata/repomd.xml文件是否存在且非空U 盘是否以ro只读模式挂载导致yum无法写入缓存目标机的glibc版本是否低于测绘机如测绘机是 7.9目标机是 7.6导致createrepo生成的 SQLite 数据库不兼容。4.4 第四步执行原子化安装Why--assumeyes和--setopt是离线环境的生命线现在可以安装了。但绝不能直接yum install nginx必须加上关键参数# 安装 nginx 及其所有依赖自动确认跳过已安装包 yum install -y --setopttsflagsnodocs nginx # --setopttsflagsnodocs 是关键它告诉 yum 跳过安装所有文档文件man pages, /usr/share/doc/* # 这能减少 30% 的磁盘占用且在服务器环境中文档几乎从不被查阅-y参数必不可少因为离线环境下没有交互终端yum会卡在Is this ok [y/d/N]:提示上。--setopttsflagsnodocs是我从无数次磁盘空间不足的崩溃中总结出的黄金参数——一个python3包的文档目录动辄 50MB而nodocs模式下它只安装核心的.pyc文件和二进制。安装完成后验证服务状态# 检查 nginx 是否安装成功 rpm -qa | grep nginx # 应该输出nginx-1.20.1-10.el7.ngx.x86_64 # 启动并设为开机自启 systemctl start nginx systemctl enable nginx # 检查端口监听 ss -tlnp | grep :80 # 应该看到 nginx 进程监听 80 端口4.5 第五步卸载临时仓库并清理Why保持系统清洁避免未来yum update意外启用离线源部署成功后必须移除临时添加的仓库否则下次yum update会尝试从 U 盘拉取更新而 U 盘可能已被拔掉# 删除所有由 yum-config-manager 添加的 repo 文件 rm -f /etc/yum.repos.d/generated-repo-*.repo # 卸载 U 盘 umount /mnt/usb/base /mnt/usb/updates /mnt/usb/epel # 清理挂载点 rmdir /mnt/usb/{base,updates,epel,scripts}至此整个离线部署流程完美闭环。从 U 盘插入到nginx服务正常运行全程不超过 10 分钟且所有操作均可脚本化形成标准化交付物。5. 常见问题与独家排查技巧实录在五次真实离线部署中我记录了 17 个高频问题。下面精选 5 个最具代表性的附上我的第一手排查思路和解决方案。这些问题90% 的网上教程都不会提但它们恰恰是让你在客户机房里多待两小时的关键。5.1 问题一“Error: Package: xxx requires yyy, but none of the providers can be installed”现象yum install报错提示某个包如libcurl需要libssh2但yum说找不到 provider。排查思路这不是包没下载而是libssh2这个包可能存在于epel源但你的测绘环境没启用 EPEL导致yum deplist没把它列出来。解决方案在测绘机上手动启用 EPEL 源yum install epel-release重新运行yum deplist nginx确认libssh2是否出现在输出中如果出现将其加入nginx_deps.txt重新走一遍七步流程。独家技巧用repoquery --whatrequires libssh2可以反向查询哪些包依赖libssh2快速定位漏掉的上游包。5.2 问题二“GPG key retrieval failed: [Errno 14] curl#37 - Couldnt open file /etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7”现象yum makecache报 GPG 密钥文件不存在。原因createrepo生成的repomd.xml中data typeprimary节点的checksum typesha256和open-checksum typesha256是基于gpgkeyfile:///etc/pki/rpm-gpg/...的路径计算的。但离线机上没有这个文件。终极解法在测绘机上下载并导入 GPG 密钥然后在createrepo时指定--gpg-key# 在测绘机上下载密钥 curl -o /tmp/RPM-GPG-KEY-CentOS-7 http://mirror.centos.org/centos/7/os/x86_64/RPM-GPG-KEY-CentOS-7 # 为每个源目录生成 repodata 时带上密钥 createrepo --gpg-key /tmp/RPM-GPG-KEY-CentOS-7 --workers2 --database --update /rpm_cache/base这样repomd.xml中的gpgkey字段就会指向file:///tmp/RPM-GPG-KEY-CentOS-7而你只需在离线机上把密钥文件放到/tmp/下即可。虽然麻烦但一劳永逸。5.3 问题三“Transaction check error: file /usr/lib64/libcrypto.so.1.1 from install of openssl-libs conflicts with file from package openssl11-libs”现象安装openssl-libs时与已有的openssl11-libs冲突。本质这是 CentOS 7 上著名的 OpenSSL 双版本共存问题。openssl11-libs是 EPEL 提供的 OpenSSL 1.1.x而系统自带的是 1.0.2。nginx可能同时依赖两者。安全解法不要强行--force安装查看nginx的Requires字段rpm -qpR /mnt/usb/epel/Packages/nginx-*.rpm | grep openssl如果它要求openssl11-libs那就只启用epel源禁用base源中的openssl相关包在/etc/yum.conf中添加excludeopenssl*阻止 base 源的 openssl 包被安装。5.4 问题四“Could not contact any CDS servers” 或 “Failed to synchronize cache for repo ‘base’”现象yum makecache报无法连接 CDSContent Delivery Server。真相这是yum的一个古老 bug当baseurl是file://协议时某些版本的yum会错误地尝试发起 HTTP 请求。这不是网络问题而是yum的代码缺陷。绕过方案在/etc/yum.repos.d/下手动编辑生成的 repo 文件将baseurlfile:///mnt/usb/base改为baseurlfile:///mnt/usb/base/末尾加斜杠。这个细微差别能欺骗yum进入正确的本地文件处理分支。5.5 问题五U 盘在目标机上识别为只读Read-only file system现象mount后ls -l /mnt/usb/base显示所有文件权限为r--r--r--且createrepo报错Permission denied。根源U 盘文件系统是 FAT32而 FAT32 不支持 Linux 的 Unix 权限位。mount时内核会默认以ro模式挂载。可靠解法在测绘机上将 U 盘重新格式化为 ext4mkfs.ext4 /dev/sdb1重新拷贝所有文件在离线机上挂载时显式指定rwmount -o rw /dev/sdb1 /mnt/usb/base
