【Q1】升级成功但是版本号没变化
版本号没变化请直接咨询子固件组件，版本号更新由子固件组件自行管理，固件管理仅为外部提供版本号展示，不修改版本号内容
【Q2】升级框架问题与各固件组件问题快速定位
升级非bmc固件的时候，有时候会升级失败，通过 /var/log/app_debug_log_all（最新版的日志已经移到/var/log/app.log） 有时候可以快速定界是firmware_mgmt升级框架问题还是各固件组件升级生效导致的固件失败（cpld、bios、vrd等）。firmware_mgmt解包成功并识别到是什么固件之后，会发送信号通知多样硬件触发升级，多样硬件收到信息进行升级，然后把升级结果返回给firmware_mgmt。所以当出现以下日志，就可以确认多样硬件给firmware_mgmt返回了升级失败信号。
关键日志：Upgrade <某固件> process failed, ret=<非0返回值> 有这条打印说明firmware明确收到了来自多样硬件的升级失败信息。
【Q3】升级BIOS升级完成，上电后发现未生效
1.查看BIOS升级完是否注册到了firmware_mgmt：
查看firmware_mgmt资源树，若存在以下字段，则已注册到firmware_mgmt；若无以下字段，优先找Bios组件定位
2.若已注册到firmware_mgmt，自查未生效方式如下：
查找关键词“PowerState changed to xxx”，若不存在PowerState changed to OFF，则有可能是下电失败，只有完全下电，即OFF状态才会触发生效
以下图片即为无OFF的情况
本问题经过上下电组件定位：
下电超时了,可能环境逻辑版本有误
【Q4】上电升级CPLD，下电后未生效
场景：上电情况下升级了CPLD，下电后CPLD未触发生效，环境没AC，CPLD版本没变 定位（三板斧）Q：
1、查看操作日志，找到对应操作的时间
2、搜索app日志对应时间点，查看详细升级日志
3、在相关事件点附近查看日志，观察CPLD升级生效流程日志是否按照正常预期执行： （1）CPLD上电升级，向firmware_mgmt注册生效item
（2）环境下电 （3）firmware_mgmt监听到下电，触发生效
在步骤（1）中，我们（敏锐地）看到CPLD注册的生效条件是PowerCycle，说明跑了CPLD生效定制化（BMCSet_CPLD_UpgradeActiveCondition），此定制项定制之后，下电和强制下电将不会生效CPLD，只有PowerCycle才会生效CPLD。
所以本次CPLD没生效的原因是环境被人跑了定制化，firmware_mgmt的mdb_info.log资源树可以佐证：
消除此定制化： busctl --user call bmc.kepler.general_hardware /bmc/kepler/general_hardware/MicroComponent bmc.kepler.MicroComponent.ConfigManage Import a{ss}ss 0 {\"ConfigData\":{\"CustomSettings\":{\"BMCSet_CPLD_UpgradeActiveCondition\":{\"Import\":true,\"Value\":\"PowerOff\"}}}} custom 或 执行一次空定制
若以上三个步骤均没问题，general_hardware与firmware_mgmt均不存在报错信息，查看fructrl是否有以下日志重复打印，以下日志表明AC失败了
此时需咨询上下电，即fructrl组件责任人
如有关键字“refresh the cache, and then execute ac down”打印，表示写寄存器触发ac成功了,但是硬件没有做对应的ac动作，需咨询相关硬件负责人
注：使用上述的定位三板斧，已经能够定位出大部分的升级问题。
【Q5】cli升级期间，cli连接突然断开
现象：用例执行cli升级期间，查询升级进度突然无响应
正常的升级进度应该是这样的：
问题根因：Administrator用户信息被改，导致Administrator的连接断开，所以cli突然登出，导致突然查不到升级进度
操作日志如下：一个IP使用Administrator登录cli触发升级，升级期间，另一个IP也登录了Administrator，并修改了用户信息。修改用户信息将导致Administrator用户登出，导致升级的那个cli会话直接断开，最终升级进度回显被中断
【Q6】升级报错：无效升级包/FirmwareType is nil
日志如下："get obj nil for Id="
新日志如下："FirmwareType is nil, invalid package config"
firmware_mgmt版本>=1.10.50之后，固件类型的定义被外置，详情参考V3固件管理一本通文档 遇到这种报错，就是因为没有在vpd仓定义需要升级的固件类型，自发现没分发此固件的对象给firmware_mgmt，导致firmware_mgmt无法识别此固件。
新增固件对象的方法：vpd仓中对应的机型的platform.sr中新增对象， "FirmwareComponentInfo_BMC": { "ComponentID": 2, "ComponentIDEx": 131, "Name": "Bios", "RevisionNumber": 0 }
ComponentID与ComponentIDEx数据需与update.cfg内数据保持一致
【Q7】升级失败报错：升级文件与机型不匹配 关键字update.cfg
app日志：sys-uid(1030abf00) not in update.cfg's ProductUIDList 等几条日志
原因：就是升级的包，与当前环境的机型信息不匹配。不允许升级
想要强行升级的办法：
1、ipmcset -d rollback尝试回滚，使用另一个看能否升级
2、如果另一个分区也报机型不匹配，自己通过本地manifest构建出一个过渡版本，先升级到过渡版本，然后在升级到预期版本。
以DA123C举例，想要把当前 非DA123C机型 升级到 DA123C，按以下步骤操作：
（1）在manifest仓找到DA123C机型的BMC固件的update.cfg文件
（2）修改ProductID字段，改成65535，表示匹配所有的产品系列
3、个人构建出包： python3 frame.py -t target_personal --stage=dev -b TaiShan200_DA123C 把此包升级到环境上，然后就可以升级到目标DA123C版本了
【Q8】升级超时失败
三个现象代表三个阶段的超时失败：
（1）prepare阶段超时失败。现象：升级进度在5%持续一分钟，然后升级失败，app.log存在以下打印：
说明子固件在prepare阶段没有在一分钟内响应firmware_mgmt，导致超时失败。 关键日志：Wait message reply timeout
（2）process阶段超时失败。现象：升级进度在>=15%持续一小时，然后升级失败，app.log存在Wait message reply timeout相关打印
（3）finish阶段超时失败。现象：升级进度在99%持续一分钟，然后升级失败，app.log存在Wait message reply timeout相关打印。
【Q9】升级iBMC成功，复位起来之后iBMC当前版本号没变
烧片了2023.5的烧片包，升级最新版本BMC，升级成功后BMC起不来。
环境烧片了23年5月份的BMC包，然后升级当前较新的版本（TR5-1以后的版本），能够升级成功，但是发现BMC多次起不来，然后自动回退成原来5月份的版本。
观察到串口日志有如下打印：
从上述串口打印发现，每次到启动Rsyslog服务时，反复启动几次失败，紧接着BMC就挂了，说明Rsyslog启动失败与BMC服务起不来强相关。 （找相关专家询问后，基本确认就是Rsyslog起不来导致BMC无法启动）
解决方案：烧片一个TR5的BMC
注：iBMC升级成功之后，多次启动失败然后切分区到原来的版本，导致的一个直接现象就是 升级之后版本号不变。
这一类的问题，共性情况如下：
现象： 升级成功之后，主分区版本号没变，可用分区版本号变了。
原因： 升级实际上是成功的，升级成功后复位iBMC，iBMC系统启动失败，三次未启动成功之后触发分区切换，切回了原版本。
根因： 定位根因需要进一步查看串口日志，串口日志 dump_info\OSDump\uart2com.dat
举例一：串口打印内核异常日志，说明rtos内核crash，问题出在RTOS或SDK，应当找相关领域定位
举例二：查看framework.log，看是否有组件启动异常，连续两次启动检查失败会触发切分区
如上日志发现确实有组件服务异常，启动检查失败，找对应领域责任人定位
【Q10】传包失败导致签名校验失败
1、app日志看firmware_mgmt错误打印，发现是签名校验失败
2、 分析用例发现传包阶段失败
3、查看/tmp空间使用情况
原因是/tmp目录存在一些临时文件，导致空间被占用了60M，而/tmp目录容量只有100M，再次上传一个升级包的时候，由于/tmp目录容量不够，导致传了一个不完整的hpm上去，导致签名校验失败。
建议：（1）优化脚本，触发升级之前先清理/tmp目录。（2）提需求，通过手动或自动方式清理tmp目录
【Q11】网络波动导致传包中断，升级失败
同上一个传包失败导致升级失败的问题，从日志看还是签名校验失败，
但是这一次导致传包失败的不是/tmp目录满了，而是BMC突然断开连接。
问题原因可能是 网络波动 或 当时BMC突然复位 或 部分服务重启 导致BMC不可达。 此类问题具体问题具体分析，非升级问题。
【Q12】升级过程中bmc_core重启导致升级失败
升级过程中升级失败，观察bmc_core启动日志发现当时bmc_core刚好重启过。
重启原因是bmc_core中的event组件存在内存泄漏，导致bmc_core达到512M内存使用阈值，触发重启。 当时刚好正在进行升级。
措施（已执行）：从bmc_core中分离event组件的服务。
【Q13】升级密钥解密失败导致升级失败
升级失败，查看app日志存在如下解密密钥失败打印
说明是升级需要的密钥解密失败，可能原因是key_mgmt更新密钥之后，ksf密钥与升级密钥不匹配，导致升级密钥无法解密。这部分有可能是key_mgmt存在缺陷。
当前firmware版本 >=1.0.30 已经从firmware角度增强健壮性解决了这个问题。
规避措施：
1、 删除环境密钥
rm /data/opt/bmc/upgrade/profile_en
rm /data/opt/bmc/upgrade/profile_en.bak2、 重启bmc_core服务
systemctl restart bmc_core3、 等firmware服务起来之后，重新升级即可
【Q14】升级卡住不想等两小时或无法平滑重启 急需重启一下恢复环境
！！慎用 方法有以下两类
【强制重启】
1.telnet下执行 systemctl reboot
若无法进入telnet
2.clp调试命令：reboot -f --》进入clp：输入clp_commands
【AC】
cli命令：ipmcset -t maintenance -d accycle
AC约等于拔电源，没有什么能阻止AC，fructrl组件起不来除外
【Q15】升级包版本太低/过旧的升级包
情况1 环境上允许降级升级属性DowngradeAllowed可能被置成了false
查询方式：
busctl --user get-property bmc.kepler.bmc_upgrade /bmc/kepler/UpdateService/UpdateMgmt bmc.kepler.UpdateService.UpdateMgmt DowngradeAllowed值为false则不允许降级升级，即不允许升比当前环境版本低的升级包
恢复方式
busctl --user set-property bmc.kepler.bmc_upgrade /bmc/kepler/UpdateService/UpdateMgmt bmc.kepler.UpdateService.UpdateMgmt DowngradeAllowed b true情况2 RevisionNumber值大于升级包中配置的Revision值
查看RevisionNumber：
ipmitool -H *bmc_ip* -I lanplus -p 623 -U *用户名* -P *密码* -C 17 raw 0x30 0x93 0xdb 0x07 0x00 0x5b 0x2d 0x00 0x06 0x00 0xc0 *0x19*(ComponentId) *0xff 0xff 0xff 0xff*(ComponentIdEx)RevisionNumber设置成0：
ipmitool -H *bmc_ip* -I lanplus -p 623 -U *用户名* -P *密码* -C 17 raw 0x30 0x93 0xdb 0x07 0x00 0x5a 0x2d 0x00 0x07 0x00 0xc0 *0x19*(ComponentId) *0xff 0xff 0xff 0xff*(ComponentIdEx) *0x00*(RevisionNumber)