报废失败原因跟踪 SP升级咨询

[ChenMinjun]

如下图，在资产报废页面中，只有Disk是报废失败，请问是什么原因？
以下是\dump_info\LogDump\app.log的相关日志片段，没有涉及到Disk报废失败的打印。

026-01-12 09:10:43.594402 metric_analyzer NOTICE: optical_obj_manager.lua(220): Initialization of optical modules finished.

2026-01-12 09:10:45.573255 bmc_core ERROR: lldp_proc.c(318): Can’t find port name from LLDP

2026-01-12 09:10:45.652321 power_mgmt NOTICE: pmbus_GW_CRPS.lua(235): Power1 work mode: 1 [repeated 146 times in 301s from 2026-01-12 09:05:44.886875 to 2026-01-12 09:10:45.652321]

2026-01-12 09:10:45.771606 oms NOTICE: task_mgmt.lua(418): Update task[Id: 1776787389, StartTime: 2026-01-12T09:10:21+08:00, Progress: 80, State: Running] successfully

2026-01-12 09:10:45.872470 oms NOTICE: task_mgmt.lua(418): Update task[Id: 1776787389, StartTime: 2026-01-12T09:10:21+08:00, Progress: 85, State: Running] successfully

2026-01-12 09:10:45.975251 oms NOTICE: task_mgmt.lua(418): Update task[Id: 1776787389, StartTime: 2026-01-12T09:10:21+08:00, Progress: 100, State: Completed] successfully

2026-01-12 09:10:46.471101 power_mgmt NOTICE: pmbus_GW_CRPS.lua(235): Power2 work mode: 1 [repeated 146 times in 302s from 2026-01-12 09:05:44.685604 to 2026-01-12 09:10:46.471101]

2026-01-12 09:10:50.569671 power_mgmt NOTICE: pmbus_GW_CRPS.lua(235): Power4 work mode: 0 [repeated 144 times in 301s from 2026-01-12 09:05:49.371233 to 2026-01-12 09:10:50.569671]

2026-01-12 09:10:56.570432 product_mgmt NOTICE: task_mgmt.lua(418): Update task[Id: 2428800929, StartTime: 2026-01-12T09:07:31+08:00, Progress: 0, State: Exception] successfully

2026-01-12 09:10:56.570739 product_mgmt NOTICE: retire.lua(499): Retire system finished

2026-01-12 09:11:03.595759 compute ERROR: cpu_object.lua(323): update cpu2 mem power failed: 195, nil. [repeated 8 times in 291s from 2026-01-12 09:05:24.805618 to 2026-01-12 09:10:15.622293][flush]

2026-01-12 09:11:03.596653 compute ERROR: cpu_object.lua(323): update cpu1 mem power failed: 195, nil. [repeated 7 times in 258s from 2026-01-12 09:05:55.328182 to 2026-01-12 09:10:13.570241][flush]

环境信息

• 操作系统：[如 Ubuntu 24.04]

• 软件版本：[如 OpenUBMC2509]

• 硬件配置：[如 CPU、内存等]

重现步骤

1. [第一步]
   BMC WebUI点击“资产报废”
   查看结果报废中断，其中bmc和bios都返回报废成功，但Disk报废失败。

2. [第二步]

在cli中执行ipmcset -t maintenance -d retiresystem -v 0，但依然
报废中断，其中bmc和bios都返回报废成功，但Disk报废失败。

期望结果

报废成功

[ubmc_assistant (openUBMC_Assistant)]

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

Disk报废失败原因分析

根据您提供的信息，在资产报废过程中，BIOS和BMC报废成功，但Disk报废失败。然而，从提供的app.log日志片段中，并未发现与Disk报废直接相关的错误记录。

以下是基于现有信息的综合分析：

---

一、日志分析结论

当前日志未包含关键线索

• 提供的app.log内容中：
  • 有product_mgmt NOTICE: retire.lua(499): Retire system finished，表明整个“系统报废”流程已结束。
  • 有多个组件的例行操作和非致命错误（如LLDP端口未找到、电源模式通知等）。
• 但是没有任何关于存储设备（Disk/Storage）在报废过程中失败的日志打印。
• 特别是缺少如 failed to retire disk、storage secure erase failed、NVMe sanitize failed 等关键字。

结论：当前app.log不足以定位Disk报废失败的根本原因。

---

二、可能的根本原因（基于openUBMC/IBMC系统行为推断）

由于Disk报废涉及数据安全擦除操作，失败通常由以下几类原因导致：

1. 安全擦除命令执行失败（Secure Erase / Sanitize）

• Disk报废的核心是执行安全擦除，确保数据不可恢复。
• 对于NVMe磁盘，调用Sanitize命令；SATA/SAS使用SECURE ERASE。
• 可能问题：
  • 磁盘不支持该命令或固件版本过旧。
  • 磁盘处于写保护状态或存在硬件故障。
  • 擦除命令超时或被中断。

相关日志本应出现在：storage 或 disk_service 的模块日志中，例如：

storage ERROR: secure_erase.lua: disk0 sanitize failed, ret=-1

2. 驱动或服务未正确启动

• 在“最小系统”或异常升级后，storage 相关组件可能未正常加载。
• 从知识库文档DC-4可知，系统中存在 component[storage] exited total 1 times 这类记录，表明storage模块可能不稳定。

如果storage服务未运行，则无法识别磁盘，自然无法执行报废。

3. 权限或流程控制问题

• 报废操作需要特定权限和流程控制。
• 若系统检测到磁盘正在被使用（如RAID阵列未停用、文件系统挂载中），会拒绝执行擦除。

应检查是否先执行了“卸载”、“停用RAID”等前置操作。

4. 固件兼容性或签名问题

• 如知识库Search Result #7所述，某些场景下因证书缺失或密钥不匹配导致操作失败。
• 虽然主要用于升级，但也可能影响高权限的数据销毁操作。

---

三、建议排查步骤

步骤1：检查完整日志路径

当前仅查看了app.log，应补充检查以下日志文件：

日志文件	说明
/dump_info/LogDump/storage.log	存储专属日志，最可能包含失败细节
/dump_info/LogDump/framework.log	系统框架日志，记录服务启动与交互
/var/log/messages	全局系统日志，包含内核级磁盘操作信息

搜索关键词：

• retire disk
• secure erase
• sanitize
• storage fail
• NVMe cmd timeout

步骤2：通过命令行验证磁盘状态

登录BMC CLI，执行以下命令：

# 查看磁盘是否被识别
ipmcget -t storage -d list

# 查询磁盘健康状态
ipmcget -t storage -d health

# （若支持）手动触发安全擦除测试（谨慎操作）
ipmcset -t storage -d sanitize -v <disk_id>

步骤3：确认是否所有磁盘均失败

• 是否所有磁盘都报废失败？
• 或仅为部分磁盘（如特定槽位）？

若为部分失败，则更可能是硬件问题（如某块SSD故障）。

步骤4：检查系统是否为“最小系统”模式

参考知识库DC-10：

• 若系统升级后仅启动了部分组件（“最小系统”），可能导致storage服务未加载。
• 执行以下命令确认：

  ps | grep storage_service
  busctl --user list | grep storage
  

---

四、解决方案建议

原因类型	解决方案
服务未启动	重启storage服务或整个BMC系统
磁盘不支持擦除	升级磁盘固件，或物理销毁
磁盘在使用中	停止RAID、卸载文件系统后再报废
日志不全	使用完整日志包（含storage.log）提交工单分析
权限问题	使用高权限账户操作，确认已通过认证

---

五、附加说明

• 在openUBMC系统中，资产报废（retire）是一个多阶段流程，由product_mgmt协调各组件完成。
• product_mgmt可能只记录“整体完成”，而不会透传子组件的失败详情到app.log。
• 因此，必须查看各子系统的独立日志才能精确定位。

---

总结

项目	结论
根本原因	当前无法确定，需更完整日志
最可能原因	安全擦除命令失败 或 storage服务异常
关键缺失日志	storage.log、framework.log
下一步建议	收集完整日志包并搜索sanitize/secure erase相关错误

建议操作：
使用BMC的“一键日志收集”功能，导出完整的LogDump，并重点分析storage模块日志，以定位具体失败原因。

相关链接：

1. BMC复位过程中出现fail、error日志，如何进行调试定位
2. 我按照“从零开始，玩转openUBMC”搭建环境没有hpm_signer工具，怎么制作和生成过度包？
3. powercycle测试中BMC服务发生异常，导致关机后没有开机
4. hardware进程重拉原因分析求助
5. RAID卡常见问题指南 | 文档中心 | openUBMC

[vyasa (欧文健)]

看看 2026-01-12T09:07:31+08:00 之后 product_mgmt 是否有相关日志呢。Disk报废这里是拉起SP执行的任务，可以看看sp是否正常启动了。

[ChenMinjun]

@vyasa

SP执行

app.log最早的日志在2026-01-12 09:10:42.999579
收集了几次日志，都是没有StartTime开始那小段的日志，你也会吗？

[ChenMinjun]

在其他机器的日志里，看到有关联的信息。

SP如何升级呢？

[vyasa (欧文健)]

日志的问题可以看看擦除的时候，是否有擦除日志选项。

sp升级可以使用redfish接口 /redfish/v1/Managers/1/SPService/SPFWUpdate/1/Actions/SPFWUpdate.SimpleUpdate

[ChenMinjun]

我按文档要求填入参数，但返回"Querying is not supported by the implementation."，请问是为什么呢？

[JiaHuiLei]

请求的参数以json格式写在body里，不要写在params或URL上

且ImageURI需要修改成：nfs:///<路径>/xxx.iso 或 cifs://<用户名>:<密码>@/<路径>/xxx.iso

[ChenMinjun]

这样是不是代表SP升级请求成功？ 如何检查升级结果呢？

[JiaHuiLei]

用这个接口 https://{{IP}}/redfish/v1/Managers/{{manage-id}}/SPService/SPFWUpdate/1 查看升级进度，当TransferProgressPercent和UpgradeProgress都达到100就代表升级成功了