【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组件定位
- 若已注册到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)【Q16】升级报错：无效升级包/FirmwareType is nil
日志报错如下：
固件类型的定位被外置，遇到这种报错就是因为没有在VPD仓定义需要升级的固件类型，自发现没分发此固件的对象给固件管理组件，导致固件管理组件无法识别此固件。新增固件对象的方法：VPD仓中对应的机型的platform.sr中新增对象，如下如所示，且ComponentID与ComponentIDEx数据需与update.cfg内数据保持一致。
【Q17】 密钥解密失败导致升级失败
如上图日志打印说明是升级需要的密钥解密失败，可能原因是key_mgmt更新密钥后，ksf密钥与升级密钥不匹配，导致升级密钥无法解密，当前固件版本大于等于1.0.30，已经从firmware角度增强健壮性，解决了整个问题。如果遇到该问题规避措施如下：
- 删除环境密钥
- 重启bmc_core服务；
- 组件服务起来之后，重新升级。
【Q18】 升级白牌包时报"p12 parse fail"
白牌包在制作的过程中涉及到ssl证书，证书分为加密和不加密两种，该日志对应的是加密证书，加密证书的制作分为四个步骤，分别为原始加密.pxf证书制作，确认加密密码，去密码，设置加密密码，而该报错是因为在制作证书的时候未按照要求去密码设置，导致在解密的时候系统解密密钥与加密密钥不匹配。
【Q19】 保留配置升级和不保留配置升级BIOS均失败
日志上显示get snaphot failed,尝试下发如下图命令，确实是否有返回：
返回报错，此时根本原因是上图中的BIOS资源树未成功加载，从而生成快照失败。沟通后发现，环境为天池模组环境，无bcu，导致bcu中涉及bios升级的资源树全部未加载，解决方案是将bcu中涉及bios的资源树部分功能进行迁移，最好跟着产品走。
【Q20】 V2无法升级V3
ipmcget -d v 获取V2版本信息
收集日志或重启触发升级，分析升级相关日志：
从日志可以看到此版本BMC缺乏或缺少根证书，导致签名校验失败，当前版本的BMC不但无法从V2升级到V3，也无法升级V2，需要先解决证书问题。解决办法：使用镜像倒换功能切换到另一个分区的BMC版本，然后再尝试升级。
【Q21】 烧片包的V2无法升级V3
环境上的BMC是一个较老的V2烧片BMC，V2升级V3日志报错如下：
原因是V2较老版本的签名只支持PKCS，不支持PSS，需要升级到中间版本作预埋，然后B版本就可以同时校验PKCS和PSS，此时再升级V3的BMC就可以成功。
【Q22】 上电升级CPLD，下电后未生效
现象：上电情况下升级了CPLD，下电后CPLD未触发生效，环境没AC,CPLD版本未变化。 定位步骤：
- 查看操作日志，确定操作时间：
- 搜索app.log日志对应时间点，查看详细升级日志：
- 在相关事件点附近查看日志，管擦和CPLD生效流程日志是否按照正常预期执行：
- CPLD上电升级，向固件管理组件注册生效item；
- 环境下电；
- 固件管理组件监听到下电，触发生效
在步骤（1）中，看到CPLD注册的生效条件是PowerCycle，说明跑了CPLD生效定制化，此定制项定制之后，下电和强制下电将不会生效CPLD，此时只需要消除此定制化即可。
【Q23】 升级超时失败
升级的三个现象代表三个阶段的超时失败：
- prepare阶段超时失败： 现象：升级进度在5%持续一分钟，然后升级失败，app.log存在如下打印：
说明子固件在prepare阶段没有在一分钟之内响应固件管理组件，导致超时失败。
- process阶段超时失败 现象：升级进度在大于等于15%持续一小时，然后升级失败，app.log存在超时相关日志打印
- finish阶段超时失败 现象：升级进度在99%持续一分钟，然后升级失败，app.log存在超时相关日志打印
MCU升级
【Q1】 VRD正在升级，无法升级MCU
上电升级VRD，下电后升级MCU返回失败：
- 当前MCU和VRD走的是一个升级通道，做了互斥限制
- VRD作为二级电源，只能在下电情况下进行升级，在os上电时缓存升级文件，返回升级成功，下电取升级文件，开始生效
需要等VRD下电生效后升级MCU，才能返回成功。 5.2最新版本更新了错误码，在VRD生效期间升级MCU返回特殊的失败提示：
【Q2】 升级riser卡MCU升级失败
storage组件使用插件式访问调用I2C，如果没有加载raid卡，在获取不到预期信息时会长时间独占总线，导致命令阻塞
【Q3】 如何查询BCU的MCU和VRD的版本号
命令查询版本号： mcu: busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018500 7
VRD: busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018501 7 busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018502 7 busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018503 7 busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018504 7 busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018505 7 busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018506 7 busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018507 7 busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Smc/Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read a{ss}uu 0 0x00018508 7
VRD升级
【Q1】 没有找到对应的升级文件
日志打印如下：对应的bin文件规则为VRD_厂商_SKU_NO.bin 厂商和SKU如下（当前B830版本只支持00_00和01_00）：
CSR升级
【Q1】 BC83PRUU(蝴蝶卡)CSR为1.17之前的版本升级出现升级失败
1.17版本CSR的port配置有问题，会导致raid卡无法正常加载，BMC会占用总线通道一直访问Raid，导致CSR升级时总线被占用，访问超时，会出现概率性升级失败的情况，需要重试几次
CPLD升级
【Q1】 获取厂商信息
下一步是获取芯片的厂商信息，根据厂商选择升级方式，在/logDump/app.log中筛选general_hardware:
大概率是ChipInfo无法获取，该Chip是挂在Jtag链路上的，有三种情况：
1、jtag链路没有切过去，在BMC中输入一下命令，看看是否可以获取到版本信息：
busctl --user set-property bmc.kepler.hwproxy /bmc/kepler/Accessor/Accessor_JtagSwitch_010101 bmc.kepler.Accessor Value t _( _ 为对应的链路，当前EXU为0，BCU为1，具体查看CSR的FirmwareRoute属性)
设置后查看信息，value是否改变：
busctl --user call bmc.kepler.hwproxy /bmc/kepler/Chip/Cpld/Cpld_1_0101 bmc.kepler.Chip.JtagTarget GetChipIdcode a{ss} 0（0101为EXU，010101为BCU，具体查看板卡的position）
以基础板为例子，正常获取到chip信息：
2、cpld扫链失败，输入dmesg驱动日志查看，可能是扩展板CPLD的版本问题，或者BMC测链路未通，未将CPLD和1711选通
3、jtag链路异常，测波形排查Jtag链路
【Q2】紫光CPLD的IIC升级失败（二盘背板）
在驱动日志中出现如下打印：
传输数据时出现丢失的情况，大概率是有毛刺影响，建议更换线缆
【Q3】 主板SVF格式升级成功后版本不变
- 查看升级的framework.log日志，发现升级时间很短就返回send data成功
- 查看linux_kenl日志（环境上输入dmesg），发现文件校验失败