1. 两个看似独立的报错实则是同一趟安装流程里的连环关卡先说说我这次踩坑的背景。要在 Ubuntu 18.04 上装 R 语言环境刚执行完apt-get update准备安装屏幕就蹦出来两行经典报错无法连接上 dl.google.com:80 (6.6.6.6)连接超时 E: 无法修正错误因为您要求某些软件包保持现状就是它们破坏了软件包间的依赖关系。第一行看起来是网络问题第二行看起来是依赖问题初看似乎是两件不相干的事。但实际排查下来这两个报错在 R 语言安装场景里是一条链表上的两个环节先解决不了仓库连接就更新不了索引更新不了索引系统就拉不到正确的依赖信息进而无法修正依赖关系。如果你只在第二行报错上死磕或者在网络配置上反复折腾都可能陷入“修了 A 又炸出 B”的死循环。这篇文章我把完整的排查链路、根因分析和可以直接抄的修复步骤都梳理出来。适合的人包括在 Ubuntu 18.04 上手动编译或通过 apt 安装最新版 R 的新手、维护老旧生产环境时碰到类似依赖冲突的运维、以及想搞懂 apt 依赖解析机制到底在做什么的 Linux 爱好者。文中涉及的命令我都会解释在干什么不会让你只复制粘贴但心里发虚。先说结论这两个问题的最优解分别是更换 apt 源到国内可直连的镜像以及为 R 4.x 系列补齐它需要的 libtinfo5 依赖。但直接给结论没有意义你需要在别的机器上复现、在别的场景里举一反三。下面按我的实际排查顺序一条条拆。2. “无法连接 dl.google.com:80 (6.6.6.6)” 到底卡在哪一环2.1 先读懂这个报错里的三个关键信息无法连接上 dl.google.com:80 (6.6.6.6)连接超时这行信息有三个值得注意的点。第一它连接的是 80 端口HTTP不是 443 端口HTTPS。很多人在这一步就直接去检查防火墙或者代理配置但其实这里暴露的是 apt 源配置里的 URL 本身可能就是 HTTP 的。旧配置里习惯写成http://加上国内网络环境对某些国外域名的 TCP 连接极不稳定超时就成了必然。第二它解析出的 IP 是 6.6.6.6。这个 IP 不是 dl.google.com 的正常公网地址。正常访问 Google 系服务DNS 应该解析出一组 Google 的全球 IP。结果解析到一个 6.6.6.6说明DNS 解析环节被干扰或者说你本地 DNS 返回了一个不可达的地址。 6.6.6.6 这种地址段本身就不是 Google 的看到这个 IP 基本可以断定域名解析结果已经被污染。第三它发生在 apt 的 update/install 阶段而不是浏览器访问阶段。apt 在更新索引或者安装软件包时会根据/etc/apt/sources.list和/etc/apt/sources.list.d/目录下的源配置去连接仓库。这里面如果混入了某个包含dl.google.com的第三方源比如 Chrome 浏览器自带的 Google 源、某些软件包安装时自动写入的 Google Cloud 源就会在更新时报这个错。我当时的环境里就同时存在两个源文件/etc/apt/sources.list里的默认 Ubuntu 源以及/etc/apt/sources.list.d/google-chrome.list。后者指向dl.google.com/linux/chrome/deb/。平时不装东西不觉得一执行apt update就要连一把 Google连不上就直接报错。虽然这个报错不一定完全中断 update 流程但在某些 apt 版本策略下它会让你后续 install 命令的依赖解析阶段进入不可靠状态。2.2 顺着报错定位“罪魁祸首”的排查思路不要把时间花在纠结 dl.google.com 为什么不给你连上。这个域名在网络环境里不稳定已经是常态你要做的是把 apt 的工作路径拉回到可控范围。我的排查顺序是这样的第一步看当前 apt 源配置里到底有哪些可用的源文件。ls -l /etc/apt/sources.list /etc/apt/sources.list.d/重点看有没有google-chrome.list、microsoft-prod.list、docker.list这类外部软件源。有的话用cat查看内容cat /etc/apt/sources.list.d/google-chrome.list第二步更新索引并加-o Acquire::http::Timeout参数缩短超时时间让报错迅速暴露。apt update -o Acquire::http::Timeout5第三步确认是不是某个源文件单独导致的问题。可以在/etc/apt/sources.list.d/下临时改掉可疑文件的后缀名比如mv /etc/apt/sources.list.d/google-chrome.list /etc/apt/sources.list.d/google-chrome.list.bak apt update如果报错消失说明问题就出在这个源上。这个方法屡试不爽因为它用二分法精准定位不做任何系统级改动。第四步如果连默认的 Ubuntu 源也慢或者超时直接把主源切换为国内镜像。这是在国内服务器上安装任何软件前几乎必做的一步。具体操作我会在下一节展开。2.3 换掉源之后别忘了同步系统时间排查过程中还有一个隐蔽问题值得单独拎出来说系统时间错误会导致 HTTPS 源连接失败。现在很多源仓库都强制 HTTPSapt 在做 TLS 握手的时候会校验证书有效性如果系统时间和真实时间相差太远证书会直接判定为未生效表现也是连接失败或者超时。刚拿到一台全新的 Ubuntu 18.04 服务器时时间经常是默认的 UTC 且未同步。你可以在执行任何网络操作之前先看一眼date -R如果时间明显不对用 ntpdate 或者 timedatectl 同步sudo ntpdate ntp.aliyun.com或者走 systemd 的方式sudo timedatectl set-ntp true这个坑我当年踩过一次查代理查了半天最后发现是虚机时间慢了整整一天。遇到网络类报错时间校准应该排在 DNS 检查之后、防火墙检查之前。2.4 确认 R 安装场景下连接 dl.google.com 的真实来源回到 R 语言这个具体场景。很多人安装 R 前会先执行sudo apt update sudo apt install r-base然后报错。问题来了你到底要不要在 Ubuntu 18.04 上装 R如果要装最新版 R 4.x官方推荐的方式是修改 sources.list 加入 CRAN 的 apt 源deb https://cloud.r-project.org/bin/linux/ubuntu bionic-cran40/但cloud.r-project.org这个域名是 CDN实际会重定向到cran.rstudio.com而 RStudio 的服务器在部分网络环境下可能会跨到 Google Cloud 的架构里间接又撞到dl.google.com的头上去。这个链路有一定偶然性但我在一台机器上复现过apt update输出里确实出现过dl.google.com连接尝试看起来像是被某个 APT 源的跳转逻辑引入的。规避方式很直接用国内 CRAN 镜像替代 cloud.r-project.org。清华 TUNA、中科大 USTC 都提供 R 的 apt 源不需要绕道 Google。3. Ubuntu 18.04 安装 R 的源配置替换步骤3.1 备份原有 sources.list 并写入国内镜像源Ubuntu 18.04 对应的代号是 bionic。国内可用的镜像源很多我用的是清华 TUNA 的。改之前先把原文件备份好养成习惯sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak.$(date %F)然后编辑sudo vim /etc/apt/sources.list把内容整体替换成下面的版本。注意一定要根据你的 Ubuntu 版本号选定 codename18.04 是 bionic不要照抄 20.04 或 22.04 的配置deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse注释掉原有的deb http://archive.ubuntu.com/ubuntu/系列行即可不必删除。备份存在的意义是方便回滚。3.2 添加国内 CRAN 源锁定 R 4.x 路线Ubuntu 18.04 自带的 R 版本是 3.2 还是 3.4 我记不太清了反正比较旧。CRAN 官方是建议用如下方式添加仓库sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E298A3A825C0D65DFD57CBB651716619E084DAB9 sudo add-apt-repository deb https://cloud.r-project.org/bin/linux/ubuntu bionic-cran40/但在国内网络环境下keyserver.ubuntu.com偶尔也会连不上cloud.r-project.org又可能发生重定向问题。我建议直接用国内 CRAN 镜像。TUNA 提供的 R 源地址是https://mirrors.tuna.tsinghua.edu.cn/CRAN/bin/linux/ubuntu bionic-cran40/添加方式echo deb https://mirrors.tuna.tsinghua.edu.cn/CRAN/bin/linux/ubuntu bionic-cran40/ | sudo tee /etc/apt/sources.list.d/r-cran.list注意如果你已经因为添加 cloud.r-project.org 导致 apt 源列表里出现了指向 Google 的解析链路务必把源列表里相关条目清理掉。顺手把google-chrome.list这类不必要的第三方源移走避免apt update时又被 dl.google.com 卡住。3.3 添加密钥的正确姿势与权限校验添加第三方源之后需要导入 GPG key。CRAN 官方 R 4.x 的 key ID 是E298A3A825C0D65DFD57CBB651716619E084DAB9可以用下面的方式导入同时测试 keyserver 连通性sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E298A3A825C0D65DFD57CBB651716619E084DAB9如果 keyserver 超时可以从 TUNA 的 key 页面直接下载。TUNA 提供了https://mirrors.tuna.tsinghua.edu.cn/CRAN/bin/linux/ubuntu/下的 key 文件路径也可以从 Ubuntu keyring 导入。实际执行时我看到报错会提示NO_PUBKEY这时候再补导入不用提前焦虑。导入后验证一下apt-key list | grep -A 5 E298看到公钥信息出现即可。3.4 重新 update观察报错是否仍然指向 dl.google.comsudo apt update这一步如果顺利输出会显示从mirrors.tuna.tsinghua.edu.cn拉取索引不再出现dl.google.com。如果仍然有连接尝试排查/etc/apt/sources.list.d/下所有文件把可疑条目全部注释掉。直到apt update干净通过网络这一关才算过去。注意apt update通过只能说明索引拉取正常不保证依赖解析一定成功。依赖问题是下一章节的主线。4. “E: 无法修正错误因为您要求某些软件包保持现状” 的根因与解法4.1 错误产生的本质apt 依赖解析的服务条款先翻译一下这句英文报错E: Unable to correct problems, you have held broken packages.字面意思是“你 hold 住了损坏的软件包”。这跟中文报错“要求某些软件包保持现状”是一个意思。在 apt 的依赖解析逻辑里它会根据你要安装的包和已安装的包之间的关系自动计算一套升级、降级、新装的方案。当某些包处于以下三种状态之一时解析就会失败被 holdapt-mark hold或者/etc/apt/preferences里设置了 Pin-Priority导致版本被锁定。依赖冲突目标包需要的依赖版本与当前系统内已装版本冲突且 apt 不会自动降级你已装的包。依赖缺失目标包依赖的某个包在仓库里根本不存在或者版本不满足。R 4.x 在 Ubuntu 18.04 上典型的依赖问题就是libtinfo5 缺失。R 4.0 之后编译的二进制包依赖libtinfo.so.5但 Ubuntu 18.04 的仓库里默认提供的是libtinfo.so.6对应包名libtinfo6。你没法直接在 18.04 官方仓库里apt install libtinfo5因为该版本对应的库未被收录。于是你要求装 r-base它要求装 libtinfo5apt 找不到就报“无法修正错误”。4.2 从报错本身提取有效线索而不是只看最后一行执行sudo apt install r-base完整输出里除了最后一行错误前面往往还有一行类似The following packages have unmet dependencies: r-base-core : Depends: libtinfo5 but it is not installable这个Depends: libtinfo5才是关键信息。一定要养成看完整输出的习惯。很多人只看最后一行“保持现状”就直接开始搜错误文本结果搜出来的方案千奇百怪包括暴力删除系统包、禁用某源、aptitude 大法其中不少方案很危险。我当时把输出存下来后发现了三行关键信息r-base-core依赖libtinfo5libtinfo5在 bionic 仓库里不可安装系统提示可能需要apt --fix-broken install或手动安装依赖看到这些思路就明确了补上 libtinfo5 即可。4.3 libtinfo5 的获取途径本地 .deb 文件法与第三方源法方法一直接下载 Ubuntu 18.04 可用的 libtinfo5 包在 Ubuntu 18.04 上libtinfo5 虽然没有直接收录在新版仓库但可以通过 Ubuntu 的旧包仓库或者 Launchpad 找到。实测可用的链接是 Ubuntu 的bionic-updates或者bionic-security中的libtinfo5包但 18.04 的官方仓库里我记得是没有 5 版本的需要通过如下方式下载 .deb 文件wget http://archive.ubuntu.com/ubuntu/pool/universe/n/ncurses/libtinfo5_6.1-1ubuntu1_amd64.deb注意这个 URL 需要确认实际存在的版本号。如果链接失效可以用apt-cache policy libtinfo5先看一下当前系统能否解析到这个包。如果输出N: Unable to locate package libtinfo5说明源里确实没有必须走手动安装。下载后sudo dpkg -i libtinfo5_*.deb如果提示缺少其他依赖再执行sudo apt -f install方法二R 官方社区提供的预编译依赖比较省事的方式是参考 R 官方在 Ubuntu 上的文档它们也意识到 libtinfo5 的缺失问题。CRAN 的bionic-cran40源中其实附带了这个依赖的元信息在某些情况下 apt 会提示r-base-dev或者r-base-core的推荐安装里包含libtinfo5但前提是你已经添加了 CRAN 源且源里有这个包。实测 TUNA 的镜像里同步了libtinfo5但你的系统里如果用的是旧源可能拉不到。方法三临时启用 bionic-backports 或者 focal 源不推荐除非你很清楚风险网上有人建议直接把 Ubuntu 20.04 的 libtinfo5 包拿来用。版本跨度过大动态库的 ABI 不一定兼容 glibc 版本轻则跑不起来重则影响其他依赖库的使用。我不建议在生产环境用这个方法。Ubuntu 18.04 是一个相对保守的系统不要为了一个小依赖把系统搞成“混血儿”。我最终采用的方式在 TUNA 镜像源下直接检索libtinfo5apt-cache search libtinfo5如果输出里有libtinfo5 - transitional package直接安装sudo apt install libtinfo5如果提示不能定位再从 Ubuntu 官方包存档网站下载 .deb 手动安装。整个过程没有动用任何非常规操作。4.4 安装 R 前必要的系统级依赖一次装齐libtinfo5 只是依赖链里最显眼的一环。R 作为一个统计计算平台还会依赖很多开发库。建议在装 R 之前先把编译环境和其他可能缺失的库一起装上sudo apt install --no-install-recommends \ software-properties-common \ dirmngr \ libxml2-dev \ libssl-dev \ libcurl4-openssl-dev \ libopenblas-dev \ libnlopt-dev \ libtinfo5这里面libxml2-dev、libssl-dev、libcurl4-openssl-dev是 R 包安装时的三大基础库很多 R 包在编译时会依赖它们。libopenblas-dev提供高性能的 BLAS 矩阵运算库R 装好后做数值计算会明显更快。libnlopt-dev是部分优化算法的依赖如果要装nloptr这个 R 包就需要它。--no-install-recommends避免系统拉进来一堆建议包减少依赖冲突面。R 本身是解释型语言但它的包生态里有大量 C/C 代码需要编译所以编译工具链也要补齐sudo apt install build-essential gfortrangfortran很关键很多统计计算包如quadprog、forecast的底层依赖 Fortran 编译器。4.5 处理完依赖后重新安装 r-base 的完整命令序列sudo apt update sudo apt install r-base r-base-dev如果一切正常apt 会列出需要安装的包数量包括r-base-core、r-base-dev、r-recommended等最后提示你输入Y。安装结束后验证R --version能看到类似R version 4.x.x (2024-xx-xx)的输出说明安装成功。如果执行到这里仍然报依赖错误先别急着用aptitude或者apt --fix-broken install盲目修复。你应该确认下面几件事是否还有 hold 状态的包apt-mark showhold是否还有未完成的 dpkg 安装dpkg --audit是否有版本冲突apt-cache policy r-base-core这套检查顺序其实覆盖了 90% 的依赖类问题。5. 一条完整的“Ubuntu 18.04 装 R”实操路径从空白环境到 R 可用结合前面所有排查下面是一条我在干净环境里实测可行的完整路径。每一步都有目的不是简单的命令堆叠。5.1 步骤一系统基础准备时间、语言、网络sudo timedatectl set-ntp true sudo apt update sudo apt install -y vim wget curl ca-certificates apt-transport-httpsca-certificates和apt-transport-https经常被忽略但它们能解决 HTTPS 源证书验证和传输协议支持的问题。如果系统太旧apt-transport-https可能已经不需要了因为新版 apt 自带支持安装也无妨。5.2 步骤二更换主源为 TUNA参照 3.1 的操作确保apt update能正常从国内拉到索引。执行完成后看输出里有无报错再继续下一步。5.3 步骤三添加 CRAN 源并导入密钥echo deb https://mirrors.tuna.tsinghua.edu.cn/CRAN/bin/linux/ubuntu bionic-cran40/ | sudo tee /etc/apt/sources.list.d/r-cran.list sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys E298A3A825C0D65DFD57CBB651716619E084DAB9如果密钥服务器连不上用 TUNA 提供的https://mirrors.tuna.tsinghua.edu.cn/CRAN/bin/linux/ubuntu/路径下的 key 文件导入wget -qO- https://mirrors.tuna.tsinghua.edu.cn/CRAN/bin/linux/ubuntu/ | grep -i pubkey找到实际 key 链接后用 apt-key add 导入。不同镜像站结构略不同自行检索即可。5.4 步骤四安装 libtinfo5apt-cache policy libtinfo5看看能不能定位到这个包。能定位就直接装不能定位就手动下载 .debcd /tmp wget http://archive.ubuntu.com/ubuntu/pool/universe/n/ncurses/libtinfo5_6.1-1ubuntu1_amd64.deb sudo dpkg -i libtinfo5_*.deb安装完成后用ldconfig -p | grep libtinfo可以看到libtinfo.so.5已经在列表里。5.5 步骤五安装 R 本体sudo apt install -y r-base r-base-dev要装r-base-dev是因为它包含构建 R 包所需的基础头文件和工具只装r-base后面install.packages()时大概率会缺Rscript或编译工具。5.6 步骤六验证 R 环境并设置国内 CRAN 镜像R 装完后用R进入交互界面试试安装一个简单包比如install.packages(jsonlite)。第一次装包往往会选择默认的 CRAN 镜像这里可以提前把镜像配置写入~/.Rprofileoptions(repos c(CRAN https://mirrors.tuna.tsinghua.edu.cn/CRAN/))这一行配置放在.Rprofile里R 每次启动都会自动加载。国内连默认 CRAN 非常慢这个配置能直接改善安装 R 包的速度是实测最有效的优化手段之一。整个流程走完R 环境已经可用。如果你只关心“能装能用”到这里就可以收工了。但作为排错文章我觉得有必要把这次踩坑中更重要的一条经验单独讲讲如何判断一个问题值不值得深挖以及如何规避类似问题在你环境里反复出现。6. 我自己在这两个报错上排了半天之后的几点心得6.1 报错之间是有因果链的不要孤立地处理某个错误文本这次我在一开始犯的错误就是看到dl.google.com连接超时第一反应是去检查防火墙、改代理折腾了二十分钟看到依赖关系报错又去执行aptitude install r-base结果 aptitude 给我列了一堆降级方案差点把系统核心库版本给改了。后来冷静下来把整条报错从头到尾读了一遍才发现这两个问题的根源都在源配置与依赖缺失上。报错信息里的每个字段都值得抠尤其是 IP 地址、包名和Depends那几行它们直接指向问题源头。6.2 不要动不动就“强制修复”很多所谓的修复比你想象的激进apt --fix-broken install这个命令确实能处理一部分依赖问题但它的行为是“尝试各种可能的修复组合”有时候会删除你以为无害的包。在旧版本 Ubuntu 上做这种操作风险比在新版本上高得多。我的建议是能用明确的手动依赖补齐方案就不要用黑盒的自动修复。装一个明确的.deb文件、安装一个明确的libtinfo5包每一步都可控、可回滚。6.3 版本的“新旧”不能只看包名要看动态库符号R 4.x 依赖libtinfo.so.5而不是包名libtinfo5这个问题本质是动态库 ABI 的升级。如果你以后在别的发行版上遇到类似“某个软件更新后依赖库版本对不上”的报错记住不是包名包含版本号就一定兼容。用ldd检查可执行文件的动态库依赖列表比搜报错文本可靠得多。比如ldd /usr/lib/R/bin/exec/R | grep tinfo如果输出显示libtinfo.so.5 not found那就说明系统少了对应版本的动态库接下来要做的不是改 R 的二进制而是补动态库。6.4 国内网络环境下的 R 生态镜像配置要一步到位R 语言的安装只是第一步后续装包才是日常。R 的默认镜像在国外没有提前配置国内镜像的话install.packages()的体验会让你怀疑人生。除了 CRAN 镜像Bioconductor 的镜像也要相应调整。如果你做生物信息学相关分析在~/.Rprofile里加两行options(BioC_mirror https://mirrors.tuna.tsinghua.edu.cn/bioconductor)这样装BiocManager相关包时速度也会快很多。这属于环境配置的“默认动作”不是可选项。6.5 最后顺带解决一个问题系统里残留的 google-chrome 源该不该删我的建议是如果机器上不需要 Chrome 的自动更新直接把.list文件改名备份即可不属于系统关键组件。需要重新启用时把后缀改回来就行。这个操作不仅解决了dl.google.com报错也减少了apt update的整体耗时。但如果你确实在用 Chrome 且需要自动更新那只能保留这个源并接受国内网络下apt update偶发超时的现实——没有两全其美的方案因为 Chrome 的 apt 源只有 Google 官方一家没有国内镜像。6.6 以后在其它 Ubuntu 版本上装 R思路是相通的这套排查逻辑不局限于 18.04。Ubuntu 20.04 上装 R 4.1、4.2 也可能遇到依赖缺失只是缺失的包名可能不同22.04 上装 R 4.3 可能又是另一套依赖需求。核心思路永远是先看完整报错提取依赖名再看系统仓库里有没有这个包没有就定点下载 .deb 补齐最后再尝试安装目标包。这个过程可以复用到安装 Nodes.js、MariaDB、PostgreSQL 任何一个复杂软件包上。我在实际测试中发现只要遵循“换源 → 补依赖 → 正常安装”的顺序几乎不会再被这两个报错卡住。与其每次踩坑后搜答案不如把这套流程固化下来形成肌肉记忆。你接下来的操作中如果还碰到其它依赖问题按照同样的排查框架大概率也能自己找出一条路来。