Method for repairing baseboard management controller and electronic device

Abstract

The application discloses a substrate management controller repairing method and electronic equipment, and relates to the technical field of substrate management controller repairing, and comprises the following steps: when it is detected that the substrate management controller is in a universal bootloader stage, obtaining firmware information; detecting whether the current working state of the substrate management controller meets certain abnormal conditions according to the firmware information; when the condition is met, controlling the substrate management controller to enter a network boot mode, starting a diskless system, downloading an image file of abnormal firmware from a preset terminal, and executing the flashing of the abnormal firmware, so that after the repairing, the network boot mode is exited, the problems that hardware design is complex, upgrading is prone to failure and threatens safety due to the complex programmable logic device and the network module in remote refreshing, and the problem that the efficiency is low in manual firmware transmission in universal bootloader repairing are solved, the technical effect that external dependence is reduced, and the substrate management controller is repaired in batches automatically by scripts is achieved, and maintainability is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of baseboard management controller repair, and particularly relates to a baseboard management controller repair method and an electronic device. BACKGROUND

[0002] In the related art, the network channel switching module can be connected with a baseboard management controller (BMC) and a programmable logic device, and then the user command and data can be acquired through the network channel switching module, and the baseboard management controller is controlled to suspend operation before the baseboard management controller firmware is updated. The baseboard management controller firmware to be updated sent by the user remotely is stored to the baseboard management controller firmware storage module through the network channel switching module, so that the baseboard management controller continues to work after the baseboard management controller firmware is updated. When the target baseboard management controller firmware fails, it is determined whether the target universal bootloader in the target baseboard management controller firmware can be normally started. If yes, the standby baseboard management controller firmware stored in the mobile storage device is started by using the target universal bootloader. If no, the standby universal bootloader stored in the mobile storage device is burned to the target baseboard management controller firmware, and the standby baseboard management controller firmware is started by using the standby universal bootloader. Then, when the standby baseboard management controller firmware is started, the target baseboard management controller firmware is refreshed by using the standby baseboard management controller firmware.

[0003] However, in the related art, the remote refresh needs the support of a complex programmable logic device (CPLD) and a network channel module, which not only increases the hardware design complexity, but also may cause the baseboard management controller upgrade failure or even the whole machine unavailable once the complex programmable logic device firmware or logic is problematic. In addition, the complex programmable logic device itself does not have a complete security startup chain, which may cause malicious attacks and damage the security of the whole machine. The repair method of the universal bootloader needs to manually put the firmware into the mobile storage, which is low in efficiency and is not conducive to batch maintenance, and needs to be improved. SUMMARY

[0004] The application provides a substrate management controller repair method and an electronic device to at least solve the problem that a remote refreshing scheme in the prior art needs to use a complex programmable logic device and a network module, which causes a great increase in hardware design complexity. In addition, the complex programmable logic device itself has defects in firmware or logic, which easily causes the upgrade process to fail, and even causes the whole machine to be paralyzed in a serious case. In addition, the complex programmable logic device lacks a complete security start mechanism, which seriously threatens the safety of the whole machine. In addition, the repair method based on a universal boot loader needs manual participation in firmware transmission, which is extremely inefficient and difficult to meet the actual needs of batch maintenance.

[0005] The application provides a substrate management controller repair method, which comprises the following steps: obtaining firmware information of at least one firmware managed by at least one substrate management controller in the case that it is detected that the at least one substrate management controller is in a universal boot loader stage; detecting whether a current working state of a corresponding substrate management controller meets a preset abnormal condition according to the firmware information of each firmware; in the case that it is detected that the current working state meets the preset abnormal condition, controlling the at least one substrate management controller to enter a network boot mode, starting a pre-constructed diskless system, downloading an image file of an abnormal firmware in the at least one firmware from a preset terminal, performing flashing of the abnormal firmware according to the image file, and exiting the network boot mode after the abnormal firmware is repaired.

[0006] The application also provides a substrate management controller repair device, which comprises: an obtaining module, which is used for obtaining firmware information of at least one firmware managed by at least one substrate management controller in the case that it is detected that the at least one substrate management controller is in a universal boot loader stage; a detecting module, which is used for detecting whether a current working state of a corresponding substrate management controller meets a preset abnormal condition according to the firmware information of each firmware; and a repairing module, which is used for, in the case that it is detected that the current working state meets the preset abnormal condition, controlling the at least one substrate management controller to enter a network boot mode, starting a pre-constructed diskless system, downloading an image file of an abnormal firmware in the at least one firmware from a preset terminal, performing flashing of the abnormal firmware according to the image file, and exiting the network boot mode after the abnormal firmware is repaired.

[0007] The application also provides an electronic device, which comprises a memory for storing a computer program and a processor for executing the computer program to implement the steps of any one of the substrate management controller repair methods.

[0008] The application further provides a computer readable storage medium, and the computer readable storage medium stores a computer program.

[0009] The application further provides a computer program product, which comprises a computer program.

[0010] Through the application, when it is detected that the baseboard management controller is in the universal bootloader stage, the firmware information of the firmware managed by the baseboard management controller can be acquired, and then whether the current working state of the corresponding baseboard management controller meets certain abnormal conditions is detected according to the firmware information of each firmware, and when the conditions are met, the baseboard management controller is controlled to enter the network boot mode, the pre-constructed diskless system is started, the image file of the abnormal firmware is downloaded from the preset terminal, and the flashing of the abnormal firmware is performed according to the image file, so that after the abnormal firmware is repaired, the network boot mode is exited, and therefore, the technical problems that the remote refreshing scheme is complex in hardware design due to the complex programmable logic device and the network module, the firmware defects easily cause the upgrading failure and the whole machine paralysis, and in addition, there is a lack of security start mechanism and threatens the security can be solved. BRIEF DESCRIPTION OF DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor on the basis of these drawings.

[0012] Figure 1 A flowchart of a baseboard management controller repair method provided by an embodiment of the application is provided.

[0013] Figure 2 A flowchart of universal bootloader (U-boot for short) loading provided by an embodiment of the application is provided.

[0014] Figure 3 A flowchart of baseboard management controller repair provided by an embodiment of the application is provided.

[0015] Figure 4 A block schematic diagram of a baseboard management controller repair device provided by an embodiment of the application is provided.

[0016] Reference signs:

[0017] Wherein, 10 - the repair device of substrate management controller; 100 - first acquisition module, 200 - detection module, 300 - repair module. DETAILED DESCRIPTION

[0018] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0019] It should be noted that in the description of the present application, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that the processes, methods, articles or devices comprising a series of elements not only include those elements, but also include other elements not explicitly listed or inherent to such processes, methods, articles or devices. The terms "first", "second" and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0020] In order to enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the drawings and specific embodiments.

[0021] The embodiments of the present application provide a substrate management controller repair method, and the method is described in detail in combination with the execution flow of the substrate management controller repair method.

[0022] Specifically, Figure 1 A flowchart of a substrate management controller repair method according to an embodiment of the present application is provided.

[0023] As Figure 1 shown, the substrate management controller repair method comprises the following steps:

[0024] In step S101, when it is detected that at least one substrate management controller is in the universal bootloader stage, the firmware information of at least one firmware managed by the at least one substrate management controller is acquired.

[0025] It can be understood that in the embodiment of the present application, the baseboard management controller starts to execute U-boot first, then the U-boot starts to load the kernel in the storage device (such as memory), and the kernel starts to run various application programs after starting, such as application program 1 responsible for power management, application program 2 monitoring the temperature of the server, application program 3 controlling the fan, and the like, and the present application does not make specific limitation, and the flow is as shown in Figure 2 U-Boot is a widely used open source boot loader, mainly used in embedded systems.

[0026] Further, the embodiment of the present application can add a self-checking function in the U-boot booting stage, when the baseboard management controller starts, first enter the U-Boot booting stage, and obtain the firmware information of the firmware managed by the baseboard management controller.

[0027] For example, when the server starts, the baseboard management controller enters U-Boot, U-Boot initializes the hardware and detects the storage device, and then obtains the firmware information of the firmware managed by the baseboard management controller.

[0028] In step S102, whether the current working state of the corresponding baseboard management controller meets the preset abnormal condition is detected according to the firmware information of each firmware.

[0029] In some embodiments, the embodiment of the present application can detect whether the current working state of the corresponding baseboard management controller meets a certain abnormal condition according to the firmware information of each firmware. The certain abnormal condition can be set by those skilled in the art according to the actual situation, and the present application does not make specific limitation.

[0030] For example, the embodiment of the present application can detect whether the current working state of the baseboard management controller meets a certain abnormal condition according to the firmware information by detecting whether the firmware partition in the memory storage of the baseboard management controller is valid, and whether there is a legal kernel in the partition.

[0031] Optionally, in an embodiment of the present application, before starting the pre-constructed diskless system, it further includes: determining the network running data of the diskless system based on the network data of at least one baseboard management controller and the initial address identifier of the diskless system; in response to the boot loading instruction of the diskless system, obtaining the kernel image and the root file system of the diskless system based on the network running data; and constructing the diskless system based on the kernel image and the root file system.

[0032] It can be understood that the embodiment of the present application can build a diskless linux system server in a baseboard management controller network environment, and then when the baseboard management controller detects firmware exception, that is, the current working state of the baseboard management controller meets certain abnormal conditions, enter the diskless linux system through U-Boot and PXE (Preboot Execution Environment), and then complete the download and automatic refreshing of the baseboard management controller firmware in the diskless system.

[0033] In some embodiments, the embodiment of the present application can determine the network running data of the diskless system according to the network data of the baseboard management controller and the initial address identification of the diskless system, and then respond to the boot loading instruction of the diskless system to obtain the kernel image and the root file system of the diskless system through the network running data, and then build the corresponding diskless system.

[0034] The network running data of the diskless system can include but is not limited to IP (Internet Protocol Address) address, subnet mask, gateway, domain name system, TFTP (Trivial File Transfer Protocol Server Address) server address, NFS (Network File System) shared path, etc., which is not limited by the present application.

[0035] For example, after the server is powered on, the baseboard management controller reports its IP, MAC (Media Access Control Address) address and hardware information to the management server through the intelligent platform management interface protocol, and then the management server queries the pre-configured mapping table according to the MAC address, allocates a dynamic IP (such as 192.168.1.101) and network parameters, enters the PXE boot loader process, obtains the kernel image and the root file system of the diskless system, and loads the kernel image and the root file system, and then builds the corresponding diskless system.

[0036] The embodiment of the present application can dynamically generate the network running data of the diskless system by real-time collection of network data by the baseboard management controller and combination of the initial address identification of the diskless system before starting the pre-built diskless system, and when the boot loading instruction is received, the kernel image and the root file system are obtained on demand, the self-adaptive construction and zero-touch deployment of the diskless system network environment are realized, the complex network environment can be dynamically adapted, the deployment flexibility is improved, the start reliability is enhanced, the failure rate is reduced, and large-scale deployment is supported.

[0037] Optionally, in an embodiment of the present application, based on the kernel image and the root file system, the diskless system is constructed, comprising: extracting image parameters in the kernel image that meet preset working conditions; determining a loading mode of the root file system according to system data of the root file system; and constructing the diskless system based on the image parameters and the loading mode.

[0038] In some embodiments, the embodiments of the present application can extract image parameters in the kernel image that meet certain working conditions, and determine a loading mode of the root file system according to system data of the root file system, and then construct a corresponding diskless system. The certain working conditions can be set by those skilled in the art according to actual conditions, and the present application does not make specific limitations.

[0039] For example, the embodiments of the present application extract image parameters in the kernel image that meet certain working conditions, such as supporting 64-bit central processing unit architecture, containing target network card drivers (such as E1000E network cards), etc., and the present application does not make specific limitations.

[0040] Further, the embodiments of the present application can determine a corresponding loading mode according to system data of the root file system, such as data format, data size, etc., and then construct a corresponding diskless system.

[0041] The embodiments of the present application can first extract image parameters in the kernel image that meet certain working conditions, and determine a corresponding loading mode according to system data of the root file system, thereby constructing a diskless system, dynamically matching parameters, avoiding startup failure due to parameter mismatch, accurately adapting to diversified hardware environments, improving deployment flexibility, shortening startup time, and reducing operation risk.

[0042] Optionally, in an embodiment of the present application, before starting the pre-constructed diskless system, it further comprises: obtaining a hash value of the diskless system; determining whether the hash value is equal to a target hash value; if the hash value is not equal to the target hash value, then reconstructing the diskless system until the hash value is equal to the target hash value, and allowing the reconstructed diskless system to start; and if the hash value is equal to the target hash value, then allowing the diskless system to start.

[0043] It can be understood that in the embodiments of the present application, the target hash value can be understood as a hash value that the diskless system is expected to have, which can be used to represent the hash value of the diskless system in a correct, complete, and unaltered state.

[0044] As a possible implementation manner, the embodiments of the present application can first obtain a hash value of the diskless system, and determine whether the hash value of the diskless system is equal to a target hash value, and then in the case of inequality, reconstruct the diskless system until the hash value of the reconstructed diskless system is equal to the target hash value, and allow the corresponding diskless system to start.

[0045] In some embodiments, the embodiments of the present application can allow direct startup of the corresponding diskless system when the hash value of the diskless system is not equal to the target hash value.

[0046] For example, the embodiments of the present application can calculate the hash value of the diskless system image by using SHA-256 (Secure Hash Algorithm 256) or MD5 (Message-Digest Algorithm 5) algorithm, and when a hash value mismatch is detected, automatically trigger the reconstruction process, that is, automatically reconstruct the root file system by script, which can use incremental update, that is, replace only the difference file; or full reconstruction, that is, regenerate the root file system from the source image. The specific settings can be made by those skilled in the art according to the actual situation, and the present application does not make specific limitations.

[0047] Further, the embodiments of the present application inject the startup parameters through the PXE boot loader after the hash value matches to start the corresponding diskless system.

[0048] The embodiments of the present application can obtain the hash value of the diskless system before starting the pre-constructed diskless system, and judge whether the hash value is equal to the target hash value. If not, the diskless system is reconstructed until the hash value is equal to the target hash value, and the reconstructed diskless system is allowed to start. Otherwise, the corresponding diskless system is allowed to start directly. The data consistency verification avoids startup failure or abnormal operation caused by system damage, improves system stability, reduces failure rate, does not require manual intervention, reduces operation and maintenance cost, and is suitable for various diskless architectures and flexible deployment.

[0049] Optionally, in an embodiment of the present application, before performing the flashing of the abnormal firmware according to the image file, it further includes: obtaining a target image file of the target abnormal firmware; based on the target abnormal firmware and the target image file, performing the flashing of the target abnormal firmware according to the target image file, and calculating a flashing failure rate of the target abnormal firmware flashing; based on the target abnormal firmware, the target image file and the flashing failure rate, constructing a flashing execution prediction model.

[0050] It can be understood that in the embodiments of the present application, the image file can be understood as a copy file completely consistent with the original file or system, which is stored in a specific format and contains all data and structure information of the file system, and can be used for data backup, recovery and system deployment operations. In the firmware flashing scenario, the image file contains all program codes and configuration information required by the target firmware, and is the basic data source of the flashing operation.

[0051] Further, the embodiment of the present application can calculate the flash failure rate of the target abnormal firmware when the target abnormal firmware is flashed by the target image file.

[0052] In actual execution, the embodiment of the present application can calculate the flash failure rate of the target abnormal firmware according to the target abnormal firmware and the corresponding target image file before flashing the abnormal firmware according to the image file, and then construct a flash execution prediction model based on the target abnormal firmware, the target image file and the flash failure rate.

[0053] For example, when collecting the target abnormal firmware and the corresponding target image file of different models of devices, the obtained information can include but is not limited to firmware version, device hardware parameters, flash tool version and flash failure condition, and the present application is not limited thereto. A flash execution prediction model is constructed by using a machine learning algorithm. When a new device needs to be flashed, the corresponding firmware information is input into the flash execution prediction model to predict the flash failure rate of this time.

[0054] The embodiment of the present application can calculate the flash failure rate of the target abnormal firmware according to the target abnormal firmware and the corresponding target image file before flashing the abnormal firmware according to the image file, and then construct a flash execution prediction model. The flash execution prediction model is constructed based on the target abnormal firmware and the corresponding image file, which can accurately construct the flash execution prediction model, avoid misjudgment caused by model generalization, dynamically adapt to device and environment changes, avoid high-risk operations in advance, and improve user experience and business continuity.

[0055] In step S103, when it is detected that the current working state meets the preset abnormal condition, the at least one baseboard management controller is controlled to enter a network boot mode, a pre-constructed diskless system is started, an image file of an abnormal firmware in at least one firmware is downloaded from a preset terminal, the abnormal firmware is flashed according to the image file, and the network boot mode is exited after the abnormal firmware is repaired.

[0056] As a possible implementation, the embodiment of the present application can control the at least one baseboard management controller to enter a network boot mode when it is detected that the current working state meets a certain abnormal condition, and start a pre-constructed diskless system to download an image file of an abnormal firmware in at least one firmware from a preset terminal, and flash the abnormal firmware according to the image file until the abnormal firmware is repaired and the network boot mode is exited.

[0057] The network boot mode is an alternative booting scheme for loading an operating system or a start file from a remote server through a local area network or a wide area network, and a core purpose thereof is to bypass a locally damaged storage medium and ensure that the system can still be normally started.

[0058] For example, when the U-boot detects an abnormal memory partition, damaged firmware, a failed check (hash / signature error), or the like, the embodiment of the present application determines that the current working state of the base management controller meets certain abnormal conditions, and performs repair of the baseboard management controller according to the flow shown in Figure 3

[0059] Step S301: Start the U-Boot.

[0060] Step S302: Obtain firmware information.

[0061] Step S303: Determine whether the firmware is abnormal.

[0062] If the firmware is abnormal, perform step S304; otherwise, perform step S308.

[0063] Step S304: Enter the network boot mode.

[0064] In the embodiment of the present application, the network boot mode can be entered by pressing a key to enter a boot menu, selecting a network boot option, and entering the network boot mode.

[0065] Step S305: Obtain network configuration through DHCP and start a pre-constructed diskless system.

[0066] ​Wherein, the embodiment of the application needs a network environment when entering the diskless system, therefore, U-Boot can first load a network driver (supporting NCSI (Network Controller Sideband Interface), independent baseboard management controller network interface or USB (Universal Serial Bus) device), and then sends a DHCP (Dynamic Host Configuration Protocol) request to obtain the IP address of the baseboard management controller itself, gateway and IP address of the diskless system server, boot loading, after the baseboard management controller configures its own IP and gateway, then downloads the kernel image and diskless system root file system from a preset terminal, such as a remote server (may be in TFTP (Trivial File Transfer Protocol) / HTTP (Hypertext Transfer Protocol) / NFS (Network File System) mode), to start the pre-constructed diskless system.

[0067] Step S306: running a remote tool to refresh the abnormal firmware in the baseboard management controller.

[0068] Wherein, after the diskless system runs, the baseboard management controller loads the kernel image into the memory, starts the linux system from the memory, and then enters the diskless linux system environment.

[0069] Wherein, the diskless linux system is built-in with a minimized management tool, after the diskless linux system is started, the built-in management tool starts to download the image file of the abnormal firmware, firmware verification, etc., and then writes the downloaded image file to the memory in the baseboard management controller; after the writing is completed, the log is recorded and uploaded to the log server.

[0070] Step S307: abnormal firmware repair, exit network boot mode.

[0071] Wherein, after the abnormal firmware repair is completed, the network boot mode is exited, and after the log record is uploaded, a restart is performed, at this time, the normal baseboard management controller firmware running environment is entered.

[0072] Step S308: baseboard management controller normal start.

[0073] The embodiment of the present application realizes diskless system starting from a remote server, does not depend on substrate management controller self storage, reduces recovery dependence, and then can realize firmware downloading, checking and writing under the diskless system without manual intervention; when batch abnormality of data center substrate management controller occurs, batch automatic repair is realized; and on-site maintenance is reduced.

[0074] Optionally, in an embodiment of the present application, the flashing of the abnormal firmware according to the image file comprises: inputting the image file and the abnormal firmware into a pre-constructed flashing execution prediction model to output an actual flashing failure rate of the abnormal firmware flashing; detecting whether the actual flashing failure rate is greater than a preset threshold; in the case that the actual flashing failure rate is greater than the preset threshold, determining that the flashing fails, and re-executing the flashing of the abnormal firmware until the flashing of the abnormal firmware is completed.

[0075] In some embodiments, the embodiment of the present application can input the image file and the abnormal firmware into a pre-constructed flashing execution prediction model, and then output an actual flashing failure rate of the abnormal firmware flashing, and detect whether the actual flashing failure rate is greater than a certain threshold, if greater, determine that the flashing fails, and re-execute the flashing of the abnormal firmware until the flashing of the abnormal firmware is completed. The certain threshold can be set by a person skilled in the art according to the actual situation, and the present application does not make specific limitations.

[0076] For example, the embodiment of the present application detects that 15 firmware of substrate management controllers of 100 servers have firmware abnormalities due to version leakage of the firmware, at this time, the embodiment of the present application can input the image file of the abnormal firmware and the current hardware information into a pre-constructed flashing execution prediction model, and then predict the flashing failure rate of each device, if the flashing failure rate is greater than a certain threshold, take optimization measures (such as adjusting the flashing parameters, replacing the image version), and retry until the repair is successful.

[0077] The embodiment of the present application can input the image file and the abnormal firmware into a pre-constructed flashing execution prediction model, and then output an actual flashing failure rate of the abnormal firmware flashing, and detect whether the actual flashing failure rate is greater than a certain threshold, if greater, determine that the flashing fails, and re-execute the flashing of the abnormal firmware until the flashing of the abnormal firmware is completed, identify high-risk operations in advance, avoid potential failures in advance, reduce failure probability, dynamically adjust flashing strategy, improve overall success rate of flashing, realize full-process automation, reduce manual intervention, protect key equipment, enhance system stability, guarantee business continuity, and improve user experience.

[0078] Optionally, in an embodiment of the present application, before re-executing the flashing of the abnormal firmware, further comprising: counting the total number of execution of the flashing; determining whether the total number of execution is greater than a preset number of times; if the total number of execution is greater than the preset number of times, generating an abnormal alarm corresponding to the baseboard management controller according to the mirror file and the abnormal firmware, and prohibiting the flashing of the abnormal firmware; if the total number of execution is less than or equal to the preset number of times, allowing the re-execution of the flashing of the abnormal firmware.

[0079] In some embodiments, before re-executing the flashing of the abnormal firmware, the present application embodiment can first count the total number of execution of the flashing, and determine whether the total number of execution is greater than a certain number of times, if greater, generate an abnormal alarm corresponding to the baseboard management controller according to the mirror file and the abnormal firmware, and prohibit the flashing of the abnormal firmware, otherwise, allow the re-execution of the flashing of the abnormal firmware. Wherein, the certain number of times can be set by the person skilled in the art according to the actual situation, and the present application does not make specific limitations.

[0080] For example, in the repair process of 15 baseboard management controllers, the present application embodiment can set the certain number of times to 2 times, for baseboard management controller 1, the first flashing fails due to network jitter; the second flashing succeeds after adjusting the timeout parameter, at this time, the total number of execution is 2 times, equal to 2 times, not exceeding the limit, and the process ends normally; for baseboard management controller 2, the first flashing fails due to memory damage; the second flashing still fails after replacing the image; the third flashing fails after trying to reduce the flashing speed, at this time, the total number of execution is 3 times, greater than 2 times, therefore, the present application embodiment can intercept the fourth flashing and generate a corresponding alarm signal.

[0081] Before re-executing the flashing of the abnormal firmware, the present application embodiment can first count the total number of execution of the flashing, and determine whether the total number of execution is greater than a certain number of times, if greater, generate an abnormal alarm, and prohibit the flashing of the abnormal firmware, otherwise, allow the re-execution of the flashing of the abnormal firmware, prevent unlimited retries, avoid system paralysis, precise fault location, accelerate problem repair, hierarchical response strategy, optimize operation and maintenance resource allocation, compatible with complex environment, adapt to diversification equipment.

[0082] Optionally, in an embodiment of the present application, the flashing of the abnormal firmware according to the mirror file comprises: determining the replacement priority of the abnormal firmware according to the firmware parameters and the dependency relationship of the abnormal firmware; and executing the flashing of the abnormal firmware according to the replacement priority.

[0083] It can be understood that in the embodiments of the present application, the dependency relationship between the firmwares can be divided into hardware dependency, such as firmware A requiring that the device must be equipped with a specific model of a baseboard management controller chip; and software dependency, such as firmware B requiring that the basic firmware C be flashed first, otherwise it cannot be loaded. Therefore, in order to avoid the failure of flashing the abnormal firmware due to the missing dependency, it is necessary to ensure that the flashing order is correct.

[0084] Further, the embodiments of the present application can determine the replacement priority of the abnormal firmware according to the firmware parameters and the dependency relationship, and then perform the flashing of the abnormal firmware according to the corresponding replacement priority. In the embodiments of the present application, the replacement priority can be divided into three levels, wherein priority 1> priority 2> priority 3.

[0085] For example, when the firmware of 200 baseboard management controllers is upgraded to repair vulnerabilities, each device runs multiple firmwares (such as main control firmware, communication firmware, sensor driver firmware). The embodiments of the present application can first obtain the firmware parameters of the abnormal firmware, such as version number, dependency level, etc., and then determine the dependency relationship between different firmwares, such as the communication firmware depending on a specific version of the main control firmware, and then use the weighted scoring method to calculate the priority score of each firmware, and divide the replacement priority into three levels from high to low according to the priority score, and then perform the flashing of the abnormal firmware in stages, such as priority 3 performing the flashing of the basic layer, such as the main control firmware; priority 2 performing the flashing of the middle layer, such as the communication firmware; and priority 1 performing the flashing of the application layer, such as the sensor driver firmware, and the 200 devices are divided into batches for flashing, 50 devices per batch, and multi-threading is used to shorten the overall time.

[0086] The embodiments of the present application can determine the replacement priority of the abnormal firmware according to the firmware parameters and the dependency relationship of the abnormal firmware, and then perform the flashing of the abnormal firmware according to the replacement priority, preferentially flash the firmware with the replacement priority, avoid dependency conflicts, ensure the success rate of flashing, ensure that the device can still maintain basic services during the flashing process, reduce the risk of device downtime, ensure business continuity, improve large-scale deployment efficiency, significantly improve the security, efficiency and scalability of the upgrade process, and is especially suitable for large-scale, high-complexity, multi-component device maintenance scenarios, which can effectively reduce the operation and maintenance risk and cost.

[0087] Optionally, in an embodiment of the present application, downloading the image file of the abnormal firmware from at least one firmware in the preset terminal comprises: identifying the fault type of the abnormal firmware; matching the initial image file suitable for the fault type for the abnormal firmware based on the fault type; and screening the initial image file to obtain the image file.

[0088] As a possible implementation manner, the embodiment of the application can match the initial image file suitable for the failure type for the abnormal firmware according to the failure type of the abnormal firmware, and screen the initial image file to obtain the image file. The failure type may, but is not limited to, include storage medium damage, version conflict, etc., and the application does not make specific limitations.

[0089] For example, in the case that the baseboard management controller has abnormal firmware, the embodiment of the application screens the initial image file according to the failure type of the abnormal firmware, for example, if the failure type is storage medium damage, a low-level repair image is matched; if the failure type is version conflict, a compatibility image is matched, and further, the embodiment of the application further screens the initial image file, such as hardware compatibility, and further obtains the final image file.

[0090] The embodiment of the application can first match the initial image file suitable for the failure type for the abnormal firmware according to the failure type of the abnormal firmware, and screen the initial image file to obtain the final image file. The failure drive matching, accurate repair, and risk reduction decompose the acquisition of the image file into three steps of failure identification, initial matching, and fine screening, each of which can be automatically executed through a script or a tool, reducing manual intervention, greatly shortening the upgrade cycle, saving manpower and time cost, and supporting multi-firmware collaborative upgrade, flexible adaptation, and complex scenarios.

[0091] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and a necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better implementation manner.

[0092] The repair method of the baseboard management controller according to the embodiment of the application can obtain the firmware information of the firmware managed by the baseboard management controller when it is detected that the baseboard management controller is in the universal boot loader stage, and then detect whether the current working state of the corresponding baseboard management controller meets certain abnormal conditions according to the firmware information of each firmware, and when it meets, control the baseboard management controller to enter the network boot mode, start the pre-constructed diskless system to download the image file of the abnormal firmware from the pre-set terminal, and execute the flashing of the abnormal firmware according to the image file, so as to exit the network boot mode after the abnormal firmware is repaired. Therefore, the technical problems of the remote refreshing scheme, such as complex hardware design caused by complex programmable logic device and network module, firmware defects easily causing upgrade failure and whole machine paralysis, lack of security start mechanism threatening safety, and the like can be solved. The universal boot repair method needs manual firmware transmission, and the efficiency is low and difficult to maintain in batches. The technical effects of reducing external dependence for firmware recovery, automatically realizing batch repair of the baseboard management controller by script, reducing on-site maintenance, and improving maintainability are achieved.

[0093] Embodiments of this application also provide a repair apparatus for a substrate management controller.

[0094] Figure 4 This is a block diagram of a repair apparatus for a substrate management controller provided according to an embodiment of this application.

[0095] like Figure 4 As shown, the repair device 10 of the substrate management controller includes: a first acquisition module 100, a detection module 200 and a repair module 300.

[0096] The first acquisition module 100 is used to acquire firmware information of at least one firmware managed by at least one baseboard management controller when it is detected that at least one baseboard management controller is in the general bootloader stage.

[0097] The detection module 200 is used to detect whether the current working state of the corresponding baseboard management controller meets the preset abnormal conditions based on the firmware information of each firmware.

[0098] The repair module 300 is used to control at least one baseboard management controller to enter network boot mode when the current working state is detected to meet the preset abnormal conditions, start the pre-built diskless system, download the image file of the abnormal firmware in at least one firmware from the preset terminal, perform the flashing of the abnormal firmware according to the image file, and exit the network boot mode after the abnormal firmware is repaired.

[0099] Optionally, in one embodiment of this application, it further includes: a determination module, a response module, and a construction module.

[0100] The determination module is used to determine the network operation data of the diskless system based on the network data of at least one baseboard management controller and the initial address identifier of the diskless system before starting the pre-built diskless system.

[0101] The response module is used to respond to the boot load instructions of the diskless system to obtain the kernel image and root file system of the diskless system based on network runtime data.

[0102] The build module is used to build diskless systems based on kernel images and root file systems.

[0103] Optionally, in one embodiment of this application, the construction module includes: an acquisition unit, a first determination unit, and a construction unit.

[0104] The acquisition unit is used to extract image parameters from the kernel image that meet preset working conditions.

[0105] The first determining unit is used to determine the loading method of the root file system based on the system data of the root file system.

[0106] A construction unit is configured to construct the diskless system based on the mirror parameter and the loading mode.

[0107] Optionally, in an embodiment of the present application, the method further comprises a second obtaining module, a first judging module, a first starting module and a second starting module.

[0108] The second obtaining module is configured to obtain the hash value of the diskless system before starting the pre-constructed diskless system.

[0109] The first judging module is configured to judge whether the hash value is equal to the target hash value.

[0110] The first starting module is configured to re-construct the diskless system until the hash value is equal to the target hash value when the hash value is not equal to the target hash value, and allow starting the re-constructed diskless system.

[0111] The second starting module is configured to allow starting the diskless system when the hash value is equal to the target hash value.

[0112] Optionally, in an embodiment of the present application, the repairing module 300 comprises a second determining unit and an executing unit.

[0113] The second determining unit is configured to determine the replacement priority of the abnormal firmware according to the firmware parameter and the dependency relationship of the abnormal firmware.

[0114] The executing unit is configured to execute the flashing of the abnormal firmware according to the replacement priority.

[0115] Optionally, in an embodiment of the present application, the repairing module 300 comprises an identifying unit, a matching unit and a screening unit.

[0116] The identifying unit is configured to identify the fault type of the abnormal firmware.

[0117] The matching unit is configured to match the initial mirror file suitable for the fault type for the abnormal firmware based on the fault type.

[0118] The screening unit is configured to screen the initial mirror file to obtain the mirror file.

[0119] Optionally, in an embodiment of the present application, the method further comprises a third obtaining module, a calculating module and a predicting module.

[0120] The third obtaining module is configured to obtain the target mirror file of the target abnormal firmware before executing the flashing of the abnormal firmware according to the mirror file.

[0121] The computing module is configured to calculate a flashing failure rate of the target abnormal firmware based on the target abnormal firmware and the target image file.

[0122] The prediction module is configured to construct a flashing execution prediction model based on the target abnormal firmware, the target image file and the flashing failure rate.

[0123] Optionally, in an embodiment of the present application, the repairing module 300 comprises an input unit, a detection unit and a determination unit.

[0124] The input unit is configured to input the image file and the abnormal firmware into the pre-constructed flashing execution prediction model to output an actual flashing failure rate of the abnormal firmware flashing.

[0125] The detection unit is configured to detect whether the actual flashing failure rate is greater than a preset threshold value.

[0126] The determination unit is configured to determine flashing failure and re-execute the flashing of the abnormal firmware until the flashing of the abnormal firmware is completed, when the actual flashing failure rate is greater than the preset threshold value.

[0127] Optionally, in an embodiment of the present application, the repairing module 300 further comprises a statistical module, a second determination module, a first execution module and a second execution module.

[0128] The statistical module is configured to count a total number of executions of the flashing before re-executing the flashing of the abnormal firmware.

[0129] The second determination module is configured to determine whether the total number of executions is greater than a preset number of times.

[0130] The first execution module is configured to generate an abnormal alarm of the corresponding baseboard management controller according to the image file and the abnormal firmware and prohibit the flashing of the abnormal firmware when the total number of executions is greater than the preset number of times.

[0131] The second execution module is configured to allow the re-execution of the flashing of the abnormal firmware when the total number of executions is less than or equal to the preset number of times.

[0132] The features of the embodiments of the repairing device of the baseboard management controller can be referred to the related descriptions of the embodiments of the repairing method of the baseboard management controller, which will not be repeated here.

[0133] The repair device of the baseboard management controller provided in the embodiment of the present application can acquire firmware information of firmware managed by the baseboard management controller when it is detected that the baseboard management controller is in the universal bootloader stage, and then detect whether the current working state of the corresponding baseboard management controller meets certain abnormal conditions according to the firmware information of each firmware, and control the baseboard management controller to enter the network boot mode when the abnormal conditions are met, start the pre-constructed diskless system to download the image file of the abnormal firmware from the preset terminal, and perform the flashing of the abnormal firmware according to the image file, so as to exit the network boot mode after the abnormal firmware is repaired. Therefore, the technical problems that the remote refreshing scheme is complex in hardware design due to the complex programmable logic device and the network module, the firmware defects easily cause the upgrading failure and the whole machine paralysis, and in addition, there is a lack of security start mechanism to threaten the security, the universal boot repair method needs to manually transmit the firmware, the efficiency is low, and it is difficult to maintain in batches can be solved, the technical effects that the external dependence for firmware recovery is reduced, the script is automatically used to realize the batch repair of the baseboard management controller, the on-site maintenance is reduced, and the maintainability is improved are achieved.

[0134] The embodiment of the present application further provides an electronic device, including a memory and a processor, the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in the baseboard management controller repair method embodiments.

[0135] The embodiment of the present application further provides a computer readable storage medium, which stores a computer program, wherein the computer program is configured to execute the steps in the baseboard management controller repair method embodiments when running.

[0136] In an example embodiment, the computer readable storage medium described above can include but is not limited to a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0137] The embodiment of the present application further provides a computer program product, which includes a computer program, and the computer program is executed by a processor to implement the steps in the baseboard management controller repair method embodiments.

[0138] The embodiment of the present application further provides another computer program product, which includes a non-volatile computer readable storage medium, and the non-volatile computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps in the baseboard management controller repair method embodiments.

[0139] Those skilled in the art will further realize that the mere concepts, teachings, and embodiments described herein are merely meant to provide an enabling description of the applications and are not intended to limit the scope of the applications. Therefore, embodiments or examples described herein are not meant to be limiting, but merely to aid in the understanding of the overall more complete disclosure of the applications. Accordingly, those skilled in the art will recognize that modifications and variations of the more complete description herein can be resorted to without departing from the spirit and scope of the applications. Therefore, it is intended that the applications encompass all such modifications and variations as fall within the scope of the applications. All articles, patents, and other publications that have been cited are incorporated herein by reference for the aspects not inconsistent with the present disclosure.

[0140] The above has carried on the detailed introduction to the repair method of the substrate management controller provided by the application. The principle and implementation mode of the application are described by applying specific examples in the present disclosure. The above description of the embodiments is only used to help understand the method and core idea of the application. It should be pointed out that for those skilled in the art, some improvements and modifications can be made to the application without departing from the principle of the application. These improvements and modifications also fall within the protection scope of the claims of the application.

Claims

1. A method of repairing a baseboard management controller, the method comprising: The method comprises the following steps: In the case of detecting that at least one baseboard management controller is in a general boot loader stage, obtaining firmware information of at least one firmware managed by the at least one baseboard management controller; According to the firmware information of each firmware, detecting whether the current working state of the corresponding baseboard management controller meets a preset abnormal condition; In the case of detecting that the current working state meets the preset abnormal condition, controlling the at least one baseboard management controller to enter a network boot mode, starting a pre-constructed diskless system, downloading an image file of an abnormal firmware from a preset terminal, performing flashing of the abnormal firmware according to the image file, and exiting the network boot mode after the abnormal firmware is repaired. Before starting the pre-constructed diskless system, the method further comprises: Based on the network data of the at least one baseboard management controller and the initial address identification of the diskless system, determining the network running data of the diskless system; In response to a boot loading instruction of the diskless system, obtaining a kernel image and a root file system of the diskless system based on the network running data; Based on the kernel image and the root file system, constructing the diskless system.

2. The method of claim 1, wherein, The construction of the diskless system based on the kernel image and the root file system comprises: Extracting an image parameter in the kernel image that meets a preset working condition; According to system data of the root file system, determining a loading mode of the root file system; Based on the image parameter and the loading mode, constructing the diskless system.

3. The method of claim 1, wherein, Before starting the pre-constructed diskless system, the method further comprises: Obtaining a hash value of the diskless system; Judging whether the hash value is equal to a target hash value; If the hash value is not equal to the target hash value, reconstructing the diskless system until the hash value is equal to the target hash value, and allowing to start the reconstructed diskless system; If the hash value is equal to the target hash value, allowing to start the diskless system.

4. The method of claim 1, wherein, The flashing of the abnormal firmware according to the image file comprises: According to firmware parameters and a dependency relationship of the abnormal firmware, determining a replacement priority of the abnormal firmware; According to the replacement priority, performing the flashing of the abnormal firmware.

5. The method of claim 1, wherein, The downloading of the image file of the abnormal firmware from the preset terminal comprises: Identifying a fault type of the abnormal firmware; Based on the fault type, matching an initial image file suitable for the fault type for the abnormal firmware; Screening the initial image file to obtain the image file.

6. The method of claim 1, wherein, Before performing the flashing of the abnormal firmware according to the image file, the method further comprises: Obtaining a target image file of a target abnormal firmware; Based on the target abnormal firmware and the target image file, performing the flashing of the target abnormal firmware according to the target image file, and calculating a flashing failure rate of the target abnormal firmware; Based on the target abnormal firmware, the target image file, and the flashing failure rate, constructing a flashing execution prediction model.

7. The method of claim 6, wherein, The flashing of the abnormal firmware according to the image file comprises: inputting the mirror image file and the abnormal firmware into a pre-constructed flashing execution prediction model to output an actual flashing failure rate of the abnormal firmware flashing; detecting whether the actual flashing failure rate is greater than a preset threshold value; in a case where the actual flashing failure rate is greater than the preset threshold value, determining that the flashing fails and re-executing the flashing of the abnormal firmware until the flashing of the abnormal firmware is completed.

8. The method of claim 7, wherein, Before re-executing the flashing of the abnormal firmware, further comprising: counting a total number of executions of the flashing; judging whether the total number of executions is greater than a preset number value; if the total number of executions is greater than the preset number value, generating an abnormal alarm of the corresponding baseboard management controller according to the mirror image file and the abnormal firmware, and prohibiting the flashing of the abnormal firmware; if the total number of executions is less than or equal to the preset number value, allowing the flashing of the abnormal firmware to be re-executed.

9. An electronic device, comprising: comprising: a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor executing the program to implement the repair method of the baseboard management controller according to any one of claims 1-8.

Images