前阵子接了个挺头疼的活：一台放在隔离网段里的 openEuler 22.03 LTS SP4 服务器，最小化安装，只有命令行，却要求补一套 UKUI 桌面。机器不能出网，意味着常见的dnf install路径完全走不通，所有依赖必须在外网环境准备好再带进去。一开始我以为拷几个 rpm 进去就行，真正动手才发现 UKUI 的依赖树远比想象中深——桌面环境牵扯到显示服务、窗口管理器、控制中心、会话管理、音视频底层库，随便数一下都有上百个包，靠手工一个个找根本不现实。
折腾完整个流程后，我把可复现的步骤完整记录了下来。适合的读者很明确：运维要处理内网 Linux 桌面部署、开发者在虚拟机里想给 openEuler 装图形界面、以及那些已经踩进依赖泥潭想找一条稳定路线的人。这篇文章会告诉你为什么选 UKUI、如何在联网机器上打包完整依赖、到了离线机器上怎样搭建本地仓库完成安装，最后再把装完最容易遇到的几个问题一并解决掉。
1. 为什么选UKUI，以及离线部署的整体思路
1.1 UKUI 在服务器桌面场景中的定位
openEuler 默认安装是不带图形界面的，生产环境通常也用不到桌面。但当这台机器要承担一些特殊角色——比如内网里的管理终端、给非技术人员提供一个可操作的入口、或者某些业务系统需要一个 GUI 环境来承载——桌面就变得必要了。
桌面环境的选择上，GNOME 和 KDE 当然也能装，但在 openEuler 这种偏服务器定位的系统上，我不会优先选它们。GNOME 对系统资源占用偏高，在只有 2G 内存的虚拟机上跑起来会明显发沉；KDE 功能确实丰富，但相对复杂，装完要配置的东西也多。UKUI 的优势在于轻量，底层基于 GTK 和 Qt 组件，整体内存占用比 GNOME 小一截，启动速度也更快。更关键的是它的操作习惯非常贴近大家熟悉的传统桌面布局——开始菜单在左下角，任务栏在底部，各种设置面板一目了然。对内网里不熟悉 Linux 命令行的用户来说，这个上手门槛低很多。
| 桌面环境 | 内存占用 | 上手难度 | 适合场景 |
|---|---|---|---|
| GNOME | 较高 | 中等 | 通用工作站、开发者 |
| KDE | 高 | 较高 | 高定制化需求的桌面 |
| UKUI | 较低 | 低 | 内网管理终端、轻量桌面、虚拟化环境 |
从 openEuler 官方仓库的维护情况来看，UKUI 在 22.03 LTS 系列中的包相对完整，SP4 版本里桌面组件已经比较成熟。选它做离线部署目标，技术上可行，资源消耗也可控。
1.2 离线安装的两条技术路线对比
离线安装 Linux 桌面的常规做法有两条路，我在动手前专门对比过。
第一条是整库同步，用reposync把 openEuler 的某个仓库（比如 everything 或 EPOL）全部同步下来，做成一个本地镜像源。好处是一劳永逸，后续想装任何软件都能用；坏处也很明显——仓库体积动辄十几 GB 甚至几十 GB，下载耗时、占磁盘、内网拷贝也费劲。如果目标机只需要一个 UKUI 桌面，这么做明显性价比不高。
第二条是精确依赖拉取，利用dnf download --resolve把 UKUI 包组以及它们的全部依赖一次性下载到指定目录，然后在离线机器上配置成本地仓库。这种方式的体积通常在 1~2 GB，传输和安装都很快，而且不依赖目标机原本有任何软件源，只要 rpm 包齐了就能装。
我最终选择了第二条路线，同时把第一条作为兜底方案。原因很直白：精确拉取足够解决问题，而整库同步要付出的时间和存储成本实在不划算。后面会有单独一节讲 reposync 备用方案的用法。
2. 在联网机器上把依赖“打包带走”
2.1 下载机的环境准备与仓库源配置
准备一台能访问公网的机器作为下载机。这里有一个被我反复验证过的重要前提：下载机的系统版本最好和目标机保持一致，至少是同一个大版本系列。因为dnf download --resolve解析依赖依赖的是本机的 dnf 数据和仓库元数据，如果你在 CentOS 上用同样的命令给 openEuler 拉包，解析出来的依赖树很可能是错的。我用了一台安装 openEuler 22.03 LTS SP4 最小化系统的虚拟机来干活，效果最稳。
下载机的磁盘建议预留 20 GB 以上空闲空间。UKUI 的包组全部依赖加起来通常在 1~2 GB，但 dnf 下载过程中会产生大量临时文件，包目录也要留足余量，别卡在磁盘不足这种低级问题上。
接下来配置仓库源。openEuler 22.03 LTS SP4 相关的几个仓库中，UKUI 所在的是 EPOL 仓库。如果只启用默认的 OS 仓库，是搜不到 UKUI 包组的。我的做法是添加一个完整的仓库配置文件，把 OS、everything、EPOL 都写上，保险起见一个不漏：
cat > /etc/yum.repos.d/openEuler.repo <<'EOF' [OS] name=OS baseurl=https://repo.openeuler.org/openEuler-22.03-LTS-SP4/OS/x86_64/ enabled=1 gpgcheck=1 gpgkey=https://repo.openeuler.org/openEuler-22.03-LTS-SP4/OS/x86_64/RPM-GPG-KEY-openEuler [everything] name=everything baseurl=https://repo.openeuler.org/openEuler-22.03-LTS-SP4/everything/x86_64/ enabled=1 gpgcheck=1 gpgkey=https://repo.openeuler.org/openEuler-22.03-LTS-SP4/everything/x86_64/RPM-GPG-KEY-openEuler [EPOL] name=EPOL baseurl=https://repo.openeuler.org/openEuler-22.03-LTS-SP4/EPOL/main/x86_64/ enabled=1 gpgcheck=1 gpgkey=https://repo.openeuler.org/openEuler-22.03-LTS-SP4/EPOL/main/x86_64/RPM-GPG-KEY-openEuler EOF如果 gpgkey 路径在配置时无法访问或报 404，一个务实的处理方式是把对应的gpgcheck临时改为0。这只是下载阶段的临时措施，目标机安装阶段用的是本地仓库，同样不需要走 gpg 验证。
配置完后执行：
dnf clean all && dnf makecache看到仓库元数据正常拉取，下载机环境就算准备好了。
2.2 用包组锁定UKUI的完整包清单
UKUI 在 openEuler 的仓库里是以包组（group）的形式组织的，这是离线部署最方便的一点，因为包组本身已经帮我们把桌面所需的核心组件圈好了。
先用下面的命令确认包组名称和可用状态：
dnf group list --available | grep -i ukui正常情况下输出里会有一行类似 “UKUI” 或 “UKUI Desktop” 的名字。然后用dnf group info查看组内的具体包清单：
dnf group info "UKUI"输出中会列出 Mandatory Packages、Default Packages 和 Optional Packages 三类。其中 Mandatory 和 Default 是安装桌面必须或默认提供的，必须全部纳入下载范围；Optional 可以根据需求选择，一般初装不需要全部拉下来。
为了后续离线机不依赖包组元数据也能安装，顺手把组内包名导出成清单文件：
dnf group info "UKUI" | awk '/^( [a-zA-Z0-9_+-])/ {print $1}' | sort -u > /root/ukui_pkglist.txt wc -l /root/ukui_pkglist.txt这一步导出的清单后面有重要用途，先在下载机上放好。如果组内包很多导致后续命令行过长，可以用分批方式处理，但通常 UKUI 全组包的数量级在 100~200 个，一次性传给 dnf 问题不大。
2.3 用 dnf download 精确拉取全部依赖
包清单有了，接下来就是核心命令。dnf download本身只下载指定包，--resolve参数会拉取所有依赖，--alldeps保证把各种条件下的依赖也纳入，--destdir指定输出目录。
mkdir -p /root/ukui-pkgs cd /root/ukui-pkgs cat /root/ukui_pkglist.txt | xargs -n 50 dnf download --resolve --alldeps --destdir=/root/ukui-pkgs这里用xargs -n 50分批传入包名，避免包太多时单条命令超长。每一批下载时 dnf 都会解析该批包及其依赖，所以即便分成多批，最终目录里也会包含完整依赖链。
执行过程中留意 dnf 的输出。如果某个包反复提示“没有可用软件包”，大概率是仓库没配全，需要回到 EPOL 仓库检查；如果提示依赖冲突，可能是系统已有某些旧版本包，可以在命令里加--allowerasing，让 dnf 在解析时能替换冲突包。
下载结束后统计一下：
ls /root/ukui-pkgs/*.rpm | wc -l同时把包清单再检查一遍，确认目标包都出现了。目录里可能混入一些非 UKUI 组但属于运行依赖的包，这完全正常，不要手动删除。唯一需要留意的是是否出现.i686等多架构包。在 x86_64 机器上，某些基础库的 32 位变体会作为依赖被拉进来，留着无妨，不用特殊处理。
这里有个很容易被忽略的操作：除了 rpm 包本身，还得把 EPOL 仓库的组元数据（comps.xml）一起保存下来。后面离线机上要能识别“UKUI”这个包组，依赖的就是这份文件。获取方式很简单：
BASE=https://repo.openeuler.org/openEuler-22.03-LTS-SP4/EPOL/main/x86_64/ curl -s $BASE/repodata/repomd.xml | grep comps从输出中获取 comps 文件的真实文件名，然后下载：
curl -s -o comps.xml $BASE/repodata/<实际文件名>将这个comps.xml放到/root/ukui-pkgs/目录下，后面createrepo时要用到。
2.4 打包传输与校验环节
下载目录里的所有内容都要原样传到离线机。传输介质可以是 U 盘、移动硬盘，也可以是两块网卡之间的直连。不管用什么方式，我都建议在打包前做一次校验，防止拷贝过程中出现 rpm 损坏导致安装时报错。
在下载机上生成校验文件：
cd /root/ukui-pkgs sha256sum *.rpm > CHECKSUMS.txt然后打包：
cd / tar -czf /tmp/ukui-pkgs.tar.gz /root/ukui-pkgs拿到目标机上解压后，可以用sha256sum -c CHECKSUMS.txt验证一遍。这一步看似多余，实际非常值得。有一次我用 U 盘拷贝，中途文件系统有坏块，导致两个 rpm 损坏，安装时 dnf 提示“包校验失败”，排查了半天才找到原因。提前做校验能把这类问题挡在开始阶段。
目标机上建议把解压目录放在/opt/ukui-pkgs，路径固定下来，后面配置仓库文件时直接用。解压命令：
mkdir -p /opt/ukui-pkgs tar -xzf /tmp/ukui-pkgs.tar.gz -C /opt ls /opt/ukui-pkgs/*.rpm | wc -l数量与下载机一致，就说明传输完整。
3. 离线机上的仓库创建与UKUI安装
3.1 在下载机上预先生成仓库元数据
离线机上不一定预装createrepo工具，所以一个实用的经验是：在联网下载机上就把仓库元数据生成好，随包一起带走。目标机只需要配置 repo 文件，不需要额外安装任何工具。
在下载机/root/ukui-pkgs目录下执行：
cd /root/ukui-pkgs createrepo_c -g comps.xml .-g comps.xml这个参数很关键，它把前面保存的包组信息写入仓库元数据。这样目标机用dnf group list才能看到“UKUI”这个包组，而不是只能逐个安装 rpm。如果你在目标机上执行dnf group list找不到组，十有八九是这步的组信息没有生成成功。
执行完后，/root/ukui-pkgs/repodata/目录会出现在包目录里。这个目录必须和 rpm 包一起打包传输，不要落下。如果已经按前文流程打包了，确认tar.gz里包含repodata目录即可。
3.2 目标机的repo配置与包组识别
在目标机上，先备份并禁用系统自带的远程仓库，否则 dnf 每次做缓存都会尝试连外网，超时时间很长，白白浪费时间：
mv /etc/yum.repos.d/openEuler.repo /etc/yum.repos.d/openEuler.repo.bak然后新建一个本地仓库配置：
cat > /etc/yum.repos.d/local-ukui.repo <<'EOF' [local-ukui] name=Local UKUI Repository baseurl=file:///opt/ukui-pkgs enabled=1 gpgcheck=0 EOF这里gpgcheck=0是故意的。本地仓库里的 rpm 包虽然是官方下载的，但目标机可能没有导入过 openEuler 的 GPG 公钥，gpgcheck=1会校验签名失败。如果对包来源有严格要求，可以在目标机上先导入公钥再开启校验，但内网离线场景下为了稳妥和效率，我建议直接关掉校验。
刷新缓存：
dnf clean all && dnf makecache接下来验证包组是否被正确识别：
dnf group list --available | grep -i ukui如果能看到 UKUI 相关组，恭喜，仓库配置成功了。如果看不到，先检查/opt/ukui-pkgs/repodata是否存在，再检查createrepo_c -g comps.xml是否真的执行过。
3.3 dnf group install 安装及依赖冲突处理
包组可以识别，安装就简单了：
dnf group install -y "UKUI" --allowerasing--allowerasing是内网安装中很实用的参数。因为目标系统可能已经带了某些与 UKUI 组件冲突的基础包，开启这个参数后 dnf 会替换冲突项而不是直接失败。但要注意，这并不意味着可以随意使用--skip-broken，后者会跳过无法解决的依赖，导致桌面装一半缺组件，后患无穷。
如果 dpkg 包组方式遇到问题，可以用前面导出的包清单作为后备方案：
dnf install -y $(cat /root/ukui_pkglist.txt) --allowerasing安装过程中如果输出“没有可用软件包”的提示，定位思路是回到下载机上确认该包是否真的存在于仓库中，而不是立刻换方案。很多时候只是某个包在 SP4 版本中改了名字，需要在下载机上重新查询并补充下载。
安装耗时看机器性能，一般 5~15 分钟。结束后验证一下 UKUI 的核心包是否都已落地：
rpm -qa | grep -i ukui | head -n 203.4 设置图形启动目标与显示管理器
UKUI 装完后，系统默认还在multi-user.target，重启后依旧只能进命令行。需要手动切换到图形目标：
systemctl set-default graphical.target systemctl get-default输出应该是graphical.target，到这里才算真正让系统知道“下次启动要进桌面”。
接着处理显示管理器。UKUI 在 openEuler 上通常搭配 lightdm，确认是否已经安装并启用：
systemctl status lightdm如果提示服务不存在，先从本地仓库安装：
dnf install -y lightdm systemctl enable lightdm --now到这里可以重启了：
reboot重启后应该能看到登录界面。如果仍然卡在字符界面，或者登录后黑屏，就进入下一节的处理流程。
4. 装完不等于完事：验证、网络与显示三大问题
4.1 怎么判断桌面真的可用
重启后如果直接看到图形登录界面，说明基本成功。但如果还在命令行界面，先不要急着重装，按下面顺序排查。
先看默认目标是否真的切换了：
systemctl get-default再看显示管理器是否运行中：
systemctl status lightdm journalctl -u lightdm -n 50如果 lightdm 根本没起来，看日志里有没有明确报错。最常出现的是缺少某个 Xorg 相关包，或者是配置文件里的 Session 路径不对。可以先手动执行一次startx来测试底层 X 服务是否正常：
startx如果startx能启动一个简单的 X 环境，说明 Xorg 本身没问题，问题多半在 lightdm 或 UKUI 会话的集成上。如果startx都失败，看/var/log/Xorg.0.log，里面会有显卡驱动或显示初始化失败的详细线索。虚拟机上最常见的情况是缺少xorg-x11-drv-*相关的驱动包，可以在下载机上把xorg-x11-drv-*系列也拉下来带进去补装。
4.2 虚拟机里“没有连接以太网”怎么修复
很多网友问过 openEuler 装进虚拟机后没有网络的问题。尤其在这个离线场景下，目标机如果连局域网都不通，后续文件传输、远程管理都会很麻烦。
首先要明确一个现象：新建虚拟机时默认只创建了“有线连接”的配置，但网卡未必被 NetworkManager 接管。在换好网卡驱动的情况下，先用nmcli查看设备状态：
nmcli device status如果设备状态是 “disconnected”，说明网卡存在但连接未激活，最简单的处理是：
nmcli device connect ens33接口名请按实际情况替换，可能是 ens3、ens160、eth0。执行后nmcli device status应该变成 “connected”。
如果网卡设备本身就没显示，则要检查虚拟机的网络适配器设置——VMware 里要保证“已连接”复选框被勾选，VirtualBox 里要在“设置-网络”中启用“连接网线”。
对需要固定 IP 的场景，直接编辑对应网卡配置文件：
vi /etc/sysconfig/network-scripts/ifcfg-ens33关键字段：
BOOTPROTO=none IPADDR=192.168.1.100 PREFIX=24 GATEWAY=192.168.1.1 DNS1=192.168.1.1 ONBOOT=yes注意ONBOOT=yes必须写，否则重启后网卡不会自动启用。生效：
nmcli con reload nmcli con up ens334.3 中文字体、输入法与显示分辨率的补充处理
离线装完 UKUI，最容易遭遇的“看起来有问题”场景是中文全部显示成方块。原因很简单：最小化系统没有安装中文字体，桌面环境的中文渲染自然无从谈起。这个在下载机上准备包时需要额外带上中文字体包，比如wqy-zenhei、wqy-microhei、fonts-noto-cjk。如果前面没有拉取，回到下载机单独下载这些包再补装即可。
dnf download --resolve --destdir=/root/ukui-pkgs wqy-zenhei wqy-microhei fonts-noto-cjk createrepo_c /root/ukui-pkgs重新打包传到目标机，然后：
dnf install -y wqy-zenhei wqy-microhei fonts-noto-cjk输入法方面，UKUI 默认可能带 ibus，但没有中文输入引擎，顺手把ibus-libpinyin或fcitx5-chinese-addons也装上。我个人建议使用 fcitx5，候选词质量好一些，GTK/Qt 应用兼容性也不错。
分辨率异常也是虚拟机的常见问题。VMware 平台装open-vm-tools即可：
dnf install -y open-vm-tools systemctl enable vmtoolsd --nowVirtualBox 则需要挂载增强功能 ISO，安装virtualbox-guest-additions。装完重启后分辨率就能正常跟随窗口大小变化。
5. 版本对应、架构差异与复盘心得
5.1 SP3与SP4的包不能混用
看到标题里的 SP4，提醒一个容易踩的坑：不同 SP 版本的 rpm 包不能想当然地混用。SP3 和 SP4 之间，底层基础库（glibc、openssl、systemd 等）很可能存在版本差异，你从 SP3 仓库拉下来的包拿到 SP4 系统上，安装时会直接报依赖冲突或不满足条件。
所以做离线包准备时，目标机是哪个 SP 版本，下载机就严格用哪个 SP 版本的仓库。不要为了省事在 SP3 上下载后再拿到 SP4 上试，结局基本都是浪费一个晚上。
如果真的已经踩进去了，最快的解决方式是把目标机的/etc/yum.repos.d/改回官方源（如果有内网镜像），在线安装；如果完全没有网，只能重新在对应版本的仓库上抓包再来一遍。
5.2 x86_64之外的架构做法
整条流程在 aarch64 架构上同样成立，命令几乎完全一致，只需要把仓库地址中的x86_64替换成aarch64即可。需要注意几点：下载机的架构必须与目标机一致；包不能跨架构混用，aarch64的包在x86_64上装不了；部分 UKUI 组件在 ARM 平台上的依赖可能略有差异，如果dnf group info看到 Optional 包列表不同，以实际输出为准。
如果你是做嵌入式开发，跑在 RK3588 这类 ARM 板子上，只要内核支持 framebuffer 或 DRM 驱动，UKUI 桌面是可以正常起来的，但尽量用系统自带的内核和驱动，别盲目升级内核，否则显示服务可能起不来。
5.3 几条真正值得记住的经验
复盘整条流程，我总结出几个不算复杂但很关键的细节。
第一，createrepo这步一定要在联网下载机上做，并且把 comps.xml 组信息带进去。目标机没有createrepo工具，等你到了离线环境才发现装不了、需要补工具时，整个链路就被打断了。
第二，目标机的官方 repo 文件要第一时间移走。哪怕你已经配置了本地仓库，只要官方源还开着，dnf makecache或安装时某个依赖解析都会去尝试访问外部网络，每次超时等几十秒，整场安装会被拖得很痛苦。
第三，rpm 包校验文件CHECKSUMS.txt不要省。传输介质不一定是可靠的，尤其是 U 盘拷贝大文件时可能出现静默损坏。多花两分钟做校验，能帮你省掉在目标机上反复排查“为什么安装报错”的大量时间。
第四，package 目录不要删。下载机上的/root/ukui-pkgs完整保留，下次再有同类机器需要装桌面，直接把这个目录打包带走，配置好 repo 后一条dnf group install就完成，省掉了全部重新下载的流程。
我在实际部署中通常会把这类离线包目录归档在服务器或网盘里，标注好对应的系统版本和架构。后面再遇到“内网机器要装桌面”的需求，基本成了复制粘贴的事。UKUI 的离线部署并不神秘，本质就是提前把依赖算好、把组信息带全、在目标机上搭一个本地源，然后让 dnf 自己完成剩下的事情。按这条链路走下来，内网桌面的部署会比你想象中顺很多。
