ssh不支持linux指令，telnet无法连接，升级后固件版本不会变

交流互助区
1

问题描述

ssh不支持linux指令，telnet无法连接，升级后固件版本不会变

环境信息

2603Tag点，VM乌班图24.04.03虚拟机，米尔3093开发板

编译指令

bingo build --build-type release

重现步骤

  1. 最开始尝试使用制作白牌包的方式更换logo等图片信息，一直不正常；

    然后直接通过本地替换的方式：修改build/product/BMC/openUBMC/manifest.yml下的wbd_up_files:的值，并在build/product/BMC/openUBMC/wbd_up_file下添加/修改文件，最终发现Web页面成功替换；

  2. 再次替换build/product/BMC/openUBMC/wbd_up_file发现始终不在生效；接着把代码恢复到clone时的状态（且删除temp、output、/root/.conan2），重新编译、升级发现还是不行；

  3. 在社区查询后，尝试在本地清白牌包（build/product/BMC/openUBMC/wbd_up_file新增CLEAR_ALL空文件，并把conf文件中的name值修改为CLEAR_ALL）如下：

    [File0]

    Name=CLEAR_ALL

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

  4. 后来升级后发现并没有生效，且Telnet无法连接（在此之前是正常的），并且ssh只支持图中的命令，不支持Linux指令

    image
    image469×265 48.4 KB

  5. 在社区提问/查询后发现是编译指令的问题，于是使用bingo build --build-type debug编译后升级，发现依旧没有效果；

  6. 排查后发现每次点击升级后，Web提示升级成功，但固件好像并没有升级成功，而是跑到了可用分区；尝试过保留/不保留配置，结果都一样；尝试可用分区镜像倒换，重启后倒换并未成功；尝试过在ssh回滚，未成功

image
image645×402 29.4 KB

7，在每次更新的时候观察串口，发现部分打印如下：
tar: rootfs_iBMC.img: not found in archive
openUBMC:/->p1970-01-01 00:26:47.773142 maca NOTICE: init.lua(101): stop watchdog timer
Stopping Session c1 of User Administrator…
Stopping Session c2 of User Administrator…
[ OK ] Removed slice Slice /system/modprobe.
[ OK ] Stopped target Multi-User System.
[ OK ] Stopped target Login Prompts.
[ OK ] Stopped target Timer Units.
[ OK ] Stopped start logrotate timer.
[ OK ] Stopped start partition usage monitor timer.
[ OK ] Stopped Daily Cleanup of Temporary Directories.
Stopping alarm service…

尝试代码还原，并删除output temp /root/.conan2 ,重新init ，再次编译，没有报错，升级后还是一样的结果。

总结：

1，当前主要问题是步骤6无法正确升级，在步骤4之前是没有出现这种情况；

2，步骤5中，从社区中看到是–build-type release的问题，导致telnet无法连接，SSH无法使用Linux指令；但在替换logo前用的编译指令一直是bingo build --build-type release，telnet与ssh一直是正常的，为什么？

2

答案内容由AI生成，仅供参考：
总结：Web界面显示的“升级成功”是一个误报。实际上，BMC在尝试写入新固件时（解压rootfs阶段）发生了错误，导致升级失败。系统可能触发了回滚机制，因此版本未发生变化，或者新固件写入不完整导致无法启动。

解决方案与建议

结合上下文中的信息，您的修复路径应该聚焦于使用正确的构建命令和恢复系统环境。

步骤 1：重新构建正确的固件包

  • 编译Debug包：使用以下命令生成一个支持Telnet和完整Linux命令的调试固件包：
    bingo build -b openUBMC -r openubmc_dev -bt debug --stage rc
    或者简写为：
    bingo build -b openUBMC -bt debug -r openubmc_dev

步骤 2：尝试恢复系统到可操作状态

您当前无法通过Web或SSH正常升级，需要利用串口进行恢复。根据 Search Result 4 (BMC固件损坏时恢复环境指导)：

  1. 进入Debug模式：通过串口登录BMC后，立即执行以下命令进入debug/telnet模式以获得root权限：

    /opt/debug/busybox telnet localhost

    （注：根据 Search Result 1，如果telnet命令不可用，请使用 ipmcset -d serialdir -v 1 确保串口不被切走，然后进行下一步）

  2. 上传新固件：通过SFTP或您可用的任何方式（如从OS带内发送），将步骤1编译好的Debug包上传到BMC的 /tmp 目录。

    • 如果OS可用，您也可以使用带内IPMI升级，但根据您的日志，可能需要先启用带内通道。参考 Search Result 1 中的方法。
    • SFTP命令示例：sftp Administrator@<BMC_IP>，登录后 put <your_new_firmware.hpm> /tmp/

  3. 实施分区切换或强制升级：

    • 方案A：切换分区：如果您怀疑当前分区损坏，可以切换到备用分区。
      ipmcset -d rollback
    • 方案B：强制升级：如果分区切换无效，直接使用上传的包进行升级。
      ipmcset -d upgrade -v /tmp/<your_new_firmware.hpm>

  4. 重启BMC：升级完成后，重启BMC以使新固件生效。如果一切顺利，您将登录到一个全新的、功能完整的Debug环境。

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

根据您提供的Context信息，我对您遇到的问题进行了详细分析。您的核心问题可以归纳为以下几点：

  1. SSH不支持Linux指令：SSH登录后只能使用有限命令。
  2. Telnet无法连接：Telnet服务未启动或不可用。
  3. 升级后固件版本不生效：Web提示升级成功，但实际版本未变化。

以下是基于上下文信息的详细解答：

1. SSH不支持Linux指令 & Telnet无法连接

根本原因：您使用的编译指令 bingo build --build-type release 生成了 Release包，而非 Debug包。

  • 知识图谱证据：debug package 实体描述明确指出，“bingo build命令默认生成一个debug包，支持Telnet和扩展命令”。相反，Release包为了生产环境的安全性和稳定性，通常会禁用Telnet和完整的Linux命令集。
  • 文档片段证据 (Doc 1, 6)：
    • 在话题 #6611 中，用户 YMQMKK 明确指出了这一点：“–build-type release出的是release包，用debug包才支持telnet和更多指令”。
    • 在话题 #4527 中，用户 Tzyy_Q_wbdc2 在解决了同样的问题后总结道：“编译时 -bt=debug 出包就是linux终端模式”。

关于您“替换logo前为什么正常？”的疑问：
这很可能是因为您最初在进行logo替换并成功生效时，使用的是同一个 bingo build --build-type release 编译出的固件包。在步骤4之前，系统运行在该固件上，Telnet和SSH功能正常，说明这个Release包可能包含了Telnet服务。问题出现在步骤5，当您为了清除logo而使用 CLEAR_ALL 配置并再次编译升级后，这个新的Release包在编译过程中破坏了或覆盖了与Telnet服务及完整Linux命令支持相关的组件/配置，导致升级后的系统丢失了这些功能。

2. 升级后固件版本不生效 & 打印信息 tar: rootfs_iBMC.img: not found in archive

根本原因：这是一个典型的 固件升级失败 问题，与firmware_mgmt模块执行的Firmware Upgrade Process有关。根据日志，升级过程在解压和写入 rootfs_iBMC.img 时失败。

  • 知识图谱证据：
    • Upgrade Failure 实体描述了多种失败场景，其中提到：“升级过程在特定阶段停滞——例如在I2C固件更新过程中停在15%或47%”。您的日志显示在解压 rootfs 镜像时失败，属于阶段特定错误。
    • Firmware Upgrade 操作实体说明：“Firmware Upgrade过程易因各种因素失败，包括… 解密错误、缓冲区大小不匹配、时序冲突（如与BIOS POST阶段）和错误配置”。
    • Firmware_Upgrade_Failure 概念实体指出：“在某些情况下，该过程看似完成成功，但固件版本仍然不变，表明在感知与实际更新结果之间存在差异”。
  • 文档片段证据 (Doc 4)：
    • 话题 #4493 的日志中，报告了几乎完全相同的错误：
      Failed to search command: /bin/tar xvf /dev/shm/upgrade/rootfs_img.tar.gz -O rootfs_BMC.img
...
Function    execve   : mismatched command    /bin/tar
      这表明BMC内部用于解压固件包的命令/bin/tar不存在或与预期不符。您的日志 tar: rootfs_iBMC.img: not found in archive 指向了固件包本身损坏或解压后的镜像文件与预期不符，导致写入失败。

总结：Web界面显示的“升级成功”是一个误报。实际上，BMC在尝试写入新固件时（解压rootfs阶段）发生了错误，导致升级失败。系统可能触发了回滚机制，因此版本未发生变化，或者新固件写入不完整导致无法启动。

解决方案与建议

结合上下文中的信息，您的修复路径应该聚焦于使用正确的构建命令和恢复系统环境。

步骤 1：重新构建正确的固件包

  • 编译Debug包：使用以下命令生成一个支持Telnet和完整Linux命令的调试固件包：
    bingo build -b openUBMC -r openubmc_dev -bt debug --stage rc
    或者简写为：
    bingo build -b openUBMC -bt debug -r openubmc_dev

步骤 2：尝试恢复系统到可操作状态

您当前无法通过Web或SSH正常升级，需要利用串口进行恢复。根据 Search Result 4 (BMC固件损坏时恢复环境指导)：

  1. 进入Debug模式：通过串口登录BMC后，立即执行以下命令进入debug/telnet模式以获得root权限：

    /opt/debug/busybox telnet localhost

    （注：根据 Search Result 1，如果telnet命令不可用，请使用 ipmcset -d serialdir -v 1 确保串口不被切走，然后进行下一步）

  2. 上传新固件：通过SFTP或您可用的任何方式（如从OS带内发送），将步骤1编译好的Debug包上传到BMC的 /tmp 目录。

    • 如果OS可用，您也可以使用带内IPMI升级，但根据您的日志，可能需要先启用带内通道。参考 Search Result 1 中的方法。
    • SFTP命令示例：sftp Administrator@<BMC_IP>，登录后 put <your_new_firmware.hpm> /tmp/

  3. 实施分区切换或强制升级：

    • 方案A：切换分区：如果您怀疑当前分区损坏，可以切换到备用分区。
      ipmcset -d rollback
    • 方案B：强制升级：如果分区切换无效，直接使用上传的包进行升级。
      ipmcset -d upgrade -v /tmp/<your_new_firmware.hpm>

  4. 重启BMC：升级完成后，重启BMC以使新固件生效。如果一切顺利，您将登录到一个全新的、功能完整的Debug环境。

为什么替换logo前一切正常？

这个问题在上下文中没有直接解释，但可以基于系统工作原理进行合理推断：

  • 初始Release包的完整性：您第一次使用 bingo build --build-type release 编译的包，其Telnet服务和所有必要组件是完整且未被破坏的。
  • CLEAR_ALL 操作的破坏性：当您为了“清白牌包”而使用 CLEAR_ALL 配置，并再次用 bingo build --build-type release 编译时，构建系统可能正确地处理了您的CLEAR_ALL请求，但在此过程中，因为某些构建配置的冲突或变更，意外地影响了与网络服务（Telnet）、shell环境（busybox组件）相关的组件配置，导致生成的Release包功能不完整。
  • 固件升级的异步性：您可能认为之前的升级都成功了，但实际上最后的“CLEAR_ALL”升级过程已经损坏了系统，而您当时没有立刻察觉到，直到重启或后续操作时才暴露问题。

总之，您当前问题的核心在于构建类型和一次失败的固件升级。请按照上述解决方案，使用Debug包并利用串口进行恢复，这是基于上下文信息最可靠的修复路径。

3

1.串口登录也是和ssh一样，不支持linux命令

2.ipmcset -d rollback试过了，不行的

4

ssh是否支持linux命令和出包类型有关，clp壳是不支持linux命令的