qemu启动后ssh和web无法连接

交流互助区
1

// 此模板仅供参考，如果不适用可以修改

问题描述

qemu启动后ssh无法连接，报错：qemu-system-aarch64-release: Slirp: Failed to send packet, ret: -1

2023-08-15 09:20:46.934313 maca ERROR: init.lua(243): [event]StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.event was not provided by any .service files, check count: 17
2023-08-15 09:21:02.030746 maca ERROR: init.lua(243): [event]StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.event was not provided by any .service files, check count: 18
qemu-system-aarch64-release: Slirp: Failed to send packet, ret: -1
qemu-system-aarch64-release: Slirp: Failed to send packet, ret: -1
2023-08-15 09:20:49.106657 maca ERROR: init.lua(243): [event]StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.event was not provided by any .service files, check count: 19
qemu-system-aarch64-release: Slirp: Failed to send packet, ret: -1
2023-08-15 09:21:04.163505 maca ERROR: init.lua(243): [event]StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.event was not provided by any .service files, check count: 20

环境信息

  • 操作系统：Ubuntu 24.04

  • 软件版本：OpenUBMC 7/17主干

  • 硬件配置：wsl

重现步骤

  1. 窗口1启动qemu：/home/workspace/main/manifest# python3 build/works/packet/qemu_shells/vemake_1711.py

  2. 窗口2：ssh -p 10022 Administrator@127.0.0.1

  3. 窗口1打印：qemu-system-aarch64-release: Slirp: Failed to send packet, ret: -1

期望结果

qemu连接功能正常

实际结果

ssh和web都无法连接

尝试过的解决方案

搜索论坛历史问题尝试过几下几种修复手段问题没解决：

1、升级libslirp-dev

2、重新出包: bingo build -sc qemu

3、查看rtos版本，也无异常 /home/workspace/main/manifest# ls -l /opt/RTOS
total 4
drwxr-xr-x 6 root root 4096 Jul 17 11:27 208.11.0

分析结论

未找到问题根因，求助

2

答案内容由AI生成，仅供参考：

解决方案建议（来自上下文）

最直接的解决途径已在社区中验证（见文档块 2 “qemu启动后ssh无法连接” 的最佳答案）：

1. 确认 RTOS 版本

ls -l /opt/RTOS

预期应显示 208（即版本 208.9.0）。如果显示其他版本或不显示，说明版本不匹配。

2. 若 RTOS 版本不正确，执行以下步骤

  • 拉取最新 manifest
    确保您的 manifest 仓库为最新状态（与当前 OpenUBMC 主干匹配）。
  • 清理 conan 缓存
    rm -rf ~/.conan/data/*
  • 重新初始化环境
    python3 init.py
  • 重新构建 QEMU 固件包
    bingo build -sc qemu
  • 启动 QEMU
    python3 build/works/packet/qemu_shells/vemake_1711.py

3. 其他排查项（如 RTOS 已正确）

  • 等待启动完整：Web 访问可能需要 5~10 分钟，尤其是 Nginx 服务启动较慢（参见搜索结果 FAQ）。如果 SSH 可连接但 Web 不通，可稍后重试。
  • 检查端口映射配置：确保 config.json 中的端口设置正确，尤其在 WSL 环境下需要注意宿主机 IP 和端口转发。
  • 检查 Nginx 状态：若 SSH 可登录但 Web 不可用，可通过 SSH 进入容器检查 nginx 是否运行。

分析结论

综合上下文信息，您遇到的 SSH 与 Web 均无法连接 问题最可能的原因是 RTOS 版本不一致导致内核模块加载异常，进而引发 Slirp 网络包发送失败以及关键 D-Bus 服务缺失。升级 libslirp-dev 无法解决此根本问题。

推荐优先执行“方案建议”中的第 2 步，即拉取最新 manifest、清理缓存、重新出包并启动 QEMU。该处理方式已在多个类似案例中成功解决问题（见文档块 2 及搜索结果 FAQ）。若问题依然存在，请提供 ls -l /opt/RTOS 的显示结果以及完整的启动日志，以便进一步定位。

点击此处查看详细分析解答

问题分析

根据您提供的错误日志及上下文信息，QEMU 启动后 SSH 和 Web 均无法连接的现象主要涉及两个核心异常：

  1. Slirp 网络发送失败
    qemu-system-aarch64-release: Slirp: Failed to send packet, ret: -1
    表明 QEMU 的用户态网络组件（Slirp）无法正常发送数据包，直接导致 SSH 等基于网络的连接不可用。

  2. D-Bus 服务注册失败
    StartupCheck failed, error: org.freedesktop.DBus.Error.ServiceUnknown: The name bmc.kepler.event was not provided by any .service files
    表示系统在启动过程中未能找到名为 bmc.kepler.event 的 D-Bus 服务，影响了相关组件的初始化。

可能原因（基于上下文）

从已有的知识库和相似案例中可以推断，这两个错误很可能源于同一根本原因——RTOS 版本与当前编译环境不一致，导致内核驱动或系统服务加载异常。具体关联如下：

  • Slirp 故障
    QEMU 依赖 Slirp 进行用户模式网络传输（见关系 QEMU → Slirp）。当底层 RTOS（实时操作系统）版本与 QEMU 构建时依赖的版本不匹配时，可能导致内核模块（如 x_tables）符号版本冲突，进而使网络驱动无法正常工作，Slirp 发送包失败（见实体 Slirp Network Failure 及文档块 2 中的描述）。

  • D-Bus 服务缺失
    服务启动检查发现 bmc.kepler.event 未注册（实体 Dbus.Error.ServiceUnknown），可能是因为 RTOS 版本不一致导致相关服务文件未正确生成或加载，最终使 StartupCheck 失败（见关系 Dbus.Error.ServiceUnknown → StartupCheck）。

此外，您已尝试升级 libslirp-dev 但问题未解决，这进一步印证了问题不在于单独的库版本，而在于构建环境或固件的一致性。

解决方案建议（来自上下文）

最直接的解决途径已在社区中验证（见文档块 2 “qemu启动后ssh无法连接” 的最佳答案）：

1. 确认 RTOS 版本

ls -l /opt/RTOS

预期应显示 208（即版本 208.9.0）。如果显示其他版本或不显示，说明版本不匹配。

2. 若 RTOS 版本不正确，执行以下步骤

  • 拉取最新 manifest
    确保您的 manifest 仓库为最新状态（与当前 OpenUBMC 主干匹配）。
  • 清理 conan 缓存
    rm -rf ~/.conan/data/*
  • 重新初始化环境
    python3 init.py
  • 重新构建 QEMU 固件包
    bingo build -sc qemu
  • 启动 QEMU
    python3 build/works/packet/qemu_shells/vemake_1711.py

3. 其他排查项（如 RTOS 已正确）

  • 等待启动完整：Web 访问可能需要 5~10 分钟，尤其是 Nginx 服务启动较慢（参见搜索结果 FAQ）。如果 SSH 可连接但 Web 不通，可稍后重试。
  • 检查端口映射配置：确保 config.json 中的端口设置正确，尤其在 WSL 环境下需要注意宿主机 IP 和端口转发。
  • 检查 Nginx 状态：若 SSH 可登录但 Web 不可用，可通过 SSH 进入容器检查 nginx 是否运行。

分析结论

综合上下文信息，您遇到的 SSH 与 Web 均无法连接 问题最可能的原因是 RTOS 版本不一致导致内核模块加载异常，进而引发 Slirp 网络包发送失败以及关键 D-Bus 服务缺失。升级 libslirp-dev 无法解决此根本问题。

推荐优先执行“方案建议”中的第 2 步，即拉取最新 manifest、清理缓存、重新出包并启动 QEMU。该处理方式已在多个类似案例中成功解决问题（见文档块 2 及搜索结果 FAQ）。若问题依然存在，请提供 ls -l /opt/RTOS 的显示结果以及完整的启动日志，以便进一步定位。

3

问题 已经识别，可以暂时在manifest中切换到6月初的版本进行qemu出包和后续工作