CN116089153A - BMC Abnormal Factor Confirmation Method, System, Terminal and Storage Medium - Google Patents

Abstract

The present invention relates to the technical field of servers, and specifically provides a BMC abnormal factor confirmation method, system, terminal, and storage medium, including: generating a first image and a second image respectively for the new and old versions of firmware corresponding to the BMC; presetting the priority of the first image If the priority is higher than that of the second image, the boot program starts the BMC according to the priority of the image file; the abnormal factors of the BMC are confirmed based on the BMC startup execution result and the boot image file. The present invention realizes the confirmation of the factors causing BMC abnormality. When the BMC fails to restore the normal environment after restarting, the maintenance personnel can quickly confirm whether the BMC version function is abnormal or the laboratory network environment is abnormal, and timely check the BMC version or the laboratory network. maintain.

Description

BMC Abnormal Factor Confirmation Method, System, Terminal and Storage Medium

technical field

The invention belongs to the technical field of servers, and in particular relates to a BMC abnormal factor confirmation method, system, terminal and storage medium.

Background technique

At present, the BMC that supports firmware update can perform BMC image refresh through methods such as BMCweb, Yafuflash, and Restful scripts, which has ensured the continuous improvement of BMC functions. When the BMC Firmware refresh progress reaches 100%, the BMC will restart, and the BMC version will be rolled back after the restart is completed, so as to realize the BMC version update.

If the firmware version is abnormal, there will be a situation where the BMC cannot return to normal after restarting (for example, cannot log in to BMCweb), and there will be a lack of specific fault logs. However, if the BMC performs firmware update under the laboratory network, due to the interference of the laboratory network failure, sometimes the BMC cannot restore the normal environment after restarting (for example, cannot log in to BMCweb), and there is a lack of specific fault logs.

Therefore, when refreshing the BMC firmware in the laboratory network environment, when there is an abnormality after the BMC restarts, it is impossible to distinguish whether the abnormality of the BMC environment is caused by the functional problem of the BMC version itself, or the interference of the laboratory network failure.

Contents of the invention

In view of the above-mentioned deficiencies in the prior art, the present invention provides a BMC abnormal factor confirmation method, system, terminal and storage medium to solve the above-mentioned technical problems.

In the first aspect, the present invention provides a method for confirming abnormal BMC factors, including:

The new and old versions of firmware corresponding to the BMC generate the first image and the second image respectively;

The priority of the first image is pre-set higher than that of the second image, and the boot program boots the image file according to the priority to start the BMC;

Confirm the BMC abnormal factors based on the BMC startup execution result and the boot image file.

In an optional implementation manner, the new and old versions of firmware corresponding to the BMC generate a first image and a second image respectively, including:

Generate a second image for the BMC before the BMC performs a firmware refresh;

Save the image file uploaded after the BMC firmware version is updated as the first image.

In an optional embodiment, the priority of the first image is preset to be higher than that of the second image, and the boot program boots the image file according to the priority to start the BMC, including:

Restart the BMC after the BMC image refresh progress is completed;

In the BMC restart phase, the boot program will first boot the first image to start, and if the startup fails, it will boot the second image to start;

Write the execution result of the boot program to boot the first image into the record log.

In an optional embodiment, in the BMC restart phase, the boot program gives priority to booting the first image to start, and if the startup fails, then boots the second image to start, including:

A corresponding trigger task is generated based on the execution result of the boot program booting the first image, and the trigger task is used to trigger the boot program to switch the second image to start the BMC.

In an optional implementation manner, a corresponding trigger task is generated based on the execution result of bootstrap booting the first image startup, including:

If the boot program guides the first image to start successfully, then add the first task in the background, and the first task is used to instruct the BMC to restart and perform firmware version verification to the BMC after the restart;

If the boot program fails to guide the first image to start, a second task is added in the background, and the second task is used to instruct the boot program to guide the second image to start.

In an optional embodiment, if the boot program guides the first image to start successfully, then add a first task in the background, and the first task is used to instruct the BMC to restart and check the firmware version of the restarted BMC, include:

After restarting the BMC, obtain the current firmware version of the BMC, compare the consistency between the current firmware version and the pre-stored initial firmware version, and save the comparison result to the record log;

Use the prestored account information to send a login request to the BMC network, and save the prompt information fed back by the BMC network based on the login request to the record log, and the prompt information is used to prompt whether the login to the BMC network is successful.

In an optional implementation manner, the BMC abnormal factors are confirmed based on the BMC startup execution result and the boot image file, including:

If the BMC starts normally, and the first mirror image failed to start is recorded in the log, it is determined that the BMC version after the firmware refresh is not functioning properly;

If the BMC starts normally, and the current firmware version is inconsistent with the pre-stored initial firmware version, it is determined that the BMC firmware is refreshed successfully;

If the BMC starts normally and the current firmware version is consistent with the pre-stored initial firmware version, it is judged that the BMC firmware update failed;

If you fail to log in to the BMC network after the BMC starts, it is determined that the network environment is abnormal.

In a second aspect, the present invention provides a BMC abnormal factor confirmation system, including:

The image definition module is used to generate the first image and the second image respectively for the new and old versions of the firmware corresponding to the BMC;

The boot setting module is used to pre-set the priority of the first mirror image higher than the second mirror image, and the boot program starts the BMC by booting the mirror image file according to the priority;

The factor confirmation module is used to confirm the BMC abnormal factor based on the BMC startup execution result and the boot image file.

In an optional implementation manner, the image definition module includes:

The image generation unit is used to generate a second image for the BMC before the BMC performs firmware refresh;

The image storage unit is used to save the image file uploaded after the BMC updates the firmware version as the first image.

In an optional implementation manner, the boot setting module includes:

The progress monitoring unit is used to restart the BMC after the image refresh progress of the BMC is completed;

The image switching unit is used for the boot program to preferentially guide the first image to start during the BMC restart phase, and to guide the second image to start if the start fails;

The execution recording unit is used to write the execution result of the boot program to guide the first image to start into the recording log.

In an optional implementation manner, the image switching unit specifically performs:

A corresponding trigger task is generated based on the execution result of the boot program booting the first image, and the trigger task is used to trigger the boot program to switch the second image to start the BMC.

In an optional implementation manner, a corresponding trigger task is generated based on the execution result of bootstrap booting the first image startup, including:

If the boot program guides the first image to start successfully, then add the first task in the background, and the first task is used to instruct the BMC to restart and perform firmware version verification to the BMC after the restart;

If the boot program fails to guide the first image to start, a second task is added in the background, and the second task is used to instruct the boot program to guide the second image to start.

In an optional embodiment, if the boot program guides the first image to start successfully, then add a first task in the background, and the first task is used to instruct the BMC to restart and check the firmware version of the restarted BMC, include:

After restarting the BMC, obtain the current firmware version of the BMC, compare the consistency between the current firmware version and the pre-stored initial firmware version, and save the comparison result to the record log;

Use the prestored account information to send a login request to the BMC network, and save the prompt information fed back by the BMC network based on the login request to the record log, and the prompt information is used to prompt whether the login to the BMC network is successful.

In an optional implementation manner, the factor confirmation module includes:

The first judging unit is used to determine that the BMC version function after the firmware refresh is abnormal if the BMC starts normally and records that the first image fails to start in the recording log;

The second judging unit is used to determine that the BMC firmware refresh is successful if the BMC starts normally and the current firmware version is inconsistent with the pre-stored initial firmware version;

The third judging unit is used to determine that the BMC firmware refresh fails if the BMC starts normally and the current firmware version is consistent with the pre-stored initial firmware version;

The fourth judging unit is used for judging that the network environment is abnormal if the login to the BMC network fails after the BMC is started.

In a third aspect, a terminal is provided, including:

processor, memory, where,

The memory is used to store computer programs,

The processor is used to call and run the computer program from the memory, so that the terminal executes the above-mentioned terminal method.

In a fourth aspect, a computer storage medium is provided, and instructions are stored in the computer-readable storage medium, and when run on a computer, the computer is made to execute the methods described in the above aspects.

The beneficial effect of the present invention is that, the BMC abnormal factor confirmation method, system, terminal and storage medium provided by the present invention realize the confirmation of the factors leading to BMC abnormality by redefining the boot process of BMC startup and recording the image file boot execution result , when the normal environment cannot be restored after the BMC is restarted, the maintenance personnel can quickly confirm whether the function of the BMC version is abnormal or the laboratory network environment is abnormal, and maintain the BMC version or the laboratory network in time.

In addition, the design principle of the present invention is reliable, the structure is simple, and has very wide application prospects.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, for those of ordinary skill in the art, In other words, other drawings can also be obtained from these drawings on the premise of not paying creative work.

Fig. 1 is a schematic flowchart of a method according to an embodiment of the present invention.

Fig. 2 is another schematic flowchart of the method of an embodiment of the present invention.

Fig. 3 is a schematic block diagram of a system according to one embodiment of the present invention.

FIG. 4 is a schematic structural diagram of a terminal provided by an embodiment of the present invention.

Detailed ways

In order to enable those skilled in the art to better understand the technical solutions in the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described The embodiments are only some of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts shall fall within the protection scope of the present invention.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the technical field of the invention. The terms used herein in the description of the present invention are for the purpose of describing specific embodiments only, and are not intended to limit the present invention.

Key terms appearing in the present invention are explained below.

BMC, executive server remote management controller, the English full name is Baseboard Management Controller. It is the base board management controller. It can upgrade the firmware of the machine, check the machine equipment, and other operations when the machine is not powered on. Full implementation of IPMI functionality in the BMC requires a powerful 16-bit or 32-bit microcontroller with RAM for data storage, flash memory and firmware for non-volatile data storage, and secure remote reboot , safe power cycle, LAN alerts and system health monitoring can provide basic remote manageability. In addition to the basic IPMI function and system work monitoring function, mBMC can also realize the selection and protection of BIOS fast components by using one of the two flash memories to store the previous BIOS. For example, when the system cannot be started after the remote BIOS upgrade, the remote administrator can switch back to the previous working BIOS image to start the system. Once the BIOS is upgraded, the BIOS image can also be locked, which can effectively prevent viruses from invading it.

U-Boot is a boot loader mainly used in embedded systems, which can support many different computer system structures. List of main functions that U-Boot can support: system boot supports NFS mount, RAMDISK (compressed or uncompressed) root file system; supports NFS mount, boots compressed or non-compressed system kernel from FLASH; basic auxiliary functions are powerful The interface function of the operating system; it can flexibly set and transfer multiple key parameters to the operating system, which is suitable for the debugging requirements and product release of the system at different development stages, especially Linux support is the most powerful; it supports multiple storage methods for target board environment parameters, such as FLASH, NVRAM, EEPROM; CRC32 check can verify whether the kernel and RAMDISK image files in FLASH are intact; device drivers such as serial port, SDRAM, FLASH, Ethernet, LCD, NVRAM, EEPROM, keyboard, USB, PCMCIA, PCI, RTC, etc. Support; power-on self-test function SDRAM, FLASH size automatic detection; SDRAM fault detection; CPU model; special function XIP kernel boot.

U-boot codes that depend on the cpu architecture (such as device initialization codes, etc.) are usually placed in stage1 and can be implemented in assembly language, while stage2 is usually implemented in C language, so that complex functions can be realized, and there are more Good readability and portability. The specific start-up process includes:

1. stage1 (start.s code structure)

The stage1 code of U-boot is usually placed in the start.s file, which is written in assembly language, and its main code parts are as follows:

(1) Define the entry. Since an executable image must have one entry point, and there can only be one global entry point, usually this entry is placed at address 0x0 of the rom (Flash), therefore, the compiler must be notified to let it know this entry point, and this work can be done through Modify the linker script to do it.

(2) Set exception vector (exception vector).

(3) Set the CPU speed, clock frequency and interrupt control register.

(4) Initialize the memory controller.

(5) Copy the program in rom to ram.

(6) Initialize the stack.

(7) Go to ram for execution, and this work can be done by using the command ldrpc.

2. stage2 (C language code part)

The start armboot in lib_arm/board.c is the function started by the C language, and it is also the main function of the C language in the entire startup code. It is also the main function of the entire u-boot (armboot). This function mainly completes the following operations:

(1) Call a series of initialization functions.

(2) Initialize the flash device.

(3) Initialize the system memory allocation function.

(4) If the target system has a nand device, initialize the nand device.

(5) If the target system has a display device, initialize this type of device.

(6) Initialize relevant network equipment, fill in ip, c addresses, etc.

(7) Enter the command cycle (that is, the working cycle of the entire boot), accept the command input by the user from the serial port, and then perform corresponding work.

Image files are similar to rar ZIP archives. It makes a series of specific files into a single file in a certain format to facilitate users to download and use, such as an operating system, games, etc. Its most important feature is that it can be recognized by specific software and can be directly burned to a CD. In fact, the image file in the usual sense can be extended, and more information can be included in the image file. For example, system files, boot files, partition table information, etc., so that the image file can contain all the information of a partition or even a hard disk. In general, burning software can directly burn the content contained in the supported image file to the CD. In fact, the image file is the "extract" of the disc.

The BMC abnormal factor confirmation method provided by the embodiment of the present invention is executed by computer equipment, and accordingly, the BMC abnormal factor confirmation system runs in the computer equipment.

Fig. 1 is a schematic flowchart of a method according to an embodiment of the present invention. Wherein, the execution subject in Fig. 1 may be a BMC abnormal factor confirmation system. According to different requirements, the order of the steps in the flowchart can be changed, and some can be omitted.

As shown in Figure 1, the method includes:

Step 110, corresponding to the new and old versions of the firmware of the BMC to generate a first mirror image and a second mirror image respectively;

Step 120, presetting the priority of the first image is higher than the second image, and the boot program boots the image file according to the priority to start the BMC;

Step 130, confirming BMC abnormal factors based on the BMC startup execution result and the boot image file.

The present invention adopts the method of asynchronous refresh, after the BMC uploads the image and completes 100% of the refresh progress, the BMC version information after the current refresh is obtained for verification. If the mirror cannot be started, it is transformed into booting the main mirror to start, and a log of the backup mirror startup failure is recorded, and a task of the backup mirror startup failure is added to the background task. If the standby image is started successfully, add a task in the background task to complete the start of the standby image, then the BMC will not fail to start after the BMC is restarted. If the backup image is started successfully but the BMCIP still fails after the BMC is restarted, check whether the laboratory network is abnormal, so as to maintain the BMC version.

In order to facilitate the understanding of the present invention, the method for confirming BMC abnormal factors provided by the present invention will be further described below based on the principle of the method for confirming abnormal BMC factors of the present invention, combined with the process of confirming factors for abnormal BMC factors in the embodiments.

Specifically, please refer to Figure 2, the BMC abnormal factors confirmation method includes:

S1. Generate a first image and a second image respectively for the new and old versions of firmware corresponding to the BMC.

Before the BMC performs firmware refresh, generate a second image for the BMC; save the image file uploaded after the BMC updates the firmware version as the first image.

Specifically, before the BMC executes the firmware version update, the firmware file of the current version is compressed into a mirror image file and saved as a master mirror image. The BMC downloads the new version of the firmware file and executes the refresh of the new version of the firmware file. When the refresh progress is 100%, save the current firmware version as a backup image.

S2. It is preset that the priority of the first image is higher than that of the second image, and the boot program boots the image files according to the priority to start the BMC.

Restart the BMC after the image refresh progress of the BMC is completed; during the BMC restart phase, the boot program will guide the first image to start first, and if the startup fails, it will boot the second image to start; write the execution result of the boot program to guide the first image to start in the record log .

Specifically, the priorities of the primary image and the backup image are set, and the priority of the backup image is higher than that of the primary image. Uboot boots the standby image to start. If the booting of the standby image fails to start the BMC, it will be transformed into booting the main image to start, and a log indicating that the standby image failed to start is recorded.

In another embodiment of the present invention, in order to make Uboot switch the image file in time after starting BMC failure, based on the execution result of the boot program to guide the first image startup to generate a corresponding trigger task, the trigger task is used to trigger the boot program Switch the second image to start BMC.

Specifically, the construction principle of the trigger task includes: if the boot program guides the first image to start successfully, then add the first task in the background, the first task is used to instruct the BMC to restart and perform firmware version verification on the restarted BMC; if If the boot program fails to guide the first image to start, a second task is added in the background, and the second task is used to instruct the boot program to guide the second image to start.

In the actual test process, Uboot boots the standby image to start. If the booting of the standby image fails to start the BMC, a log of the failure of the standby image to start will be recorded, and a task of the failure of the standby image to start will be added to the background task. Based on this task, Uboot will boot the main The image file starts the BMC. If the standby image is started successfully, add a task in the background task to complete the start of the standby image, and then the BMC will not fail to start after the BMC restarts.

S3. Confirm the BMC abnormal factor based on the BMC startup execution result and the boot image file.

After restarting the BMC, obtain the current firmware version of the BMC, compare the consistency between the current firmware version and the pre-stored initial firmware version, and save the comparison result to the record log; use the pre-stored account The prompt information fed back by the login request is saved to the record log, and the prompt information is used to prompt whether the login to the BMC network is successful.

It can be seen that the record log records the execution result (success or failure) of Uboot booting the backup image to start the BMC, the consistency comparison result between the current firmware version and the pre-stored initial firmware version, and the login result of BMC web.

Based on the recorded logs, the following judgments can be made:

If the BMC starts normally, and the first mirror image failed to start is recorded in the log, it is determined that the BMC version after the firmware refresh is not functioning properly;

If the BMC starts normally, and the current firmware version is inconsistent with the pre-stored initial firmware version, it is determined that the BMC firmware is refreshed successfully;

If the BMC starts normally and the current firmware version is consistent with the pre-stored initial firmware version, it is judged that the BMC firmware update failed;

If you fail to log in to the BMC network after the BMC starts, it is determined that the network environment is abnormal.

Specifically, if the BMC fails to boot from the standby image, it is determined that the BMC version function is abnormal. If the BMC is successfully booted from the standby image, a task is added in the background task whose status is that the standby image has started successfully, restarts the BMC, and rolls back the BMC. back) to check whether the BMC version is the refreshed version, and judge whether the BMC can log in to the web normally by checking whether the BMC IP is pinged. If it still fails to log in, it is determined that the laboratory network is faulty.

In some embodiments, the BMC abnormal factor confirmation system 300 may include a plurality of functional modules composed of computer program segments. The computer program of each program segment in the BMC abnormal factor confirmation system 300 can be stored in the memory of the computer device, and executed by at least one processor to perform the function of BMC abnormal factor confirmation (see FIG. 1 for details).

In this embodiment, the BMC abnormal factor confirmation system 300 can be divided into multiple functional modules according to the functions it performs, as shown in FIG. 3 . The functional modules may include: an image definition module 310 , a boot setting module 320 , and a factor confirmation module 330 . The module referred to in the present invention refers to a series of computer program segments that can be executed by at least one processor and can complete fixed functions, and are stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

The image definition module 310 is used to generate the first image and the second image respectively for the new and old versions of the firmware corresponding to the BMC;

The boot setting module 320 is used to pre-set the priority of the first mirror image higher than the second mirror image, and the boot program starts the BMC according to the priority level of the boot mirror image file;

The factor confirming module 330 is configured to confirm BMC abnormal factors based on the BMC boot execution result and the boot image file.

Optionally, as an embodiment of the present invention, the image definition module includes:

The image generation unit is used to generate a second image for the BMC before the BMC performs firmware refresh;

The image storage unit is used to save the image file uploaded after the BMC updates the firmware version as the first image.

Optionally, as an embodiment of the present invention, the boot setting module includes:

The progress monitoring unit is used to restart the BMC after the image refresh progress of the BMC is completed;

The image switching unit is used for the boot program to preferentially guide the first image to start during the BMC restart phase, and to guide the second image to start if the start fails;

The execution recording unit is used to write the execution result of the boot program to guide the first image to start into the recording log.

Optionally, as an embodiment of the present invention, the image switching unit specifically performs:

A corresponding trigger task is generated based on the execution result of the boot program booting the first image, and the trigger task is used to trigger the boot program to switch the second image to start the BMC.

Optionally, as an embodiment of the present invention, a corresponding trigger task is generated based on the execution result of the boot program booting the first image startup, including:

If the boot program guides the first image to start successfully, then add the first task in the background, and the first task is used to instruct the BMC to restart and perform firmware version verification to the BMC after the restart;

If the boot program fails to guide the first image to start, a second task is added in the background, and the second task is used to instruct the boot program to guide the second image to start.

Optionally, as an embodiment of the present invention, if the boot program guides the first image to start successfully, then add a first task in the background, and the first task is used to instruct the BMC to restart and perform firmware version calibration on the restarted BMC. tests, including:

After restarting the BMC, obtain the current firmware version of the BMC, compare the consistency between the current firmware version and the pre-stored initial firmware version, and save the comparison result to the record log;

Use the prestored account information to send a login request to the BMC network, and save the prompt information fed back by the BMC network based on the login request to the record log, and the prompt information is used to prompt whether the login to the BMC network is successful.

Optionally, as an embodiment of the present invention, the factor confirmation module includes:

The first judging unit is used to determine that the BMC version function after the firmware refresh is abnormal if the BMC starts normally and records that the first image fails to start in the recording log;

The second judging unit is used to determine that the BMC firmware refresh is successful if the BMC starts normally and the current firmware version is inconsistent with the pre-stored initial firmware version;

The third judging unit is used to determine that the BMC firmware refresh fails if the BMC starts normally and the current firmware version is consistent with the pre-stored initial firmware version;

The fourth judging unit is used for judging that the network environment is abnormal if the login to the BMC network fails after the BMC is started.

FIG. 4 is a schematic structural diagram of a terminal 400 provided by an embodiment of the present invention. The terminal 400 can be used to execute the method for confirming abnormal BMC factors provided by the embodiment of the present invention.

Wherein, the terminal 400 may include: a processor 410 , a memory 420 and a communication module 430 . These components communicate through one or more buses. Those skilled in the art can understand that the structure of the server shown in the figure does not constitute a limitation to the present invention. It can be a bus structure, a star structure, or a More or fewer components than shown, or combinations of certain components, or different arrangements of components may be included.

Wherein, the memory 420 can be used to store the execution instructions of the processor 410, and the memory 420 can be realized by any type of volatile or non-volatile storage terminal or their combination, such as static random access memory (SRAM), electronic Erasable Programmable Read Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Read Only Memory (PROM), Read Only Memory (ROM), Magnetic Memory, Flash Memory, Magnetic Disk or Optical Disk . When the execution instructions in the memory 420 are executed by the processor 410, the terminal 400 is enabled to perform some or all of the steps in the following above-mentioned method embodiments.

The processor 410 is the control center of the storage terminal, using various interfaces and lines to connect various parts of the entire electronic terminal, by running or executing software programs and/or modules stored in the memory 420, and calling data stored in the memory, To perform various functions of the electronic terminal and/or process data. The processor may be composed of an integrated circuit (Integrated Circuit, IC for short), for example, may be composed of a single packaged IC, or may be composed of multiple packaged ICs connected with the same function or different functions. For example, the processor 410 may only include a central processing unit (Central Processing Unit, CPU for short). In the embodiments of the present invention, the CPU may be a single computing core, or may include multiple computing cores.

The communication module 430 is configured to establish a communication channel, so that the storage terminal can communicate with other terminals. Receive user data sent by other terminals or send user data to other terminals.

The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, and the program may include part or all of the steps in the various embodiments provided by the present invention when executed. The storage medium may be a magnetic disk, an optical disk, a read-only memory (English: read-only memory, abbreviated: ROM) or a random access memory (English: random access memory, abbreviated: RAM), etc.

Therefore, the present invention realizes the confirmation of the factors causing BMC abnormality by redefining the booting process of BMC startup and recording the result of booting the image file. If the version function is abnormal or the laboratory network environment is abnormal, timely maintain the BMC version or the laboratory network. The technical effect achieved by this embodiment can be referred to the description above, and will not be repeated here.

Those skilled in the art can clearly understand that the technologies in the embodiments of the present invention can be implemented by means of software plus a necessary general-purpose hardware platform. Based on such an understanding, the technical solutions in the embodiments of the present invention essentially or the part that contributes to the prior art can be embodied in the form of software products, and the computer software products are stored in a storage medium such as a USB flash drive, mobile Hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), magnetic disk or optical disk and other media that can store program codes, including several instructions to make a computer terminal (It may be a personal computer, a server, or a second terminal, a network terminal, etc.) Execute all or part of the steps of the methods described in the various embodiments of the present invention.

For the same and similar parts among the various embodiments in this specification, refer to each other. In particular, for the terminal embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for relevant details, refer to the description in the method embodiment.

In the several embodiments provided by the present invention, it should be understood that the disclosed system and method can be implemented in other ways. For example, the system embodiments described above are only illustrative. For example, the division of the modules is only a logical function division. There may be other division methods in actual implementation. For example, multiple modules or components can be combined or May be integrated into another system, or some features may be ignored, or not implemented. In another point, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of systems or modules may be in electrical, mechanical or other forms.

The modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, they may be located in one place, or may be distributed to multiple network modules. Part or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional module in each embodiment of the present invention may be integrated into one processing module, each module may exist separately physically, or two or more modules may be integrated into one module.

Although the present invention has been described in detail in conjunction with preferred embodiments with reference to the accompanying drawings, the present invention is not limited thereto. Without departing from the spirit and essence of the present invention, those skilled in the art can make various equivalent modifications or replacements to the embodiments of the present invention, and these modifications or replacements should be within the scope of the present invention/any Those skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present invention, and all should be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims (10)

1. A BMC anomaly factor determination method, comprising:

generating a first image and a second image corresponding to new and old versions of firmware of the BMC respectively;

presetting that the priority of a first image is higher than that of a second image, and starting the BMC by a bootstrap program according to a boot image file with the higher priority;

and confirming the BMC abnormal factors based on the BMC starting execution result and the image file of the starting boot.

2. The method of claim 1, wherein generating the first image and the second image corresponding to the new and old versions of firmware of the BMC, respectively, comprises:

generating a second image for the BMC before the BMC performs firmware refreshing;

and saving the image file uploaded after the BMC updates the firmware version as a first image.

3. The method of claim 1, wherein the first image is preset to have a higher priority than the second image, wherein the boot program starts the BMC according to the boot image file having the higher priority, comprising:

restarting the BMC after the mirror image refreshing progress of the BMC is finished;

in the BMC restarting stage, the bootstrap program preferentially guides the first image to start, and if the starting fails, the bootstrap program guides the second image to start;

and writing the execution result of the boot program for guiding the first image to start into a record log.

4. A method according to claim 3, wherein during the BMC restart phase, the boot program preferentially boots the first image to boot and if the boot fails, boots the second image to boot, comprising:

and generating a corresponding trigger task based on an execution result of the boot program for guiding the first image to start, wherein the trigger task is used for triggering the boot program to switch the second image to start the BMC.

5. The method of claim 4, wherein generating the corresponding trigger task based on the result of the boot program directing the execution of the first image launch comprises:

if the boot program guides the first image to be successfully started, a first task is newly added in the background, wherein the first task is used for indicating the BMC to restart and carrying out firmware version verification on the restarted BMC;

if the boot program fails to boot the first image, a second task is newly added in the background, wherein the second task is used for indicating the boot program to boot the second image.

6. The method of claim 5, wherein if the boot loader directs that the first image is successfully started, adding a first task in the background, where the first task is used to instruct the BMC to restart and perform firmware version verification on the restarted BMC, including:

after restarting the BMC, acquiring a current firmware version of the BMC, comparing the consistency of the current firmware version with a pre-stored initial firmware version, and storing a comparison result into a record log;

and sending a login request to the BMC network by using pre-stored account information, and storing prompt information fed back by the BMC network based on the login request to a log, wherein the prompt information is used for prompting whether the BMC network is successfully logged in or not.

7. The method of claim 6, wherein validating the BMC exception based on the BMC boot execution result and the boot-up image file comprises:

if the BMC is started normally and the first mirror image is recorded in the record log to fail to start, judging that the function of the BMC version after firmware refreshing is abnormal;

if the BMC is started normally and the current firmware version is inconsistent with the pre-stored initial firmware version, judging that the BMC firmware refreshing is successful;

if the BMC is started normally and the current firmware version is consistent with the pre-stored initial firmware version, judging that the BMC firmware refreshing fails;

if the login of the BMC network fails after the BMC is started, the network environment is judged to be abnormal.

8. A BMC anomaly factor validation system, comprising:

the image definition module is used for generating a first image and a second image corresponding to the new version and the old version of the firmware of the BMC respectively;

the boot setting module is used for presetting that the priority of the first image is higher than that of the second image, and the boot program starts the BMC according to the boot image file with the higher priority;

and the factor confirmation module is used for confirming the abnormal factor of the BMC based on the BMC starting execution result and the image file of the starting boot.

9. A terminal, comprising:

a processor;

a memory for storing execution instructions of the processor;

wherein the processor is configured to perform the method of any of claims 1-7.

10. A computer readable storage medium storing a computer program, which when executed by a processor implements the method of any one of claims 1-7.

Images