openEuler 24.03 安装与虚拟机踩坑记录

本文记录我在 VMware + openEuler 24.03（内核 6.x） 环境下的实际踩坑过程及解决方案和一些其他知识

问题一：虚拟机无法启动（内核版本过高）

1. 问题现象

在 VMware 中导入并启动 openEuler 24.03 安装好的虚拟机后，出现无法正常开机的情况，表现为：

• 虚拟机直接报错退出，或
• 启动到一半失败

2. 原因分析

• openEuler 24.03 使用 Linux 6.x 内核
• 我原先使用的 VMware 版本较低，仅支持到 Linux 5.x 内核
• 虚拟化平台对新内核支持不足，导致无法正常引导

3. 解决方案

升级 VMware 至较新版本（支持 Linux 6.x 内核）

升级完成后：

• 虚拟机可以正常启动
• openEuler 安装流程无异常

经验结论：

• 在使用新发行版（openEuler / Ubuntu 新 LTS）前，一定要确认虚拟化平台对内核版本的支持情况。

问题二：系统启动后只有 lo 网卡，物理网卡未显示

1. 问题现象

系统启动成功后，执行：

ip a

结果中：

• 只有 lo（回环接口）
• 没有 ens33 / eth0 等物理网卡
• 无法获取 IP，无法联网

2. 初步排查思路

这是一个典型的“设备存在但网络接口未正常工作”问题，排查顺序如下：

（1）确认 PCI 设备是否存在

lspci | grep -i ethernet

输出显示ens33存在,可见网卡在硬件上是没问题的，可以被识别的

👉 结论：

不是驱动完全缺失，而是虚拟网卡类型与 openEuler 24.03 默认驱动不兼容。

根因定位：VMware 网卡类型不兼容

1. 问题根因

• VMware 默认使用的虚拟网卡类型（如 vmxnet3）

• 在当前 openEuler 24.03 环境下：

  • 内核能看到 PCI 设备
  • 但网络接口未成功创建

2. 解决思路

强制 VMware 使用 openEuler 兼容性更好的网卡类型：e1000e

解决方案

1. 关闭虚拟机

确保 openEuler 虚拟机处于 完全关机状态。

2. 修改虚拟机配置文件（.vmx）

找到对应虚拟机目录下的 .vmx 文件，例如：

xxx.vmx

在文件中新增或修改一行：

ethernet0.virtualDev = "e1000e"

作用说明：

• 明确指定 VMware 使用 e1000e 虚拟网卡
• 该类型在 openEuler / RHEL 系列中兼容性最好

3. 重新启动虚拟机

启动后再次执行：

ip a

可以看到：

• ens33 网卡正常出现
• 网络接口状态为 UP

4. 获取 IP 地址

如果使用 DHCP，可直接：

nmcli device set ens33 managed yes
nmcli device connect ens33

或重启 NetworkManager：

systemctl restart NetworkManager

至此网络恢复正常。

验证结果

ip a
ping baidu.com

当输出可以看到：

• 网卡名称：ens33
• inet 字段下出现 IPv4 地址
• 网络通信恢复

代表网络恢复正常

openEuler 与 CentOS / Ubuntu 的简要对比

openEuler 24.03 中 dnf 启动缓慢的原因分析

在 openEuler 24.03 上执行 dnf 命令时，常出现 3–5 秒的启动延迟。该延迟主要发生在 命令初始化阶段，而非软件包下载阶段。

从实现层面看，dnf 基于 Python 运行，每次启动都需要完成以下流程：

• 插件加载
• 仓库配置解析
• 元数据有效性校验

openEuler 默认启用了较完整的插件体系，并对 仓库签名 和 元数据状态 进行严格检查。这些设计会增加启动时间，但能够显著提升系统的一致性与安全性。

此外，在启动过程中，dnf 会通过 NetworkManager + D-Bus 判断当前网络状态。在虚拟机环境中（如使用 NAT、DHCP，或曾更换网卡类型），网络状态检测可能出现短暂阻塞，从而表现为命令执行前的停顿。 这一现象在以企业级稳定性为目标的 openEuler 中尤为明显。

综合来看，dnf 启动偏慢并非性能问题，而是 openEuler 在包管理阶段对 安全校验 与 网络状态判断 更为严格所带来的结果，属于 设计取向差异，而非异常行为。

不同发行版包管理器行为对比