装 Apollo10.0 时最让人上头的不是漫长的编译而是环境准备阶段sudo apt update突然甩给你一行红字E: Type echo is not known on line 1 in source list /etc/apt/sources.list.d/apollo10.list第一次看到这个报错的人基本都懵我明明没手动改过源文件这个echo是哪来的其实九成情况源自同一个原因某个.list文件里被混进了一行本该在终端执行的 shell 命令apt 把它当成了源配置去解析结果第一列的echo被识别成一个未知类型整个更新流程直接中断。这篇文章就把 Apollo10.0 安装过程中最常碰到的这个 Apt 源配置问题讲透包含报错原理、定位方法、修复命令、正确加源姿势以及修好后你还会遇到哪些连锁坑。正在装 Apollo10.0或者还在跟/etc/apt/sources.list.d/搏斗的同学可以直接照着抄。1. 先别慌看懂这个报错在说什么1.1 逐字拆解 E: Type echo is not knownUbuntu 的 apt 软件源配置每一行有固定格式。以最常见的deb行为例deb [archamd64] https://mirrors.example.com/ubuntu focal main这里第一列deb就是 apt 认可的“类型”Type表示这一行声明的是一个二进制软件包源。apt 能识别的类型只有deb、deb-src、not以及#开头的注释行。当你某个源文件的第一列出现了echoapt 完全不认识这个类型于是直接报Type echo is not known。问题文件的真实内容往往是这样的echo deb [archamd64] https://mirrors.example.com/ubuntu focal main | sudo tee /etc/apt/sources.list.d/apollo10.list这根本不是一个源条目而是一条完整的 shell 命令行。它只是恰好以echo开头于是被 apt 拿去当类型解析自然就炸了。1.2 这个错误和 Apollo10.0 部署的关联Apollo10.0 是自动驾驶开发平台对宿主机环境要求很高通常需要 Ubuntu 20.04 或 22.04、Docker、NVIDIA 驱动以及一堆编译依赖。为了装齐这些依赖安装文档大概率会指导你往/etc/apt/sources.list.d/里写入若干源配置比如这样echo deb [archamd64] https://mirrors.example.com/ubuntu focal main | sudo tee /etc/apt/sources.list.d/apollo10.list这条命令本身没问题但网上教程常常把“要复制进文件的内容”和“写入文件的命令”放在同一个代码块里。读者在按文档操作时如果图省事直接全选复制又鬼使神差地把内容粘进了nano或vim打开的源文件里最终.list文件第一行就变成了整条echo命令。这个错误不是 Apollo10.0 特有的但它的安装流程里要配源、换源、装依赖操作密集所以特别容易撞上。2. 为什么好好的源文件会变成这样2.1 最常见的三种“案发现场”第一种也是比例最高的一种教程代码块里把命令和配置内容混在一起读者在复制时把开头的echo ...整个复制进了源文件。结果就是从/etc/apt/sources.list.d/目录里多出一个.list文件文件第一行是完整的 shell 命令后面可能还跟着好几行命令片段。第二种文件本来是从别处同步过来的。比如用scp、rsync同步配置时不小心把包含echo命令的脚本文件改名成.list放进了sources.list.dapt 更新时同样会中招。第三种环境变量和引号翻车。有人习惯用sudo echo deb ... /etc/apt/sources.list.d/xxx.list这种方式写文件实际上sudo echo只是把echo命令以 root 身份执行而重定向是当前 shell 干的普通用户对/etc/apt/sources.list.d/没有写权限命令会直接报permission denied。但如果你已经在一个 root shell 里又随手把终端里某条命令的完整文本粘进了文件那照样会把echo写进去。2.2 为什么 apt 对 sources.list.d 里的文件这么敏感/etc/apt/sources.list.d/是 apt 的“分片配置目录”系统在读完主配置文件/etc/apt/sources.list后会遍历这个目录下所有以.list或.sources结尾的文件把它们逐行合并进源配置。这个机制本身很简单但它的代价是任何非源内容的文字混进文件都会被当成配置解析。可以把它理解成一张购物清单apt 是收银员它只认清单里的商品行。结果清单第一行写着“去超市买牛奶的命令”收银员当然不认识直接拒收。报错并不是想要吓唬你而是在保护系统不被一个半残的源配置带偏这跟编译报错一样早暴露早处理。3. 三分钟修复实操删掉脏行写回正确源3.1 第一步定位具体文件报错信息里其实已经给出了嫌疑文件路径比如/etc/apt/sources.list.d/apollo10.list。如果报错只给了目录就手动列一下ls -l /etc/apt/sources.list.d/找到可疑文件后一定要带着行号查看内容sudo cat -n /etc/apt/sources.list.d/apollo10.list输出大概率长这样1 echo deb [archamd64] https://mirrors.example.com/ubuntu focal main | sudo tee /etc/apt/sources.list.d/apollo10.list看到第 1 行开头是echo不用怀疑就是它了。3.2 第二步按情况选择修复方式方法一直接编辑修正这是最直观也是我最推荐的方式sudo nano /etc/apt/sources.list.d/apollo10.list在编辑器里删掉第 1 行写入正确的源内容保存退出。正确内容长这样deb [archamd64] https://mirrors.example.com/ubuntu focal main不要丢掉[archamd64]这段它告诉 apt 只获取 amd64 架构的软件包信息否则后续可能出现 404 或者架构文件缺失的奇怪报错。方法二如果文件里只有这一行坏内容用sed删掉第 1 行最快sudo sed -i 1d /etc/apt/sources.list.d/apollo10.list删完以后文件可能是空的需要追加正确行echo deb [archamd64] https://mirrors.example.com/ubuntu focal main | sudo tee -a /etc/apt/sources.list.d/apollo10.list方法三文件已经被折腾得乱七八糟干脆备份后重建。备份一定要做否则把某个必要的源删掉后想找回来就麻烦了sudo mv /etc/apt/sources.list.d/apollo10.list /etc/apt/sources.list.d/apollo10.list.bak echo deb [archamd64] https://mirrors.example.com/ubuntu focal main | sudo tee /etc/apt/sources.list.d/apollo10.list.bak后缀不会被 apt 加载所以备份后可以安心放在目录里。3.3 第三步修改后验证修复完成后立刻跑一次更新sudo apt update如果还有残留问题会继续报下一个具体文件路径按上面流程继续处理。想只看错误行可以这样过滤sudo apt update 21 | grep -E ^E:这样比一屏刷过去的日志要清晰得多。4. 正确添加软件源的四种姿势4.1 姿势一tee 管道法最省心日常手动加源我最常用的是tee管道echo deb [archamd64] https://mirrors.example.com/ubuntu focal main | sudo tee /etc/apt/sources.list.d/apollo10.list为什么不用sudo echo ... file因为重定向由当前 shell 执行sudo echo只管提升 echo 的权限管不住重定向。用tee就不同了tee本身以 root 身份运行它从标准输入读取内容然后再写入目标文件写文件的动作具备了 root 权限这才是真正一次到位的写法。4.2 姿势二sudo sh -c 把整个重定向交给 root如果在脚本里写也可以用sudo sh -c echo deb [archamd64] https://mirrors.example.com/ubuntu focal main /etc/apt/sources.list.d/apollo10.list这里sh -c会把整条命令放到 root 上下文中执行重定向自然也是 root 身份。注意外层是单引号避免 shell 对$符号做变量展开。这种写法在单行命令行里稍显绕但可读性还算可以。4.3 姿势三编辑器直接写适合内容复杂的情况如果源内容很长比如带signed-by、多个组件、注释那就老老实实打开编辑器sudo nano /etc/apt/sources.list.d/apollo10.list编辑器最大的优点是不会把echo命令开头误写进去因为你看到的是一个文件编辑界面。另一个好处是能顺便看清文件里已有的内容避免盲目覆盖。4.4 姿势四heredoc 批量写入自动化部署首选需要给多台机器批量配环境时脚本里用 heredoc 最清晰sudo tee /etc/apt/sources.list.d/apollo10.list /dev/null EOF deb [archamd64] https://mirrors.example.com/ubuntu focal main deb-src https://mirrors.example.com/ubuntu focal main EOF这里EOF的引号非常重要。加引号是告诉 shell 不要对这里面的内容做任何变量展开这样$、\等符号才能原样写入文件。写法安全性适用场景echo tee高日常单条写入sudo sh -c中脚本内单行写入编辑器高内容复杂、需要观察heredoc高多行批量、自动化脚本5. Apollo10.0 部署中遇到这个错误的现场复盘5.1 我见过的最典型现场这个报错在社群求助里出现频率极高我印象里至少有十次以上是同一个套路一上来先贴apt update报错截图然后问是不是 Apollo10.0 和系统不兼容。其实根本不是平台的问题而是某个.list文件第一行被粘贴进了一条带echo的命令。排查思路很简单先看报错给出的文件路径再cat那个文件确认第一行是不是命令文本然后sed删掉或直接改写。整套流程三分钟内就能搞定不要一上来就想着重装系统或者重装 Apollo那会把问题搞得更复杂。5.2 Apollo10.0 环境准备阶段还容易踩的坑修好源之后前面还有几个高频坑在等着你我直接整理成一张速查表问题典型表现建议手段Docker 未装或版本太老dev_start.sh起不来提示找不到 docker安装较新的 Docker Engine执行完把当前用户加入 docker 组NVIDIA 容器工具缺失Docker 里nvidia-smi看不到 GPU安装 nvidia-container-toolkit之后重启 docker 服务磁盘空间不足编译中途失败提示 no space left编译前先用df -h检查挂载盘剩余空间Ubuntu 版本不匹配安装脚本版本检查不通过严格按 Apollo10.0 文档要求准备系统版本依赖源没配好apt install找不到包名先跑通apt update再继续装依赖5.3 修好之后你还会遇到什么源文件格式修好了只是过了第一关。后续最常冒出来的是这几类错误Malformed entry in sources.list通常是deb行后面少了组件或者 URL 路径写错。404 Not FoundUbuntu 代号写错了比如 22.04 的代号是jammy你在源里却写了focal服务器上根本找不到对应仓库。NO_PUBKEY源仓库的公钥没导入。新版本 Ubuntu 已经不推荐apt-key add正确做法是把源站提供的.gpg文件放到/etc/apt/keyrings/再用[signed-by/etc/apt/keyrings/xxx.gpg]引用。Skipping acquire of configured file架构标识配置有问题把[archamd64]补上基本能解决。这些问题和刚才那个echo报错同属“源配置”这一大类处理顺序都是先定位文件再确认格式最后重新apt update验证。6. 快问快答源配置里那些反复被问的细节6.1 报错说的是 line 1但文件里第一行不是 echo怎么回事有几种可能你看到的文件不是报错指向的那个文件在sources.list.d下可能存在多个.list文件报错行在另一个文件里也可能第一行以deb开头但行尾拼了一段命令文本apt 的“Type”还是第一列所以显示的疑似类型不一定就是echo。最直接的办法是全局搜一下sudo grep -R echo /etc/apt/sources.list.d/这样能把所有带echo的行都揪出来。6.2 直接把 /etc/apt/sources.list.d/ 清空可以吗可以但不建议。这个目录里通常还会有别的仓库配置比如 Docker、NVIDIA 或其他开发工具的源。清空之后apt update确实不报错了但很多软件会变成“找不到安装包”。正确做法是只处理报错指向的文件其余不要动。6.3 文件扩展名必须叫 .list 吗在这个目录下只有.list和.sources后缀会被 apt 加载其他后缀一律视而不见。如果教程让你把文件保存成.txt或.conf那就是无效配置修半天apt update也不会生效。6.4 修好源之后之前失败的安装会自动补上吗不会。源配置修好之后只代表apt update能正常拉取软件包列表之前失败的sudo apt install -y xxx或 Apollo 安装脚本不会被自动重跑需要手动重新执行一次。6.5 为什么终端里明明是 echo 开头文件里却独独有这一行因为复制粘贴的时候很多人会把整条命令当成“文件内容”处理。尤其是用远程终端时CtrlShiftC 和 CtrlShiftV 的手速一旦跟不上眼睛命令头和命令体就容易一起被复制进奇怪的地方。这也是为什么我强烈建议加源时优先用tee或 heredoc因为机器不会犯这种粘贴错误。最后再分享一个我自己的排查习惯遇到Type xxx is not known这类报错永远先看具体.list文件而不是先怀疑 Apollo10.0 和系统不兼容。把cat的输出和报错原文放在一起看十次有九次问题立刻明了。Apollo10.0 的环境配置是个系统工程但只要你把源、Docker、GPU 这三关顺序理清楚后面的编译流程反而顺滑得多。