Ubuntu 20.04/Debian 10安装向日葵远程控制：依赖问题排查全攻略

Ubuntu 20.04和Debian 10这两套系统，我前后装了不下十次向日葵远程控制。为什么反复装？因为每次换一台机器，依赖问题都会以新的姿势出现——有的缺libminizip1，有的报libxss1找不到，还有的干脆连dpkg都卡在半路。这篇文章就是把我踩过的坑和最终稳定的安装思路完整记录下来，给还在被依赖地狱折磨的朋友一份可以直接抄作业的解决方案，从选包、装依赖到服务启动、黑屏排查，一条龙说清楚。

先交代一下背景：我日常工作主要围绕Ubuntu 20.04展开，装ROS、折腾视觉SLAM、跑深度学习训练，这些都需要图形界面的远程操控；办公室还有几台Debian 10的老机器，常年放在机房角落，没有接显示器，全靠向日葵远程维护。这两类场景我几乎每个月都要经历一次，所以这篇踩坑实录里的每一个步骤，都是被实际验证过的，不是从官网上复制粘贴来的。

1. 为什么Linux桌面远程控制要用向日葵：选型思路与场景分析

1.1 哪些场景真正需要它

很多人觉得Linux远程控制直接用SSH就够了，这个观点在纯命令行场景下完全成立。但你一旦涉及下面这些情况，SSH就无能为力了：

• Ubuntu 20.04开发机上跑着图形化的调试工具，比如rviz、Rviz2、gazebo这类机器人和视觉仿真软件，离了图形界面根本没法定位问题。
• 实验室或机房的工作站没有接显示器，但你需要在上面打开浏览器、点击Python脚本的图形化配置界面，或者帮同事调整IDE设置。
• 用户用的是Windows电脑，但被控端是Linux，想通过一个统一的客户端入口远程处理技术支持。
• 需要远程重启图形桌面服务，或者排查某个软件在图形界面下的行为异常。

在这些场景里，远程控制工具才真正派得上用场。我自己最典型的例子是：在家远程打开实验室的Ubuntu 20.04机器，把ROS的bag包重新跑一遍，然后在rviz里观察点云效果。这套操作依赖的就是稳定可靠的Linux桌面远程方案。

1.2 和其它工具比，向日葵的核心优势

Linux下可选的远程工具其实不少，VNC、RustDesk、TeamViewer、AnyDesk、xrdp这些我都试过。对比下来，向日葵之所以成为我的主力，主要是这几点：

• 不需要公网IP，也不需要自己搭FRP内网穿透，装好客户端登录账号就能连，省掉了大量网络配置工作。
• 跨平台覆盖很全，Windows、macOS、Linux、Android、iOS都有客户端，家属和同事不管用什么设备都能帮我应急。
• 设备码加验证码的模式特别适合一次性支持，别人临时要连你的机器，你只需要把验证码发过去就行，不用加入组织架构。
• 免费版的功能对个人用户来说已经够用，远程桌面、文件传输这些核心操作都不受限。

VNC的问题在于需要自己处理内网穿透和加密，xrdp在Ubuntu 20.04上默认给的桌面环境体验一言难尽。而向日葵这类商业方案把中间那一大堆网络和协议细节都封装掉了，对普通用户和技术支持场景都非常友好。

1.3 为什么Ubuntu 20.04/Debian10成为重灾区

说实话，Ubuntu 18.04和22.04装向日葵都很顺利，唯独Ubuntu 20.04和Debian 10这两兄弟，安装过程特别容易翻车。我总结下来有三个原因：

第一，这两个系统的软件源版本都比较保守。向日葵官方deb包里声明的依赖版本，有时候和系统源里默认提供的版本正好卡在边界上，比如需要A库的1.2版本，系统源里恰好是1.1，但又不太方便随意升级。

第二，很多用户是从Windows转过来的，习惯双击deb包安装，图形安装器一闪而过只留下一个“安装失败”的提示，根本看不到真正的依赖报错信息。

第三，Ubuntu 20.04是ROS、ORB-SLAM3这类机器人项目的主力系统，用户群体里大量是学生和研究人员，系统本身已经装满了各种开发依赖，不同库之间本来就有冲突，再塞一个商业远程软件进去，依赖冲突的概率自然飙升。

2. 安装前必看：先把系统和软件包的底细摸清楚

2.1 三步确认系统与架构信息

很多人一上来就下载安装，结果装错架构或者装完完全跑不起来。我建议所有人在下载之前，先花三十秒执行下面三个命令，把底细摸清楚：

cat /etc/os-release uname -m dpkg -l | grep -i sunlogin

第一个命令用来确认系统版本是不是Ubuntu 20.04或者Debian 10，因为这两个系统的软件源和依赖库情况不一样，后面处理方案也有差异。第二个命令特别关键，现在绝大多数机器是x86_64架构，但如果你用的是树莓派或者ARM开发板，就得下载ARM版的deb包，下载错了一律装不上。第三个命令是检查机器上有没有装过旧版向日葵，如果之前安装过但没有卸载干净，新版本可能起冲突。

我自己就犯过这个错误：在一台国产ARM开发板上直接下载了amd64的deb包，dpkg倒是给我装进去了，但运行的时候直接报“Exec format error”，完全跑不起来。最后卸载重下arm64版本才解决。

2.2 官网下载包的选择：deb包还是tar.xz压缩包

向日葵Linux版在官网一般会提供两种格式的下载，一个是以.deb结尾的安装包，另一个是以.tar.xz结尾的压缩包。这两个东西的选择会影响你后续的排障难度，我建议按以下逻辑来：

• 如果你用的是Ubuntu或Debian系系统，优先选择deb包。deb包的好处是可以通过dpkg和apt管理，依赖关系清晰，卸载也干净，出问题的时候能直接看到系统提示缺哪个库。
• 如果你拿到的机器没装图形包管理器，或者你想让软件完全装在一个独立目录里，可以选择tar.xz压缩包。解压后目录里有一个install.sh脚本，执行这个脚本会完成安装和权限配置。

有一点要提前说明：tar.xz版本同样会检测系统依赖，而且因为它是自行打包的，有时候反而会把依赖问题暴露得更加明显。所以不管选哪种格式，依赖问题都无法跳过，只是处理入口不同。

2.3 依赖报错的底层原因

安装向日葵时最常见的报错是dpkg提示：

dpkg: dependency problems prevent configuration of sunloginclient: sunloginclient depends on libminizip1; however: Package libminizip1 is not installed.

很多人看到这种报错就慌了，以为系统坏了。其实这背后的原理特别简单：deb安装包在构建时会在元数据里声明自己依赖哪些库，系统在安装时如果发现这些库不存在，或者版本不满足要求，就会拒绝继续配置。这不是向日葵特有的行为，所有deb包都遵循这个规则。

依赖问题的本质是“本机软件环境”和“软件声明依赖”之间的差距。Ubuntu 20.04和Debian 10的仓库里很多基础库版本偏老，一些新版本的向日葵客户端又依赖了较新的库，两边一碰就出问题。搞清楚这一点之后，处理思路就清晰了：要么把缺失的依赖补上，要么把依赖库的版本对齐，而不能去修改deb包本身。

3. Ubuntu 20.04实战：从安装到依赖修复完整过程

3.1 下载到本地后的正确安装姿势

拿到deb包之后，我不建议直接双击用图形化安装工具，而是建议打开终端，进入文件所在目录，执行：

sudo dpkg -i SunloginClient-版本号-amd64.deb

这里文件名要以你实际下载到的为准，版本号会经常更新。用dpkg命令安装的好处是，一旦出问题，终端会清清楚楚地打印出错误原因，而不是像图形工具那样只给你一个笼统的“安装失败”弹窗。

如果一切顺利，dpkg会无报错完成安装，终端提示配置完成。如果遇到依赖问题，你会在屏幕末尾看到类似这样的错误信息：

Errors were encountered while processing: sunloginclient

这句话虽然简短，但信息量很大。它表示damn包本体已经解压进系统了，但在配置阶段因为依赖缺失而卡住。这个时候系统里其实已经多出了向日葵的文件，只不过运行不了，你需要马上修复。

3.2 依赖问题标准处理流程：apt自动修复是首选

面对上面这种依赖缺失报错，我最推荐的处理方式不是去手动下载几十个依赖库，而是让apt自己解决。在dpkg报错后，立刻执行：

sudo apt --fix-broken install

这个命令会扫描系统里所有处于“未配置完成”状态的软件包，自动分析缺失的依赖并尝试从软件源安装。Ubuntu 20.04的官方源里绝大多数基础依赖都是齐全的，绝大多数情况下这一步就能把向日葵的依赖问题解决掉。

执行过程中apt可能会提示你安装一些新的库，比如libxss1、libxtst6、libgtk-3-0。这些都是正常的，直接按Y回车继续。等它执行完，再回去执行一遍：

sudo dpkg -i SunloginClient-版本号-amd64.deb

这时候应该能顺利配置完成，不会再报错。

不过这里有个很容易被忽略的点：apt --fix-broken install依赖的是软件源配置。有些人在装系统时精简过源，只保留了极少数仓库，甚至把源列表改坏了，那么apt就找不到可用的依赖包，修复命令会报“Unable to locate package”。碰到这种情况，先检查Ubuntu 20.04的源配置，确保main、universe、multiverse这些组件都是开启状态，或者重新配置一份可用的源列表。Ubuntu的universe仓库里包含了大量的自由软件库，很多向日葵的依赖都在那里。

3.3 如果apt修复失败：手动定位缺失依赖库

apt修复失败的情况虽然少见，但也不是没有。我遇到过一种典型场景：某台Ubuntu 20.04机器被装过各种杂七杂八的源，apt源里的包版本比系统自带库还新，导致依赖冲突，apt不敢自动升级，修复命令直接卡死在“held broken packages”。

这种时候就得手动定位缺失的依赖了。先看dpkg报错里到底提示缺什么，比如报缺libminizip1，那就直接尝试用apt显式安装：

sudo apt install libminizip1

如果提示这个包在软件源里找不到，就去packages.ubuntu.com这个官方网站搜索对应的包名和Ubuntu版本，找到focal对应的下载链接，手动下载deb文件后执行安装：

sudo dpkg -i libminizip1_某个版本_amd64.deb

手动安装的时候要注意架构和版本号，不要装错了。装完缺失的库之后，再回头安装向日葵本体。

另外一个非常实用的定位技巧是利用ldd命令检查向日葵主程序缺哪些动态库：

ldd /usr/local/sunlogin/bin/sunloginclient | grep "not found"

这行命令会列出主程序运行时所有找不到的动态链接库。它能帮你绕过dpkg的依赖声明，直接从动态链接层面看清问题。有时候dpkg声明里没问题，但实际运行时缺库，这种情况通过ldd一眼就能看出来。

3.4 从tar.xz压缩包安装的备选路径

如果你拿到的不是deb包而是tar.xz压缩包，操作流程是这样的：

tar -xf SunloginClient-版本号-amd64.tar.xz cd sunloginclient sudo ./install.sh

install.sh脚本会帮你把可执行文件复制到系统目录，并自动配置systemd服务。这个路径最大的好处是安装过程更透明，脚本会打印每一步在做什么，出错的时候能清楚看到卡在哪一步。

但需要注意，install.sh本身不负责安装依赖库。如果你的系统里缺少相关库，脚本可能会正常执行完，但程序启动时直接崩溃或者报找不到库。所以我习惯了装完tar.xz版本后，也顺手跑一遍apt --fix-broken install，把可能的隐藏依赖扫一遍。

3.5 启动服务、开机自启与首次登录配置

安装完成不等于就能用了，向日葵在Linux上是通过systemd服务来管理后台进程的。安装完成后建议先手动启一次服务并设置开机自启：

sudo systemctl enable --now runsunloginclient.service sudo systemctl status runsunloginclient.service

如果你是在纯命令行环境或者SSH连接里操作，服务启动后可以执行：

/usr/local/sunlogin/bin/sunloginclient --quickstart

这个命令会在终端里直接打印出设备识别码和临时验证码，拿着这两个码就能在手机或另一台电脑的向日葵客户端里发起远程连接。这个功能对于无显示器服务器来说非常实用，我第一次在机房的Debian 10机器上用这个命令把识别码截图发给同事，对方立刻就远程进来了。

如果你有图形桌面环境，也可以直接在应用菜单里找到向日葵图标，点击打开图形界面，登录自己的向日葵账号，然后这台设备就会出现在你的设备列表里。之后远程连接就不需要再手动看验证码了，账号体系会自动完成设备绑定。

4. Debian 10的差异点：依赖修复要因地制宜

4.1 Debian 10与Ubuntu 20.04的源差异

Debian 10和Ubuntu 20.04在安装向日葵时遇到的问题高度相似，但处理细节上有个重要的区别：Debian 10的软件源默认只开启main组件，很多额外的库需要自己把contrib和non-free组件打开，或者手动从Debian的官方包网站获取。

这意味着你在Debian 10上执行apt --fix-broken install时，很可能因为源里没有对应组件而导致依赖安装失败。碰到这种情况，先打开/etc/apt/sources.list，确认仓库配置是否包含了contrib和non-free：

deb http://deb.debian.org/debian buster main contrib non-free deb http://deb.debian.org/debian-security buster/updates main contrib non-free

修改完源之后记得执行sudo apt update刷新缓存，然后再跑依赖修复命令。Debian 10的另一个特点是，它相比Ubuntu更强调稳定性，很多库的版本比Ubuntu同期的版本更保守，一些依赖在版本号上可能不满足向日葵的要求。如果遇到这种情况，可以使用DPkg命令行工具强制安装，或者从packages.debian.org网站搜索需要的库版本。我通常会先在这个网站上确认当前Debian版本对应的库里有没有相关依赖，再决定是从官方源装，还是手动下载deb。

4.2 Debian 10的依赖修复实战

在Debian 10上，我遇到最典型的情况是缺libminizip1。这个库在Ubuntu 20.04的universe源里有，但在Debian 10的默认main组件里也存在，所以正常情况下apt修复就能解决。但如果你精简过系统，或者使用的是一些定制化的Debian衍生版本，就有可能需要手动安装了。

手动安装的方法和Ubuntu那边一样，去packages.debian.org搜索libminizip1，选择buster对应的amd64架构，下载后用sudo dpkg -i安装。如果它还依赖别的库，dpkg会再次告诉你缺什么，你就按照同样的方法把依赖链逐个补齐。这个过程看起来繁琐，但实际遇到的依赖链通常很短，三五个包就能解决。

另外，Debian 10上如果你下载的是tar.xz版本的向日葵，执行install.sh时可能会遇到缺少权限导致服务注册失败的问题。这不是依赖问题，而是systemd服务文件写入权限的问题。解决方法很简单，确保你是用sudo执行，或者安装完成后手动创建systemd服务软链接。

4.3 Debian下deb包和tar.xz包的选择建议

在Debian 10上，我更加推荐使用deb包，原因是依赖追踪更严格。Debian用户对“系统不能随意崩溃”这件事的执念普遍比较强，deb包安装会让系统记录清晰的安装状态，出问题可以随时通过dpkg -r移除。而tar.xz版本虽然安装起来快，但它往系统里散落的文件不会全部被记录，卸载时可能需要手动清理。

不过有一种情况选tar.xz更合适：你需要在一批完全相同配置的机器上批量部署，tar.xz的解压加脚本安装模式更容易写成自动化脚本。把解压和install.sh命令打包成一个shell脚本，循环跑一遍就能装上所有机器，省去每台机器等apt解析依赖的时间。

5. 常见问题与排查技巧实录

5.1 远程连接后黑屏：锁屏、Wayland和显卡驱动的锅

向日葵装上之后能连上，但屏幕一直黑的，这是Linux远程控制最经典的坑。我总结下来，黑屏的原因大概有三个：

第一个是系统锁屏导致。Ubuntu 20.04默认在几分钟没操作后会进入锁屏状态，向日葵有时无法把锁屏界面正确地推流给远程端。解决思路是：如果你确定自己的使用环境比较可信，可以关闭自动锁屏，或者开启自动登录。对一台办公室工作站来说，自动登录加屏保关闭，换来的是远程随时能连上，这个取舍我认为值得。

第二个是显示服务器协议问题。Ubuntu 20.04默认使用Xorg，这个矛盾少一些，但如果你手动切换到了Wayland，向日葵连接后很可能只能看到黑屏或者白屏。建议在登录界面选择Xorg作为会话类型。Debian 10默认本来就是Xorg，就很少遇到这个问题。

第三个是NVIDIA显卡驱动的影响。Ubuntu 20.04上很多人为了跑深度学习，安装了nvidia-driver-535这类专有驱动。在某些配置下，复合式桌面渲染和远程推流会有冲突，表现为远程画面卡死或者黑屏。这个问题我没有一个通杀的解决办法，但实测比较有效的绕过方式是：远程连接前，在向日葵连接参数里尝试更换画质模式，比如改成流畅优先，减少渲染压力；或者临时把桌面特效合成器关掉。

5.2 登录界面连不上，进桌面之后才能远程

有些朋友反馈，向日葵设备列表里能看到机器在线，但尝试远程连接时提示无法连接桌面，必须本机先有人登录进入桌面才能连上。这个问题在Ubuntu 20.04和Debian 10上都很常见，根源是向日葵的服务在启动时没有获取到图形会话的权限。

解决办法有两条路。一是设置系统自动登录，让机器开机后自动进入桌面环境，向日葵就能在正常的图形会话里运行。二是使用lightdm或gdm的自动登录配置。以Ubuntu 20.04的gdm为例，编辑/etc/gdm3/custom.conf，在[daemon]部分加入：

AutomaticLoginEnable=true AutomaticLogin=你的用户名

改完重启系统，机器就会自动登录桌面。这样做的代价是安全性有所下降，但换来的是远程维护随叫随到，对实验室这类内网环境来说通常是可接受的。

5.3 服务起不来或反复退出

向日葵安装完成后，systemd服务状态显示active (running)，但过一会儿就变成inactive，或者连激活都失败。这时候不要瞎猜，先看日志：

journalctl -u runsunloginclient.service -n 50

我遇到过的比较典型的日志是提示权限不足或者某个配置文件无法写入。向日葵运行时会往/usr/local/sunlogin目录下写一些临时配置，如果这个目录的所有权不对，服务就会反复失败。解决方法是：

sudo chown -R root:root /usr/local/sunlogin sudo chmod -R 755 /usr/local/sunlogin

还有一个容易被忽略的问题是，旧版本向日葵的残余服务和新版本冲突。如果你之前装过向日葵，卸载后旧服务的软链接可能还在，新版本安装时注册的新服务反而没有生效。这种情况建议先彻底清理旧的systemd服务文件，再重新安装。

5.4 卸载干净的正确姿势

如果你决定不用向日葵了，或者要重装一个新版本，卸载方式很有讲究。用deb包安装的，直接执行：

sudo dpkg -r sunloginclient

这个命令会移除包管理的记录，但大概率不会删除/usr/local/sunlogin目录下的运行时文件。残留文件不会影响日常使用，但会影响你下一次安装“同一个版本”或“新版本”时是否干净。我的习惯是卸载后再手动删一次目录：

sudo rm -rf /usr/local/sunlogin

同时把systemd服务软链接也清理掉：

sudo systemctl disable runsunloginclient.service

如果是tar.xz版本安装的，卸载时直接运行/usr/local/sunlogin/uninstall.sh脚本，这个脚本会把安装时复制出去的文件一并清理。

5.5 问题速查表

6. 个人体会和一些额外提醒

最后再分享几个我在实际使用中沉淀下来的经验，算不上什么高深的东西，都是踩坑换来的。

第一个经验：装向日葵之前，优先保证系统软件源是完整且可用的。Ubuntu 20.04先跑一次sudo apt update，确认能正常拉取软件列表。这一步如果都不通，后面所有的依赖修复都是空中楼阁。我之前有台机器装完系统后一直处于“半断网”状态，用了很久才发现是源配置里一个字母写错了。

第二个经验：尽量用deb包而不是tar.xz包来安装。虽然tar.xz安装速度快，但deb包带来的依赖管理和卸载体验是真实可感的。尤其对不熟悉的用户，用deb包出问题还能让系统帮你说清楚缺什么，比面对一个静默失败的install.sh脚本友好得多。

第三个经验：如果有条件，给实验室或机房的机器配一个支持开机的远程管理方案。向日葵毕竟是在系统启动完成、图形会话初始化之后才能工作，机器如果卡在BIOS或者系统加载阶段，远程工具帮不了你。我这边最后是额外加了独立的IPMI管理卡，CPU风扇转不转都能在网页上看清楚。

向日葵在Ubuntu 20.04和Debian 10上的安装，说到底就是一个依赖管理的游戏。只要理解了deb包依赖机制，学会用apt --fix-broken install和手动补齐缺失库这两板斧，几乎所有安装问题都能迎刃而解。希望这篇踩坑实录能让你少走一些弯路，遇到问题的时候也能按图索骥，找到自己需要的答案。