Firmware upgrading method and device, storage medium, electronic equipment and program product

Abstract

The embodiment of the invention provides a firmware upgrading method and device, a storage medium, electronic equipment and a program product, and relates to the field of computers.The firmware upgrading method comprises the steps that first firmware upgrading operation is executed on a standby partition of a substrate management controller; under the condition that the first firmware upgrading operation is completed, first upgrading verification is carried out on the upgraded standby partition, and the first upgrading verification is used for verifying whether an upgrading result of the standby partition meets a firmware upgrading expected condition or not; under the condition that the upgrading result meets the firmware upgrading expected condition, main and standby switching operation is conducted on the main partition and the upgraded standby partition, and the main and standby switching operation is used for indicating that the main partition is set as the new standby partition and the upgraded standby partition is set as the new main partition; and executing a second firmware upgrading operation on the new standby partition. By the adoption of the scheme, the problem that the firmware upgrading efficiency is low in the related technology is solved.

Description

Technical Field

[0001] The embodiments of the present application relate to the computer field, and specifically, to a firmware upgrade method and device, a storage medium, an electronic device, and a program product. Background Art

[0002] In embedded systems and server management, firmware upgrades for baseboard management controllers (BMCs) are an important part of ensuring system security and performance. However, existing BMC firmware upgrade methods have the risk of service interruption during the upgrade process and cannot ensure the security and efficiency of the upgrade process, resulting in low firmware upgrade efficiency.

[0003] Therefore, there is a technical problem in the related art that the efficiency of firmware upgrading is low. Summary of the invention

[0004] The embodiments of the present application provide a firmware upgrade method and device, a storage medium, an electronic device, and a program product to at least solve the technical problem of low efficiency of firmware upgrade in the related art.

[0005] According to an embodiment of the present application, a firmware upgrade method is provided, comprising: performing a first firmware upgrade operation on a spare partition of a baseboard management controller, wherein the baseboard management controller includes a primary partition and a spare partition; when the first firmware upgrade operation is completed, performing a first upgrade check on the upgraded spare partition, wherein the first upgrade check is used to check whether the upgrade result of the spare partition meets the expected conditions for the firmware upgrade; when the upgrade result meets the expected conditions for the firmware upgrade, performing a primary-standby switching operation on the primary partition and the upgraded spare partition, wherein the primary-standby switching operation is used to indicate setting the primary partition as a new spare partition and setting the upgraded spare partition as a new primary partition;

[0006] A second firmware upgrade operation is performed on the new spare partition.

[0007] According to another embodiment of the present application, a firmware upgrade device is provided, comprising: a first upgrade unit, configured to perform a first firmware upgrade operation on a backup partition of a baseboard management controller, wherein the baseboard management controller comprises a primary partition and a backup partition; a verification unit, configured to perform a first upgrade verification on the upgraded backup partition when the first firmware upgrade operation is completed, wherein the first upgrade verification is used to verify whether the upgrade result of the backup partition meets the expected conditions for the firmware upgrade; a switching unit, configured to perform a primary-backup switching operation on the primary partition and the upgraded backup partition when the upgrade result meets the expected conditions for the firmware upgrade, wherein the primary-backup switching operation is used to indicate setting the primary partition as a new backup partition and setting the upgraded backup partition as a new primary partition; and a second upgrade unit, configured to perform a second firmware upgrade operation on the new backup partition.

[0008] According to another embodiment of the present application, a computer-readable storage medium is provided, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

[0009] According to another embodiment of the present application, an electronic device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0010] According to another embodiment of the present application, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the steps of the method in each embodiment of the present application are implemented.

[0011] Through the embodiments provided by the present application, by first performing the firmware upgrade in the standby partition, it is ensured that the main partition (i.e., the partition currently running) can still provide services during the upgrade, thereby avoiding system downtime and service interruption caused by the upgrade. Before the main and standby partitions are switched, the upgraded standby partition is subjected to the first upgrade check to ensure that the firmware upgrade result meets the expected conditions. Only when the upgrade result of the standby partition passes the check, the main and standby switching is performed, and then the new standby partition is subjected to the firmware upgrade, so that the firmware versions of the main and standby partitions are always consistent, thereby improving the redundancy and stability of the system. Through the first upgrade check, problems that may occur during the upgrade process can be discovered in time, such as the firmware not meeting the expected conditions, thereby avoiding switching the problematic firmware to the main state, effectively reducing the system failure rate, and ensuring the safety of the upgrade process. In summary, the embodiments provided by the present application realize the automation and intelligence of firmware upgrades, which not only reduces manual intervention and human errors, but also avoids long downtime and high failure probability caused by one-time updates through phased upgrades (first upgrading the standby partition, then upgrading the main partition), thereby achieving the technical effect of improving the efficiency of firmware upgrades, and solving the technical problem of low efficiency of firmware upgrades in the related art. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 is a hardware structure block diagram of a firmware upgrade method according to an embodiment of the present application;

[0013] Figure 2 is a flowchart of a firmware upgrade method according to the present application;

[0014] Figure 3 is a schematic diagram of another firmware upgrade method according to the present application;

[0015] Figure 4is a schematic diagram of another firmware upgrade method according to the present application;

[0016] Figure 5 is a schematic diagram of another firmware upgrade method according to the present application;

[0017] Figure 6 It is a structural block diagram of a firmware upgrade device according to an embodiment of the present application. DETAILED DESCRIPTION

[0018] The embodiments of the present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0019] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0020] The method embodiments provided in the embodiments of the present application can be executed in a computer terminal or a similar computing device. Taking running on a computer terminal as an example, Figure 1 1 is a hardware structure block diagram of a computer terminal of a firmware upgrade method according to an embodiment of the present application. Figure 1 As shown, the computer terminal may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the above-mentioned computer terminal may also include a transmission device 106 and an input and output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above-mentioned computer terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0021] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the method for determining the mapping relationship in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0022] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of a computer terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0023] As an alternative, Figure 2 As shown, a firmware upgrade method, the specific steps include:

[0024] S202, performing a first firmware upgrade operation on a backup partition of a baseboard management controller, wherein the baseboard management controller includes a primary partition and a backup partition;

[0025] S204, when the first firmware upgrade operation is completed, performing a first upgrade check on the upgraded standby partition, wherein the first upgrade check is used to check whether the upgrade result of the standby partition meets the expected conditions for the firmware upgrade;

[0026] S206, when the upgrade result meets the expected conditions for the firmware upgrade, performing an active-standby switching operation on the active partition and the upgraded standby partition, wherein the active-standby switching operation is used to indicate setting the active partition as a new standby partition and setting the upgraded standby partition as a new active partition;

[0027] S208: Execute a second firmware upgrade operation on the new standby partition.

[0028] Optionally, in this embodiment, a baseboard management controller (BMC) is an embedded microcontroller commonly used for remote monitoring and management of servers and storage devices. It can run independently of the main processor, provide real-time monitoring of system status, perform firmware updates, and perform system restart and recovery in the event of a failure.

[0029] Optionally, in this embodiment, the BMC is usually configured with two firmware storage partitions, namely a primary partition and a backup partition. The primary partition may be, but is not limited to, the partition where the currently running firmware is located, while the backup partition is used to store new or backup firmware versions.

[0030] Optionally, in this embodiment, the first firmware upgrade operation and the second firmware upgrade operation refer to firmware upgrades for the standby partition and the new standby partition, respectively, to update the firmware version, add new features, fix known problems, etc. The first firmware upgrade operation is performed on the standby partition, and the second firmware upgrade operation is an upgrade operation performed on the original active partition (now the new standby partition) after the active-standby switch.

[0031] Optionally, in this embodiment, the first upgrade verification is a series of tests performed after the first firmware upgrade operation is completed to verify whether the upgraded firmware meets predetermined expected conditions, such as the functional integrity of the firmware, the normal operation of the service, and the correctness of the configuration file.

[0032] Optionally, in this embodiment, the expected firmware upgrade conditions are used to indicate standards that should be met after the firmware upgrade, including but not limited to firmware stability, compatibility, performance indicators, etc., to ensure that the upgraded BMC can operate normally and service continuity is not affected.

[0033] Optionally, in this embodiment, the master-slave switching operation is performed after the first upgrade verification confirms that the upgrade result meets the expected conditions, with the intention of converting the current master partition into a new slave partition, and at the same time promoting the upgraded slave partition to a new master partition to ensure that the system runs on the latest firmware version.

[0034] Optionally, in this embodiment, first, the first firmware upgrade operation is performed on the standby partition of the BMC, the goal is to update the firmware version to fix known problems and improve system performance and security. During the upgrade process, the active partition continues to run, ensuring the continuity of system services.

[0035] Next, after the first firmware upgrade operation is completed, a first upgrade check is performed on the upgraded standby partition to ensure that the new firmware meets the expected conditions and to avoid system failures caused by firmware problems.

[0036] If the first upgrade verification confirms that the upgrade result meets the expected conditions, then the active-standby switching operation is performed, the active partition is set as the new standby partition, and the upgraded standby partition is set as the new active partition, thus ensuring that the system runs on the latest stable firmware version.

[0037] Finally, the second firmware upgrade operation is performed on the new backup partition (ie, the original primary partition), thereby ensuring the consistency of the firmware versions of the primary partition and the backup partition, and enhancing the redundancy and reliability of the system.

[0038] In specific implementation, the first firmware upgrade operation involves multiple steps, including firmware upload, verification, burning and bootloader setting. Firmware upload is to transfer the new firmware file to the spare partition; firmware verification is to check the integrity of the uploaded firmware file; firmware burning is to write the firmware content to the spare partition; and bootloader setting is to instruct the system to load the firmware from the upgraded spare partition after restarting.

[0039] The first upgrade verification is to verify whether the upgrade results meet expectations through a series of automated tests after the firmware upgrade is completed, such as functional module verification, health status detection, performance testing, and compatibility checks. If any unexpected conditions are detected, such as firmware function abnormalities, performance degradation, or configuration errors, the first upgrade verification will prevent the execution of the active-standby switching operation to prevent the system from running in an unstable state.

[0040] The active / standby switching operation is performed after the first upgrade verification is confirmed to be correct. By switching the partition roles, the system can run the latest version of the firmware without interrupting the service, while providing an upgrade preparation state for the new standby partition.

[0041] Finally, the second firmware upgrade operation is performed on the new backup partition, ensuring the consistency of the firmware versions of the primary and backup partitions, further enhancing the redundancy and reliability of the system. This upgrade method is not only suitable for large-scale server management environments such as data centers and cloud service infrastructure, but also for remote devices, high-availability systems and key industry applications, providing a safer, more efficient and intelligent solution for firmware upgrades.

[0042] Through the embodiments provided by the present application, by first performing the firmware upgrade in the standby partition, it is ensured that the main partition (i.e., the partition currently running) can still provide services during the upgrade, thereby avoiding system downtime and service interruption caused by the upgrade. Before the main and standby partitions are switched, the upgraded standby partition is subjected to the first upgrade check to ensure that the firmware upgrade result meets the expected conditions. Only when the upgrade result of the standby partition passes the check, the main and standby switching is performed, and then the new standby partition is subjected to the firmware upgrade, so that the firmware versions of the main and standby partitions are always consistent, thereby improving the redundancy and stability of the system. Through the first upgrade check, problems that may occur during the upgrade process, such as the firmware not meeting the expected conditions, can be discovered in time, thereby avoiding switching the problematic firmware to the main state, effectively reducing the system failure rate, and ensuring the safety of the upgrade process. In summary, the embodiments provided by the present application realize the automation and intelligence of firmware upgrades, which not only reduces manual intervention and human errors, but also avoids long downtime and high failure probability caused by one-time updates through phased upgrades (first upgrading the standby partition, then upgrading the main partition), thereby achieving the technical effect of improving the efficiency of firmware upgrades.

[0043] As an optional solution, verify the upgraded standby partition, including:

[0044] Performing a first check on the upgraded standby partition, wherein the first check is used to check whether a basic state of the upgraded standby partition meets a first expected condition;

[0045] In the case where the basic state meets the first expected condition, performing a second check on the upgraded standby partition, wherein the second check is used to check whether the upgrade module of the upgraded standby partition meets the second expected condition;

[0046] When the upgrade module meets the second expected condition, it is determined that the upgrade result meets the expected condition for firmware upgrade.

[0047] Optionally, in this embodiment, the first verification is a verification of the basic state of the upgraded standby partition, and the basic state includes but is not limited to the running state of the BMC service, the correctness of the configuration file, the thread running state, the restart record of the BMC and the average CPU usage, etc. The first expected condition sets the qualification standards for these states to ensure that the new firmware can run stably.

[0048] Optionally, in this embodiment, the second check is to check the modified functional modules in the upgraded backup partition after the first check confirms that the basic status is normal, including newly added, deleted or modified modules, to verify whether their functions are normal and whether they meet the expected performance and functional requirements. These expected conditions constitute the second expected conditions to ensure that the upgraded firmware can provide all necessary functions.

[0049] Optionally, in this embodiment, the first check is first performed to comprehensively check the basic status of the standby partition to confirm the stability of the new firmware under the minimum operating conditions; then, after the basic status check is passed, the second check is performed to focus on checking the modified functional modules in the new firmware to ensure the normal operation and performance improvement of the required functions. This phased check process can not only systematically check the applicability and functionality of the new firmware, but also detect potential faults and performance problems in advance to avoid greater impact after the active-standby switch, thereby ensuring the safety, effectiveness and trouble-freeness of the entire upgrade process.

[0050] Through the embodiments provided in this application, a detailed two-stage verification process is used to effectively prevent upgrade failures and potential system failures, thereby improving upgrade efficiency and system reliability.

[0051] As an optional solution, a first check is performed on the upgraded standby partition, including:

[0052] Obtaining a partition configuration file list of the upgraded standby partition, wherein the partition configuration file list is used to indicate setting information of the configuration file in the upgraded standby partition;

[0053] In the case where the number of configuration files is incorrect or the setting information does not meet the configuration expected condition, it is determined that the basic state of the upgraded standby partition does not meet the first expected condition.

[0054] Optionally, in this embodiment, the partition configuration file list is a part of the BMC basic health status detection configuration file, which is used to indicate the configuration file setting information in the upgraded standby partition, including the name, location, version and important setting parameters of the configuration file.

[0055] Optionally, in this embodiment, the configuration expected conditions are a set of expected conditions established to ensure that the configuration file is correctly set up, including the integrity and correctness of the configuration file and specific setting requirements matching the new firmware version, such as file existence check, configuration parameter correctness check, etc.

[0056] Optionally, in this embodiment, the correct setting of the configuration file is crucial for the BMC firmware upgrade, which directly affects whether the new firmware can run correctly and whether the system services can be provided normally. Therefore, in the first verification stage, by obtaining the partition configuration file list, the system can automatically identify the existence, version information and parameter settings of the configuration file, and compare them with the expected configuration conditions to ensure that the configuration file settings match the new firmware version and that the configuration file itself is not missing or incorrectly set. If it is found during the inspection process that the number of configuration files is wrong or the setting information does not meet the expected conditions, the system will automatically determine that the basic state of the upgraded standby partition does not meet the first expected condition, avoiding switching the problematic firmware to the main state, reducing the system failure rate, and ensuring the safety and efficiency of the upgrade process.

[0057] Through the embodiments provided in the present application, specific implementation guidance for configuration file verification during the BMC dual partition upgrade process is provided, ensuring the correctness and stability of the new firmware at the configuration level.

[0058] As an optional solution, after obtaining the partition configuration file list of the upgraded standby partition, the method further includes:

[0059] When the number of configuration files is correct and the setting information meets the expected configuration conditions, obtain the operation log of the upgraded standby partition;

[0060] Checking the records in the operation log that are in the first detection time period;

[0061] When there is an abnormal restart record in the records of the first detection time period, it is determined that the basic state of the upgraded standby partition does not meet the first expected condition.

[0062] Optionally, in this embodiment, the operation log records detailed information of the BMC during operation, including service status, error records, restart events, performance data, etc., and is an important basis for analyzing the health status of the system.

[0063] Optionally, in this embodiment, the first detection time period is a preset time window, which is used to check the operating status of the system within a period of time after the BMC is upgraded to ensure that the system runs stably under the new firmware.

[0064] Optionally, in this embodiment, the abnormal restart record is used to record an abnormal restart event recorded in the operation log, which may indicate that there is a serious stability problem in the system and further investigation and processing are required.

[0065] It is understandable that in this embodiment, the operation log of the upgraded standby partition is checked. The verification of the correctness and integrity of the configuration file is the basis for ensuring the stable operation of the new firmware, and the analysis of the operation log is an in-depth verification of the system operation status. By obtaining the operation log of the upgraded standby partition, the system can check whether there is an abnormal restart record within the first detection time period, which is an important indicator for detecting whether the new firmware is stable in actual operation. If an abnormal restart record is detected, it means that the new firmware has encountered major problems in operation and cannot meet the requirements for system stability in the first expected condition. Therefore, the basic state is considered to be not in line with expectations, and the system will not perform subsequent master-slave switching operations until the problem is resolved, ensuring that the firmware version of the active partition will not be affected by the upgrade failure, and maintaining the continuity and security of the system service.

[0066] Through the embodiments provided in the present application, by checking the operation log, it is possible to promptly discover potential problems with the new firmware after the upgrade, avoid switching firmware with stability risks to the main state, and provide stronger reliability and security protection.

[0067] As an optional solution, after checking the records in the operation log in the first detection time period, the method further includes:

[0068] When there is no abnormal restart record in the records of the first detection time period, obtaining the service running status of each service in the upgraded standby partition, and obtaining the thread running status of each thread associated with each service;

[0069] When the service running state does not meet the service expected condition or the thread running state does not meet the thread expected condition, it is determined that the basic state of the upgraded standby partition does not meet the first expected condition.

[0070] Optionally, in this embodiment, the service running status of each service is used to indicate the running status of various system services in the upgraded standby partition, including but not limited to whether the service is started normally, whether the service status meets expectations, service resource occupancy, etc.

[0071] Optionally, in this embodiment, the service expected condition is a preset standard for normal operation of the system service, ensuring the stability and efficiency of the service, including successful service startup, correctness of the service status, and reasonable use of service resources.

[0072] Optionally, in this embodiment, the thread running state of each thread is used to indicate the running status of each thread in the system service, which is an important component of the service health status. The abnormality of the thread running state may cause service failure.

[0073] Optionally, in this embodiment, the expected condition of the thread is a preset standard for normal operation of the thread, ensuring the stability and responsiveness of the thread, including correct startup of the thread, normal state of the thread, and reasonable use of thread resources.

[0074] Optionally, in this embodiment, after confirming that the system has not experienced an abnormal restart within the first detection time period, it is necessary to further verify the running status of all services and threads in order to ensure that the new firmware can stably run all necessary services and that the threads of each service can be executed correctly. The stable operation of services and threads is the cornerstone of the normal operation of the BMC. Any failure to start a service or abnormal state of a thread may affect the overall function and performance of the system. Therefore, by obtaining the running status of services and service threads in the upgraded standby partition, the system can comprehensively evaluate its health status. Once an operating status that does not meet the expected conditions is found, the basic status will be immediately determined to be not as expected, and the active-standby switching will be stopped until the running status of the services and threads passes the verification, ensuring that the upgraded BMC can achieve the expected stability and performance requirements at the service and thread levels.

[0075] Through the embodiments provided in the present application, the reliability of system upgrades is improved through a mechanism for checking the running status of services and threads, and the guarantee of system stability and service continuity is enhanced.

[0076] As an optional solution, after obtaining the service running status of each service in the upgraded standby partition, the method further includes:

[0077] When the service running state meets the service expected condition and the thread running state meets the thread expected condition, obtaining the average CPU usage rate of the upgraded standby partition in the second detection time period;

[0078] In the case where the average usage rate of the central processing unit is greater than a preset threshold, determining that the basic state of the upgraded standby partition does not meet the first expected condition;

[0079] When the average usage rate of the central processing unit is less than or equal to the preset threshold, it is determined that the basic state of the upgraded standby partition meets the first expected condition.

[0080] Optionally, in this embodiment, the second detection time period is a time window for real-time monitoring of the central processing unit (CPU) usage rate after the firmware is upgraded to ensure that the new firmware does not cause excessive CPU load during actual operation.

[0081] Optionally, in this embodiment, the average CPU usage is the average value of the CPU usage during the second detection time period, which is an important performance indicator. Too high an average usage may indicate that the system has a performance bottleneck or resource occupation problem.

[0082] Optionally, in this embodiment, the service expected condition and the thread expected condition are preset standards for service and thread running states, ensuring that all necessary services and threads can be stably run after the BMC is upgraded to meet business needs and performance requirements.

[0083] It is understandable that after the first two steps of the first verification, namely the inspection of the service and thread running status, are confirmed to be correct, the system enters the inspection of the average CPU usage. The average CPU usage is an important indicator to measure system performance and resource usage. Excessive or unstable CPU usage may mean that there is a resource bottleneck in the system or that the new firmware does not manage system resources properly, resulting in performance degradation or system instability. By monitoring the average CPU usage during the second detection time period and comparing it with the preset threshold, the system can accurately determine whether the performance of the new firmware in actual operation meets expectations, and ensure that the upgraded standby partition also meets the first expected conditions at the CPU resource level, providing completeness and depth to the verification process.

[0084] Through the embodiments provided in the present application, not only can the performance verification of the system upgrade be strengthened, but also a strong reference basis for the resource management of the BMC is provided, thereby ensuring that the upgraded system can stably operate within the preset resource usage range, and avoiding performance degradation or system instability caused by excessive resource consumption.

[0085] As an optional solution, a second check is performed on the upgraded standby partition, including:

[0086] Parsing a configuration file associated with the first firmware upgrade to obtain configuration information of the upgrade module, wherein the configuration file is used to store module information upgraded in the first firmware upgrade operation;

[0087] Configuration information is read, and module checking is performed on at least one module in the upgrade module, wherein the at least one module is a module in which a check item in the upgrade module is set to an on state.

[0088] Optionally, in this embodiment, the second check is used to indicate a check on the functional integrity and correctness of the upgrade module performed after the first check is confirmed to be correct, to ensure that the upgraded BMC can provide all necessary functional modules and that these modules can operate normally.

[0089] Optionally, in this embodiment, the first firmware upgrade management configuration file records the configuration information of all modified modules in the firmware upgrade operation, including the name, version, function description and whether verification is enabled of the upgrade module, etc., to guide the execution of the second verification.

[0090] Optionally, in this embodiment, the upgrade module is a functional module that is updated in the firmware upgrade operation, including a newly added, deleted or modified module, and functional verification is required to ensure its correctness and stability.

[0091] Optionally, in this embodiment, the check item is a parameter defined in the configuration file for controlling whether the module check is turned on, and is usually set to 0 or 1, 0 means not to turn on the check, and 1 means to turn on the check.

[0092] It can be understood that in this embodiment, 1 ensures that the system can accurately identify which modules are modified during the upgrade operation and need to perform subsequent functional verification by accurately parsing and utilizing the first firmware upgrade management configuration file. By reading the configuration file, the system can obtain detailed information of each upgrade module, including the module name, version information, and whether the verification is enabled, and then perform functional checks on the modules set to the verification-enabled state one by one to ensure that these modules can run correctly in the new firmware and are fully functional and stable. The implementation of this verification process not only improves the efficiency of firmware upgrades and avoids redundant verification of all modules, but also ensures that the functional modules of the upgraded BMC can meet the expected requirements.

[0093] Through the embodiments provided in this application, the correctness and stability of the functional modules in the new firmware version are ensured, the verification process is optimized, and the efficiency of the firmware upgrade is improved. It is suitable for scenarios with extremely high requirements for the stability of the functional modules, and helps to improve the overall operating efficiency of the system and the continuity of services.

[0094] As an optional solution, a module check is performed on at least one module in the upgrade module, including:

[0095] Extracting the interface name and request parameters of each check item of at least one module from the configuration information;

[0096] Using the interface name and the request parameters, executing an application program interface request triggered on at least one module, wherein the application program interface request is used to obtain a first response value of the at least one module;

[0097] Based on a comparison result between the first response value and the second response value indicated in the configuration information, it is determined whether the upgrade module meets the second expected condition.

[0098] Optionally, in this embodiment, the configuration information is module detailed information parsed from the first firmware upgrade management configuration file, including interface name, request parameters, expected return value, etc., which is used to guide module inspection.

[0099] Optionally, in this embodiment, an application program interface (API) request is a software communication method used to call the functional interface of a module to test its input, output and responsiveness, and is a core step of module inspection.

[0100] Optionally, in this embodiment, the first response value is the actual response value returned by the module after executing the API request, including but not limited to status code, error information, data return, etc. The second response value is the expected response value defined in the configuration information, that is, the response value that the module should return under normal operating conditions, which is used to compare with the first response value to verify the correctness of the module.

[0101] It can be understood that in this embodiment, the inspection items of each module, including the name of its functional interface and request parameters, are first obtained from the configuration information, and then the input, output and responsiveness of the module in the new firmware version are tested by executing API requests to obtain the first response value. Finally, these actual response values ​​are compared with the expected response values ​​defined in the configuration information to determine whether the module can run correctly and meet the expected functions and performance indicators.

[0102] The embodiments provided in the present application ensure that after the BMC dual-partition firmware is upgraded, the new version of the module can provide services stably and reliably, avoiding system failures caused by abnormal module functions, and is suitable for various scenarios with strict verification requirements for functional modules.

[0103] As an optional solution, determining whether the upgrade module meets the second expected condition based on a comparison result of the first response value and the second response value indicated in the configuration information includes:

[0104] When the first response value is consistent with the second response value, determining that the upgrade module meets the second expected condition;

[0105] In the case where the first response value is inconsistent with the second response value, it is determined that the upgrade module does not meet the second expected condition.

[0106] Optionally, in this embodiment, by comparing the actual operation results with the expected results, it is possible to intuitively determine whether the functional performance of the module in the upgraded BMC environment meets the expected standards. If the response values ​​of all modules are consistent with expectations, it means that the module functions are stable and the data processing is correct, meeting the upgraded functional and performance requirements, and the system can safely perform active-standby switching and promote the upgraded standby partition to the new active partition. On the contrary, if the response value of any module is inconsistent with expectations, it indicates that the module is operating abnormally in the new environment, and there may be functional errors or performance problems. It is necessary to suspend the active-standby switching operation and further debug and optimize the module until all modules pass the verification to ensure that their functions and data processing meet the second expected conditions.

[0107] The embodiments provided in this application provide security for subsequent active / standby switching, ensuring that the upgraded BMC environment can stably run all necessary functional modules and meet business needs and performance requirements.

[0108] As an optional solution, performing module inspection on at least one module in the upgrade module includes at least one of the following:

[0109] Performing a module check on a first module included in the at least one module, wherein the first module is a newly added module in the upgraded module;

[0110] Performing module inspection on a second module included in the at least one module, wherein the second module is a module deleted from the upgraded module;

[0111] A module check is performed on a third module included in the at least one module, wherein the third module is a modified module in the upgraded module.

[0112] Optionally, in this embodiment, functional verification is performed on the newly added module (first module), deleted module (second module) and modified module (third module) in the upgrade module. This verification process is distinguished based on the type of module (new, deleted, modified), ensuring that different types of modules can obtain functional verification suitable for their characteristics to confirm the functional integrity and stability of the module in the new firmware version. For the newly added first module, it is necessary to verify whether its function is correctly implemented and whether it can be seamlessly integrated with the existing system; for the deleted second module, it is necessary to confirm that its deletion will not affect the normal operation of other modules in the system, and whether there is a suitable alternative to the original function; for the modified third module, it is necessary to verify whether the expected performance improvement or problem repair is achieved after the modification, and no new functional anomalies are introduced. The implementation of this process ensures the integrity and stability of the upgraded BMC environment at the functional level.

[0113] As an optional solution, after performing the second firmware upgrade operation on the new standby partition, the method further includes:

[0114] When the second firmware upgrade operation is completed, a second upgrade check is performed on the upgraded new standby partition, wherein the second upgrade check is used to check whether the upgrade result of the upgraded new standby partition meets the expected conditions for the firmware upgrade.

[0115] Optionally, in this embodiment, after the new standby partition completes the firmware upgrade operation, the upgrade result is comprehensively tested and verified to confirm whether it meets the expected conditions for the firmware upgrade. The expected conditions for the firmware upgrade include system performance indicators, correct operation of functional modules, resource usage status, etc., which are important criteria for measuring the success of the firmware upgrade. The implementation of the second upgrade verification ensures that the new standby partition can stably run on the latest firmware version after the upgrade, with complete functions and performance up to standard, providing security for subsequent master-slave switching. If the second upgrade verification result shows that the upgrade result of the new standby partition meets expectations, the system will prepare to perform master-slave switching to promote the new standby partition to the main partition; conversely, if the verification result does not meet expectations, the system will suspend the master-slave switching operation, troubleshoot and make necessary repairs on the new standby partition until all verification conditions are met, ensuring that the upgraded BMC environment can run stably and meet business needs and performance requirements.

[0116] As an optional solution, the method further includes:

[0117] During the first firmware upgrade operation, the primary partition operates normally;

[0118] During the second firmware upgrade operation, the new primary partition operates normally.

[0119] Optionally, in this embodiment, the partition that is not upgraded in the BMC (the primary partition during the first firmware upgrade operation, the new primary partition during the second firmware upgrade operation) maintains normal operation. During the firmware upgrade operation, another partition of the BMC should be able to seamlessly take over all management and service functions to ensure the stability and continuity of the system during the upgrade process. This requirement is crucial to ensuring business continuity and system stability, especially in critical business scenarios where any service interruption may have a significant impact.

[0120] Through the embodiments provided by the present application, during any firmware upgrade operation, the active partition currently in operation should maintain normal operation, whether during the first firmware upgrade operation or the new active partition after the second firmware upgrade operation is completed. This control mechanism ensures that when the firmware upgrade is performed, a part of the BMC can always run stably and provide necessary services, avoiding service interruptions caused by firmware updates, and helping to ensure business continuity and system stability.

[0121] As an optional solution, performing a first firmware upgrade operation on a spare partition of a baseboard management controller includes:

[0122] Uploading the first firmware to the standby partition, wherein the first firmware is used to perform a first firmware upgrade operation on the standby partition;

[0123] Before performing the master-slave switching operation on the master partition and the upgraded standby partition, the method further includes:

[0124] When the upgrade result meets the expected conditions for the firmware upgrade, the first firmware is burned into the spare partition, and the spare partition after the burning is completed is determined as the upgraded spare partition.

[0125] Optionally, in this embodiment, first, the first firmware is uploaded to the standby partition through the remote management interface of the BMC to complete the transmission of the firmware file. Subsequently, the system will perform a firmware check to ensure the integrity of the first firmware and its compatibility with the current operating environment. If the firmware check passes, the system will perform a health status check and functional module verification of the upgraded standby partition, including but not limited to the operating status of the services required by the BMC, the correctness of the configuration file, the normal startup of the BMC thread, the average CPU occupancy rate, and the input and output responses of the functional modules, etc., to ensure that the new firmware version can meet all the expected conditions for the firmware upgrade. If the upgrade result passes all tests and verifications, the system will perform a burning operation, permanently store the first firmware on the standby partition, complete the first firmware upgrade operation, and determine the partition as the upgraded standby partition. At this point, the upgraded standby partition is ready, waiting for the subsequent master-slave switching operation to officially put the new version of the firmware into use.

[0126] Through the embodiments provided in the present application, by executing the process and verification mechanism of the first firmware upgrade operation on the backup partition, the stable operation of the new firmware version on the backup partition is ensured, as well as comprehensive testing and verification before the primary-backup switching, thereby avoiding system failures or performance degradation caused by upgrade failures, and providing important guarantees for business continuity and system stability.

[0127] As an optional solution, the active partition and the upgraded standby partition are switched to the active partition, including:

[0128] Setting a boot loader, wherein the boot loader is used to instruct the baseboard management controller to load and run from a new active partition after restarting;

[0129] Restart the baseboard management controller.

[0130] Optionally, in this embodiment, a boot loader is a program that runs when the BMC starts, is responsible for loading and initializing an operating system or a firmware environment, and can be configured to specify a partition from which to load and run.

[0131] Optionally, in this embodiment, restarting refers to a process of shutting down and restarting the BMC, which is usually performed after a firmware upgrade operation to ensure that the new firmware version is correctly loaded and run.

[0132] Optionally, in this embodiment, first, the system will configure the boot loader to instruct the BMC to load and run from the upgraded standby partition after restarting, ensuring that the new version of the firmware is correctly loaded. This configuration can be achieved by modifying the BMC startup configuration file or sending the corresponding configuration command through the remote management interface. Next, the system will execute the BMC restart operation. At this time, the BMC will start from the new primary partition according to the latest boot loader configuration, load and run the new version of the firmware, and officially put the new firmware version into use. The restart operation needs to be performed with caution to ensure that it is performed when the system is under low business pressure to avoid unnecessary impact on the business. After the primary and standby switching is completed, the system should be monitored for a period of time to ensure that the new version of the firmware can run stably, meet business needs and performance requirements, and avoid potential problems from having a negative impact on system operation.

[0133] Through the embodiments provided by the present application, through the active-standby switching operation process and the boot loader setting mechanism, it is ensured that in the BMC dual partition upgrade strategy, the new firmware version can be correctly loaded and run, and the active-standby switching operation is formally completed.

[0134] As an optional solution, after performing upgrade verification on the upgraded standby partition, the method further includes:

[0135] When the upgrade result does not meet the expected conditions for the firmware upgrade, an alarm message indicating the failure of the first firmware upgrade operation is reported, and the firmware version of the upgraded backup partition is rolled back to the version before the first firmware upgrade operation.

[0136] Optionally, in this embodiment, the alarm information is information reported by the system when the upgrade result does not meet the expected conditions for the firmware upgrade, which is used to indicate that the first firmware upgrade operation has failed and to provide a basis for troubleshooting and repairing the fault.

[0137] Optionally, in this embodiment, the fallback is to restore the firmware version of the upgraded standby partition to the version before the first firmware upgrade operation when the upgrade verification fails, so as to ensure the stable operation of the system.

[0138] Optionally, in this embodiment, in the event of an upgrade verification failure, the system will automatically report an alarm message, clearly indicating that the first firmware upgrade operation has failed, and provide detailed fault information and rollback instructions, so that the system administrator can troubleshoot and repair the fault according to the alarm message. After the alarm message is reported, the system will perform a rollback operation to restore the firmware version of the upgraded standby partition to the version before the first firmware upgrade operation, ensuring that the system can run stably on the old firmware version and avoiding potential faults or performance issues from affecting the business.

[0139] The embodiments provided in this application ensure that even in the event of a firmware upgrade failure, the system can be quickly restored, thereby ensuring business continuity and system stability.

[0140] As an optional solution, the upgrade result does not meet the expected conditions for firmware upgrade, including one of the following:

[0141] The basic status of the upgraded standby partition does not meet the first expected condition;

[0142] The upgraded module of the upgraded standby partition does not meet the second expected condition.

[0143] Optionally, in this embodiment, the specific circumstances in which the upgrade result does not meet the expected conditions for the firmware upgrade include the failure of the basic state to meet the first expected condition and the failure of the upgrade module to pass the verification of the second expected condition. The first expected condition of the basic state involves the level of the overall operating status of the BMC, including but not limited to system performance, resource usage, etc. If the basic state of the upgraded standby partition fails to meet these preset standards, it will be deemed that the upgrade result does not meet expectations. The second expected condition of the upgrade module focuses on the correct operation and performance of the new functional module. If the new functional module fails to pass the verification or has a functional abnormality, it will also be deemed that the upgrade result does not meet expectations.

[0144] The embodiments provided in this application ensure that even if the preset performance and functional standards are not met during the firmware upgrade process, the system can quickly restore stable operation through reporting of alarm information and rolling back the firmware version, thereby avoiding potential failures or performance issues from having adverse effects on the business.

[0145] As an optional solution, the above firmware upgrade method is applied to the BMC dual partition upgrade scenario in the server and storage fields. In this scenario, the firmware upgrade can repair known security vulnerabilities and improve the overall security of the system; the firmware upgrade can solve bugs and performance problems in the previous version and improve the stability and reliability of the system; the firmware upgrade can add new functions, improve existing functions, and improve their response speed and processing capabilities.

[0146] Usually, BMC will have two partitions for dual-mirror backup. Through dual-mirror backup, redundant storage of important data can be ensured. Once one partition fails or data is damaged, the other partition can still provide available data. Dual-mirror backup improves system reliability and availability. If a failure occurs, the system can quickly switch to the backup.

[0147] The current BMC dual partition upgrade methods generally include: Method 1: upgrade only the backup partition, and after the upgrade is completed, switch the partition to make the new firmware effective; Method 2: upgrade both partitions to the new firmware at the same time. Method 3: upgrade the backup partition first, and after the upgrade is successful, switch to the backup partition to start, and silently upgrade the old version of the main partition firmware to the latest version.

[0148] The above upgrade methods have their own drawbacks. Problem with method one: When the two versions differ greatly, after the new version fails, the old version service cannot meet the demand. Problem with method two: The upgrade time is long, causing business stagnation. At the same time, the long upgrade increases the probability of upgrade failure. Problem with method three: First upgrade the backup partition. After the upgrade is successful, switch to the backup partition to start. After it takes effect, then silently upgrade the main partition. Due to the lack of verification of the firmware function, if the function is abnormal, although the startup is successful, at this time both BMC firmware partitions have been upgraded to a version with abnormal functions, resulting in unavailable functions and the failure of this upgrade.

[0149] In order to avoid the above disadvantages, an embodiment of the present application provides a BMC dual-partition upgrade method, which silently upgrades the old version firmware to the latest version in the newly upgraded partition to ensure version consistency, while saving upgrade time and ensuring the reliability of service provision.

[0150] The BMC dual-partition upgrade process mainly includes: upgrade device selection, firmware upload, firmware verification, firmware burning, bootloader setting, BMC restart, and silent upgrade.

[0151] First, upgrade the standby partition. If the upgrade is successful, switch to the standby partition to start. After it takes effect, perform a BMC health status check and verify the function of the functional modules (newly added, deleted, and modified functional modules) modified by the new firmware. If the BMC health status self-check is OK and the modified module function verification is successful, perform a silent upgrade of the primary partition to keep the primary and standby partition firmware consistent; otherwise, the upgrade is considered a failure, and the silent upgrade of the primary partition operation is not performed, and restart from the primary partition.

[0152] Specifically, the dual partition upgrade process is as follows: Figure 3 As shown, including:

[0153] Step S302, BMC initiates a firmware upgrade process;

[0154] Step S304, upgrading the backup partition image;

[0155] Step S306, the upgrade is completed and the BMC restarts;

[0156] Step S308, BMC basic health status detection;

[0157] Step S310, when the basic health status is healthy, perform a BMC modification module function check;

[0158] Step S312, when the BMC modification module function verification passes, the original primary partition image is upgraded;

[0159] Step S314: if the BMC modification module function check fails or the basic health status is unhealthy, report a backup partition image upgrade failure warning;

[0160] Step S316: The BMC switches back to the original primary partition to start.

[0161] It is understandable that the upgrade process is initiated, and the BMC upgrades the new version of the firmware to the backup partition. The upgrade process steps include: upgrade device selection, firmware upload, firmware verification, firmware burning, bootloader setting, and BMC restart. The BMC switches to the backup partition and starts the new version of the firmware. The BMC basic health status detection checks its own health status. When its own health status is not OK, it reports the backup partition image upgrade failure alarm. Without performing a silent upgrade of the original primary partition, the BMC switches back to the original primary partition and restarts from the original primary partition. When its own health status is OK, verify the new firmware change function module, including the newly added, deleted, and modified function modules. When the modified function module verification fails, the backup partition image upgrade failure alarm is reported. Without performing a silent upgrade of the original primary partition, the BMC switches back to the original primary partition and restarts from the original primary partition. When the modified function module verification succeeds, the original primary partition image is upgraded.

[0162] Optionally, the BMC basic health status detection process, such as Figure 4 As shown, including:

[0163] Step S402, parsing the health detection configuration file;

[0164] Step S404, traverse the BMC configuration file list;

[0165] Step S406, checking whether the configuration file is correct;

[0166] Step S408, if the configuration file is correct, loop detection, obtain and record the current CPU usage;

[0167] Step S410, checking whether there is any abnormal restart record of the BMC within the detection time period through the BMC operation log or the system event log;

[0168] Step S412, if there is no abnormal restart record, traverse the BMC service list;

[0169] Step S414, checking the service running status;

[0170] Step S416, when the service running state is normal, traverse the thread running state under the service process;

[0171] Step S418, checking the thread running status;

[0172] Step S420, when the thread running state is normal, calculate the average CPU usage;

[0173] Step S422, when the average CPU usage rate does not exceed the set threshold, determining that the BMC basic health status is healthy;

[0174] Step S424: if the configuration file is incorrect or there is an abnormal restart record or the service running state is abnormal or the thread running state is abnormal or the average CPU usage exceeds a set threshold, determine that the BMC basic health state is unhealthy.

[0175] It is understandable that the BMC basic health status detection configuration file is parsed, and the configuration file content includes: BMC required service list, BMC configuration file list, CPU usage threshold, BMC operation log path or system event log path. Traverse the BMC configuration file list to check whether the BMC configuration file is correct. If the configuration file exists and some specific settings in the configuration file meet expectations, the BMC configuration file is correct; otherwise, the configuration file is incorrect, the health status detection fails, and exits directly. Obtain and record the current CPU usage. Check whether there is any abnormal restart record of BMC during the detection period through the BMC operation log or system event log. If an abnormal BMC restart occurs, the health status detection fails and exits directly. Traverse the BMC service list to check the service running status. If the service running status is abnormal, the health status detection fails and exits directly; otherwise, traverse all associated threads under the service process to check the thread running status. If the thread running status is abnormal, the health status detection fails and exits directly. Calculate the average CPU usage. If the average CPU usage exceeds the set threshold, the health status detection fails and exits directly. Complete the health status detection and end normally.

[0176] Optionally, modify the module function verification process, such as Figure 5 As shown, including:

[0177] Step S502, parsing and modifying the module verification configuration file;

[0178] Step S504, traverse the verification module;

[0179] Step S506, determining whether the current verification module is set to enable verification;

[0180] Step S508, when verification is enabled, traverse all the inspection items of the module;

[0181] Step S510, extracting interfaces and parameters;

[0182] Step S512, execute the API request and obtain a response;

[0183] Step S514, checking whether the response matches the expected return of the module interface;

[0184] Step S516, if the verification matches, determine that the modified module function verification passes;

[0185] Step S518, in the case of a verification mismatch, determining that the modified module function verification fails;

[0186] If the current verification module is not set to enable verification, the next verification module is returned for judgment.

[0187] It is understandable that the configuration file is parsed. The verification module is traversed, all the check items of the module are traversed, the interface and interface parameters in the configuration are extracted, the API request function is executed, and the request response is returned. The response is checked to see if it matches the expected return of the module interface in the configuration. If it does not match, the verification fails and exits directly. All the modified module function verifications are completed and the process ends normally.

[0188] Through the embodiments provided by the present application, an externally triggered BMC upgrade only needs to upgrade the backup partition and activate the startup backup partition. The newly started system automatically updates the backup partition according to the BMC health status, modified functional modules and firmware content differences.

[0189] Perform silent upgrades of old firmware versions in the backup partition to ensure uninterrupted service and save upgrade time. Perform health status checks after the upgrade to verify the reliability of the new firmware and ensure system stability during operation. Perform comprehensive verification of the modified functional modules in the new firmware, including newly added, deleted, and modified functions, to improve the security of firmware upgrades.

[0190] By upgrading the backup partition, the primary partition is always available during the upgrade process, avoiding system downtime and improving service continuity. Silently upgrading the old version of firmware to the latest version can reduce the time required for the overall upgrade and improve management efficiency. Through automatic update operations, the consistency of the firmware versions of the primary and backup partitions is ensured to avoid potential problems caused by version mismatches. If problems occur during the upgrade process, the automatic update operation is not performed, which can effectively prevent system failures caused by upgrade failures and ensure system security.

[0191] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of each embodiment of the present application.

[0192] In this embodiment, a firmware upgrade device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation modes, and the descriptions that have been made will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, the implementation of hardware, or a combination of software and hardware, is also possible and conceivable.

[0193] Figure 6 is a structural block diagram of a firmware upgrade device according to an embodiment of the present application, such as Figure 6 As shown, the device comprises:

[0194] A first upgrade unit 602, configured to perform a first firmware upgrade operation on a backup partition of a baseboard management controller, wherein the baseboard management controller includes a primary partition and a backup partition;

[0195] The verification unit 604 is used to perform a first upgrade verification on the upgraded standby partition when the first firmware upgrade operation is completed, wherein the first upgrade verification is used to verify whether the upgrade result of the standby partition meets the expected conditions for the firmware upgrade;

[0196] The switching unit 606 is used to perform a master-slave switching operation on the active partition and the upgraded standby partition when the upgrade result meets the expected conditions of the firmware upgrade, wherein the master-slave switching operation is used to indicate setting the active partition as a new standby partition and setting the upgraded standby partition as a new active partition;

[0197] The second upgrading unit 608 is configured to perform a second firmware upgrading operation on the new spare partition.

[0198] As an optional solution, the verification unit 604 includes:

[0199] A first verification module, used to perform a first verification on the upgraded standby partition, wherein the first verification is used to verify whether a basic state of the upgraded standby partition meets a first expected condition;

[0200] A second verification module is used to perform a second verification on the upgraded standby partition when the basic state meets the first expected condition, wherein the second verification is used to verify whether the upgraded module of the upgraded standby partition meets the second expected condition;

[0201] The determination module is used to determine that the upgrade result meets the expected condition for firmware upgrade when the upgrade module meets the second expected condition.

[0202] As an optional solution, the first verification module includes:

[0203] A first acquisition submodule is used to acquire a partition configuration file list of the upgraded standby partition, wherein the partition configuration file list is used to indicate setting information of a configuration file in the upgraded standby partition;

[0204] The first determination submodule is used to determine that the basic state of the upgraded standby partition does not meet the first expected condition when the number of configuration files is wrong or the setting information does not meet the configuration expected condition.

[0205] As an optional solution, the device also includes:

[0206] The second acquisition submodule is used to acquire the operation log of the upgraded standby partition after acquiring the partition configuration file list of the upgraded standby partition, if the number of configuration files is correct and the setting information meets the expected configuration conditions;

[0207] A checking submodule, configured to check the records in the first detection time period recorded in the operation log after obtaining the partition configuration file list of the upgraded standby partition;

[0208] The second determination submodule is used to determine that the basic state of the upgraded standby partition does not meet the first expected condition after obtaining the partition configuration file list of the upgraded standby partition and when there is an abnormal restart record in the records of the first detection time period.

[0209] As an optional solution, the device also includes:

[0210] A third acquisition submodule is used to obtain the service running status of each service in the upgraded standby partition and the thread running status of each thread associated with each service after checking the records in the first detection time period recorded in the operation log, if there is no abnormal restart record in the records in the first detection time period;

[0211] The third determination submodule is used to determine that the basic state of the upgraded standby partition does not meet the first expected condition after checking the records in the operation log that are in the first detection time period, if the service operation state does not meet the service expected condition or the thread operation state does not meet the thread expected condition.

[0212] As an optional solution, the device also includes:

[0213] A fourth acquisition submodule is used to obtain, after obtaining the service running status of each service in the upgraded standby partition, an average CPU usage rate of the upgraded standby partition in the second detection time period when the service running status meets the service expected condition and the thread running status meets the thread expected condition;

[0214] A fourth determination submodule is used to determine that the basic state of the upgraded standby partition does not meet the first expected condition after obtaining the service running state of each service in the upgraded standby partition and when the average usage rate of the central processing unit is greater than a preset threshold;

[0215] The fifth determination submodule is used to determine whether the basic state of the upgraded standby partition meets the first expected condition after obtaining the service running state of each service in the upgraded standby partition and when the average usage rate of the central processing unit is less than or equal to a preset threshold.

[0216] As an optional solution, the second verification module includes:

[0217] A parsing submodule, used to parse the configuration file associated with the first firmware upgrade to obtain configuration information of the upgrade module, wherein the configuration file is used to store the module information upgraded in the first firmware upgrade operation;

[0218] The checking submodule is used to read the configuration information and perform a module check on at least one module in the upgrade module, wherein the at least one module is a module in the upgrade module whose check item is set to an open state.

[0219] As an alternative, check the submodules, including:

[0220] An extraction submodule, used for extracting an interface name and a request parameter of each inspection item of at least one module from the configuration information;

[0221] An execution submodule, used to execute an application program interface request triggered on at least one module using an interface name and a request parameter, wherein the application program interface request is used to obtain a first response value of at least one module;

[0222] The sixth determination submodule is used to determine whether the upgrade module meets the second expected condition based on the comparison result of the first response value and the second response value indicated in the configuration information.

[0223] As an optional solution, the sixth determination submodule includes:

[0224] A seventh determination submodule, configured to determine that the upgrade module meets the second expected condition when the first response value is consistent with the second response value;

[0225] The eighth determination submodule is used to determine that the upgrade module does not meet the second expected condition when the first response value is inconsistent with the second response value.

[0226] As an optional solution, check the submodules, including at least one of the following:

[0227] A first inspection submodule, configured to perform module inspection on a first module included in the at least one module, wherein the first module is a newly added module in the upgraded module;

[0228] A second checking submodule, configured to perform a module check on a second module included in the at least one module, wherein the second module is a module deleted from the upgrade module;

[0229] The third inspection submodule is used to perform module inspection on a third module included in the at least one module, wherein the third module is a modified module in the upgraded module.

[0230] As an optional solution, the device also includes:

[0231] The third verification module is used to perform a second upgrade verification on the upgraded new standby partition after the second firmware upgrade operation is performed on the new standby partition and when the second firmware upgrade operation is completed, wherein the second upgrade verification is used to verify whether the upgrade result of the upgraded new standby partition meets the expected conditions for the firmware upgrade.

[0232] As an optional solution, during the first firmware upgrade operation, the primary partition operates normally;

[0233] During the second firmware upgrade operation, the new primary partition operates normally.

[0234] As an optional solution, the first upgrading unit 602 includes:

[0235] An upload module, used to upload a first firmware to a standby partition, wherein the first firmware is used to perform a first firmware upgrade operation on the standby partition;

[0236] The device also includes:

[0237] The burning module is used to burn the first firmware to the backup partition before performing the master-slave switching operation on the main partition and the upgraded backup partition, if the upgrade result meets the expected conditions of the firmware upgrade, and determine the backup partition after the burning is completed as the upgraded backup partition.

[0238] As an optional solution, the switching unit 606 includes:

[0239] A setting module, used for setting a boot loader, wherein the boot loader is used for instructing the baseboard management controller to load and run from a new primary partition after restart;

[0240] The restart module is used to restart the baseboard management controller.

[0241] As an optional solution, the device also includes:

[0242] The reporting module is used to report an alarm message indicating the failure of the first firmware upgrade operation and roll back the firmware version of the upgraded backup partition to the version before the first firmware upgrade operation if the upgrade result does not meet the expected conditions for the firmware upgrade after the upgrade verification of the upgraded backup partition.

[0243] As an optional solution, the upgrade result does not meet the expected conditions for firmware upgrade, including one of the following:

[0244] The basic status of the upgraded standby partition does not meet the first expected condition;

[0245] The upgraded module of the upgraded standby partition does not meet the second expected condition.

[0246] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.

[0247] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, disk, CD), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods of each embodiment of the present application.

[0248] It should be noted that the above modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.

[0249] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above method embodiments when running.

[0250] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk.

[0251] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any one of the above method embodiments.

[0252] In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

[0253] An embodiment of the present application further provides a computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores the computer program product, and when the computer program is executed by a processor, the steps of the method in each embodiment of the present application are implemented.

[0254] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.

[0255] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.

[0256] The above are only preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.

Claims

1. A firmware upgrade method, characterized in that: include: Performing a first firmware upgrade operation on a backup partition of a baseboard management controller, wherein the baseboard management controller includes a primary partition and the backup partition; When the first firmware upgrade operation is completed, performing a first upgrade check on the upgraded standby partition, wherein the first upgrade check is used to check whether the upgrade result of the standby partition meets the expected conditions for the firmware upgrade; In the case where the upgrade result meets the expected conditions for the firmware upgrade, performing an active-standby switching operation on the active partition and the upgraded standby partition, wherein the active-standby switching operation is used to indicate setting the active partition as a new standby partition and setting the upgraded standby partition as a new active partition; A second firmware upgrade operation is performed on the new spare partition.

2. The method according to claim 1, characterized in that: The verifying of the upgraded standby partition includes: Performing a first check on the upgraded standby partition, wherein the first check is used to check whether a basic state of the upgraded standby partition meets a first expected condition; In the case where the basic state meets the first expected condition, performing a second check on the upgraded standby partition, wherein the second check is used to check whether the upgraded module of the upgraded standby partition meets the second expected condition; In a case where the upgrade module meets the second expected condition, it is determined that the upgrade result meets the expected firmware upgrade condition.

3. The method according to claim 2, characterized in that The performing a first check on the upgraded standby partition includes: Acquire a partition configuration file list of the upgraded standby partition, wherein the partition configuration file list is used to indicate setting information of a configuration file in the upgraded standby partition; In the case where the number of configuration files is incorrect or the setting information does not meet the configuration expected condition, it is determined that the basic state of the upgraded standby partition does not meet the first expected condition.

4. The method according to claim 3, characterized in that: After obtaining the partition configuration file list of the upgraded standby partition, the method further includes: When the number of the configuration files is correct and the setting information meets the expected conditions of the configuration, obtaining the operation log of the upgraded standby partition; Checking the records in the operation log that are in the first detection time period; When there is an abnormal restart record in the records of the first detection time period, it is determined that the basic state of the upgraded standby partition does not meet the first expected condition.

5. The method according to claim 4, characterized in that After checking the records in the operation log that are in the first detection time period, the method further includes: When there is no abnormal restart record in the record of the first detection time period, obtaining the service running status of each service in the upgraded standby partition, and obtaining the thread running status of each thread associated with each service; When the service running state does not meet the service expected condition or the thread running state does not meet the thread expected condition, it is determined that the basic state of the upgraded standby partition does not meet the first expected condition.

6. The method according to claim 5, characterized in that After obtaining the service running status of each service in the upgraded standby partition, the method further includes: When the service running state meets the service expected condition and the thread running state meets the thread expected condition, obtaining the average CPU usage rate of the upgraded standby partition in the second detection time period; In a case where the average usage rate of the central processing unit is greater than a preset threshold, determining that the basic state of the upgraded standby partition does not meet the first expected condition; When the average usage rate of the central processing unit is less than or equal to the preset threshold, it is determined that the basic state of the upgraded standby partition meets the first expected condition.

7. The method according to claim 2, characterized in that: The performing a second check on the upgraded standby partition includes: Parsing a configuration file associated with the first firmware upgrade to obtain configuration information of the upgrade module, wherein the configuration file is used to store module information upgraded in the first firmware upgrade operation; The configuration information is read, and a module check is performed on at least one module in the upgrade module, wherein the at least one module is a module in the upgrade module whose check item is set to an on state.

8. The method according to claim 7, characterized in that The performing module inspection on at least one of the upgrade modules comprises: Extracting the interface name and request parameters of each inspection item of the at least one module from the configuration information; Using the interface name and the request parameter, executing an application program interface request triggered on the at least one module, wherein the application program interface request is used to obtain a first response value of the at least one module; Based on a comparison result between the first response value and a second response value indicated in the configuration information, it is determined whether the upgrade module meets the second expected condition.

9. The method according to claim 8, characterized in that The determining whether the upgrade module meets the second expected condition based on a comparison result between the first response value and the second response value indicated in the configuration information includes: When the first response value is consistent with the second response value, determining that the upgrade module meets the second expected condition; When the first response value is inconsistent with the second response value, it is determined that the upgrade module does not meet the second expected condition.

10. The method according to claim 7, characterized in that The performing module inspection on at least one of the upgrade modules includes at least one of the following: Performing module inspection on a first module included in the at least one module, wherein the first module is a newly added module in the upgraded module; Performing module inspection on a second module included in the at least one module, wherein the second module is a module deleted from the upgrade module; A module check is performed on a third module included in the at least one module, wherein the third module is a modified module in the upgraded module.

11. The method according to any one of claims 1 to 10, characterized in that: After performing the second firmware upgrade operation on the new spare partition, the method further includes: When the second firmware upgrade operation is completed, a second upgrade check is performed on the upgraded new standby partition, wherein the second upgrade check is used to check whether the upgrade result of the upgraded new standby partition meets the expected condition of the firmware upgrade.

12. The method according to any one of claims 1 to 10, characterized in that: The method further comprises: During the first firmware upgrade operation, the primary partition operates normally; During the second firmware upgrade operation, the new active partition operates normally.

13. The method according to any one of claims 1 to 10, characterized in that: The performing a first firmware upgrade operation on the standby partition of the baseboard management controller includes: Uploading a first firmware to the standby partition, wherein the first firmware is used to perform the first firmware upgrade operation on the standby partition; Before performing the master-slave switching operation on the master partition and the upgraded standby partition, the method further includes: In the case that the upgrade result meets the expected condition of the firmware upgrade, the first firmware is burned to the spare partition, and the spare partition after the burning is completed is determined as the upgraded spare partition.

14. The method according to any one of claims 1 to 10, characterized in that: The performing the master-slave switching operation on the master partition and the upgraded standby partition includes: Setting a boot loader, wherein the boot loader is used to instruct the baseboard management controller to load and run from the new active partition after restarting; Restart the baseboard management controller.

15. The method according to any one of claims 1 to 10, characterized in that After performing upgrade verification on the upgraded standby partition, the method further includes: In the case that the upgrade result does not meet the expected condition of the firmware upgrade, an alarm message indicating the failure of the first firmware upgrade operation is reported, and the firmware version of the upgraded backup partition is rolled back to the version before the first firmware upgrade operation.

16. The method according to claim 15, characterized in that The situation where the upgrade result does not meet the expected conditions for the firmware upgrade includes one of the following: The basic state of the upgraded standby partition does not meet the first expected condition; The upgraded module of the upgraded standby partition does not meet the second expected condition.

17. A firmware upgrade device, characterized in that: include: A first upgrade unit, configured to perform a first firmware upgrade operation on a backup partition of a baseboard management controller, wherein the baseboard management controller includes a primary partition and the backup partition; a verification unit, configured to perform a first upgrade verification on the upgraded standby partition when the first firmware upgrade operation is completed, wherein the first upgrade verification is used to verify whether the upgrade result of the standby partition meets the expected conditions for the firmware upgrade; a switching unit, configured to, when the upgrade result meets the expected conditions for the firmware upgrade, perform an active-standby switching operation on the active partition and the upgraded standby partition, wherein the active-standby switching operation is used to indicate setting the active partition as a new standby partition and setting the upgraded standby partition as a new active partition; The second upgrading unit is used to perform a second firmware upgrading operation on the new spare partition.

18. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the method according to any one of claims 1 to 16 when executed by a processor.

19. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 16 are implemented.

20. A computer program product, characterized in that The method comprises a computer program, which implements the steps of the method according to any one of claims 1 to 16 when being executed by a processor.

Images