Telnet与shh与串口连接登陆问题

交流互助区
1

2603版本，米尔开发板

出现问题前做了以下操作

1，想要替换登录页面logo等信息，但是使用白牌包制作方式一直没有结果，因此直接进行本地替换

2，修改/home/zhao/zhx/Openubmc/manifest/build/product/BMC/openUBMC/manifest.yml中wbd_up_files:

files:的值

3，修改/home/zhao/zhx/Openubmc/manifest/build/product/BMC/openUBMC/wbd_up_file/filelist.conf文件，添加自己想要的图片，bingo build --build-type release编译，在线升级后发现成功替换了！

4，想要再此更换其他背景图，于是直接替换manifest/build/product/BMC/openUBMC/wbd_up_file下的文件，再次编译升级，结果发现一直不生效！又升级回起始版本（默认背景图等）发现依旧未恢复为默认。（此时串口Telnet与shh都是OK的）

5，查阅社区帖子后，把manifest/build/product/BMC/openUBMC/wbd_up_file/filelist.conf中NAME后面修改为CLEAR_ALL，再次编译升级；
[Basic]

Version=2.00

[Filelist]

FileNum=2

[File0]

Name=CLEAR_ALL

Path=/data/opt/pme/web/htdocs

[File1]

Name=CLEAR_ALL

Path=/data/opt/pme/web/conf
6，升级完成后发现Telnet一直无法连接

image
image715×679 12.5 KB

串口和SSH可以进去，但是显示如下（不正常！）

image
image552×210 4.65 KB

image
image1054×877 44.3 KB

这个界面肯定是不正常的

WEB页面可以正常进入，且可以ping通，尝试过可用分区镜像倒换，未果，也尝试在ssh下执行rollback，未果

image
image464×416 8.74 KB

后续又尝试再次升级、升级至起始版本、保留与不保留配置项更新、恢复出厂设置等，都不行!各路大神，这个该如何解决？

2

答案内容由AI生成，仅供参考：
根据您提供的内容，文中没有明确标有“问题总结”或“结论”等字样的章节。因此，返回空内容。

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

根据您提供的信息和上下文知识库，您遇到的问题（Telnet 无法连接、SSH/串口界面显示异常）很可能是在使用 CLEAR_ALL 命令清除 web 目录文件时，误操作或过度清理，导致系统关键配置文件或启动脚本被一同清除，从而损坏了必要的系统服务。

以下是针对该问题的根因分析和详细修复步骤。

问题根因分析

  1. CLEAR_ALL的破坏性：您在 filelist.conf 中设置的 CLEAR_ALL 指令，其作用是清空指定路径下的所有文件。您指定的路径是 /data/opt/pme/web/htdocs 和 /data/opt/pme/web/conf。
  2. 间接影响Telnet服务：虽然Telnet服务本身不直接依赖这些web目录，但 openUBMC 的系统服务和启动脚本是高度耦合的。清除这些目录可能损坏了：
    • 公共动态库或符号链接：Web 目录可能包含其他服务（包括 telnet 的 BusyBox 组件）所需的链接或依赖文件。
    • 系统配置文件：/data/opt/pme/web/conf 被清除，可能导致依赖于这些配置的 bmc_network 或 serialdir 等服务状态异常，进而影响 telnet 的正常启动或串口切换逻辑。
  3. 印证现象：
    • SSH/串口能进但显示异常：说明基本网络和内核是正常的，但用户态的 shell 环境或初始化脚本（如 .profile, /etc/profile）被破坏或找不到关键配置，导致显示乱码或行为异常。
    • Telnet彻底失效：telnet 服务（如 busybox telnetd）可能因为缺少依赖文件、配置错误或服务启动脚本被损坏而无法启动。
    • 回滚/升级无效：因为问题出在数据分区（由 CLEAR_ALL 指令直接修改的存储区域），而双分区回滚或常规升级（未指定 CLEAR_ALL）通常不覆盖此区域，所以无法修复。

解决方案（按优先级排序）

方法一：通过串口进入系统内部诊断与修复（最推荐）

您提到 “串口可以进去” ，这是当前唯一的修复突破口。请严格按以下步骤操作：

  1. 保持串口连接并快速登录：BMC启动后，迅速通过串口输入用户名和密码登录系统。
  2. 进入本地Telnet调试模式：
    • 在串口 shell 中，立即执行以下命令，强制进入本机的 telnet 会话（即使网络telnet服务挂了，本地BusyBox可能仍可用）：
      /opt/debug/busybox telnet localhost
    • 如果上述命令失败（报错或卡死），请尝试：
      /data/home/busybox1711 telnet localhost
    • 如果还是失败，说明busybox组件本身被损坏，需要看下一步。
  3. 强制将串口保持在BMC侧：
    • 如果串口被自动切走，请在串口日志出现的瞬间快速输入：
      ipmcset -d serialdir -v 1
    • 这个命令可以将串口输出固定到 BMC 侧，防止被 OS 抢占，以便持续操作。
  4. 检查关键服务日志：
    • 登录后，查看核心框架日志，寻找具体的报错原因：
      cat /var/log/framework.log
    • 同时查看通用调试日志：
      cat /var/log/app.log
    • 重点关注日志中关于 iam、account 或 bmc_network 服务的报错。
  5. 修复受损目录（关键一步）：
    • 假设您能进入 shell（即使是残缺的），请尝试手动重建被 CLEAR_ALL 删掉的目录和关键文件。您可能需要从另一台正常同版本设备上获取这些文件，或从 openUBMC 的镜像/源码中提取。
    • 示例（请根据实际日志和报错决定具体文件）：
      # 重建web的基础目录（可能需要创建简单的index.html或占位文件）
mkdir -p /data/opt/pme/web/htdocs
mkdir -p /data/opt/pme/web/conf
# 从另一个正常节点或cpio包中恢复关键配置文件
# 例如：scp user@normal_bmc:/data/opt/pme/web/conf/some_config /data/opt/pme/web/conf/
  6. 最终手段 - 强制重启服务：
    • 完成文件恢复后，重启受影响的服务：
      # 重启所有服务（谨慎使用，可能中断当前会话）
systemctl reboot
# 或者只尝试重启特定服务
# systemctl restart bmc_network
# systemctl restart telnet  (如果存在该服务名)

方法二：通过烧录/刷机方式完全恢复（备用方案）

如果方法一无法进入系统或修复失败，则必须进行底层芯片级恢复。

  1. 直接烧录：按照社区的标准流程（如使用烧录器或特定脚本）烧录一个全新的、已知可用的 openUBMC 镜像（建议使用与您板型匹配的官方debug版镜像）。
  2. 从Uboot切换分区：
    • 给BMC重新上电，在串口出现提示时（如“Hit any key to stop autoboot”），迅速按键进入 Uboot 命令行。
    • 使用 Uboot 命令手动切换到备用分区（通常是 Area 1 或 Area 0），然后从该分区启动系统。
      # 示例（具体命令需参考您的Uboot版本）
setenv bootargs '... root=/dev/mmcblk0p3 ...'  # 指向另一个分区
boot

总结与建议

您遇到的CLEAR_ALL操作已经造成了文件系统层面的破坏，常规的在线升级和分区切换无法修复数据分区的内容。

  • 核心思路：利用仅存的串口通道，通过busybox工具强行进入系统，手动恢复被删除的Web目录及其依赖文件。 这是最快速、最彻底的软件修复方案。
  • 长期建议：在尝试修改系统文件结构时，强烈建议先在QEMU仿真环境中进行测试，确认操作安全后再在物理板上执行。QEMU环境下，您可以通过 ssh Administrator@localhost -p 10022 和 /data/home/busybox_x telnet localhost 进行测试，且支持快照回滚，极大地降低了风险。

请立即通过串口登录，优先尝试方法一进行诊断和手动修复。

4

openUBMC:/->/opt/debug/busybox telnet localhost
COMMAND NOT SUPPORTED
openUBMC:/->
命令基本都是不支持！

5

–build-type release出的是release包，用debug包才支持telnet和更多指令。