openEuler离线安装UKUI桌面：依赖打包与本地仓库搭建全流程

前阵子接了个挺头疼的活一台放在隔离网段里的 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] nameOS baseurlhttps://repo.openeuler.org/openEuler-22.03-LTS-SP4/OS/x86_64/ enabled1 gpgcheck1 gpgkeyhttps://repo.openeuler.org/openEuler-22.03-LTS-SP4/OS/x86_64/RPM-GPG-KEY-openEuler [everything] nameeverything baseurlhttps://repo.openeuler.org/openEuler-22.03-LTS-SP4/everything/x86_64/ enabled1 gpgcheck1 gpgkeyhttps://repo.openeuler.org/openEuler-22.03-LTS-SP4/everything/x86_64/RPM-GPG-KEY-openEuler [EPOL] nameEPOL baseurlhttps://repo.openeuler.org/openEuler-22.03-LTS-SP4/EPOL/main/x86_64/ enabled1 gpgcheck1 gpgkeyhttps://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”这个包组依赖的就是这份文件。获取方式很简单BASEhttps://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] nameLocal UKUI Repository baseurlfile:///opt/ukui-pkgs enabled1 gpgcheck0 EOF这里gpgcheck0是故意的。本地仓库里的 rpm 包虽然是官方下载的但目标机可能没有导入过 openEuler 的 GPG 公钥gpgcheck1会校验签名失败。如果对包来源有严格要求可以在目标机上先导入公钥再开启校验但内网离线场景下为了稳妥和效率我建议直接关掉校验。刷新缓存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关键字段BOOTPROTOnone IPADDR192.168.1.100 PREFIX24 GATEWAY192.168.1.1 DNS1192.168.1.1 ONBOOTyes注意ONBOOTyes必须写否则重启后网卡不会自动启用。生效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 自己完成剩下的事情。按这条链路走下来内网桌面的部署会比你想象中顺很多。