ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

rosdep换清华源修复Website may be down报错

rosdep换清华源修复Website may be down报错 在 Ubuntu 20.04 上装 ROS Noetic流程走到第 6 步 rosdep 初始化我原本以为就是两行命令的事sudo rosdep init然后rosdep update顶多两分钟收工。结果这一关硬生生卡了我快两小时rosdep报错还能理解连换成rosdepc之后依然报了同款Website may be down而且都是死在清华源上。跑到技术群里一看一堆人和我一样对着mirrors.tuna.tsinghua.edu.cn这个域名干瞪眼。这篇文章就是我把整个排查过程彻底捋清楚之后的完整记录从报错机制、URL 拼接、缓存清理到最终修复方案全部写透。无论是第一次装 ROS 的新手还是被这个报错反复折磨的老手都能对号入座。1. 现象复盘rosdep 和 rosdepc 在同一道坎上翻了车1.1 从例行操作变成卡点ROS 安装教程里前面几步无非是换源、装 base、装 melodic 或 noetic 的主包一切顺利。等到第 6 步执行sudo rosdep init rosdep update很多人第一次翻车就在这儿。我当时的心态也简单官方教程让这么干照着抄就行顶多网络慢一点多等一会儿。事实证明这种例行操作的心态最容易让人忽视报错里的关键信息。我先执行的是官方原始流程。sudo rosdep init这一步通常能过去因为它在本地创建源列表文件不涉及网络请求。真正开始卡的是rosdep update它要去网络上拉取一堆 YAML 索引文件而且默认地址是 GitHub 的 raw 域名。这一步在国内环境里经常是等了半天最后给你一行冷冰冰的报错。1.2 报错原文与触发时间线先看 rosdep 的直接报错我把它复原如下$ rosdep update reading in sources list data from /etc/ros/rosdep/sources.list.d/20-default.list ERROR: unable to process source [https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/base.yaml]: urlopen error [Errno -2] Name or service not known ERROR: unable to process source [https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/python.yaml]: Website may be down ERROR: unable to process source [https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/ruby.yaml]: Website may be down注意一个细节第一次报错是Name or service not known后面几行又变成Website may be down。这两种提示在 rosdep 的异常捕获里都被归成了源不可用本质上是一回事请求压根没成功。Website may be down是 rosdep 收到任意网络请求异常后统一打印的提示语它不代表网站真的挂了只代表rosdep 没拿到它想要的响应。心态崩的还在后面。我按网上的建议去安装rosdepc打算用国内替代工具绕过去。装好之后再执行sudo rosdepc init rosdepc update结果 rosdepc 一样卡在 update 阶段报的还是这行ERROR: unable to process source [https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/base.yaml]: Website may be down好家伙两个工具一个报 GitHub raw 的错一个报清华源的错表面看像是全网所有源都挂了但我自己清楚清华源在国内明明是通着的浏览器和 curl 都能打开。这就说明问题大概率不在源本身而在配置或环境。1.3 一句话总结问题的本质这个报错的本质是 rosdep 请求源文件失败后用一个笼统的提示把真正的网络原因包住了。后续所有排查方向都应该是如何让 rosdep 成功拿到 YAML 文件而不是如何让报错消失。想清楚这一点后面排查才不会瞎试命令。2. 为什么 rosdep 会喊website may be down它到底在访问什么2.1 rosdep update 的工作链路rosdep 的工作机制其实不复杂它维护了一份系统依赖包名到 ROS 包名的映射关系。执行rosdep update时它会按顺序做三件事读取本地的源列表文件/etc/ros/rosdep/sources.list.d/20-default.list。根据这个文件里写的 URL逐个下载对应的 YAML 文件。把下载结果合并成索引缓存供后续rosdep install --from-paths src --ignore-src这类命令使用。所以真正决定 rosdep 接下来访问哪个网站的人是你自己就藏在20-default.list里。默认情况下这个文件里写的是raw.githubusercontent.com/ros/rosdistro/master/rosdep/base.yaml这样的 URL。看到这个域名国内环境的朋友应该已经能猜到问题出在哪了。2.2 raw.githubusercontent.com 在国内环境的真实处境raw.githubusercontent.com是 GitHub 用来提供仓库原始文件下载的域名绝大多数国内网络环境下这个域名的连通性非常不稳定。要么是 DNS 解析失败要么是连接超时偶尔能通但速度感人。rosdep 每次更新都要同时拉取 base、python、ruby、nodejs 等好几个 YAML 文件只要其中一个失败整个 update 流程就会中断并抛出Website may be down。这里有个容易误导人的地方很多人以为报错里的 URL 是github.com以为浏览器能打开 GitHub 就等于 rosdep 能通。实际上 rosdep 访问的是 raw 子域名走的是另一套解析和连接路径。很多人的浏览器能打开 github 主站但 raw 域名依然超时两者完全不冲突。2.3 清华源为什么能救场但前提是 URL 要拼对清华源之所以能成为标准解决方案是因为它把ros/rosdistro这个仓库整体同步到了国内镜像路径就是mirrors.tuna.tsinghua.edu.cn/rosdistro/。rosdep 只需要访问这个镜像而不需要再碰任何境外域名速度自然快得多。但问题来了源码里默认的 URL 结构是https://raw.githubusercontent.com/ros/rosdistro/master/rosdep/base.yaml其中master表示分支名rosdep/base.yaml表示仓库内的文件路径。镜像站为了同步多个分支通常会把分支名作为目录层级暴露出来。也就是说换成清华源之后URL 必须拼成https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/base.yaml很多人踩的第一个坑就是漏掉master这一层直接写了mirrors.tuna.tsinghua.edu.cn/rosdistro/rosdep/base.yaml。这个地址访问过去大概率是 404 或者目录列表页rosdep 同样会报Website may be down。这就是我把所有报错都指向清华源的原因——最不是源的问题而是地址没写对。3. 换清华源的正确姿势URL 拼写与缓存清理一个都不能少3.1 清华源镜像的目录结构master 这一层最容易丢我特意用 curl 验证了清华源的真实目录结构避免凭记忆写错。在 bash 里执行curl -I https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/base.yaml返回HTTP/1.1 200 OK说明这个地址真实有效。再试漏掉 master 的版本curl -I https://mirrors.tuna.tsinghua.edu.cn/rosdistro/rosdep/base.yaml返回结果如果是 404 或者错误页那就印证了前面的判断URL 里必须有master。这个细节特别容易翻车因为清华源本身提供浏览目录的功能你直接点进 rosdistro 目录会看到 master 这个文件夹但很多人不会站在镜像同步整仓的角度去理解这个层级于是凭感觉把路径写错。3.2 一份可以照抄的 20-default.list 内容我的最终方案是直接编辑源列表文件把里面所有 URL 整体替换成清华源。先备份再编辑sudo cp /etc/ros/rosdep/sources.list.d/20-default.list ~/20-default.list.bak sudo vim /etc/ros/rosdep/sources.list.d/20-default.list在 vim 里执行全局替换把raw.githubusercontent.com/ros/rosdistro全部替换为mirrors.tuna.tsinghua.edu.cn/rosdistro:%s/raw.githubusercontent.com\/ros\/rosdistro/mirrors.tuna.tsinghua.edu.cn\/rosdistro/g替换后完整文件应该长这样核心部分注释行可保留可删除yaml https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/osx-homebrew.yaml osx yaml https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/base.yaml yaml https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/python.yaml yaml https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/ruby.yaml yaml https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/nodejs.yaml yaml https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/java.yaml yaml https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/gentoo.yaml这里必须提醒一句不要自作主张在每一行后面加注释比如# 清华源。rosdep 对源列表文件的行格式要求很死板每行是yaml [URL]的结构后面多出来的内容会被当成格式错误轻则忽略该行重则直接报错。想留备注就单独开一行用#开头。3.3 curl 验证先行别让 rosdep 背锅修改完文件之后不要急着跑rosdep update。先用 curl 把文件里所有 URL 都打一遍确认每个地址都能返回有效 YAML 内容。最简单的做法是写个循环grep -o https://[^ ]* /etc/ros/rosdep/sources.list.d/20-default.list | while read url; do echo $url curl -s -o /dev/null -w %{http_code}\n $url done如果所有 URL 都返回200那基本可以断定网络层面没问题接下来就可以动手清缓存了。这一步是很多人遗漏的也是让 rosdep 继续报错的隐形元凶。3.4 清缓存sources.cache 删不删差距很大rosdep 会把源文件下载结果缓存到~/.ros/rosdep/目录下。我这次遇到的情况是URL 文件已经被我改对了curl 验证也全通过但rosdep update依然报错。问题恰恰出在旧缓存上。rosdep 在部分版本里读到缓存之后如果发现缓存中的源 URL 失效会优先沿用旧的异常结果甚至直接用缓存覆盖掉新的源列表解析结果。清理方法很暴力rm -rf ~/.ros/rosdep放心删这只是用户级缓存不是工具本身。删除后 rosdep 会在下次 update 时重新创建这个目录并重新下载所有源文件。如果你之前用sudo rosdep update跑过那还要注意一个坑sudo 环境下缓存写入的是/root/.ros/rosdep而不是当前用户的~/.ros/rosdep。两个目录都要看一眼该删就删。提示rosdep init这类写系统目录的操作需要 sudo但rosdep update尽量不要加 sudo否则缓存权限归属混乱后面换回普通用户执行rosdep install时会再次踩坑。4. rosdepc 也报错的完整排查链路与最终修复4.1 rosdepc 不是万能药它只是换了默认地址先说清楚 rosdepc 是什么。它不是 ROS 官方的工具而是国内开发者为了方便大家在镜像环境下使用 rosdep 而做的替代命令安装方式是sudo pip install rosdepc它的作用说白了就是把默认的源列表文件指向国内地址然后提供一个和 rosdep 几乎一模一样的命令接口。很多人以为 rosdepc 一定能绕过所有网络问题但实际上它依然依赖网络去拉 YAML 文件只是目的地址从 GitHub 变成了清华源。如果你本地的配置、缓存或者网络环境本身有问题rosdepc 照样会报Website may be down。我这次就是栽在这个认知上以为装完 rosdepc 就万事大吉没想到它读的还是那一份 20-default.list而且缓存里残留的数据依旧在捣乱。4.2 按这个顺序排查半小时内定位根因如果你跟我一样rosdep 和 rosdepc 都报错别急着试各种网上的命令。按下面这个顺序逐步排查每一步都有明确目的第一步确认源列表文件里没有境外地址残留。cat /etc/ros/rosdep/sources.list.d/20-default.list如果里面还有raw.githubusercontent.com那就先用上一节的替换方法改掉。如果文件不存在可能是之前手动清理时删过头了需要重新 init。第二步检查文件是否只有一个源列表。ls -la /etc/ros/rosdep/sources.list.d/正常情况下应该只有20-default.list一个文件。如果你发现还有50-xxx.list之类的其他文件很可能之前装过别的工具往这个目录里塞了东西。这些额外文件指向的 URL 可能已经失效rosdep 只要扫到其中一个无法访问的源就会认为整个 update 失败。第三步验证 URL 可用性。用上一节的 curl 循环命令确认文件里的每个 URL 都返回 200。这里有一个经验之谈如果清华源偶尔抽风返回 503 或者连接重置可以先换中科大源地址是mirrors.ustc.edu.cn/rosdistroURL 拼法完全一致。第四步检查环境变量。echo $ROSDISTRO_INDEX_URLrosdep 在部分版本里会优先读取这个环境变量中的地址如果它指向了一个不可访问的 URL即使源列表文件全对也无济于事。如果有输出且不是清华源地址就执行unset ROSDISTRO_INDEX_URL清掉。第五步删除缓存重新初始化。sudo rm -rf /etc/ros/rosdep/sources.list.d rm -rf ~/.ros/rosdep sudo rosdep init rosdep update这里最关键的是一开始先把整个 sources.list.d 目录删掉否则rosdep init会因为default sources list file already exists直接拒绝执行。很多人卡在这句报错上其实就是旧文件没清理干净。4.3 最终采用的修复方案全删重来 手动锁源我最终的修复动作其实非常简单但这套组合拳几乎能覆盖 rosdep 和 rosdepc 的所有同类问题# 1. 备份原配置 sudo cp -r /etc/ros/rosdep/sources.list.d /etc/ros/rosdep/sources.list.d.bak # 2. 删除旧配置与用户缓存 sudo rm -rf /etc/ros/rosdep/sources.list.d rm -rf ~/.ros/rosdep # 3. 重新初始化 sudo rosdep init # 4. 手动改成清华源再次确认替换完整 sudo sed -i s|raw.githubusercontent.com/ros/rosdistro|mirrors.tuna.tsinghua.edu.cn/rosdistro|g /etc/ros/rosdep/sources.list.d/20-default.list # 5. 更新 rosdep update我最后用的是sed而不是 vim因为 sed 批量替换更不容易漏行。执行完第 5 步终端里开始出现一串Hit https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/...心里那块石头才算落了地。5. 验证与举一反三这次修好下次怎么防5.1 怎么确认 update 真的走了清华源不要只看命令有没有报错要观察 update 过程的输出。成功走清华源时日志里会明确写出它访问的域名比如reading in sources list data from /etc/ros/rosdep/sources.list.d/20-default.list Hit https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/base.yaml Hit https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/python.yaml Hit https://mirrors.tuna.tsinghua.edu.cn/rosdistro/master/rosdep/ruby.yaml你可以再复跑一次命令确认幂等性grep -v ^# /etc/ros/rosdep/sources.list.d/20-default.list | grep -o https://[^/]*如果输出里只剩下mirrors.tuna.tsinghua.edu.cn说明配置彻底干净了。随后执行rosdep install --from-paths src --ignore-src -r -y也算通过的标志因为依赖解析会重新走一遍索引比单纯 update 更能验证完整性。5.2 同类换源场景的三种兄弟坑处理完 rosdep我还发现类似的换源后不生效问题在其他包管理器里一样常见顺手总结一下apt 换清华源编辑/etc/apt/sources.list把官方地址替换成mirrors.tuna.tsinghua.edu.cn/ubuntu/之后必须执行sudo apt update刷新索引。如果忘了刷新apt 可能报 404 或依然走旧源缓存。这一点和 rosdep 忘删缓存是同一个道理。pip 换清华源很多人遇到Could not find a version that satisfies the requirement pandas就以为清华源坏了其实绝大多数时候是 pip 版本太旧或者当前 Python 版本不受支持。稳妥的方案是pip install --upgrade pip pip install -i https://pypi.tuna.tsinghua.edu.cn/simple pandas也可以把源写进~/.pip/pip.conf一劳永逸但同样要记得在装包时留意日志确认它真的走了清华源。Termux 换清华源手机上的 Termux 换源后一定要执行pkg update重新拉取索引。这个环境和 rosdep 的最大相似点是源地址改了但旧索引还挂在本地不刷新就会被旧数据带偏。5.3 把源地址检查变成肌肉记忆整个排查过程下来我最深的感触是这类报错百分之八九十不是工具坏了也不是源挂了而是配置和缓存的组合问题。以后再遇到Website may be down我的固定反应已经变成三连问文件里写的是哪个域名URL 路径有没有少一层缓存有没有删干净把这三件事查完绝大多数问题都能解决。如果你也卡在 rosdep 和 rosdepc 上报同一句错直接按顺序检查这三项大概率一次过。
返回列表