前段时间我在 openEuler 22.03 SP3 上搭自动化测试环境需要装一个 Google Chrome 跑无头浏览器。我从官网拉了一个 rpm 包下来dnf install ./google-chrome-stable_current_x86_64.rpm一执行满屏的 Failed dependencies 直接给我整懵了。libXss.so.1、libgbm.so.1、libatk-bridge-2.0.so.0 全冒出来网上搜一圈翻来覆去就是“安装依赖、再装一次”这几句话实际上根本不止这么简单。这篇东西把我完整的操作记录、依赖排查思路、踩过的坑都整理出来给需要在 openEuler 上安装 Chrome 的朋友一个能直接照着做的方案。无论你是要在最小化服务器上用无头模式跑自动化脚本还是想在桌面环境里正常使用 Chrome这套内容都适用。1. 先把问题想清楚openEuler 装 Chrome 到底卡在哪1.1 openEuler 和 CentOS/RHEL 的“远房亲戚”关系openEuler 是一个从内核到用户态都走 Linux 路线的开源操作系统包管理用的是 RPM/DNF这点和 RHEL/CentOS 系是一样的所以很多人下意识觉得“CentOS 怎么装openEuler 就怎么装”。实际用下来这个惯性会带来不少麻烦。openEuler 虽然兼容 RPM 包格式也提供 dnf/yum 工具但它的软件仓库是独立维护的很多包名、依赖关系、版本策略都跟 RHEL/CentOS 不一样。举个例子Chrome 官方 rpm 包在 RHEL 8 上可能只依赖少数几个系统库但在 openEuler 的最小化安装里同一份 rpm 会检测出十几个缺失依赖。原因很直接openEuler 默认不启用 EPEL也没有 CentOS 的那套 extras 仓库你在 CentOS 上熟悉的yum install某些包名的路径在 openEuler 里完全不成立。还有一点容易被忽视openEuler 是独立社区维护的发行版它和 CentOS 的关系更像是“同门师兄弟”而不是“换皮”。看到“RPM 兼容”不等于“二进制包完全可以通用”。依赖缺失时优先用 openEuler 自己的仓库补不要直接去抓 CentOS 的 rpm 来硬塞否则轻则版本冲突重则把 yum 数据库搞乱后续重装系统都有可能。1.2 Chrome 官方 rpm 包为什么在 openEuler 上爱缺依赖Chrome Linux 版官方只提供 deb 和 rpm 两种安装包rpm 包本身不是一个“绿色免安装”的静态二进制它在安装时会检查一堆共享库文件是否存在。这些库主要是 GTK3 图形栈相关的比如 libgtk-3、libnss3、libxss、libatk-bridge 等等。如果你的 openEuler 是“最小化安装”没有装任何图形组件那这些库绝大多数都是缺的。再加上 Chrome 为了稳定会把依赖写成“精确到 .so 文件的 soname”而不是只写一个软件包名。比如它要求libXss.so.1()(64bit)而不只是“libXScrnSaver”。在 CentOS 的桌面环境里这些库早就随系统装好了但 openEuler 服务器为了精简很可能一个都没装。于是 dnf 解析依赖时就会一次性报出一大串缺失项。还有一个隐藏差异Chrome rpm 包在构建时的基准系统多数是 Fedora/RHEL 系对 openEuler 来说是“外人”。rpm 解析依赖时不看发行版名称只看具体的库文件和版本号所以只要 openEuler 仓库有对应库就能解没有就会硬生生卡住。这也是为什么同一个 rpm 在不同 openEuler 版本上表现不一样。说白了你缺的不是 Chrome 本身而是承载 Chrome 的那一套图形运行环境。1.3 三种安装方式选哪种我心里有数这里先剧透一下整体思路后面会逐一展开。第一种是官网下载 rpm 包后用 dnf 本地安装优点是不依赖 Google 仓库的连通性适合网络环境比较特殊的情况缺点是没有自动升级后续版本更新要手动来。第二种是添加 Google Chrome 官方 yum/dnf 源直接dnf install google-chrome-stable好处是后续dnf update能自动升级缺点是官方源的访问质量在不同网络环境下差别很大源不通时你会卡在 makecache 阶段反而更耗时间。第三种是曲线方案用社区镜像或者第三方源把 Chrome 的 rpm 包放到本地再套用第一种方式安装适合内网环境或离线安装。我个人优先推荐第一种下载 rpm 包 dnf install ./xxx.rpm。它最可控依赖解析也交给 dnf只是需要自己根据报错补充缺失库。本文后面的实操也主要沿着这条路走。2. 装之前的环境准备与信息确认2.1 确认系统版本和 CPU 架构Chrome 官方 Linux 包有 x86_64 和 arm64 两种架构下载前一定要先确认自己的系统是哪种。cat /etc/openEuler-release uname -m如果输出是x86_64下载 rpm 时用google-chrome-stable_current_x86_64.rpm如果输出是aarch64要下载google-chrome-stable_current_arm64.rpm。这两者的 URL 后缀不一样下载错会在安装时直接报 “Architecture is not supported”。另外顺便看一下系统有没有可用的包管理器缓存dnf repolist如果这一步显示Repo list is empty说明某个仓库有问题先解决仓库问题再装 Chrome不然后面会连带报很多奇怪的错误。我发现很多新手装 Chrome 失败根本不是 Chrome 的问题而是 dnf 仓库本身就不可用导致连依赖库都拉不下来。2.2 保持仓库可用别让 dnf 罢工openEuler 默认的 repo 文件放在/etc/yum.repos.d/openEuler.repo里通常配置了 BaseOS、EPOL、debuginfo 等几个仓库。装 Chrome 时主要靠 BaseOS 这些基础仓库来补齐依赖所以第一步要确保它们能正常访问。建议先执行一遍dnf makecache如果缓存刷新失败可以先看报错信息是网络原因还是 metadata 损坏。网络原因就检查连通性metadata 损坏可以清理缓存dnf clean all dnf makecache如果你的测试机是内网环境无法访问外部软件源也可以把 openEuler 的 ISO 镜像挂载为本地仓库。但这不是本篇文章的核心先不展开。你只需要知道Chrome 依赖的库大部分都能从 openEuler 自带仓库里找到仓库可用是安装成功的大前提。有的人会图省事在测试环境里直接禁用 GPG 校验dnf install --nogpgcheck ./google-chrome-stable_current_x86_64.rpm这个我一般不建议除非你很清楚 rpm 包的来源并且愿意承担风险。Chrome 官方包是带签名校验的开着 gpgcheck 能多一层保障。2.3 导入 Google 签名公钥可选但推荐如果后面打算配置 Google 官方源或者想对下载下来的 rpm 做一次签名校验可以先把 Google 的签名公钥导入系统。操作很简单rpm --import https://dl.google.com/linux/linux_signing_key.pub导入后可以用rpm -qa gpg-pubkey查看公钥是否已经存在。如果你所在的网络环境访问dl.google.com不稳定这一步可能失败那就跳过等后面安装时用--nogpgcheck临时绕过也别忘了把 repo 文件里的gpgcheck1改成0否则添加完源仍然会卡在公钥校验上。很多教程里说“导入失败没关系反正能装”但实际上如果你用了官方 repo 又没导入 keydnf makecache之后刷出来的第一个报错就是公钥问题到时候还是要回来处理。3. 完整安装实操从下载 rpm 到跑通第一个页面3.1 下载 Google Chrome 对应架构的 rpm 包我建议直接在命令行里用 wget 或 curl 下载再放到一个干净的目录下比如/tmp。以 x86_64 架构为例dnf install -y wget cd /tmp wget https://dl.google.com/linux/direct/google-chrome-stable_current_x86_64.rpm如果你是 arm64比如在 RK3588 这类板子上跑 openEuler就把文件名换成google-chrome-stable_current_arm64.rpm其他不变。提示如果你当前机器访问外网不方便可以在另一台能正常访问的机器上下载好 rpm再通过 scp、U盘等方式拷贝过来。Chrome 的 rpm 包在同一架构下可以在不同 RPM 系发行版之间复用只要依赖解决掉就行。下载完成后可以用ls -lh看一下文件大小一般 100~120MB 左右。如果只有几十 KB多半是下载到了错误页面先检查 URL 是不是写错了。3.2 用 dnf 安装并观察依赖报错这里的关键是不要用rpm -ivh直接装而是用dnf install ./xxx.rpm。这样 dnf 会把 rpm 包本身和它的依赖一起放进一个依赖事务里优先从 openEuler 仓库里找缺失的库。dnf install ./google-chrome-stable_current_x86_64.rpm命令执行后 dnf 会先解析依赖如果仓库里能补齐它会列出要安装的依赖包数量并询问你是否继续。输入 y 回车等待安装完成即可。这也是最快、最安全的路径。如果仓库里补不齐你就会看到类似这样的错误错误软件包google-chrome-stable-xxx.x86_64 需要libXss.so.1()(64bit)不要慌下面一节就是专门处理这种局面的。我第一回看到这种错误时还以为 rpm 包是坏的换了版本还是一样后来才明白是系统图形库太干净了。3.3 用 dnf provides 反查缺失库对应的软件包看到“需要某个 .so 文件”这种报错最笨的办法是一个个去搜网上的说法但这很容易搜到过时结论。正确做法是用 dnf 自带的反向查询功能让 repo 自己告诉你这个库由哪个包提供。dnf provides */libXss.so.1输出里会出现类似libXScrnSaver-1.2.3-5.el8.x86_64 : X11 Screen Saver extension library 仓库openEuler-22.03-LTS-BaseOS看到仓库是 openEuler 自己的就可以直接装dnf install -y libXScrnSaver有些最小化安装的 openEuler 可能没有 repoquery 命令可以用dnf install -y dnf-utils装一下然后用repoquery --whatprovides */libXss.so.1查询。另外直接把.so文件路径写全也能提高匹配成功率。同理libgbm.so.1大概率由mesa-libgbm提供libatk-bridge-2.0.so.0由at-spi2-atk提供libnss3.so由nss提供libcups.so.2由cups-libs提供。把这些常见项一口气装上也能省很多时间dnf install -y libXScrnSaver mesa-libgbm at-spi2-atk nss cups-libs装完之后再重新执行dnf install ./google-chrome-stable_current_x86_64.rpm如果还有缺失就继续用dnf provides逐个击破。我第一次实际配置的时候这样来回三轮就把依赖全部补齐了后面再装就很顺。3.4 无头模式下验证安装成功依赖补齐、Chrome 安装完成后先不要急着找桌面图标直接在终端里验证一下版本google-chrome-stable --version能打印出版本号说明二进制可执行文件本身没问题。接着跑一个无头模式测试看看能不能正常加载网页google-chrome-stable --headless --disable-gpu --dump-dom https://example.com正常会输出一坨 HTML 内容这就说明 Chrome 的核心功能已经可以用了。注意如果你是 root 用户直接执行可能会先遇到Running as root without --no-sandbox is not supported的错误解决办法在第 5.2 节这里先不展开。4. 依赖问题深度解决方案4.1 常见缺失依赖清单与对应包名为了让你心里有底我把 openEuler 下装 Chrome 最常见的几类缺失依赖和对应包名整理成一张表方便你对照排查。报错提示中的依赖对应的 openEuler 软件包说明libXss.so.1libXScrnSaverX11 屏幕保护扩展库最小化安装时最容易缺libgbm.so.1mesa-libgbmMesa GBM 图形内存管理库headless 模式也需要libatk-bridge-2.0.so.0at-spi2-atk辅助功能桥接层libnss3.sonss网络安全服务库Chrome 启动必备libcups.so.2cups-libsCUPS 打印客户端库libgtk-3.so.0gtk3GTK3 图形库桌面界面用libxkbcommon.so.0libxkbcommonX11 键盘协议库libdrm.so.2libdrmDRM 直接渲染管理库这张表不是百分之百固定因为不同 openEuler 小版本的软件包版本不同但大方向是这样。遇到不在表里的依赖永远优先用dnf provides去查而不是凭经验乱装。另外装完依赖后一定要重新执行一次dnf install ./google-chrome-stable_current_x86_64.rpm让 dnf 重新校验整个依赖事务而不是直接去双击快捷键否则有可能 Chrome 已经装上了但依赖其实还是残缺状态。4.2 强制安装与手动补库的利弊网上很多教程会教你一条“万能命令”rpm -Uvh --nodeps --force google-chrome-stable_current_x86_64.rpm这个命令确实能跳过依赖检查把 Chrome 装进去。但我要泼一盆冷水这只是在 rpm 数据库层面骗过去了并不是真的把依赖问题解决了。Chrome 启动时仍然需要那些 .so 文件缺一个就会在运行时直接报error while loading shared libraries然后退出。所以强制安装只适合两种场景一种是你已经通过其他方式把缺失库全部补齐了只是不想让 rpm 再去检查一遍另一种是纯测试环境你就想看个大概不在乎有没有完整运行能力。日常使用和自动化测试我都不推荐这么做。如果你真的用了强制安装后面又遇到启动报错可以通过ldd查看可执行文件到底缺哪些库ldd /opt/google/chrome/chrome | grep not found会列出缺失的 .so 文件再按 4.1 节的方法逐个补齐即可。这里补一个经验很多时候用ldd查出来的缺失库并不是真的没装而是 32 位和 64 位版本混在一起了。openEuler 默认是 64 位系统Chrome 也只要 64 位库如果之前有人图方便装了 32 位兼容库反而会干扰判断。4.3 添加官方 repo 后如何升级和维护如果你不想每次升级都手动下载 rpm可以把 Google Chrome 官方源配置进 dnf。新建一个仓库文件cat /etc/yum.repos.d/google-chrome.repo EOF [google-chrome] namegoogle-chrome baseurlhttps://dl.google.com/linux/chrome/rpm/stable/$basearch enabled1 gpgcheck1 gpgkeyhttps://dl.google.com/linux/linux_signing_key.pub EOF然后刷新缓存并安装dnf makecache dnf install -y google-chrome-stable以后要升级就是dnf update google-chrome-stable需要注意的是Google 官方源在你当前网络环境下可能慢或者连不上遇到这种情况不用纠结回到手动下载 rpm 的方式即可。手动 rpm 安装的 Chrome 不会自动升级隔一段时间检查一次版本就好。我自己的习惯是如果这台机器是专门跑自动化的就一定要用官方 repo 管理版本因为 chromedriver 和 Chrome 版本一旦错位测试脚本全挂排查起来非常痛苦。5. 图形界面、字体和自动化场景的经验补充5.1 最小化安装系统上的图形环境很多人是在服务器上装 openEuler当时图省事选了最小化安装没有桌面组件。如果这种情况下你只是想让 Chrome 无头跑一下那不需要装图形界面。可如果你想打开浏览器看效果、调试页面就得先把图形环境补上。先看系统里有没有可用的桌面组dnf group list找到类似GNOME、KDE Plasma Workspaces、X Window System这样的组名后安装dnf groupinstall -y X Window System GNOME装完后把默认启动级别切到图形模式systemctl set-default graphical.target reboot整个过程依赖很大时间比较长要有耐心。装好后在图形终端里启动 Google Chrome就能看到正常窗口了。如果不想给服务器装完整桌面也可以用 SSH X11 转发在你本地电脑上用支持 X11 的 SSH 客户端连接服务器服务端配一下X11Forwarding yes执行google-chrome-stable时窗口会跳到本地屏幕上适合临时看一眼界面。5.2 root 运行 Chrome 的 Sandbox 问题openEuler 默认 root 用户的地位很高很多新手会全程用 root。但 Chrome 出于安全考虑有一层独立的沙箱机制它不允许 root 用户直接启动会弹出一句提示Running as root without --no-sandbox is not supported.原因其实不难理解Chrome 的沙箱设计目标是限制子进程的权限而 root 本身就是最高权限沙箱对它没有约束意义所以 Chrome 宁可拒绝启动也不带病运行。解决办法有几个。最推荐的是新建一个普通用户用普通用户去打开 Chromeuseradd chromeuser passwd chromeuser su - chromeuser google-chrome-stable如果只是临时测试也可以给启动命令加--no-sandboxgoogle-chrome-stable --no-sandbox但这一项会关闭浏览器沙箱意味着浏览器漏洞可能导致更大的危害不建议在长时间运行的自动化任务或者生产环境里用。我在自动化测试机上为了让 Jenkins 任务能稳定跑专门用了一个普通用户去执行 Selenium 脚本避免 root no-sandbox 的组合。5.3 中文显示为方块的处理Chrome 装好了打开中文网页全是方框十有八九是系统里没有中文字体。openEuler 最小化安装基本不带中文字体这个不补不行。在终端里装一下常见中文字体dnf install -y wqy-zenhei wqy-microhei装完刷新字体缓存fc-cache -f然后再启动 Chrome 看中文基本就正常了。如果没有文泉驿字体包可以用dnf search cjk或者dnf search font找一下仓库里有没有google-noto-sans-cjk-fonts之类的包效果一样。这个坑特别容易被人忽略因为安装过程一点错都不报只有打开页面才会发现全是方块非常影响判断。5.4 给 Selenium/Playwright 用的配置建议openEuler 服务器上装 Chrome很多时候不是给人用的而是给自动化测试用的。这种情况下有几点经验值得分享。一来浏览器驱动版本必须和 Chrome 版本匹配。Chrome 120 之后官方推广的 Chrome for Testing 路线图是让驱动和浏览器一起下载避免版本错位。如果你是用 Selenium建议先用google-chrome-stable --version确认版本号再去找对应的 chromedriver。二来自动化脚本里启动浏览器时建议加上下面这些参数能少踩很多坑--no-sandbox --disable-dev-shm-usage --disable-gpu --remote-debugging-port9222在容器环境里跑特别是 /dev/shm 很小的时候--disable-dev-shm-usage几乎是必备的不然浏览器开几个标签页就崩。这里放一个最简的 Selenium 示例方便你验证环境是否通from selenium import webdriver from selenium.webdriver.chrome.options import Options options Options() options.add_argument(--headless) options.add_argument(--no-sandbox) options.add_argument(--disable-dev-shm-usage) driver webdriver.Chrome(optionsoptions) driver.get(https://example.com) print(driver.title) driver.quit()三来不要用 root 直跑自动化服务。哪怕你给脚本加了--no-sandbox也建议把整个 Jenkins 或调度器服务跑在专用用户下这样就算浏览器被奇怪的页面利用影响范围也可控。6. 常见问题速查与最终避坑提示6.1 安装与启动错误速查表问题现象原因解决办法dnf 安装时报Failed dependencies缺少 Chrome 运行所需的共享库用dnf provides */缺失文件名查包名并安装error while loading shared libraries: libnss3.so系统缺少 nss 库dnf install -y nsserror while loading shared libraries: libxss.so.1系统缺少 libXScrnSaverdnf install -y libXScrnSaverRunning as root without --no-sandbox is not supportedChrome 不允许 root 直接运行使用普通用户或临时加--no-sandbox不推荐Chrome 启动后闪退可能是 GPU/图形栈问题用--disable-gpu启动观察日志打开中文网页显示方块缺少中文字体安装 wqy-zenhei 等字体并fc-cache -f添加官方源后dnf makecache卡住源站网络质量不稳定取消该 repo改用手动下载 rpm 的方式headless 模式没有输出页面加载失败或参数错误加--dump-dom后检查 URL 和网络连通性6.2 我踩过且希望你不要踩的坑第一个坑也是最容易踩的看到依赖报错就贸然去 CentOS 的源里下载 rpm 来装。openEuler 和 CentOS 的库版本不完全一致强制塞进去可能当时解决了 Chrome 的依赖却把系统自己的包管理事务搞坏了。正确做法是永远优先用 openEuler 仓库的包。第二个坑在最小化服务器上想用 Chrome结果花了很长时间装桌面环境其实完全没必要。无头模式加--dump-dom、--print-to-pdf这些功能已经覆盖了大部分批处理需求。先确认你到底需要“看见”浏览器还是只需要它干活再决定要不要装图形界面。第三个坑升级节奏没规划好。手动 rpm 安装的 Chrome 不会提醒你升级时间久了版本会和 chromedriver 对不上。如果跑自动化最好把版本检查写进巡检流程或者干脆用官方 repo 管理升级避免测试脚本某一天突然大面积失败。第四个坑忽略普通用户和沙箱的关系。我在一台 openEuler 测试服务器上用 root 跑了一段时间 Chrome总觉得加了--no-sandbox没事后来排查安全问题越想越后怕。现在凡是长期跑的任务我都会单独开一个系统用户把浏览器、chromedriver、脚本都扔给它权限尽量收敛。最后分享一个我目前用得比较顺手的小套路先dnf install ./xxx.rpm缺什么用dnf provides补什么装完立刻用无头模式跑一次--dump-dom验证然后根据实际用途决定是加官方源还是手动维护版本。这套流程在好几台 openEuler 22.03 的机器上跑下来基本没再翻过车。