登录超时：
ssh登录有问题
重新启动构建时出现这个错误
登录报错
答案内容由AI生成，仅供参考：
总结
| 问题 | 原因 | 建议 |
|---|---|---|
| 登录超时 | 系统未完全启动 | 等待 3~5 分钟，观察启动日志 |
| SSH 被拒绝 | 端口未转发或 SSH 未启动 | 检查 netstat 和 telnet |
| 账号密码错误 | 使用非默认凭证 | 使用 Administrator / Admin@90000 |
| 频繁失败 | 构建环境异常 | 清理 Conan 缓存，重新构建 |
最终建议：
使用标准流程重建环境：
conan remove "*"
bingo build -sc qemu
python3 build/works/packet/qemu_shells/vemake_1711.py
等待日志出现 bmc has successfully started 后再尝试登录。
如仍无法解决，建议上传完整日志以进一步分析。
点击此处查看详细分析解答
QEMU 仿真环境登录问题分析与解决方案
根据您提供的信息，您在使用 QEMU 仿真环境时遇到了 账号密码错误、登录超时以及 SSH 连接被拒绝 的问题。以下是针对这些问题的详细分析和解决方案。
问题现象总结
-
Web 登录超时卡死：
localhost login: localhost login: Login timed out after 60 seconds. -
SSH 连接失败：
ssh_exchange_identification: Connection closed by remote host -
可能伴随 GLib 错误日志：
(process:2327): GLib-CRITICAL **: g_source_set_callback_indirect: assertion 'source != NULL' failed
正确的登录方式（确认基础配置）
默认账号密码（适用于 openUBMC QEMU 环境）：
| 登录方式 | 地址 | 端口 | 用户名 | 密码 |
|---|---|---|---|---|
| SSH | localhost |
10022 |
Administrator |
Admin@90000 |
| Web | https://localhost |
10443 |
Administrator |
Admin@90000 |
| Telnet | localhost |
10023 |
- | - |
Administrator / Admin@90000
常见原因及解决方案
1. QEMU 启动未完成，服务尚未就绪
- 现象：SSH 或 Web 登录提示超时或连接被关闭。
- 原因：QEMU 虽已启动，但内部服务（如
iam、nginx、ssh daemon）未完全初始化。 - 解决方案：
- 等待 3~5 分钟后再尝试登录。
- 检查是否看到如下启动完成标志日志：
notify security core that bmc has successfully started
ssh Administrator@localhost -p 10022成功的前提是 QEMU 内部系统已完全启动。
2. SSH 服务未启动或网络转发异常
- 现象：
ssh_exchange_identification: Connection closed by remote host - 可能原因：
- QEMU 的 Slirp 网络栈失败，导致端口转发失效。
- SSH 守护进程未正常拉起。
- 宿主机与 Guest 间的端口映射配置错误。
解决方案：
(1) 检查端口映射配置
确保 QEMU 启动时正确映射了端口。常见配置如下：
"mapports": {
"ssh": 10022,
"https": 10443,
"ipmi": 10623,
"telnet": 10023
}
- 表示：Host 的
10022→ Guest 的22（SSH 默认端口）
(2) 验证端口监听状态
在宿主机执行：
netstat -tulnp | grep 10022
# 或
lsof -i :10022
如果无输出，说明 QEMU 未成功绑定端口，请重新启动。
(3) 尝试 Telnet 测试基础连接
telnet localhost 10022
- 若连接立即断开 → 端口服务未就绪或崩溃
- 若能连接 → 可能是认证问题
3. 系统资源不足或性能瓶颈导致启动缓慢
- 现象：启动时间极长、登录卡顿、超时
- 原因：QEMU 对宿主机性能敏感（尤其是内存和 CPU）
- 参考建议（来自社区 FAQ）：
“目前qemu受电脑配置影响很大，启动失败哪个日志因为iam没有起来，没有办法登录”
解决方案：
- 建议宿主机至少具备：
- CPU ≥ 8核
- 内存 ≥ 8GB 分配给 QEMU
- 修改
config.json提高性能配置：
"qemu_cfg": {
"core_num": 8,
"memory": 8
}
- 避免在低配机器上运行复杂仿真。
4. IAM / Account 服务未启动导致认证失败
- 关键点：即使系统启动，若
iam服务未运行，则无法进行任何登录。 - 判断依据：
- 成功日志中应包含：
component[iam] is detected in the environment - 若缺失，则可能是仿真镜像损坏或启动失败。
- 成功日志中应包含：
解决方案：
-
重新生成镜像并清理缓存：
# 清理 conan 缓存 conan remove "*" # 重新构建 bingo build -sc qemu -
使用官方推荐脚本启动：
python3 build/works/packet/qemu_shells/vemake_1711.py
5. Docker / Conan 环境问题（如自建镜像）
- 若您使用的是自定义 Docker 镜像，可能存在：
- SSH 服务未安装
busybox或openssh-server缺失- 文件权限异常
解决方案：
在容器内手动启动 SSH 服务（适用于调试）：
service ssh start
并确认 /etc/ssh/sshd_config 中允许 root 登录：
PermitRootLogin yes
PasswordAuthentication yes
6. GLib 断言错误说明
(process:2327): GLib-CRITICAL **: g_source_set_callback_indirect: assertion 'source != NULL' failed
- 影响范围：该错误多见于 Lua 或 Snlua 子系统，在
vnc_proxy等组件初始化阶段出现。 - 是否致命？非致命警告，不影响核心服务运行，但建议确认
vnc_proxy是否正常启动：netstat -anp | grep :5900
推荐排查流程
| 步骤 | 操作 | 目的 |
|---|---|---|
| 1 | 等待 QEMU 完全启动（3~5分钟） | 排除服务未就绪 |
| 2 | 检查 telnet localhost 10022 是否通 |
判断端口是否开放 |
| 3 | 查看日志中是否有 iam 组件检测日志 |
确认认证服务存在 |
| 4 | 使用标准命令重新构建：bingo build -sc qemu |
排除构建问题 |
| 5 | 使用官方 vemake_1711.py 启动 |
排除启动脚本问题 |
| 6 | 检查宿主机资源（CPU/内存） | 排除性能瓶颈 |
| 7 | 清理 Conan 缓存并重试 | 解决依赖包污染 |
成功连接示例
SSH 登录：
ssh Administrator@localhost -p 10022
输入密码：Admin@90000
成功后显示命令行提示符，可执行
lsprop、getprop等命令。
Web 登录：
浏览器访问：
https://localhost:10443
参考资料来源
- [Qemu相关FAQ]：明确指出 SSH 和 IPMI 启动快于 Web，建议等待 Nginx 拉起
- [【教学培训篇】体验openUBMC]：提供默认账号密码及启动完成标志
- [Docker开发环境搭建]：说明端口映射关系
- [Qemu使用指南]：解释
mapports配置含义 - [QEMU 仿真与 BMC 业务开发指南]：指导 SSH 和 Web 登录方式
总结
| 问题 | 原因 | 建议 |
|---|---|---|
| 登录超时 | 系统未完全启动 | 等待 3~5 分钟，观察启动日志 |
| SSH 被拒绝 | 端口未转发或 SSH 未启动 | 检查 netstat 和 telnet |
| 账号密码错误 | 使用非默认凭证 | 使用 Administrator / Admin@90000 |
| 频繁失败 | 构建环境异常 | 清理 Conan 缓存，重新构建 |
最终建议：
使用标准流程重建环境：
conan remove "*"
bingo build -sc qemu
python3 build/works/packet/qemu_shells/vemake_1711.py
等待日志出现 bmc has successfully started 后再尝试登录。
如仍无法解决，建议上传完整日志以进一步分析。
qemu受限于性能问题，需要高性能的机器，一般情况下，跑10min，稳定了之后可以正常进入