极客工场

Appearance

共 2,391 字预计阅读约 8 分钟

make pdk git fetch 超时 fatal: unable to access github.com 速查：断点续跑与镜像加速 ​

更新时间：2026-10-24。FAQ 速查页，属于开源 EDA 排错系列，总入口见 开源 EDA 报错排错中心。按 OpenLane Docker 安装实录 走到 make pdk 这一步，日志滚了十几分钟后突然停在一句 fatal: unable to access ... Failed to connect——这是安装链路里最高发的网络坑：open_pdks 要从 GitHub 拉 skywater-pdk 和多个标准单元库源（sky130_fd_sc_hd 等），慢网络或没配代理的环境下 submodule 拉取必断。好消息是 make pdk 支持断点续跑，已下载的部分不会重来，多数情况原地重跑就能过；顽固的需要给 git 配代理或换镜像源。

本文要回答的问题 ​

  • fatal: unable to access github.com: Failed to connect 断在安装链路的哪一环？
  • make pdk 失败后重跑，之前下载的几个小时会不会白费？
  • 怎么区分「网络不通」「代理没配」「DNS 解析失败」三种超时？
  • 日志里没有 fatal 字样、却在编译中途莫名中断，为什么先要查磁盘？

一、报错原文与典型现象 ​

报错出现在 make pdk 的源码拉取阶段，真实日志形态如下（路径与域名为占位）：

bash
$ make pdk
[INFO] PDKs root directory: /home/demo/OpenLane/pdks
[INFO] Building skywater-pdk libraries...
Cloning into 'skywater-pdk'...
fatal: unable to access 'https://github.com/google/skywater-pdk.git/':
Failed to connect to github.com port 443: Connection timed out
make[1]: *** [Makefile:128: skywater-pdk] Error 128

变体还有两种：Could not resolve host: github.com（DNS 环节就失败）与 Operation timed out after 300000 milliseconds（连接能建立但传输中途断）。三者的共同点：都死在 git 的 fetch/clone 动作上，都发生在 make pdk 阶段——安装文的三类失败判别口诀里，make pdk 死且日志出现 git fetch/clone 字样的，九成是网络。对照之下，make pull-openlane 死是 Docker Hub 拉不动，make test 死才轮到工具链本身。

典型误判是看到 Error 就去重装 Docker 镜像——镜像和网络拉源码是两条独立链路，重拉镜像对 git 超时毫无帮助，白白浪费半小时。

二、病因处置速查表 ​

报错现象 / 场景可能原因快速验证处置
Failed to connect ... port 443 timed out出口网络到 GitHub 不通或极慢curl -I https://github.com 看是否超时配 git 代理或换镜像源后重跑
Could not resolve hostDNS 解析失败nslookup github.com 无应答换 DNS（如公共 DNS）或检查网络配置
Operation timed out after N ms连接能建但大仓库传输中断重跑仍在同一仓库断加大 git 缓冲、 shallow 不可用则换时段/代理
报错出现在某个 submodule主仓已下完，子模块断看日志停在哪个子模块名原地重跑 make pdk，断点续跑只补缺的
重跑多次仍同一处失败代理只对 shell 生效、git 未配git config --get http.proxy 为空git config --global http.proxy ... 后重跑
无 fatal 字样但编译中断磁盘在构建中途耗尽（伪装成编译错）df -h 看剩余空间清出 15 GB 以上再重跑
换了网络环境后首次失败公司/校园网出口限制 GitHub手机热点对比测试走允许的网络或预下载 PDK 源码

三、排查决策图 ​

这张图按「先续跑、再定层、后修复」的顺序组织：红是报错入口与命中的根因，蓝是排查动作，绿是通过分支，橙是修复动作，紫是防复发沉淀。

eda/ts-make-pdk-git-fetch-timeout.md D2 示意图

读这张图抓主线：第一反应永远是原地重跑一次——断点续跑机制决定了重跑成本很低；只有再次超时才进入定层分支：curl/nslookup 区分网络层与 DNS 层，网络通但编译中断的要转去查磁盘（磁盘满会伪装成莫名其妙的编译错误，见第四节）。

四、逐条排查展开 ​

断点续跑是第一处置，不是重头来。 open_pdks 的构建是一组 make 目标，已下载完成的仓库和已编译完的库目录在 pdks/ 下原地保留，重跑 make pdk 时 make 只会重做缺失的目标。所以第一次看到 fatal 的正确动作就是再敲一遍 make pdk——慢网络下常见「每跑一次多下两个子模块，三五次之后全部补齐」。验证续跑成功的标志与安装文一致：pdks/sky130A/libs.ref/ 下出现 sky130_fd_sc_hd 等库目录，且里面有 lib/ 与 lef/ 文件。

定层：网络、DNS、代理三件事分开测。 curl -I https://github.com 超时说明出口层不通；nslookup github.com 无应答而 curl 走 IP 能通，是 DNS 的问题；浏览器能开 GitHub 而 git 命令超时，九成是代理只配在浏览器/系统层，git 没继承。git 的代理配置是独立的一档：

bash
git config --global http.proxy http://proxy.example.com:8080
git config --global --get http.proxy   # 确认生效

只给 https 仓库用就配 http.proxy（GitHub 的 clone URL 虽然是 https scheme，走的仍是这项配置）。配完重跑 make pdk 即可，不需要重启 Docker。

镜像加速与预下载。 代理也不通的受限网络，两条路：一是把 git 的 GitHub 访问切到可用的镜像/加速服务（git config --global url."<镜像前缀>".insteadOf "https://github.com/"，具体前缀以你所用服务为准）；二是在网络好的机器上预先克隆 skywater-pdk 与各标准单元库源，打包拷到目标机的 pdks/ 对应位置，再跑 make pdk 让构建跳过下载段。后者麻烦但最稳，适合要给一整组机器装环境的场景。

磁盘满会伪装成网络之外的随机错误。 PDK 构建中间产物比成品大得多，磁盘在中途耗尽时，症状不是明确的 no space，而是 gcc/make 莫名报错、日志戛然而止——安装文把这条列为 make pdk 段的第二高发坑。所以只要日志里没有 git 字样、又不是网络形态的中断，先 df -h：构建全程建议保留 15 GB 以上余量，构建完成后可清掉 pdks/ 下的中间目录、只留 sky130A 成品。

submodule 逐个断的场景怎么读日志。 open_pdks 的拉取不是一个大 clone，而是主仓加一串 submodule/依赖库（sky130_fd_sc_hd、sky130_fd_sc_ms 等高密度与中密度库源）。日志里 Cloning into '<库名>' 之后紧跟 fatal 的那一行，就是本次断掉的库；上一次成功拉完的库在日志里对应完整的 checkout 记录。慢网络下的典型节奏是每跑一遍 make pdk 多补齐一两个库，所以「重跑了三次还在报错」不等于没有进展——对照三次日志里最后成功拉取的库名，能看到断点在稳步后移。连续多次都断在同一个库上，才说明这个仓库的体积超出了当前网络的承受能力，该上代理或镜像，不要再无脑重试。

git config 加大缓冲对慢网络有效。 传输中途断（Operation timed out after N ms）的场景，除了配代理，还有两个 git 层面的缓解参数值得先设：git config --global http.postBuffer 524288000 加大 HTTP 缓冲，git config --global http.lowSpeedLimit 0 与 http.lowSpeedTime 999999 关掉低速超时判定。这两个参数不改变网络本身，只是让 git 对慢连接更有耐心，对「能连上但每秒只有几十 KB」的网络特别有效。

把报错原句贴去搜 issue。 OpenLane 的安装坑高度集中，Failed to connect 类问题在仓库 issue 里有成片的先例，按 issue 里的环境信息（操作系统、Docker 版本）对照自己的环境，往往能直接抄到解法——这是安装文给的朴素但常被忘的手段。

五、规范做法与预防 ​

  • 装机清单预置网络配置：给新机器装环境时，git 代理/镜像配置与 usermod -aG docker 放在同一步完成，不等报错再补。
  • 先小后大验证网络：make pdk 之前先手动 git clone 一个小仓库试探，通了再启动几十分钟的 PDK 构建。
  • 磁盘红线写进检查表：df -h 余量低于 15 GB 不开始 make pdk；装完清中间产物，保持 10 GB 以上余量。
  • 续跑优先：任何 make pdk 中断后的第一动作是原地重跑，不删 pdks/、不重拉镜像——删除是最后手段，不是第一手段。
  • 团队环境笔记：可用的代理地址、镜像前缀、预下载包位置写进团队环境笔记，新人照抄而不是各自踩一遍。

这一篇在知识体系里的位置 ​

本篇是开源 EDA 排错簇中「安装网络」节点的 FAQ 页：完整安装流程与三类失败的判别口诀见 OpenLane Docker 安装实录；装好之后的权限坑见同簇速查页，装完进入流程后的报错从 开源 EDA 报错排错中心 按工具入口分流。

一句话总结 ​

make pdk 报 fatal: unable to access github.com: Failed to connect 是 GitHub 拉源码阶段的网络超时：第一动作是原地重跑（断点续跑只补缺失的库），顽固的用 curl/nslookup 定层后给 git 配代理或换镜像源，受限网络可预下载 PDK 源码拷入 pdks/；日志无 git 字样却中途编译中断的先 df -h 查磁盘——磁盘满会伪装成随机编译错。装机清单预置代理配置与磁盘红线，这类报错基本一次清零。