这台AGX Orin从到手的第一天起就躺在工作室角落的机架上插着电源、接着网线旁边没有显示器也没有键鼠。平时开发我都是SSH进去敲命令倒也没觉得有什么问题但碰上断电、临时演示、或者人不在工位想瞄一眼桌面状态的时候就很尴尬板子一旦进入待机必须有人走过去按一下电源键才能起来而我恰恰经常不在它旁边。这次记录的就是我在它上面配置“上电自动开机”和“远程桌面”的过程包含最终跑通的完整配置、三次重启验证的结果以及中间踩过的几个坑。这套配置适合谁如果你手里有一台Jetson AGX Orin开发套件想把它当成一台真正的无人值守边缘服务器来用或者你刚接触这类板卡、对Linux服务托管和远程访问体系不太熟这篇文章可以帮你省掉一大圈弯路。我会尽量把每一步的“为什么这么做”也讲清楚而不是只丢给你一堆命令。1. 先搞清楚AGX Orin默认的开机方式为什么让人抓狂1.1 默认行为插电后是待机不是开机AGX Orin官方开发套件的外接DC电源接上后板子上的白色电源指示灯会亮但这只代表“电源就绪”整机仍然处于待机状态SoC没有启动操作系统没有加载。要找它起来必须短按一下机箱上的电源键触发完整的上电时序然后才会进入U-Boot、加载内核、起来Ubuntu。对桌面用户来说这没什么但对准备把Orin放到机架、配电箱旁边长期跑任务的场景来说这个“必须物理按键”的设计很麻烦。实验室里跳闸、插拔排插、或者你远程发指令让智能插座断电重启等来电之后板子并不会自己开机所有服务仍然停在断电那一刻的状态人不在现场就彻底抓瞎。1.2 目标拆解三层问题要分开解决“上电自动开机”这个词听起来简单实际上拆开之后是三个完全不同层面的问题第一层是“谁来按下电源键”。这是硬件层问题官方开发套件没有直接给你一个“AC来电自启”的开关我在后面的章节会说几种可行的处理思路。第二层是“电源键按下之后系统能不能自动进入桌面”。这一层是软件问题默认的GDM登录管理器会停在账户密码界面等你输入无人值守照样卡住。解决办法是配置自动登录。第三层是“进了桌面之后远程服务有没有自动跑起来”。TigerVNC这类服务不会因为你登录了就自己启动需要交给systemd托管。这层嵌套关系先想明白后面动手才不会乱。很多人配置失败问题就出在只解决了其中一层比如开了自动登录但没配VNC自启或者VNC配了自启但被登录界面挡住连上去看到的不是桌面而是登录窗口。1.3 配置完成后的最终形态我在这个项目里最终落地的形态是这样的插上DC电源后通过外置延时触发模块短接一次电源键引脚板子自动开机开机后GDM自动登录进桌面不需要输密码TigerVNC以systemd服务的形式开机自启监听在5901端口我在外面用SSH隧道加密连接VNC不直接裸奔暴露端口。整个过程可以做到完全无人值守断电重启后板子自己开机、自己进桌面、自己把VNC服务拉起来我只需要在笔记本上连一下就能看到完整桌面。2. 软件层先行自动登录与开机任务托管2.1 GDM自动登录配置让开机直接进桌面AGX Orin在JetPack 5.x系列里用的是Ubuntu 20.04桌面版默认显示管理器是GDM3。自动登录的配置在/etc/gdm3/custom.conf文件里。我用编辑器打开这个文件sudo nano /etc/gdm3/custom.conf在[daemon]段落里加入下面三行内容[daemon] AutomaticLoginEnabletrue AutomaticLogin你的用户名注意这里的你的用户名要替换成Orin上实际存在的账户名。改完保存后不用急着重启验证后面还有别的配置要一起改。这里有个容易踩的坑如果你之前修改过LightDM或者其他显示管理器custom.conf这份配置是不生效的。所以动手前先确认一下当前到底用的是哪个显示管理器cat /etc/X11/default-display-manager输出如果是/usr/sbin/gdm3那就走GDM的配置如果是/usr/sbin/lightdm要去改/etc/lightdm/lightdm.conf里的autologin-user字段。我自己在这台Orin上就是后者因为JetPack某些版本会自带LightDM而不是GDM。用错了配置文件配半天重启还是停在登录界面一点效果都没有。2.2 为什么用systemd而不是rc.local托管开机任务刚接触Linux开机启动的人很容易想到rc.local在文件里写一行启动命令就完事。但rc.local的问题是执行时机太早、依赖的网络服务可能还没就绪而且没有日志、没有进程守护脚本写错了也不容易定位。我在这台Orin上统一用systemd来托管所有开机任务包括后面要做的TigerVNC服务。systemd的优势在于可以声明依赖关系、查看日志、设置失败自动重启尤其是Afternetwork-online.target这种网络就绪等待条件对远程桌面服务来说至关重要。举个例子如果你写了一个开机脚本需要联网执行用rc.local很容易出现“脚本跑了但网络没起来”的问题。而systemd服务可以这样声明[Unit] DescriptionOrin startup service Afternetwork-online.target Wantsnetwork-online.target这就等于告诉systemd等网络完全就绪再执行这个服务。对于所有跟远程通信相关的开机任务这个声明基本属于必备项。2.3 开机需要图形环境怎么办DISPLAY与XAUTHORITY如果你的开机任务需要访问图形界面比如自动启动某个GUI程序光设置Aftergraphical.target还不够。系统服务默认运行在无头环境没有DISPLAY环境变量程序不知道该往哪个显示器上画。这时候需要手动在服务里声明两样东西DISPLAY:0和XAUTHORITY。:0是本地第一个X显示器的编号XAUTHORITY指向当前用户的X权限文件。不声明这两项GUI程序会直接报cannot open display错误。之后的VNC服务虽然不需要连本地显示器但它要创建自己的虚拟显示所以这个思路要有。后面的配置我会实际用到。3. 远程桌面方案选型VNC三兄弟的实际取舍3.1 各有优劣TigerVNC、x11vnc、NoMachine对比远程桌面方案在Linux下有得选但在AGX Orin上真正值得考虑的其实就三个TigerVNC、x11vnc、NoMachine。我把它们的核心差异整理了一下方案会话类型配置复杂度资源占用适用场景TigerVNC独立的虚拟桌面中等需配xstartup和systemd较低无人值守常驻服务x11vnc镜像当前物理桌面低一条命令中等临时协助、远程指导NoMachine独立/镜像均可低安装即用中等追求低延迟、图形操作频繁TigerVNC是独立会话它不管你本地有没有接显示器、显示器上在显示什么它自己开一个虚拟桌面。这样做的好处是干净、互不干扰本地接屏幕干本地的事远程连上去干远程的事。x11vnc则直接把当前物理桌面画面通过VNC协议传出去所见即所得但如果你在本地把机器关了显示器或者切换了用户远程画面也会跟着变。NoMachine走的是NX协议压缩和网络自适应做得比VNC好在跨互联网的弱网环境下延迟更低。但它安装包比较大更新跟NVIDIA JetPack的绑定关系也不如apt源里的包来得干净我更倾向把它当备选方案。3.2 为什么最终选了TigerVNC我的核心需求是“常驻、稳定、可无人值守”这种情况下TigerVNC几乎是最合适的选择。首先它的独立会话机制意味着我不需要关心板子本地有没有人操作。其次TigerVNC是纯命令行配置可以干净地塞进systemd里托管开机自动拉起、崩溃自动重启完全符合服务器式管理习惯。第三它的资源占用比NoMachine低AGX Orin的CPU资源应该留给推理任务而不是远程画面编码。至于桌面环境我配合使用的是Xfce。这里必须多说一句JetPack默认的GNOME桌面在VNC下特别容易出灰屏问题。当你用VNC客户端连上TigerVNC默认会话时GNOME的某些组件在虚拟显示上无法正常工作经常出现一片灰色、鼠标变叉号、右键菜单没反应的情况。我一开始在这上面浪费了不少时间后面换了Xfce才彻底解决。3.3 x11vnc作为应急方案的定位虽然TigerVNC是主力但我在系统里还是装了x11vnc用来应对一种场景我需要远程指导本地坐在板子前面的人操作这时候镜像当前物理桌面比开个独立会话更直观。sudo apt install x11vnc x11vnc -storepasswd x11vnc -forever -shared -rfbauth ~/.vnc/passwd -rfbport 5900注意x11vnc的端口默认是5900而不是TigerVNC的5901两边别搞混。这个方案我不做自启只在需要临时协助时手动拉起来用用完就关避免两个VNC服务互相干扰。4. TigerVNC配置实录一份可以直接抄的配置4.1 安装与密码初始化在AGX Orin上安装TigerVNC很简单apt直接拉sudo apt update sudo apt install tigervnc-standalone-server tigervnc-common xfce4 xfce4-goodies这里一次性把TigerVNC服务端和Xfce桌面都装好。xfce4-goodies是一堆配套小工具和面板插件不是必须的但用起来顺手很多。安装完成后先给当前用户设置VNC访问密码vncpasswd这一步会生成~/.vnc/passwd文件里面存的是加密后的密码。建议在vncpasswd交互过程中直接设置一个只读密码也就是第二遍输入的密码这样别人通过只读方式连进来只能看不能操作排查问题时很实用。4.2 配置xstartup让VNC会话启动后进入XfceVNC服务启动后需要知道该启动哪个桌面环境。这个由~/.vnc/xstartup文件决定。我的配置内容如下#!/bin/sh unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS exec startxfce4写完后必须给它加执行权限否则VNC会提示无权限执行chmod x ~/.vnc/xstartup这里解释一下为什么要unset DBUS_SESSION_BUS_ADDRESS。VNC会话是一个独立的虚拟显示没有经过正常的登录流程环境变量里往往带着系统启动时残留的错误DBus地址。不清理的话Xfce启动时会连不上DBus会话总线导致桌面组件起不来面板加载不全甚至整个桌面起不来。这两行unset基本是老Linux运维配置VNC的统一操作应该顺手写上。4.3 用systemd托管VNC服务开机自启与崩溃恢复接下来是重头戏。为了不依赖手动登录和手工执行我把VNC服务交给systemd。写一个服务模板文件sudo nano /etc/systemd/system/vncserver.service内容如下[Unit] DescriptionVNC server for display %i Afternetwork.target [Service] Typesimple User你的用户名 Group你的用户名 WorkingDirectory/home/你的用户名 ExecStart/usr/bin/vncserver -fg -localhost yes -geometry 1920x1080 -depth 24 :%i ExecStop/usr/bin/vncserver -kill :%i Restarton-failure [Install] WantedBymulti-user.target这里有三个地方必须重点解释。第一个是-fg参数。TigerVNC的vncserver本质上是一个包装脚本它启动真正的Xvnc进程后自己就退出了。systemd的Typesimple服务要求主进程保持前台运行不加-fg的话systemd会认为服务启动后立即退出然后疯狂尝试重启日志里全是一片乱码。加上-fg让vncserver以交互方式保持前台运行systemd才能正确托管它的生命周期。第二个是-localhost yes这个参数。我特意没有用-localhost no因为VNC默认的密码校验是明文传输的直接监听在0.0.0.0上等于把5901端口暴露给整个局域网任何能抓到包的人都能看到你的键盘输入。后面我会用到SSH隧道来连通这个端口所以这里绑定本机就好安全很多。第三个是模板文件里的%i。这是systemd的模板实例占位符当我执行systemctl enable --now vncserver1时%i会被替换成数字1代表VNC display编号:1对应端口就是5901。保存文件后重新加载systemd配置并启动服务sudo systemctl daemon-reload sudo systemctl enable --now vncserver1用以下命令确认服务状态和监听端口systemctl status vncserver1 ss -tlnp | grep 5901看到LISTEN状态就说明服务已经起来了。此时用任何VNC客户端连接127.0.0.1:5901输入刚才设置的密码就能看到一个完整的Xfce桌面。4.4 远程访问的安全姿势SSH隧道与内网组网配置完成后的客户端连接方式我强烈建议不要图省事直接连IP的5901端口。VNC协议本身是明文的密码在网络上裸奔。正确做法是先用SSH隧道把端口打通再让VNC客户端连接本地端口。使用Linux/macOS终端可以这样建立隧道ssh -L 5901:127.0.0.1:5901 你的用户名Orin的IPWindows的OpenSSH客户端同样支持这条命令。隧道建立后VNC客户端连接127.0.0.1:5901数据会经过SSH加密通道转发到Orin本地的5901端口VNC服务的-localhost yes限制也因此正好满足。如果你的使用场景是跨互联网访问不推荐直接把Orin的22端口暴露到公网。我在这台板子上装了Tailscale这类内网组网工具Orin和笔记本都在同一个虚拟内网里然后在组网IP上建立SSH隧道访问5901端口。整个链路是加密的又不需要在路由器上做任何端口映射对没有公网IP的办公网络特别友好。5. 排查实录重启三次才把整套流程彻底跑通配置完成后我并没有急着收工而是反复重启验证整套自动化链路是否真的可用。这里记录几个我实际踩到的坑和对应的排查过程希望能帮你少走弯路。5.1 第一个坑VNC连上后一片灰屏第一次配好TigerVNC满心欢喜地用VNC Viewer连上去结果屏幕是一整片灰色鼠标变成一个X形右键点击毫无反应。这种情况就是典型的桌面环境启动失败。我当时的排查链路是这样的先查看VNC的会话日志日志文件在~/.vnc/orin:1.log里面记录了Xvnc启动时加载xstartup的输出。日志里看到Xfce加载过程正常执行但最后没有报致命错误桌面却没起来。后来我意识到问题出在GNOME和VNC的兼容性上。因为我是从JetPack默认桌面环境起步的虽然xstartup里写的startxfce4但系统的会话管理变量可能还有残留。最后我是通过彻底清理~/.vnc目录、手动执行vncserver -kill :1干掉旧的会话、然后重新启动VNC解决的。如果你的情况跟我类似建议按照这个顺序操作vncserver -kill :1 rm -rf ~/.vnc/*.log systemctl restart vncserver1重启后用干净的客户端重新连接。如果还是灰屏检查Xfce是否真的装上了、xstartup是否有执行权限、日志里有没有缺少库文件的报错。5.2 第二个坑systemd服务反复重启这个坑出现在我第一次把VNC服务交给systemd时。服务状态永远在activating (start)和failed之间反复横跳systemctl status显示进程一启动就退出。排查日志时发现VNC进程其实成功启动了Xvnc也在内存里跑着但systemd就是不认为它在“运行”。原因就是我前面提到的那个-fg参数缺失。因为/usr/bin/vncserver这个脚本默认会fork出Xvnc后台进程然后自己退出systemd的Typesimple模式根本不认这种后台进程方式所以反复执行、反复判定失败。解决方式就是在ExecStart里显式加上-fg强制vncserver脚本别退出保持前台运行。这个坑很隐蔽很多教程根本没提我建议你把这条记下来。5.3 第三个坑自动登录配置不生效GDM自动登录配置写好后我满心期待地执行reboot结果板子起来还是一个登录界面需要手动输密码。当时有点蒙因为/etc/gdm3/custom.conf里的配置看起来完全正确。后来我用cat /etc/X11/default-display-manager查了一下发现这台Orin压根用的不是GDM而是LightDM。JetPack的某些镜像会默认使用LightDM作为登录管理器。后来我改了/etc/lightdm/lightdm.conf[Seat:*] autologin-user你的用户名 autologin-user-timeout0重启后才真正实现自动登录。所以如果你也遇到配了GDM但不生效的情况第一时间检查当前机器用的是哪个显示管理器别在错误的配置上反复折腾。5.4 第四个坑端口通着VNC客户端却拒绝连接有一次系统重启后我发现ss -tlnp | grep 5901能看到VNC在监听但外部VNC客户端怎么都连不上连接直接超时。检查了一圈发现是ufw防火墙拦截了端口。Ubuntu桌面版默认不会自动启用ufw但如果你之前为了加固系统手动开启了防火墙就会遇到这个情况。解决办法很简单放行SSH端口即可因为VNC走SSH隧道的话只需要SSH端口可达sudo ufw allow 22/tcp sudo ufw enable注意如果你坚持要让VNC端口对外直接可连那还需要sudo ufw allow 5901/tcp但我不建议这么做。走SSH隧道之后防火墙层面只需要放行一个SSH端口攻击面小很多。6. 硬件层再进一步把“上电自动开机”真正落地6.1 官方开发套件有没有“AC来电自启”选项我在这台AGX Orin上用的JetPack 5.1.2版本里没有找到任何官方提供的“AC上电自动开机”开关。NVIDIA官方开发套件的定位是开发调试工具默认就是待机后需要按键唤醒它没有像服务器主板那样的“Restore AC Power Loss”选项。所以如果你是跟我一样的官方开发套件并且条件允许最稳妥的“上电自动开机”思路是把设备的电源保持在在线状态也就是不要把电彻底断掉。但这又跟“断电重启后自动恢复”的需求相冲突。6.2 第三方载板的AUTO ON跳线我后来帮别人调试时接触过几款第三方Orin载板发现很多工业级载板在设计时会直接提供一个自动上电跳线或者拨码开关有的叫“AUTO POWER ON”有的叫“AC LOSS AUTO BOOT”原理就是让电源管理芯片在检测到外部电源接入时直接触发上电时序而不是等按键信号。如果你用的是第三方载板我强烈建议你先翻一下硬件手册搜索“AUTO ON”“ATX”“PWR_ON”等关键词很可能会有意外收获。这是最干净、最可靠的方案不需要任何额外硬件改动。官方开发套件没有这个选项这类跳线在某些工业载板上却是标配不得不说是产品定位的差异。6.3 低成本外置触发模块方案如果你跟我一样用的是官方开发套件又确实需要在每次上电后让板子自动开机我的做法是加一个“上电延时触发模块”。原理很简单模块检测到DC电源接通后延时几秒让电源稳定下来然后输出一个短暂的脉冲短接一次电源键引脚等效于有人按了一下电源键。具体操作上模块的输入接DC电源的正负极输出端两根线接到开发套件主板电源按键的引脚两侧。安全起见我建议先万用表确认按键引脚的定义不要盲接搞错方向可能烧板子。延时设置不需要太长3到5秒够用太短可能导致电源还在抖动时就触发。这个方案虽然不是那么“软件化”但胜在成本极低、可靠性高而且对设备本身的改动很小。如果你不想拆机那就只能接受“断电后需要手动按键开机”的现实毕竟官方开发套件的定位摆在那里。6.4 长期运行的维护建议配置完成后这台Orin现在全天候挂在工作间里无人值守跑着推理任务和远程桌面服务。运行了一个多星期我总结了几个对长期运行有用的维护点。第一个是功率模式。AGX Orin支持多种电源档位从20W到60W MAXN不等。远程桌面这类轻量任务不需要把功耗拉满我用nvpmodel -q查看当前模式把默认模式维持在40W档发热和风扇噪音平衡得比较好。只有跑大模型推理时才会临时切到MAXN模式。第二个是运行监控。我用了两条最常用的命令sudo tegrastats可以实时查看CPU、GPU、内存占用和温度sudo jetson_clocks可以强制解锁所有核心频率但这个命令会让发热明显上升不建议长期开着只在需要性能拉满时用。第三个是日志轮转。VNC会话的日志文件会随着时间增长~/.vnc/*.log如果不清理会越来越大。加上板子作为服务器长期运行系统日志本身也需要管理我装了个logrotate配置定期清理VNC日志防止日志把根目录塞满。到最后你会发现AGX Orin这类设备真正耐用的形态不是一台需要人伺候的开发板而是一台通电就能进桌面、远程随时能连的服务器。配置完这套体系之后我远程改代码、看日志、甚至顺手把桌面上的浏览器窗口拖一拖都跟在本地操作没什么区别。自动化这件事前期多花半小时后面省下的是无数个“要跑一趟机房”的下午。