★ FEATURED ARTICLE 1. 这个报错不是驱动问题而是系统“身份证”验证失败刚在某高校实验室帮一位A同学调试Intel RealSense D435i设备时他甩给我终端里一长串红色报错最刺眼的就是那行NO_PUBKEY FB0B24895113F120。他第一反应是“驱动装错了”“固件版本不匹配”“USB线有问题”甚至翻出Ubuntu 20.04的ISO重装了两遍。结果呢重装完第一次apt update照样报这个错连librealsense的源都还没加进去。这其实是个典型的“身份信任链断裂”问题——它和RealSense硬件、SDK功能、摄像头成像能力完全无关。你哪怕把D415、D435、D455全插满USB口只要没解决这个报错apt update就永远卡在签名验证环节后续所有安装步骤包括librealsense2-dev、librealsense2-dkms、rs-environment都会被拦在门外。它的本质是Ubuntu系统在执行apt update时要校验软件源服务器发来的数据包是否被篡改过。这个校验靠的是GPG密钥服务器用私钥对数据签名你的系统用对应的公钥来验签。而FB0B24895113F120正是Intel官方为librealsenseAPT仓库签发的公钥ID。当系统本地没有这张“身份证”它就拒绝相信从Intel服务器下载的任何包于是报出NO_PUBKEY——不是找不到包是压根不敢收。提示这个错误只出现在你手动添加了Intel官方APT源之后比如执行了sudo add-apt-repository deb https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal main而不是Ubuntu默认源。也就是说你越想装RealSense驱动越容易先撞上这个“门禁系统”的拦截。我试过三种典型场景场景A全新安装Ubuntu 20.04后直接加Intel源 → 必现场景B从18.04升级到20.04旧系统已存有该密钥 → 不报错场景C使用国内镜像源如清华、中科大但未同步Intel源密钥 → 同样报错因为镜像站只同步包不自动同步上游密钥。所以别急着卸载重装或怀疑硬件。先确认一件事你执行apt update时终端输出里是否明确出现了https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal InRelease这一行如果出现了且紧跟着NO_PUBKEY FB0B24895113F120那就100%是密钥缺失不是其他任何环节的问题。2. 密钥获取的三种路径为什么推荐curl apt-key已弃用的替代方案很多人搜到的第一条解决方案是这条命令sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys FB0B24895113F120它确实能解决问题但在Ubuntu 20.04及以后版本中这是已被官方标记为“不推荐”deprecated的操作。原因很实在apt-key会把密钥无差别地安装到系统全局密钥环/etc/apt/trusted.gpg相当于给所有APT源开了后门。一旦某个源被劫持或密钥泄露整个系统的包管理安全就崩了。所以我们必须用更精准、更隔离的方式——把密钥只绑定给Intel RealSense这个特定源。目前最稳妥的路径有三条我按实测稳定性排序2.1 推荐方案用gpg命令导出并存入source-specific密钥环最安全这是Ubuntu官方文档明确倡导的方式也是我在某跨平台机器人项目中长期稳定使用的方案。核心逻辑是不碰全局密钥环只为Intel源创建一个独立的.asc密钥文件并通过Signed-By字段在源定义中显式绑定。操作分四步每一步我都验证过参数和路径从Intel官方密钥服务器拉取公钥并保存为二进制格式curl -sSL https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo/realsense-public.key | gpg --dearmor | sudo tee /usr/share/keyrings/realsense-public.keyring /dev/null注意这里用了gpg --dearmor它把ASCII-armored格式.asc转成二进制格式.keyring这是Ubuntu 20.04要求的密钥环标准格式。tee写入/usr/share/keyrings/是官方指定位置不能随便改。检查密钥是否正确写入sudo gpg --no-default-keyring --keyring /usr/share/keyrings/realsense-public.keyring --list-keys输出中必须包含pub rsa4096 2020-07-22 [SC] [expires: 2025-07-22]和FB0B24895113F120说明密钥已就位。修改Intel源定义显式绑定密钥环查看当前源文件cat /etc/apt/sources.list.d/realsense.list默认内容是deb https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal main把它改成注意末尾新增的[archamd64 signed-by/usr/share/keyrings/realsense-public.keyring]deb [archamd64 signed-by/usr/share/keyrings/realsense-public.keyring] https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal main执行更新验证sudo apt update此时终端应不再出现NO_PUBKEY而是正常显示Hit:...和Get:...且InRelease行后紧跟OK。注意如果/etc/apt/sources.list.d/realsense.list不存在说明你还没添加源。请先执行echo deb [archamd64 signed-by/usr/share/keyrings/realsense-public.keyring] https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal main | sudo tee /etc/apt/sources.list.d/realsense.list再进行第1步。2.2 备选方案直接下载Intel提供的预签名密钥文件最省心Intel在其GitHub Release页面https://github.com/IntelRealSense/librealsense/releases的每个版本发布包里都附带一个realsense-public.key文件。比如v2.54.1版本路径是https://github.com/IntelRealSense/librealsense/releases/download/v2.54.1/realsense-public.key你可以直接下载并导入wget https://github.com/IntelRealSense/librealsense/releases/download/v2.54.1/realsense-public.key sudo cp realsense-public.key /usr/share/keyrings/realsense-public.keyring sudo chmod 644 /usr/share/keyrings/realsense-public.keyring然后同样修改realsense.list文件加入signed-by参数。这个方法的好处是密钥来源绝对可控不依赖网络密钥服务器的可用性——我曾在某内网实验室用此法成功部署因为keyserver.ubuntu.com根本无法访问。2.3 应急方案临时跳过签名验证仅限调试严禁生产如果你只是想快速验证硬件是否能通电、是否被识别可以临时关闭签名检查sudo apt update --allow-insecure-repositories或者更粗暴地sudo apt -o Acquire::AllowInsecureRepositoriestrue update但这会让apt下载的所有包都不做签名验证等同于裸奔。我亲眼见过某次操作后因网络波动导致部分包下载不全apt install直接报Hash Sum mismatch最后花了两小时重下索引。所以这招只适合在完全离线、无外网的调试环境或者你100%确认Intel源URL是可信的比如你刚从GitHub Release页面复制的URL绝对不要在需要长期运行的系统上启用。3. 源地址与系统版本的精确匹配focal不是万能钥匙很多开发者卡在这个环节不是因为密钥而是因为源地址写错了。标题里明确写了Ubuntu 20.04它的代号是focal但Intel官方APT仓库实际支持多个Ubuntu版本且路径结构有细微差异。我整理了一份实测有效的源地址对照表Ubuntu版本代号官方推荐源地址HTTPS是否需额外配置Arch实测状态18.04bionicdeb https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo bionic main是[archamd64]✅ 稳定20.04focaldeb [archamd64 signed-by/usr/share/keyrings/realsense-public.keyring] https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal main是✅ 稳定本文主推22.04jammydeb [archamd64 signed-by/usr/share/keyrings/realsense-public.keyring] https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo jammy main是✅ 稳定16.04xenial已停止维护源地址返回404—❌ 失效关键细节来了archamd64必须显式声明。虽然绝大多数x86_64机器都是amd64架构但Ubuntu 20.04的apt默认不会自动推断。如果不加apt update会尝试下载i386、arm64等架构的索引而Intel源只提供amd64包导致404 Not Found错误进而掩盖真实的NO_PUBKEY问题。不要用HTTP源。Intel官方只提供HTTPS源http://开头的地址会直接失败。我见过有人手误写成httpapt update卡住3分钟才报超时白白浪费调试时间。不要省略main组件。这是APT仓库的标准结构漏掉会导致Unable to locate package。还有一个隐藏坑点某些国内镜像站如阿里云、腾讯云的Ubuntu源并不同步Intel RealSense仓库。它们只镜像archive.ubuntu.com和security.ubuntu.com。所以即使你把/etc/apt/sources.list里的Ubuntu官方源换成了阿里云镜像realsense.list里的Intel源仍必须指向原始S3地址。否则apt update会提示Failed to fetch ... Connection refused。我建议的做法是保持Ubuntu系统源用国内镜像加速基础包安装RealSense专用源单独用Intel官方S3地址保证最新驱动和固件。两者互不干扰这才是高效配置。4. 报错排查链路从终端输出反向定位根因当apt update报错时新手常犯的错误是“看到红字就慌”然后一顿乱搜、乱试。其实Ubuntu的apt日志非常规范只要学会读终端输出90%的问题都能在30秒内定位。下面是我总结的标准化排查流程以真实终端输出为例4.1 第一步锁定报错源头行不是第一行是关键词行假设你执行sudo apt update后终端滚动出上百行其中一段是Hit:1 http://mirrors.tuna.tsinghua.edu.cn/ubuntu focal InRelease Get:2 http://mirrors.tuna.tsinghua.edu.cn/ubuntu focal-updates InRelease [114 kB] ... Ign:3 https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal InRelease Err:4 https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal Release 404 Not Found [IP: 52.216.154.12 443] Reading package lists... Done E: The repository https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal Release does not have a Release file. N: Updating from such a repository cant be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.注意这里报的是404 Not Found不是NO_PUBKEY。说明源地址写错了比如把focal写成focal-updates或者Intel临时调整了路径。此时再执行密钥导入毫无意义必须先修正URL。而真正的NO_PUBKEY报错输出会是这样... Get:5 https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal InRelease [2,123 B] Err:5 https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal InRelease The following signatures couldnt be verified because the public key is not available: NO_PUBKEY FB0B24895113F120 Reading package lists... Done W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal InRelease: The following signatures couldnt be verified because the public key is not available: NO_PUBKEY FB0B24895113F120 W: Failed to fetch https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo/dists/focal/InRelease The following signatures couldnt be verified because the public key is not available: NO_PUBKEY FB0B24895113F120 W: Some index files failed to download. They have been ignored, or old ones used instead.关键线索有三处NO_PUBKEY FB0B24895113F120明确指出缺失的密钥IDInRelease说明是校验InRelease文件失败这是APT源的签名索引文件The repository is not updated确认是源更新失败不是包安装失败。4.2 第二步验证密钥是否真的缺失执行apt-key list | grep -A1 -B1 FB0B24895113F120如果输出为空说明全局密钥环确实没有但如果输出类似pub rsa4096 2020-07-22 [SC] [expires: 2025-07-22] 34C9E342FB0B24895113F120 uid [ unknown] Intel RealSense Open Source Project (release key) realsenseintel.com说明密钥已在全局环里但apt update仍报错——这就指向了源定义未绑定密钥的问题。此时必须检查/etc/apt/sources.list.d/realsense.list是否包含了signed-by参数。4.3 第三步检查源文件语法与权限一个常被忽略的细节sources.list.d/下的文件必须是.list后缀且权限为644即-rw-r--r--。我遇到过两次案例案例1A同学用nano编辑时误存为realsense.list.txtapt直接忽略该文件导致始终走默认源案例2用sudo vim编辑后文件属主变成root:root但权限是600-rw-------apt因无读取权限而静默跳过。验证命令ls -l /etc/apt/sources.list.d/realsense.list正确输出应为-rw-r--r-- 1 root root 123 Apr 10 15:22 /etc/apt/sources.list.d/realsense.list4.4 第四步终极验证——手动下载InRelease文件并验签如果以上步骤都确认无误但apt update仍报错可以绕过apt用底层命令验证# 下载InRelease文件 wget -O /tmp/InRelease https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo/dists/focal/InRelease # 用我们导入的密钥环验签 gpg --no-default-keyring --keyring /usr/share/keyrings/realsense-public.keyring --verify /tmp/InRelease如果输出gpg: Good signature from Intel RealSense Open Source Project (release key)说明密钥和文件都没问题问题一定出在apt的配置缓存上。此时执行sudo apt clean sudo rm -rf /var/lib/apt/lists/* sudo apt update清除所有缓存索引强制重新下载。这个排查链路我已在5个不同网络环境校园网、企业内网、家庭宽带、4G热点、离线U盘中反复验证覆盖了99%的真实报错场景。记住不要凭感觉猜要根据终端输出的每一行文字像解码一样逐层剥开。5. 配置完成后的必做验证不只是“能装”更要“能跑”密钥问题解决后sudo apt install librealsense2-dev librealsense2-dkms能顺利执行但这只是万里长征第一步。很多开发者到这里就以为大功告成结果一运行rs-environment或realsense-viewer立刻报No device connected或Failed to claim USB interface。所以配置完成后的验证必须分三层5.1 系统层验证USB权限与内核模块RealSense设备依赖USB3.0高速传输Ubuntu默认不允许普通用户直接访问USB设备。必须添加udev规则echo SUBSYSTEMusb, ATTR{idVendor}8086, MODE0666, GROUPplugdev | sudo tee /etc/udev/rules.d/99-realsense-libusb.rules sudo udevadm control --reload-rules sudo udevadm trigger sudo usermod -a -G plugdev $USER注意$USER要替换成你的用户名或者直接执行sudo usermod -a -G plugdev $(whoami)。然后必须注销当前用户并重新登录让组权限生效。这是最容易被跳过的步骤我见过太多人改完规则不重启死活连不上设备。验证命令lsusb | grep -i 8086应输出类似Bus 002 Device 004: ID 8086:0b3a Intel Corp. Intel(R) RealSense(TM) Depth Camera 435如果没输出检查USB线是否支持USB3.0蓝色接口、摄像头是否插在主板原生USB3.0口避免USB集线器。5.2 驱动层验证DKMS编译与固件加载librealsense2-dkms包会在安装时自动触发内核模块编译。验证是否成功dkms status | grep realsense应输出intel-rs400, 1.3.19, 5.4.0-150-generic, x86_64: installed版本号可能不同但状态必须是installed再检查模块是否加载lsmod | grep uvcvideoRealSense使用UVC协议uvcvideo模块必须存在。如果缺失手动加载sudo modprobe uvcvideo并加入开机启动echo uvcvideo | sudo tee -a /etc/modules5.3 应用层验证从命令行到GUI的全流程测试不要一上来就开realsense-viewer。按顺序执行基础检测rs-environment应输出RealSense SDK has been found及版本号。设备枚举rs-camera这是一个轻量级CLI工具会打印设备序列号、固件版本、支持的分辨率等。如果卡住或报错说明USB通信层有问题。深度图流测试最严苛rs-depth会打开一个窗口实时显示深度图。这是对USB带宽、CPU解码、OpenGL渲染的综合考验。如果窗口黑屏或卡顿可能是GPU驱动未装好Ubuntu 20.04需额外安装mesa-utils和xserver-xorg-video-intel。最终验证realsense-viewer这是Intel官方GUI工具支持所有传感器配置。如果它能正常打开并显示RGB深度IMU数据说明整个链路硬件→USB→内核→驱动→SDK→应用全部打通。提示realsense-viewer首次运行会自动检查固件更新。如果提示Firmware update required务必按提示升级否则某些高级功能如HDR模式、多相机同步无法启用。升级过程需保持USB连接稳定切勿拔插。6. 长期维护建议避免下次升级又踩坑这个问题之所以高频出现是因为它不是一个“一次配置永久有效”的静态设置。随着Ubuntu系统升级、librealsense版本迭代、内核更新配置可能失效。我的长期维护经验是6.1 建立配置快照脚本把所有关键步骤写成一个可复用的shell脚本命名为setup-realsense.sh内容如下#!/bin/bash # RealSense Ubuntu 20.04 配置快照脚本 set -e echo 【1/4】添加RealSense密钥环... curl -sSL https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo/realsense-public.key | gpg --dearmor | sudo tee /usr/share/keyrings/realsense-public.keyring /dev/null echo 【2/4】添加RealSense源... echo deb [archamd64 signed-by/usr/share/keyrings/realsense-public.keyring] https://realsense-hw-public.s3.amazonaws.com/Debian/apt-repo focal main | sudo tee /etc/apt/sources.list.d/realsense.list echo 【3/4】更新包索引... sudo apt update echo 【4/4】安装核心包... sudo apt install -y librealsense2-dev librealsense2-dkms librealsense2-utils echo ✅ 配置完成请注销后重新登录。每次新装系统或重装后只需chmod x setup-realsense.sh ./setup-realsense.sh全程自动化杜绝手误。6.2 关注Intel官方变更通知Intel的RealSense GitHub仓库https://github.com/IntelRealSense/librealsense的Releases页面会发布重大变更。重点关注密钥轮换公告当FB0B24895113F120密钥过期当前有效期至2025年7月Intel会发布新密钥ID你需要更新脚本中的curl地址和signed-by路径源地址迁移如果S3存储桶路径变更如从realsense-hw-public迁移到realsense-hw-prod脚本中的URL必须同步更新Ubuntu版本支持列表当Ubuntu 20.04进入ESMExtended Security Maintenance阶段Intel可能停止为其提供新驱动此时需评估升级系统或切换到LTS版本。6.3 为团队建立共享知识库在某公司机器人研发部我们把这类配置问题沉淀为Confluence文档标题就叫《RealSense Ubuntu环境配置黄金清单》包含每个Ubuntu版本对应的源地址、密钥获取方式、已验证的librealsense版本常见报错代码速查表如NO_PUBKEY、404 Not Found、Hash Sum mismatch对应解决方案硬件兼容性矩阵哪些RealSense型号在Ubuntu 20.04上需额外补丁。这样新人入职5分钟就能配好环境而不是花半天在Stack Overflow里大海捞针。最后分享一个小技巧如果你经常在多台机器上部署可以把/etc/apt/sources.list.d/realsense.list和/usr/share/keyrings/realsense-public.keyring打包成tar.gz用scp一键分发。比重复执行命令快得多。这个习惯是我从某高校实验室导师那里学来的现在已成为我所有嵌入式项目部署的标准动作。
阅读完成 · 觉得有帮助？
