// 此模板仅供参考，如果不适用可以修改
问题描述
在使用脚本启动QEMU时，日志一直重复下面这几行，一个多小时都没有继续往下执行：
2023-08-15 09:20:51.683715 maca NOTICE: base.lua(396): monitor component web_backend added, service: bmc.kepler.web_backend
2023-08-15 09:20:52.672757 maca NOTICE: base.lua(396): monitor component redfish added, service: bmc.kepler.redfish
2023-08-15 09:20:53.928048 maca NOTICE: base.lua(396): monitor component dcmid added, service: bmc.kepler.dcmid
pcie_card.json change…
pcie_nvme.json change…
连接SSH也没有成功。
应该怎么成功启动QEMU
环境信息
答案内容由AI生成，仅供参考：
QEMU启动卡在"pcie_nvme.json change…"且SSH无法连接的排查与解决
根据您提供的问题描述和现有知识库信息，这可能是QEMU启动过程中组件初始化未完成或网络（Slirp）配置异常导致的。以下是结合已知案例的分析与建议：
问题关联分析
-
日志停滞原因
- 日志中持续出现
pcie_nvme.json change...，与知识库中 Pcie Device 在QEMU仿真环境下无法自发现的问题相关。QEMU环境加载PCIe设备失败时，可能导致相关组件（如 soctrl、network_adapter、bmc_soc）启动检查无法完成，从而卡住启动流程。
- 同时，SSH连接失败可能由 Slirp网络组件发送报文失败（ret: -1） 造成，该问题在类似案例中表现为"qemu启动后ssh和web无法连接"。
-
已知类似案例
- 知识库中有案例：
qemu-system-aarch64-release: Slirp: Failed to send packet, ret: -1，伴随 StartupCheck failed 及 bmc.kepler.event 服务未提供等错误。这与您的现象高度相似。
建议排查步骤
-
检查并清理构建缓存
保持默认config文件内容不变，删除manifest temp目录和output目录后重新拉起QEMU。知识库FAQ指出此操作"此时能够顺利拉起qemu"。
-
确认网络服务状态
-
升级或重装网络依赖
针对Slirp网络问题，可尝试：
- 升级
libslirp-dev 版本。
- 重新生成QEMU包：
bingo build -sc qemu。
- 确认RTOS版本无异常（
ls -l /opt/RTOS）。
-
关注组件适配状态
- 知识库指出
soctrl、bmc_soc 等组件在QEMU中尚未适配，可能导致启动检查反复失败。若日志中伴随"StartupCheck failed"，可检查是否有组件依赖缺失（如 bmc.kepler.devmon 服务）。
注意事项
- QEMU的SSH和IPMI启动通常会比Web界面更快，Web无法连接往往只是nginx尚未拉起，可稍候重试。
- 若清理缓存后仍无法解决，建议比对当前环境与知识库中已知问题案例（如"qemu启动后ssh和web无法连接"）的详细日志，进一步定位具体报错组件。
说明：由于知识库未提供针对 pcie_nvme.json change... 停滞问题的直接解决方案，以上建议综合了QEMU启动常见故障的排查经验。若上述方法无效，可能需要提供更完整的QEMU启动日志（包括 framework.log 或 maca 日志）以便进一步分析。