Stable Diffusion 转 TensorRT 设备错位报错排查与修复
2026/10/1 6:04:45
在不少内网、涉密网段或者完全断网的机房里，最让人头疼的事就是装个软件却四处找不到依赖包。Kylin v10 x86_64 这套系统的 Yum 源里躺着成百上千个 RPM 包，平时联网一条命令就能装的东西，一旦挪到隔离环境，就得想办法把这些安装包全部搬到本地。把整个 Yum 源的所有安装包下载到本地指定目录，说白了就是给自己造一个离线仓库，之后不管装 PostgreSQL、JDK17，还是补一个不认识的小依赖，都能指着本地目录直接装，再也不用抱着 U 盘一个包一个包地扛。这套做法适合谁？内网运维、需要在银河麒麟上批量部署软件的工程师，以及任何被"cannot find a valid baseurl for repo"报错折腾过的人，都值得把它吃透。
1. 整源下载的需求拆解与方案选型
1.1 到底什么场景需要把整个源搬回家
先别急着敲命令。整源下载这个动作本身有点重，先想清楚自己的场景属于哪一类，不然很可能用大炮打了蚊子。常见的三种情况是这样的：
- 内网隔离环境。生产网段和互联网物理隔离，机器上有 Yum 命令但没有可达的源，任何一次
yum install都会以Cannot find a valid baseurl收场。 - 批量部署。手上有几十台同款 Kylin v10 x86_64，与其每台都逐个补包，不如搭一个本地源一次到位，后续统一指向。
- 版本锁定。有些老系统依赖特定版本的包，公网源更新后老版本下架，离线仓库能把当时那批包装的状态原样冻住。
我见过有人图省事，只挑几个常用包装进移动硬盘，结果到了现场发现缺了个底层的.so依赖，硬是又跑一趟。整源下载的价值就在这里——把"要装什么"这个未知数直接归零，依赖关系在源内部是自洽的，怎么解都能解出来。
1.2 三种下载方式的取舍
把源搬本地，主流的思路有三条，各有脾气：
| 方式 | 命令工具 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| reposync 逐包下载 | yum-utils 里的 reposync | 只拉 RPM 包，体积可控，可增量 | 下载慢，元数据要自己生成 | 内网源、离线仓库最常用 |
| rsync 镜像同步 | rsync | 完整镜像连元数据一起同步 | 需要镜像站支持 rsync，体积大 | 有专门镜像站对接 |
| yumdownloader | yum-utils 里的 yumdownloader | 按需精确下载 | 只解决单个包，不成体系 | 补个别包 |
大多数内网场景，reposync 是最优解。原因很直接：它认的是系统当前配置好的仓库，下载的是 RPM 本体，不带一堆用不上的索引和元数据冗余，体积更友好；再配合 createrepo 本地重建索引，就得到一个功能完整的私有源。
1.3 为什么我最终锁定 reposync 加 createrepo 这条链路
reposync 的定位很清晰——它按 repo 为单位，把远端每个包拉到本地目录，同时保留包的原始层级。真正让它成为主角的是后面那一环createrepo生成的元数据。没有元数据，你下载下来的只是一堆散装 RPM；有了元数据，这堆文件才被"激活"成一个可以被 Yum 识别的源。
我选这条链路的另一个原因是可控性。reposync 支持-n（只拉最新版本）、--download-path（自定义落盘目录）、-d（清理远端已删除的本地包），这些开关组合起来，既能做一次性全量，也能做日后的增量同步。相比之下 rsync 更适合和镜像站做字节级镜像，对"我只想要一个自己能用的源"这种诉求反而过重。
注意：reposync 默认会下载仓库里所有版本、所有架构的包，如果不加限制，一个完整 OS 仓库轻松就能吃掉 20GB 以上。动手前先估好盘，别等下到一半 dd 报警。
2. 动手前的环境准备与源确认
2.1 确认系统版本与 CPU 架构
第一步永远是认清自己在什么系统上。Kylin v10 有几个发行分支（SP1、SP2、SP3 等），不同分支自带源地址和包集合都有差异，架构也分 x86_64 和 aarch64。先跑几条命令把底细摸清：
cat /etc/.kyinfo cat /etc/os-release uname -m rpm -q --qf '%{ARCH}\n' kernel/etc/.kyinfo是麒麟系统特有的版本标识文件，里面能直接看到发行版本号，比通用的os-release更准。uname -m返回x86_64就说明架构没错。这一步看着简单，但我踩过一次坑：在一台 arm64 机器上照着 x86_64 的文档操作，源地址对了、命令也对，但下载回来一堆x86_64包一个都装不上，白折腾半天。
2.2 先把现有的 Yum 源修通
整源下载的前提是当前系统的 Yum 源本身能正常工作，否则 reposync 无从下手。看看现在配了哪些源：
yum repolist all ls -l /etc/yum.repos.d/yum repolist all会列出所有启用的和禁用的仓库，重点关注enabled那一列。如果输出里全是Cannot find a valid baseurl for repo: base/7/x86_64这类红色报错，说明源的baseurl指错了，或者网络压根不通。
麒麟系统的源配置一般放在/etc/yum.repos.d/下，形如kylin_aarch64.repo、ks10-adv-os.repo这类文件。打开看看里面baseurl指向哪里：
grep -E 'baseurl|name|enabled' /etc/yum.repos.d/*.repo如果baseurl是个内网地址而那台服务器又连不上，就得先换成可用的源。企业环境通常会有自己的内部镜像站，直接找运维要地址；如果是能联网的临时机器，也可以临时指向公共开源镜像站点，把包先拉下来。这里多句嘴，源地址的改动最好先备份原文件：
cp /etc/yum.repos.d/xxx.repo /etc/yum.repos.d/xxx.repo.bak改完源文件，务必刷新缓存确认通了：
yum clean all yum makecache yum repolistyum repolist能正常打印出仓库名和包数量，才算真正准备好。
2.3 装上 reposync 和 createrepo 两把工具
默认系统不一定带yum-utils，而 reposync 和 yumdownloader 都在里面；createrepo 则是单独的包。一次性装齐：
yum install -y yum-utils createrepo装完后验证一下，两个命令都要能查到版本：
reposync --help createrepo --helpreposync的--help里参数不少，先别被吓到，常用的就那么几个，下一章逐个拆。装工具这步有个小陷阱：如果系统最小化安装且源不通，yum install会直接失败，那就得回到 2.2 先把源弄通，别死磕。
实操心得：在准备下载的目标机器上，我习惯建一个专门的目录，比如
/data/offline-yum，并且把它挂在数据盘而不是系统盘。系统盘根分区往往只有几十 G，整源下载分分钟把它撑爆，最后连带系统都起不来。
3. reposync 整源下载完整实操
3.1 reposync 核心参数逐条拆解
reposync 的用法是reposync [选项]，不加参数时它会按当前所有启用的 repo 挨个同步。关键选项我列一下，并且说说各自解决什么问题：
-r <repoid>或--repoid：只同步指定仓库。这个 repoid 是yum repolist里显示的那个方括号里的名字，比如ks10-adv-os。想分仓管理就靠它。-p <path>或--download-path：指定下载落盘根目录。省略的话它会默认扔到/var/cache/yum或当前目录，容易撞上系统盘。-n或--newest-only：只下载每个包的最新版本。整源里同一个包常存在多个版本，加上它体积能省一大截。-d或--delete：把远端已删除、本地还留着的包清掉，做增量同步时必开。-l或--urls：不下载，只把 URL 列出来。可以先跑一次看看规模，心里有数。-a <arch>：指定架构，比如-a x86_64，避免拉到别的架构的包。--norepopath：不把仓库名作为子目录，直接铺在下载根目录下。
先干一件事，把要下的仓库名字和大致规模摸清楚：
yum repolist reposync -l -r ks10-adv-os | wc -l第二条命令只在终端打印包 URL 个数，不会真下载，几秒钟就能告诉你这个仓里有多少个包。
3.2 落盘路径规划与磁盘空间估算
路径这块要有规划，别随手一个reposync -r xxx就开始下。我的习惯是按仓库分目录，一个源一个文件夹：
mkdir -p /data/offline-yum/kylin-os mkdir -p /data/offline-yum/kylin-updates然后用-p指到父目录，reposync 会自动为每个 repoid 建子目录。空间估算是必须的，可以用列 URL 的方式粗估：
reposync -l -r ks10-adv-os | wc -l df -h /data一个包平均按 1MB 到 3MB 估，几万个包的 OS 仓加上 updates，20GB 是保守数字，实际见过 30GB 以上的。看下df -h，可用空间至少留出估算值的 1.5 倍做缓冲。宁多勿少，磁盘这事上犯不着抠。
这里补一个我自己的目录结构参考，方便后期维护：
/data/offline-yum/ ├── kylin-os/ # 操作系统基础包 ├── kylin-updates/ # 更新包 └── repodata-cache/ # 元数据操作的临时目录3.3 分批下载与断点续传的实战做法
整源下载动辄几个小时，一口气跑完风险不小——网络抖动、SSH 断开、磁盘写满都会让前功尽弃。我的做法是分仓、分阶段下，并且用nohup挂到后台：
nohup reposync -r ks10-adv-os -p /data/offline-yum -n -a x86_64 > /tmp/reposync-os.log 2>&1 &命令行解释一下：-r ks10-adv-os锁定那个基础仓，-p /data/offline-yum指定落盘根目录，-n只下最新版，-a x86_64限定架构，最后把输出重定向到日志。挂后台后可以随时看进度：
tail -f /tmp/reposync-os.log如果中途断了，reposync 的好处是可以重复执行——已下载的包它会识别跳过，续着下。这点比 yumdownloader 友好得多，后者断了得重头来。全部下完后，对着日志检查有没有 "Failed" 之类的字眼：
grep -iE 'fail|error|timeout' /tmp/reposync-os.log无输出才算干净。
注意事项：
-n只下最新版看着省空间，但如果你的目标是"任何老版本都能装"，那就别加-n，它会把仓库里全部历史版本一起拉下来。选哪个完全取决于你是要"够用"还是"全量留档"。
3.4 下载过程中的状态监控
下载跑起来之后别当甩手掌柜。几个监控点：
- 磁盘水位：
watch -n 60 'df -h /data'，每隔一分钟看一眼，防爆盘。 - 目录大小：
du -sh /data/offline-yum/kylin-os，看增长趋势估算剩余时间。 - 进程存活：
ps -ef | grep reposync，确认后台进程还在。 - 网络吞吐：
iftop或nload（需要装），能看出是卡了还是在跑。
这几个观察里，磁盘水位最要命。reposync 不会因为盘满而优雅停止，它往往写到一半报个No space left on device，留下一堆半截文件，还得手动清理。
4. 把下载目录变成可用的本地 Yum 源
4.1 createrepo 生成元数据
RPM 包下完了，这一堆文件还只是一堆文件。Yum 认源认的是元数据，也就是repodata目录里的repomd.xml及其索引文件。用 createrepo 给每个仓库目录生成索引：
createrepo -v /data/offline-yum/kylin-os createrepo -v /data/offline-yum/kylin-updates-v是 verbose，会打印处理过程。命令跑完，对应目录下会多出一个repodata/文件夹。看一眼：
ls -l /data/offline-yum/kylin-os/repodata/能看到repomd.xml、*-primary.xml.gz等文件就对了。如果后续再往目录里补包，不用整个重跑，用--update增量刷新：
createrepo --update /data/offline-yum/kylin-os--update只处理变化的包，速度比全量重建快很多。这一步是整条链路的关键——很多人卡在"包都下好了为什么 yum 不认"，十有八九就是漏了 createrepo。
4.2 编写本地源配置文件
接下来让 Yum 认识这个本地目录。在/etc/yum.repos.d/下新建一个local-offline.repo：
[kylin-local-os] name=Kylin Local OS Repo baseurl=file:///data/offline-yum/kylin-os enabled=1 gpgcheck=0 priority=1 [kylin-local-updates] name=Kylin Local Updates Repo baseurl=file:///data/offline-yum/kylin-updates enabled=1 gpgcheck=0 priority=1几个字段说明一下。baseurl用file://加绝对路径，指向 createrepo 生成的目录；gpgcheck=0关掉签名校验，因为自己搭的源没有验签体系，但生产环境若在意可保留拷贝来的 GPG key 并开启校验；priority=1让本地源优先级最高，避免优先去连不通的公网源。
如果本地目录还想通过 HTTP 给其他机器共用，那就在本机起个 httpd：
yum install -y httpd systemctl enable --now httpd再把目录软链或配置到/var/www/html/下，baseurl改成http://本机IP/...即可。不过对单机使用来说，file://方式最省事，不需要额外服务。
4.3 清理缓存并验证本地源
改完配置，刷新缓存并验证：
yum clean all yum makecache yum repolistyum repolist应该能看到kylin-local-os和kylin-local-updates，并且它们的状态是 enabled。接下来找一个之前装不上的包实测：
yum install --downloadonly <某个包> -y # 或者直接装 yum install -y <某个以前缺的依赖>如果能正常解析并安装，说明本地源彻底活了。验证时有个小技巧：先把公网源禁掉（enabled=0），只留本地源，这样能确认包确实是本地源提供的，而不是偷偷连了公网。测试完再把公网源按需恢复。
提示：如果
yum repolist报repomd.xml找不到，八成是 createrepo 的目录和 baseurl 指向的目录对不上，或者 createrepo 没跑成功，回去检查两步。
5. 常见问题排查与维护经验
5.1 高频报错与对应处理速查
干这活踩坑是家常便饭，我把最常撞上的几类整理成表，遇到先对号入座：
| 报错信息 | 常见原因 | 处理办法 |
|---|---|---|
| Cannot find a valid baseurl for repo | 源地址错、网络不通、源被禁 | 检查baseurl和enabled，ping 通源地址 |
| repomd.xml: [Errno 256] No more mirrors | 本地 repodata 缺失或路径不对 | 重跑 createrepo，核对 baseurl 目录 |
| No space left on device | 磁盘写满 | 清理后换数据盘，重新续传 |
| package is not signed / GPG 校验失败 | gpgcheck=1 但无对应 key | 导入官方 key 或临时设 gpgcheck=0 |
| repomd.xml 404 | createrepo 未执行完或目录被移动 | 检查 repodata 目录是否存在 |
| Nothing to do | 包已装或包名拼错 | 换包名或确认是否已安装 |
这几条覆盖了九成以上的现场报错。碰到新问题，先别慌，yum -v加 verbose 看详细输出，或者翻/var/log/yum.log。
5.2 磁盘被撑爆后的抢救方法
真要下满盘了，先别重启系统，静静处理：
du -sh /data/offline-yum/* # 看哪个仓最占地方 find /data -name '*.tmp' -delete # 清掉下载中的临时文件reposync 断了留下的半截文件通常带.part或临时后缀，清掉这些不完整的再重新执行 reposync 续传。如果确实是总量超出预期，那就得做取舍了：比如加上-n只留最新版，或者只下os和updates这两个核心仓，把体积大的额外仓（如果有）排除。我在一个客户现场就遇到过磁盘只有 40G 却想全量下源的情况，最后改成"只下最新版 + 只下核心仓"，体积从预估的 35G 压到 12G，刚好放下。
5.3 增量更新与长期维护
离线源不是搭一次就完事了，源会更新，本地也得跟。维护动作是这样的：
# 1. 同步新增/更新的包，顺带删除远端已下架的 reposync -r ks10-adv-os -p /data/offline-yum -n -d # 2. 刷新本地元数据（增量） createrepo --update /data/offline-yum/kylin-os # 3. 清缓存让 Yum 重新识别 yum clean all && yum makecache-d是关键，它让本地目录和远端保持一致，不会越积越乱。如果把这套动作写成脚本挂到定时任务里，就得到一个自动跟票的私有源。脚本大致长这样：
#!/bin/bash set -e BASE=/data/offline-yum for repo in kylin-os kylin-updates; do reposync -r ks10-adv-os -p $BASE -n -d createrepo --update $BASE/$repo done yum clean all yum makecache挂到 crontab 每周跑一次即可。维护这块最容易被忽略，很多人的离线源搭好后半年不动，等到急着装包时才发现里面全是过期版本。
5.4 几个用血换来的实操心得
聊几个文档里不会写、但实际很值钱的经验。
第一，别在业务高峰期跑 reposync。它很吃网络和磁盘 IO，把生产机的带宽占满，业务请求会被拖慢。挑夜里或维护窗口做。
第二，下载前先yum clean all。这是很多人想不到的一点——reposync 会读取 Yum 的缓存元数据来决定下什么，如果缓存是旧的，下到的包版本可能是过期的。先清缓存再同步，拿到的是最新状态。
第三，验证要"断网验证"。搭好源之后把网线逻辑断开（或临时禁用公网源），再装一个包试试。不然你没法确定装成功是本地源的功劳，还是网还通着走了公网。我见过一次，源其实配错了，但因为网还通，测试时一直能装，等搬到内网才全露馅。
第四，定期检查.repo文件的priority。系统里如果有多个源，优先级没设好，Yum 可能优先去连那个连不上的公网源，然后一切失败。本地源永远给最高优先级（数字最小）。
实操心得：如果目标是长期维护离线源，我强烈建议把它做成 HTTP 服务，而不是每台机器都拷一份
file://目录。一台机器搭源、全内网通过baseurl=http://源机IP/...访问，更新一次所有人都受益，省下的磁盘和人力不止一点点。
这套"整源下载到本地 + createrepo 激活 + 本地源指向"的组合，实际用下来非常稳。我自己维护的那套源已经跑了两年多，从最初的 PostgreSQL、JDK17 手动补包，到现在任何内网机器一句yum install就能解决，中间省下的反复折腾时间难以计数。要说还有什么可以继续深挖的方向，那就是把 yumdownloader 也纳进来——当只需要个别包、又不想动整个源的时候，yumdownloader --resolve --destdir=/path <包名>连依赖一起打包，会比整源下载轻快得多，适合临时补漏的场景。