企业官网建设流程全解析

作者本人遇到过太多同事刚拿到 Orin 开发板，第一反应就是拔掉显示器、丢进机柜，然后通过 NoMachine 远程登录。接下来屏幕就停在 NVIDIA Logo 上，反复重装 NoMachine、重启板卡都不解决问题。今天这篇分享完整讲清楚这个现象的底层链路，以及一套在 JetPack 6.0 上真正可复现的 Headless 解决方案。内容不求花哨，只求实测有效。

1. 先别折腾远程软件，这个“NVIDIA Logo 卡死”其实是图形栈的问题

很多人的第一反应是 NoMachine 没装好、服务没起来、或者端口被防火墙挡了。实际方向完全不对。现象是 NoMachine 客户端能连上，画面也出来了，但永远停在开机阶段的 NVIDIA Logo，这意味着网络连接、NX 协议握手都是通的，问题出在板卡本地的图形会话没有起来。可以把这个过程想象成去一栋楼找人：NoMachine 只是带你到了大厅门口，但如果大厅里根本没有前台接待、没有电梯运行，你只能在门口看墙壁上的公司招牌，也就是那个 Logo。

1.1 Headless 模式下完整图形链路的四段路程

Jetson 板卡从开机到远程桌面的图形链路，通常分成四段：第一段是内核驱动初始化 framebuffer，把早期启动画面的 NVIDIA Logo 显示在默认输出上；第二段是显示管理器（Display Manager）拉起 Xorg；第三段是 Xorg 成功绑定 GPU 后，把画面从内核 framebuffer 接管到真正的桌面会话；第四段才是 NoMachine 通过 X 协议连到 Xorg，把这个画面实时传到客户端。

无头模式下最常见的问题，是第二段和第三段之间直接断裂。也就是说内核 framebuffer 还停在 Logo，但 Xorg 根本没有成功初始化，或者初始化了一半就被显示管理器放弃。NoMachine 连接过去后，它最多只能读到残留的 framebuffer 内容，或者显示一个由它自己创建的虚拟显示，而这个虚拟显示上也没有桌面。所以你会看到鼠标能动、画面在，但永远没有登录框。

1.2 用 5 条命令定位到底断在哪一段

与其猜，不如直接看进程和日志。拿到一台卡 Logo 的 Jetson，先用 SSH 登录，按顺序执行下面这组命令：

systemctl status display-manager pgrep -af Xorg ls -la /tmp/.X11-unix/ sudo grep -E "(EE)|(WW)" /var/log/Xorg.0.log loginctl list-sessions

每条命令的用途说一下。systemctl status display-manager会告诉你系统当前默认的显示管理器是 gdm3 还是 lightdm，以及它是不是正在运行；如果显示 inactive 或 failed，那基本可以直接锁定方向。pgrep -af Xorg用来确认 Xorg 进程是否存在，输出/usr/lib/xorg/Xorg :0这样一行，说明 X server 已经跑在 :0 显示编号上；没有任何输出，说明 X 根本没起来。ls -la /tmp/.X11-unix/是看有没有 X0 这个 socket 文件，有的话说明 Xorg 在监听，没有则说明连监听都没建立。sudo grep -E "(EE)|(WW)" /var/log/Xorg.0.log是抓 Xorg 启动日志里的错误和警告，这一步经常能直接看到Failed to get display device之类的关键行。最后loginctl list-sessions查看是否已经有图形会话分配给了某个用户。

1.3 一个典型的日志长什么样

我自己在检查一台朋友的 Orin NX 时，看到过非常典型的日志片段：

(EE) NVIDIA(0): Failed to attach to NVIDIA driver (EE) NVIDIA(0): Failed to initialize the NVIDIA kernel module (WW) NVIDIA(0): No display devices found (WW) NVIDIA(0): Falling back to no display device

这个组合非常直白地说明问题：NVIDIA 驱动在启动 Xorg 时，找不到任何可用的显示设备。正常情况下，只要有 HDMI 或 DP 显示器接着，驱动就能从这个物理接口上读到一个 EDID 信息，然后建立一组显示模式；拔掉显示器之后，驱动会认为没有任何输出设备，于是拒绝初始化。板卡进了这个状态，系统只能停留在内核 framebuffer 的 Logo 画面上。

2. 为什么 JetPack 6.0 特别容易出这个问题

JetPack 6.0 对应的 Linux for Tegra 内核版本是基于 Ubuntu 22.04 构建的，相比 JetPack 5.x，更新了很多系统组件，默认桌面环境是 GNOME，显示管理器更多时候是 GDM，而不是以前 L4T 上常见的 LightDM。这个变化本身不是什么坏事，但它带来两个直接影响。第一，GDM 对无显示设备的处理策略比 LightDM 更严格，它发现没有可用显示设备时，不会自动去创建一个虚拟输出，很多时候直接放弃启动 Xorg。第二，JetPack 6.0 的 GNOME 会话里同时存在 Xorg 和 Wayland 两种登录条目，而 NoMachine 对 Wayland 的支持仍然不成熟，如果系统或用户选择了 Wayland 会话，远程连接就会卡在更早的阶段。

2.1 从 JetPack 6.0 的默认桌面环境说起

JetPack 6.0 刷完系统后，连接显示器是可以直接看到 GNOME 桌面的。GDM 会检测到 HDMI 接口上有一个真实显示器，于是正常初始化 Xorg，并给当前用户分配一个图形会话。一切看起来都很美好。可一旦拔掉显示器，GDM 再次启动 Xorg 时，驱动层发现没有任何 display device，就会回退到“无法创建输出”的状态。这解释了为什么很多人在有显示器时一切正常，拔掉显示器用 NoMachine 就立刻卡 Logo。

此外，JetPack 6.0 的镜像里默认安装了 Wayland 会话的入口。GNOME 在 Wayland 模式下桌面运行流畅，但 NoMachine 的服务端本质上是依赖 X11 协议的，即使新版能部分适配 Wayland，在嵌入式 Tegra 平台上也极不稳定。所以我通常会建议直接把 Wayland 会话入口移走，强制系统使用 Xorg，确保 NoMachine 连接的是一个它最熟悉的 X server。

2.2 物理显示器缺席时，Xorg 初始化失败的真实原因

Xorg 之所以在无显示器时失败，不是内核不支持，也不是硬件坏了，而是 NVIDIA 驱动在默认策略下要求至少存在一个显示输出设备。这种策略对桌面显卡是合理的：你不会希望显卡在没有显示器的状态下消耗额外资源。但 Jetson 这种嵌入式板卡恰恰相反，Headless 部署是常态，我们需要让驱动在没有任何物理显示设备时，仍然认为有一个虚拟输出，并且创建一组默认显示模式。这就是后面要配置AllowEmptyInitialConfiguration与UseDisplayDevice这两个选项的原因。

另一个容易忽略的细节是，内核 framebuffer 的 Logo 画面不会被自动清掉。即使你后来想办法让 Xorg 起来了，如果显示管理器没有正确接管，屏幕上的内容可能仍然停留在那个 Logo。这时候不要以为又是配置失效，先去确认 Xorg 进程和日志，只要 Xorg 起来了，画面切换往往只需要重新触发一次会话登录。

2.3 NoMachine 和 X server 的合作关系

NoMachine 的 Linux 服务端设计上并不是自己去画桌面的，它依赖系统里已经存在的 X server。具体来说，客户端连接时，NoMachine 服务端会检查目标显示编号上的 X server 是否可用，可用就直接接入，不可用则会尝试创建自己的虚拟显示。问题在于，它自己创建的虚拟显示通常也会调用 Xorg，而 Xorg 同样会被 NVIDIA 驱动的“找不到显示设备”策略卡住。结果就是 NoMachine 努力尝试半天，最终还是只能给你一个空壳或者遗留的 framebuffer。

所以正路只有一条：让系统在启动阶段就有一个稳定的 Xorg 运行在:0显示编号上，并且里面跑着一个已登录的 GNOME 桌面会话。NoMachine 只负责“观看”和“控制”这个现成会话，不再需要自己从零去创建显示环境。这套思路既解决了卡 Logo，也避免了远程连接时反复触发新显示而导致的资源浪费。

3. 核心修复：三步配置无头 Xorg + 自动登录

接下来这一段是整个方案的关键。我不会只告诉你“改一个配置文件”，而是按实际项目里最小可用、最可复现的路径，一档一档做下去。全程不需要插 HDMI 诱饵器，不需要改 NoMachine 客户端破解方案，只需要在系统层面把无头显示能力打开。

3.1 第一步：备份现有 X 配置

动手前先把可能存在的旧配置备份好。JetPack 镜像不一定默认生成/etc/X11/xorg.conf，但如果你之前手动装过桌面驱动、用过轻量窗口管理器，文件可能存在。执行下面的命令：

sudo cp /etc/X11/xorg.conf /etc/X11/xorg.conf.bak.$(date +%F) 2>/dev/null || true mkdir -p ~/headless-fix

2>/dev/null || true是为了处理文件不存在时命令不报错退出。这个备份习惯非常重要，后面如果出现异常，你还能在 SSH 终端里快速恢复现场，而不是面对一个反复重启的板卡手足无措。

3.2 第二步：写一份无头可用的 xorg.conf

接下来创建主配置文件。执行：

sudo nano /etc/X11/xorg.conf

写入以下完整配置：

Section "ServerLayout" Identifier "HeadlessLayout" Screen "Screen0" EndSection Section "Monitor" Identifier "ConfiguredMonitor" VendorName "Unknown" ModelName "NVIDIA Virtual" Option "DPMS" "false" EndSection Section "Device" Identifier "nvidia0" Driver "nvidia" VendorName "NVIDIA Corporation" BoardName "NVIDIA Tegra" Option "AllowEmptyInitialConfiguration" "true" Option "UseDisplayDevice" "None" Option "ConnectedMonitor" "DFP-0" EndSection Section "Screen" Identifier "Screen0" Device "nvidia0" Monitor "ConfiguredMonitor" DefaultDepth 24 SubSection "Display" Depth 24 Modes "1920x1080" "1280x720" "1024x768" Virtual 1920 1080 EndSubSection EndSection

逐个解释关键字段。AllowEmptyInitialConfiguration设为true，是告诉 NVIDIA 驱动允许在没有物理显示器连接的情况下初始化 Xorg。这个选项最初是给云端 GPU 虚拟化场景准备的，在 Jetson 上同样生效，是整个方案的基石。UseDisplayDevice设为None，意思是驱动不要强行绑定某个物理输出接口，而是走虚拟输出通道。ConnectedMonitor设为DFP-0，则让驱动按照数字平板显示器的逻辑口准备好模式列表，避免因为缺失 EDID 而把分辨率锁死在极低档位。Screen 段里的Virtual 1920 1080，是给 framebuffer 预分配一块足够大的工作区，后续无论 NoMachine 客户端窗口多大，画面都不会因为 framebuffer 太小而出现缩放残影。

有一个细节值得说明：BusID我并没有写在 Device 段里。Tegra 平台的 Xorg 驱动通常能自动定位到 GPU，强制指定PCI:0:0:0在部分 JetPack 版本上反而可能导致探测失败。如果你的板卡有特殊配置，可以在确认lspci | grep -i nvidia的输出后再补上。

3.3 第三步：让显示管理器自动登录并锁死 X11

光有 xorg.conf 还不够，还要保证显示管理器启动 Xorg 后，直接进入一个已登录的桌面会话，否则 NoMachine 连接过去看到的依然是一个登录界面，很多时候鼠标键盘都无法在远程正确输入。另外必须把 Wayland 会话排除掉。

如果你的系统使用 GDM，执行：

sudo nano /etc/gdm3/custom.conf

改成这样：

[daemon] WaylandEnable=false AutomaticLoginEnable=true AutomaticLogin=你的用户名 [security] DisallowTCP=true [debug] Enable=false

如果你的系统使用 LightDM，执行：

sudo nano /etc/lightdm/lightdm.conf

写入：

[Seat:*] autologin-user=你的用户名 autologin-session=ubuntu

这里的autologin-session要和/usr/share/xsessions/目录下的实际 session 文件名对应。JetPack 6.0 上常见的是ubuntu-xorg.desktop或gnome-xorg.desktop，你可以先执行ls -l /usr/share/xsessions/看清楚了再填。

同时建议把 Wayland 会话入口暂时移走，避免 GDM 自动选中 Wayland：

sudo mv /usr/share/wayland-sessions/gnome-wayland.desktop ~/headless-fix/gnome-wayland.desktop.bak

这一步做完，系统会强制走 Xorg 方向，NoMachine 才能稳定接入。

3.4 第四步：NoMachine 指向现有 X server

服务端配置其实不需要做太多事。NoMachine 的默认逻辑是在检测到系统已经存在 X server 时，直接复用这个会话。我们要做的只是在 NoMachine 客户端里指定显示编号为0，也就是让服务器地址写成你的板卡IP:0。如果连接后仍然黑屏，再检查 NoMachine 连接属性里的协议设置，选择 X11，并且确保没有勾选“创建新的虚拟显示”这类会触发新 Xorg 的选项。

另外值得注意的一点是，如果系统之前已经在无头状态下被多次尝试连接，NoMachine 服务端可能残留了一些孤立的旧会话。可以在 SSH 终端里执行：

sudo /usr/NX/bin/nxserver --terminate

把旧会话全部清掉，再重新连接。这个操作不会影响系统本身的桌面会话，只是清理 NoMachine 层面的连接记录。

3.5 重启后的验证流程

配置完成后，执行sudo reboot。重启后不要立刻开 NoMachine，先用 SSH 登录板卡，依次执行：

pgrep -af Xorg ls -la /tmp/.X11-unix/ DISPLAY=:0 xdpyinfo | head -20

如果第一行输出显示类似/usr/lib/xorg/Xorg :0，第二行能看到X0文件，第三行能打印出屏幕尺寸、分辨率列表，就说明 Xorg 已经成功跑在:0上了。此时再打开 NoMachine 客户端连接，绝大多数情况下会直接看到 GNOME 桌面，而不是那块让人头疼的 NVIDIA Logo。

4. 实操记录：一台 Orin NX 从卡 Logo 到顺利看到桌面的完整过程

为了让你对这套流程有更直观的感受，我拿一个真实的故障处理过程复盘一遍。板卡型号是 Orin NX 16GB，JetPack 6.0 官方镜像，用户通过 NoMachine 远程使用，最初卡 Logo，本地没有接任何显示器。

4.1 故障现场初查

SSH 登录后，我先执行了systemctl status display-manager，看到 GDM 处于 actvie 状态，但pgrep -af Xorg没有任何输出，说明 GDM 一直卡在反复尝试启动 Xorg 的状态。接着查日志：

sudo grep -E "(EE)|(WW)" /var/log/Xorg.0.log

输出里出现了(EE) NVIDIA(0): Failed to get display device。这一条足以确认根因，就是无物理显示设备导致 Xorg 初始化失败，跟 NoMachine 本身毫无关系。此时最有效的思路不是重装 NoMachine，而是从系统图形栈补上无头能力。

4.2 修改的文件清单

我总共改了四个地方，整个过程不超过十分钟，全部通过 SSH 完成。具体如下：

这里特别建议服务器端配置不要再去改/usr/NX/etc/server.cfg。我见过很多人一上来就改服务端显示创建方式，结果把 NoMachine 的默认行为搞乱，反而更难排查。在目标系统已有稳定 Xorg 的前提下，保持服务端默认就是最安全的。

4.3 重启后的日志确认

重启之后，我再次查看日志，这次成功关键行变成了这样：

(==) NVIDIA(0): Using 0 display devices (==) NVIDIA(0): Virtual display device enabled (==) NVIDIA(0): Setting mode 1920x1080

注意Using 0 display devices并不是错误，它表示没有物理显示设备，但驱动已经允许虚拟输出，所以后面能看到分辨率正常设置为 1920x1080。同时loginctl list-sessions里已经出现用户会话，说明自动登录生效。此时 NoMachine 客户端连接后，桌面、鼠标、键盘、应用窗口全部正常。

4.4 分辨率与交互体验优化

如果远程桌面分辨率不理想，或者客户端窗口拉伸后画面模糊，可以在远程桌面终端里用 xrandr 查看当前输出设备名称和模式：

xrandr -q

虚拟输出在 Jetson 上通常会显示为一个默认设备，可能是default或DFP-0。想要增加一个自定义分辨率，可以这样手动创建：

cvt 1920 1080 60 xrandr --newmode "1920x1080_60.00" 173.00 1920 2048 2248 2576 1080 1083 1088 1120 -hsync +vsync xrandr --addmode DFP-0 1920x1080_60.00 xrandr --output DFP-0 --mode 1920x1080_60.00

其中cvt生成的实际参数值要以输出为准，不同面板会有细微差异。上面的数值是常见的 1920x1080@60Hz 参数，直接复制大概率能跑，但严谨一点应该先执行cvt 1920 1080 60拿到确切的 modeline 再填进xrandr --newmode。

交互方面还有一个小坑：如果连接后发现鼠标能显示但键盘没反应，先不要改系统，去 NoMachine 客户端连接属性里查看“远程输入”选项是否开启。新版客户端有的默认策略会拦截键盘事件，需要手动把 input 开关打开。

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

在实际部署过程中，同一套配置在不同板卡、不同 JetPack 小版本上可能表现不同。我把高频出现的问题和解决路径整理成一张速查表，然后逐个展开说明：

5.1 改了配置还是卡 Logo，怎么办

先检查配置文件是否真的被 Xorg 加载。执行：

sudo grep -E "using config file" /var/log/Xorg.0.log

如果日志里显示用的是/etc/X11/xorg.conf，说明路径加载正常；如果它显示的是别的位置，或者完全没有提到配置，就说明你的配置文件路径不对，或者文件名不对。JetPack 6.0 的 Xorg 默认搜索顺序里会读取/usr/share/X11/xorg.conf.d/目录下的.conf文件，所以也可以把上面的配置放到这个目录里，文件命名成类似20-headless.conf，效果一样。另一个容易被忽略的点是文件权限，确保是 root 所有并且可以读取：

sudo chown root:root /etc/X11/xorg.conf sudo chmod 644 /etc/X11/xorg.conf

5.2 分辨率太低，只有 640x480

这种情况通常是因为UseDisplayDevice和ConnectedMonitor没有配合好，驱动创建了虚拟输出但不知道给你准备哪些显示模式。除了本章前面说的Virtual 1920 1080之外，还可以在 Screen 段的 SubSection 里明确写出分辨率：

SubSection "Display" Depth 24 Modes "1920x1080" "1600x900" "1280x720" Virtual 1920 1080 EndSubSection

如果这样仍然不生效，就进入桌面后手动用 xrandr 添加模式。这种方式比较适合单台调试，如果是批量部署，最好第一版就把分辨率写死在配置里。

5.3 NoMachine 连上黑屏但 SSH 正常

这个坑很典型。现象是 NoMachine 客户端能连上，屏幕黑漆漆一片，但 SSH 访问完全正常，甚至能远程看到进程都在跑。原因多半是客户端默认选择让 NoMachine 自己新建一个显示环境，而不是去接:0上已有的会话。解决方式是把连接属性里的显示编号改为 0，并且在服务端先清理可能存在的旧虚拟会话：

sudo /usr/NX/bin/nxserver --terminate sudo /usr/NX/bin/nxserver --restart

清理后再连接，通常就能从黑屏变回桌面。

5.4 鼠标键盘失效

远程桌面最怕连上了却操作不了。检查顺序是这样的：先看 NoMachine 客户端连接属性，确认 “Enable input” 或类似选项是勾选状态；然后在远程桌面里执行xinput list，查看 X server 是否识别到虚拟输入设备；最后检查 GDM 是否同时存在多个会话，如果是，注销掉多余会话再重新连接。

如果实在找不到问题，可以先在 SSH 里杀掉当前 GDM 再让其自动重启：

sudo systemctl restart display-manager

等待十几秒后，自动登录会话会重新建立，NoMachine 再连接通常会恢复正常。

5.5 自动登录反复失败

自动登录失败最常见的原因是会话名称不对。比如配置里写了autologin-session=gnome，但目录下实际叫gnome-xorg.desktop，显示管理器就找不到会话。正确做法是登进板卡后执行：

ls -l /usr/share/xsessions/

然后用输出里的文件名去掉.desktop后缀去填配置。LightDM 场景下还要检查/var/log/lightdm/目录里的日志，里面会直接记录启动失败的会话名称和原因。GDM 场景则重点看：

sudo journalctl -u gdm3 --no-pager -n 50

日志里如果有pam_unix(gdm-autologin:auth): conversation failed之类的内容，通常是用户名错误或密码策略问题，重新确认AutomaticLogin字段即可。

6. 为什么不推荐 HDMI 诱饵器，而推荐这套配置方案

很多人一遇到这个坑，第一反应是去淘一个 HDMI 诱饵器，也就是 EDID 模拟器。插上去之后，系统确实能骗过显卡驱动，让它以为有一个 1080p 显示器接着，Xorg 也能正常启动。这个方法不是不能用，但我不建议把它作为最终方案。

如果是独此一台的开发板，插一个诱饵器确实省事。但如果是做边缘计算设备的批量交付，每台设备都要买一个诱饵器、塞在机箱里、还要担心运输松动，这个方案就很难看了。更重要的是，xorg.conf 这套配置完全可以打进你自定义的系统镜像里，烧录完成后开机即用，无论怎么换设备都能复现。

从维护角度看，配置化方案还容易排查。设备出问题时，你只要 SSH 进去看 Xorg 日志和配置，就能判断是驱动问题、配置问题还是会话问题。而诱饵器方案一旦出问题，还要怀疑 EDID 模拟器本身是不是坏了，排查链路反而更长。

我个人在实际项目中一直坚持用这套方案。一个重要体会是，JetPack 升级到 6.x 之后，系统服务和桌面环境都往 systemd 收敛，问题虽然看起来复杂，但排查链路很清晰：从 Xorg 日志入手，确认 GPU 能不能初始化，比反复重装 NoMachine 有效得多。