BIOS automatic configuration method for large-scale server cluster

Abstract

This invention relates to the field of computer remote management technology and discloses a method for automatic BIOS configuration of a large-scale server cluster. The method includes: acquiring and parsing the BIOS configuration file of the target server, extracting the starting instruction, subsequent instructions, and execution logic descriptions of each instruction; after executing the current instruction, selecting the subsequent path according to its logical definition: if defined as sequential execution, selecting the predetermined next instruction; if defined as conditional jump, detecting changes in the BIOS interface and dynamically selecting the corresponding instruction from the subsequent instructions for jump execution based on the recognition result; iterating this process until the termination condition is met, and generating a configuration result. By flexibly defining the sequential and conditional jump logic through the configuration file and realizing intelligent branch navigation based on real-time interface status detection, the method significantly improves the automation level, accuracy, and adaptability to complex interaction scenarios of configuration, fundamentally solving the problems of low efficiency, poor consistency, and inability to batch process graphical interface branches in manual configuration of each server.

Description

Technical Field

[0001] This invention relates to the field of computer remote management technology, and in particular to a method for automatic BIOS configuration of a large-scale server cluster. Background Technology

[0002] In server management, BIOS configuration is a crucial step in server initialization, deployment, and subsequent operation and maintenance. Traditionally, this task relied on administrators manually configuring each server's BIOS settings interface. This manual approach has significant limitations: First, it is inefficient, with the configuration process for a single server typically taking 15 to 30 minutes. For large-scale server cluster deployments, this requires substantial manpower and time, failing to meet the demands of rapid delivery and agile operation. Second, due to its reliance on manual judgment and input, the configuration process carries a high risk of human error, easily leading to inconsistencies in BIOS configuration parameters between servers within the cluster, thus jeopardizing the stability and performance optimization of the entire system. Third, the traditional method lacks a unified configuration management and task distribution platform, essentially operating on a decentralized, point-to-point basis, failing to achieve true batch automation management and consistent policy application. Furthermore, the BIOS interface layout, option names, and interaction logic of different manufacturers and server motherboard models often vary significantly. This heterogeneity makes developing universal automated configuration tools extremely difficult, and traditional solutions struggle to achieve broad compatibility across multiple motherboard models. Summary of the Invention

[0003] The purpose of this invention is to provide an automatic BIOS configuration method for large-scale server clusters. By defining execution logic based on configuration files and realizing dynamic instruction jumps based on interface status detection, the method significantly improves the automation, accuracy, and scenario adaptability of BIOS configuration for large-scale server clusters, and effectively solves the technical problems of low efficiency, error-proneness, and inability to batch process complex interactive branches in manual configuration.

[0004] To address the aforementioned technical problems, a first aspect of this invention provides a method for automatic BIOS configuration of a large-scale server cluster, comprising the following steps:

[0005] Step S100: Obtain the BIOS configuration file corresponding to the target server;

[0006] Step S200: Parse the BIOS configuration file and extract a start operation instruction, several subsequent operation instructions, and the execution logic description of each instruction;

[0007] Step S300: Execute the current operation instruction and perform the corresponding setting action in the BIOS setting interface of the target server. The first current operation instruction executed is the starting operation instruction.

[0008] Step S400: If the execution logic is defined as sequential execution, then a preset next subsequent operation instruction is selected as the operation instruction to be executed; if the execution logic is defined as conditional jump, then the change of the BIOS setting interface after the current operation instruction is executed is detected, and the corresponding subsequent operation instruction is selected from the plurality of subsequent operation instructions based on the interface detection result and jumps to execute.

[0009] In step S500, steps S300 and S400 are repeated. In response to the completion of the process termination condition, result information indicating that the target server BIOS auto-configuration is complete is generated.

[0010] Furthermore, obtaining the BIOS configuration file corresponding to the target server includes:

[0011] Obtain the motherboard model identifier of the target server;

[0012] Based on the motherboard model identifier, match the target motherboard model subdirectory from the preset configuration file directory;

[0013] Obtain at least one configuration file from the target motherboard model subdirectory as the BIOS configuration file, wherein the configuration file is a data file describing a single BIOS operation command in a structured data format.

[0014] Further, obtaining at least one configuration file from the target motherboard model subdirectory as the BIOS configuration file includes:

[0015] Identify the BIOS configuration operation types defined in the configuration file, where the BIOS configuration operation types are predefined identifiers used to instruct the automation interface to perform specific categories of actions;

[0016] Obtain the execution parameters associated with the BIOS configuration operation type, the execution parameters being the input data necessary to drive the automation interface to complete the specific category of action;

[0017] The combination of the BIOS configuration operation type and the execution parameters is used to fully describe a single BIOS operation command that can be executed by the automation interface.

[0018] Further, obtaining the motherboard model identifier of the target server includes:

[0019] A hardware information query request is sent to the target server through the baseboard management controller interface of the target server;

[0020] The system receives response information from the baseboard management controller interface, parses the response information, and obtains the motherboard model identifier of the target server.

[0021] Furthermore, the step of parsing the BIOS configuration file to extract a start operation instruction, several subsequent operation instructions, and an execution logic description for each instruction includes:

[0022] The execution logic description of each operation instruction is extracted from the BIOS configuration file. The description of each operation instruction includes: a sequence definition for indicating sequential execution or at least one judgment condition for indicating conditional jump. Each judgment condition is associated with a target instruction identifier. The judgment condition is used to describe the interface characteristics that the BIOS settings interface should satisfy when it is in the expected state.

[0023] The start operation command is determined based on the start identifier in the BIOS configuration file;

[0024] The execution logic description is parsed to determine whether each operation instruction is suitable for sequential execution or conditional jump;

[0025] If the execution logic description contains judgment conditions, then the judgment conditions are parsed to obtain the corresponding judgment method and judgment parameters;

[0026] The judgment method includes a first judgment method based on screen coordinate color value matching and a second judgment method based on optical character recognition result matching. The judgment parameters include the preset coordinate position and expected color value on which the first judgment method depends, and the text recognition area and expected text content on which the second judgment method depends.

[0027] Furthermore, the first determination method based on screen coordinate color value matching includes:

[0028] Obtain the color values ​​of several sample coordinate points associated with the preset coordinate position, and the several sample coordinate points constitute a detection sample set for characterizing specific visual elements in the BIOS settings interface;

[0029] The color values ​​of the plurality of sample coordinate points are matched with the expected color value. When the number of successfully matched sample coordinate points reaches a preset threshold, the first judgment method is determined to be a successful match.

[0030] Furthermore, the second judgment method based on optical character recognition result matching specifically includes:

[0031] Perform single-line optical character recognition within the text recognition area to obtain the recognized text result;

[0032] The execution of the second judgment method satisfies the following preset conditions: the actual text corresponding to the expected text content is located in the center of the text recognition area in the BIOS settings interface, and the background noise of the text recognition area is lower than the preset noise level;

[0033] The identified text result is matched with the expected text content to determine whether the second judgment method is successful.

[0034] Further, executing the current operation instruction includes:

[0035] Generate a corresponding simulated human-computer interaction device signal based on the type of the current operation instruction;

[0036] The simulated human-computer interaction device sends signals to the remote management interface of the target server;

[0037] The simulated human-computer interaction device signals include simulated mouse signals and simulated keyboard signals. The simulated mouse signals are used to control the movement and clicking of the cursor in the BIOS settings interface, and the simulated keyboard signals are used to input characters or control keys in the BIOS settings interface.

[0038] Furthermore, before executing the current operation instruction, the following steps are also included:

[0039] Send a system restart command to the target server via a remote management protocol;

[0040] During the restart process of the target server, its video output signal is detected to confirm that the BIOS settings interface has been successfully loaded.

[0041] Furthermore, the generation of the result information indicating that the target server's BIOS auto-configuration is complete includes:

[0042] After the target server restarts and enters the operating system, or after entering the BIOS settings interface again, obtain the actual settings of key BIOS configuration items;

[0043] The actual setting value is compared with the expected setting value defined in the BIOS configuration file, and the result information containing the configuration verification status is generated based on the comparison result.

[0044] Accordingly, a second aspect of the present invention provides an electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the above-described BIOS auto-configuration method for a large-scale server cluster.

[0045] Accordingly, a third aspect of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-described BIOS automatic configuration method for a large-scale server cluster.

[0046] The above-described technical solutions of the embodiments of the present invention have the following beneficial technical effects:

[0047] 1. By introducing variable execution logic (sequential execution and conditional jump) based on configuration file definitions and the dynamic instruction jump mechanism driven by it, intelligent orchestration of the BIOS configuration process is achieved. When the configuration logic is defined as sequential execution, it efficiently advances along the predetermined path. When it is defined as conditional jump, it automatically triggers interface status detection and accurately selects and jumps to the correct subsequent steps from multiple candidate instructions based on real-time recognition results. It can easily handle complex interactive scenarios such as dialog boxes, error messages, and menu branches that are common in BIOS setup. It fundamentally solves the problem of process interruption or configuration failure caused by the inability of traditional batch configuration tools to handle graphical interface branches, and greatly improves the robustness and scenario coverage of the automated process.

[0048] 2. By constructing a configuration file repository strictly organized by motherboard model and combining it with a mechanism that automatically obtains and matches hardware identifiers through out-of-band management interfaces, precise and adaptive configuration management of large-scale heterogeneous server clusters is achieved. The motherboard model is authoritatively obtained through the server's BMC interface, and based on this as the sole basis, a set of configuration files designed and tested specifically for that model is located and loaded from the pre-set directory structure. The "one model, one policy" configuration management approach completely encapsulates the technical details of adapting to different hardware platforms in the corresponding configuration files, so that the core execution engine does not need to care about the underlying hardware differences.

[0049] 3. By integrating dual-mode interface judgment technology based on multi-point RGB coordinate detection and single-line OCR recognition, and setting strict activation conditions (such as multi-point sampling, center positioning, and low background noise), fast and highly reliable recognition of non-standardized BIOS graphical interface elements and text information is achieved. RGB detection determines specific graphic states by verifying a visual feature sample set composed of multiple coordinate points, effectively resisting single-point pixel noise interference. OCR recognition extracts key text information while optimizing success rate by limiting the recognition area and text position. This solves the problem that pure program interface methods cannot be adapted to all motherboards, while simple image matching lacks stability, providing an indispensable and solid technical foundation for achieving fully automatic configuration through simulated human-computer interaction. Attached Figure Description

[0050] Figure 1 This is a flowchart of the BIOS automatic configuration method for a large-scale server cluster provided in an embodiment of the present invention. Detailed Implementation

[0051] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0052] Please refer to Figure 1 The first aspect of this invention provides a method for automatic BIOS configuration of a large-scale server cluster, comprising the following steps:

[0053] Step S100: Obtain the BIOS configuration file corresponding to the target server.

[0054] In automated management scenarios of large-scale heterogeneous server clusters, to ensure the accuracy and adaptability of configurations, it is first necessary to determine the specific configuration strategy for each target server based on its specific hardware identity. This is achieved by calling the server's Baseboard Management Controller (BMC) standard interface to obtain its authoritative motherboard model identifier. Based on this identifier, a pre-built configuration file repository strictly organized by motherboard model is retrieved and matched. For example, for a server with the model "RH2288HV3", the directory named "RH2288H_V3" is found in the configuration repository, and the corresponding main configuration file (such as bios_config_main.json) is loaded from it. This configuration file is not an executable program, but rather a declarative document written in structured data formats such as JSON, purely used to describe the BIOS setting goals and operation procedures, achieving complete decoupling between the configuration strategy and the underlying execution engine.

[0055] Step S200: Parse the BIOS configuration file and extract a start operation instruction, several subsequent operation instructions, and the execution logic description of each instruction.

[0056] After loading the configuration file, it is deconstructed and converted into a data structure that the engine can understand and execute. The parsing process first identifies the starting point of the entire automation process, namely the "starting operation instruction" (e.g., enter_bios_setup). Then, it extracts "several subsequent operation instructions" that constitute the complete process (e.g., set_boot_order, enable_vt, etc.). The parsing engine extracts an "execution logic description" for each operation instruction. This description is divided into two categories: one is "sequence definition," which simply indicates that after the instruction is executed, the process will unconditionally jump to a preset next instruction; the other is "conditional jump definition," which contains one or more "judgment conditions." Each condition describes a specific state that the BIOS interface may appear in after the instruction is executed (e.g., a menu item is highlighted, a prompt box appears), and is associated with a "target instruction identifier," indicating which instruction should be executed if the state is detected. For example, a save configuration instruction may be associated with two judgment conditions: if a "Save Changes?" dialog box appears, it jumps to the instruction to confirm saving; if it returns directly to the main menu, it jumps to the instruction to exit the BIOS.

[0057] Step S300: Execute the current operation instruction and perform the corresponding setting action in the BIOS setting interface of the target server. The first current operation instruction executed is the start operation instruction.

[0058] First, the "start operation command" is executed. Then, the operation is driven by the current command dynamically determined by the process, simulating the operation of a human administrator on the BIOS graphical interface. An out-of-band connection is established through the server's remote management interface (such as IPMI virtual KVM or Redfish graphical console extension). According to the "setup action" defined in the current operation command, the execution engine converts it into a series of low-level, standardized simulated human-computer interaction device signals. For example, if the command requires "press the F10 key", the engine injects the F10 key press and release signal sequence into the server's virtual keyboard interface through the remote management protocol; if the command requires "move the cursor to coordinates (100, 200) and click", the corresponding mouse movement and click signals are injected. This process completely replicates manual operation, but is completed automatically by the program with extremely high speed and consistency.

[0059] In step S400, if the execution logic is defined as sequential execution, a preset next subsequent operation instruction is selected as the operation instruction to be executed. If the execution logic is defined as conditional jump, the changes in the BIOS settings interface after the current operation instruction is executed are detected, and the corresponding subsequent operation instruction is selected from several subsequent operation instructions based on the interface detection result and jumps to execute.

[0060] After executing an operation instruction, instead of blindly executing the next instruction, the subsequent path is determined based on the "execution logic description" parsed in step S200 and bound to that instruction. If the description is "sequential execution," no state detection is required; the flow pointer is directly directed to the next subsequent operation instruction in a predefined order. If the description is "conditional jump," a perception-decision loop is entered: First, the current BIOS interface image is captured via a remote video stream; then, the interface recognition module (integrating RGB color detection and OCR text recognition) is called to analyze the image and obtain the "interface detection result" (e.g., recognizing the "Boot Options" menu title or detecting the "Enabled" checkbox highlighted in blue); finally, this detection result is matched one by one with all the "judgment conditions" associated with the current instruction. Once a match is successful, the next specific instruction to be executed is located from the instruction set based on the "target instruction identifier" associated with the condition, thus achieving dynamic jump.

[0061] In step S500, steps S300 and S400 are repeated. In response to the completion of the process termination condition, result information indicating that the target server BIOS auto-configuration is complete is generated.

[0062] The next operation instruction determined in step S400 is set as the new "current operation instruction," and then the loop of steps S300 (execution) and S400 (decision) is repeated. This "execution-detection-decision-jump" loop will continue, and the end of the process is controlled by the "process end condition," which is usually defined in the configuration file. For example, the process is considered to end when a specific instruction marked as exit_and_save is executed and its operation is successfully completed. Finally, a structured "result information" is generated by combining the status logs of the entire execution process, the success and failure information of each step, and the final configuration verification result. This information is recorded and reported for task auditing, status monitoring, and troubleshooting, thereby completing the end-to-end automated management of the BIOS configuration of a single server.

[0063] This invention abstracts the BIOS configuration process into an "automated script" defined by a structured configuration file, containing a starting point, operation instruction set, and branch execution logic (sequential and conditional jumps). It then constructs an execution system capable of parsing this script, simulating human-computer interaction via a remote interface, and performing closed-loop state perception and intelligent decision-making based on real-time interface recognition. This achieves a high degree of automation and intelligence in BIOS configuration for large-scale server clusters. It significantly reduces the configuration time per machine from tens of minutes to minutes, ensuring extremely high accuracy. Furthermore, it introduces conditional branching logic based on interface state detection, enabling the automated process to flexibly and reliably handle various possible branching scenarios in BIOS interface interactions (such as confirmation dialogs, error messages, and different menu paths). This provides strong adaptability and robustness in handling complex and heterogeneous BIOS interfaces, effectively solving the problem that traditional scripting tools cannot handle graphical interface branching interactions. It offers a practical solution for unified automated configuration management in ultra-large-scale, multi-vendor heterogeneous server environments.

[0064] Further, step S100, obtaining the BIOS configuration file corresponding to the target server, includes:

[0065] Step S110: Obtain the motherboard model identifier of the target server.

[0066] In the automated management of heterogeneous server clusters, accurately identifying the hardware model of each target server is a prerequisite for targeted configuration. By invoking the standard interface of the server hardware out-of-band management module (typically the IPMI or Redfish protocol interface provided by the Baseboard Management Controller, BMC), a standard hardware information query request is sent to the target server (e.g., the IPMI Get Device ID command or accessing the Redfish / Chassis endpoint). From the returned structured response data, key fields uniquely identifying the motherboard hardware (such as "Product Name" and "Board Part Number") are parsed out, serving as the precise "motherboard model identifier." This approach is independent of whether the server operating system is installed or functioning correctly, ensuring reliable hardware identification during critical stages such as bare-metal delivery, before operating system deployment, or after system failure, laying a solid foundation for subsequent configuration adaptation.

[0067] Step S120: Match the target motherboard model subdirectory from the preset configuration file directory according to the motherboard model identifier.

[0068] After obtaining the motherboard model identifier, it needs to be mapped to the corresponding configuration resource library. Therefore, a pre-built configuration file directory tree organized logically by motherboard model needs to be maintained. The organization rule of this directory tree is that the name of each subdirectory strictly corresponds to the identifier string of a known motherboard model (for example, the directory "ProLiant DL380 Gen10" corresponds to this HP server model). The identifier string parsed in step S110 is matched precisely or by rules (such as prefix matching) with all the subdirectory names in the above-mentioned pre-built directory tree. Once a match is successful, the subdirectory is determined to be the "target motherboard model subdirectory". This directory name-based mapping mechanism unifies the diversity of physical hardware with the isolation of configuration logic, enabling the quick and accurate location of a set of configurations customized and tested for a specific hardware model from a unified configuration repository. This is the core design for achieving automatic cross-platform adaptation.

[0069] Step S130: Obtain at least one configuration file from the target motherboard model subdirectory as a BIOS configuration file. The configuration file is a data file that describes a single BIOS operation command in a structured data format.

[0070] After locating the correct target subdirectory, specific configuration commands need to be loaded from it. This subdirectory typically contains multiple independent configuration files (e.g., enter_bios.json, set_boot_order.json, enable_vt.json), each using a structured format like JSON, focusing on describing an atomic, executable BIOS operation command. Depending on the needs of the current configuration task, one or more such files are read, forming a complete set of "BIOS configuration files." For example, a file named disable_secure_boot.json explicitly defines the operation type (e.g., key_action), specific parameters (e.g., key sequence ["F10", "Right", "Enter"]), and preconditions that may need to be met before execution (e.g., detection logic for a specific page). Decoupling a complex configuration process into multiple single command files greatly improves the modularity, reusability, and maintainability of the configuration strategy. This allows operations personnel to flexibly address BIOS configuration needs in different scenarios by combining and updating these fine-grained configuration files, without modifying the upper-level automation engine code.

[0071] Through the refined steps described above, from identifier acquisition and directory matching to file loading, accurate and automated location and loading of the target configuration strategy are achieved when configuring BIOS on large-scale heterogeneous server clusters. This process requires no manual intervention for model identification or file selection, eliminating the risk of human error, and ensures the authority of the identifier through direct querying via the hardware interface.

[0072] Further, obtaining the target server's motherboard model identifier in step S110 includes:

[0073] Step S111: Send a hardware information query request to the target server through the baseboard management controller interface of the target server.

[0074] In data center scenarios involving the unified management of large-scale, multi-vendor, heterogeneous servers, a reliable and standardized method is needed to accurately identify the hardware identity of each server, especially the motherboard model, which is the foundation for all subsequent differentiated configurations. This step initiates an out-of-band query by utilizing the standard network interface provided by the Baseboard Management Controller (BMC), a management component commonly built into server hardware and independent of the main operation. Specifically, based on the target server's BMC network address and authentication information, a hardware information query request conforming to industry-standard management protocols (such as IPMI or Redfish) is constructed and sent. For example, the IPMITool command-line tool can be used to execute `ipmitool -H`.<BMC_IP> The raw 0x06 0x01 command, or a GET request sent via an HTTP client to the / redfish / v1 / Chassis / 1 endpoint of the Redfish interface, is executed entirely outside the server's business operating system and is independent of the state of any services or agents running on it. Therefore, this query can still be executed even when the server is powered off, the operating system is not installed, or it is in a "bare metal" state, ensuring that its critical hardware identifiers can be obtained at any stage of the server's lifecycle, especially during the initial rack deployment phase.

[0075] Step S112: Receive response information from the baseboard management controller interface, parse the response information, and obtain the motherboard model identifier of the target server.

[0076] After sending the query request, the BMC will return a structured response according to the protocol specifications. The task of this step is to accurately extract the motherboard model identifier from this response message. For the IPMI protocol, the response may be a raw data frame containing multiple data fields, which needs to be parsed according to the IPMI specification document to extract the specific fields representing "motherboard product information". For the more readable Redfish RESTful API, the response is usually a JSON object, from which key attribute values ​​such as "Model" or "PartNumber" need to be parsed. The parsing logic needs to be robust to handle subtle differences that may exist in the BMC implementations of different vendors. For example, it might first try to find a more precise model identifier in the vendor-specific namespace under the "Oem" (Original Equipment Manufacturer) field of the JSON object; if not found, it would fall back to a general field. The finally extracted identifier string (such as "S2600WFT") will serve as the unique and authoritative basis for the server hardware model. This identifier is the core link between the physical hardware and the pre-configured policy library; its accuracy directly determines whether subsequent automated configurations can load the correct "operation script".

[0077] Further, step S130, obtaining at least one configuration file from the target motherboard model subdirectory as a BIOS configuration file, includes:

[0078] Step S131: Identify the BIOS configuration operation type defined in the configuration file. The BIOS configuration operation type is a predefined identifier used to instruct the automation interface to perform a specific category of action.

[0079] After loading the configuration file for a specific motherboard model, the first step is to understand the operational intent described in the file. The configuration file uses a standardized structure, explicitly containing a key field declaring the "BIOS configuration operation type" for this operation. This type is a predefined enumeration value or string identifier, such as "detect_page", "mouse_click", or "key_press". Each type corresponds to a type of atomic action that the automation interface can perform. For example, in a configuration file `set_memory_frequency.json`, the operation type field might be defined as "detect_page", indicating that the automation engine's primary task is to detect the page state, rather than immediately executing the settings. By parsing this field, it's possible to accurately determine which functional module in the automation framework should be invoked next, thus transforming abstract configuration data into explicit behavioral instructions. This typed design is the core of the configuration-driven architecture, enabling the configuration file to express complex BIOS interaction logic clearly and unambiguously in a declarative rather than procedural manner.

[0080] Step S132: Obtain the execution parameters associated with the BIOS configuration operation type. The execution parameters are the input data necessary for the driver automation interface to complete a specific type of action. The combination of the BIOS configuration operation type and the execution parameters is used to fully describe a single BIOS operation command that can be executed by the automation interface.

[0081] After identifying the operation type, it's necessary to obtain the precise data required to drive that operation, i.e., the "execution parameters." These parameters are also defined in the configuration file as key-value pairs, and their content and format are closely related to the operation type. For example, for the "detect_page" type, the associated parameters might include "region" (the coordinates of the screen area to be detected [x1, y1, x2, y2]) and "expected_pixel_color" (the expected RGB value of the key pixel (255,0,0) or the expected text string "Main Menu"). For the "key_press" type, the parameter might be "key_sequence" (an array of key codes, such as ["F2", "Down", "Down", "Enter"]). During parsing, these parameters are extracted and verified from the configuration data based on the operation type. The combination of the operation type and its associated parameters constitutes a complete, independently executable "single BIOS operation command." This command not only tells the system "what to do", but also precisely specifies "how to do it" and "under what conditions", providing sufficient and clear contextual information for the subsequent automated execution engine.

[0082] Further, step S200 involves parsing the BIOS configuration file to extract a start operation instruction, several subsequent operation instructions, and an execution logic description for each instruction, including:

[0083] Step S210: Extract the execution logic description of each operation instruction from the BIOS configuration file. The description of each operation instruction includes: a sequence definition for indicating sequential execution or at least one judgment condition for indicating conditional jump. Each judgment condition is associated with a target instruction identifier. The judgment condition is used to describe the interface characteristics that should be satisfied when the BIOS settings interface is in the expected state.

[0084] The engine traverses the logical structure of the configuration file and extracts the "execution logic description" for each operation instruction unit defined therein. This description is a key data structure that clearly defines how to determine the next step after the current instruction has been executed. Specifically, it is manifested in two mutually exclusive types: one is "sequence definition", which is a simple directional identifier that indicates that the process should unconditionally jump to a preset subsequent instruction (e.g., "next_step":"step_save"), which is suitable for linear, branchless operation sequences; the other is "conditional jump definition", which contains one or more "judgment conditions". Each judgment condition is a complete rule unit. On the one hand, it describes the expectation of a specific state of the BIOS graphical interface through the "interface feature" field (e.g., "the pixel at coordinates (50,100) is red (255,0,0)" or "the text 'Save and Exit' is identified in the region (200,150,400,180)"). On the other hand, it indicates which specific subsequent instruction should be jumped to if the expected state is detected through the "target instruction identifier" field (e.g., "target_step":"confirm_save"). This design encodes the complex, visually-responsive human-computer interaction logic entirely into configuration data that can be parsed by machines.

[0085] Step S220: Determine the start operation command based on the start identifier in the BIOS configuration file.

[0086] After extracting all instructions and their logical descriptions, a clear entry point must be determined for the entire automation process. The parsing engine searches for a pre-defined "starting identifier" in the global scope or a specific section of the configuration file. This identifier is typically a field name or attribute value with special meaning, such as "initial_step":"enter_bios" or a boolean flag "is_entry_point": true. By matching this identifier, the engine uniquely locates the "starting operation instruction" that serves as the starting point of the process from among the numerous extracted operation instructions. For example, in a configuration containing multiple instructions such as enter_bios, navigate_to_boot, and set_boot_order, by identifying the starting identifier marked on the enter_bios instruction, it is determined to be the first execution action of the entire automation task; ensuring that no matter how complex the configuration process is, the execution engine can always start working from a definite and correct initial state.

[0087] Step S230: The execution logic description is parsed to determine whether each operation instruction is suitable for sequential execution or conditional jump.

[0088] After obtaining the execution logic description of each instruction, it needs to be initially classified so that the execution engine can adopt different subsequent processing strategies. The parsing engine checks the "execution logic description" data structure extracted for each operation instruction in step S210. If the description only contains a "sequence definition" field (such as an explicit next_step value), the engine marks the instruction as suitable for the "sequential execution" mode; after executing the instruction, no interface state judgment is required, and the process will directly proceed along the predetermined path. If the description contains a "judgment condition" field (usually an array containing one or more condition objects), the engine marks the instruction as suitable for the "condition jump" mode; after executing the instruction, the interface detection process must be started, and the subsequent path will be dynamically determined based on the actual detection results.

[0089] Step S240: If the execution logic description includes a judgment condition, then the judgment condition is parsed to obtain its corresponding judgment method and judgment parameters. The judgment method includes a first judgment method based on screen coordinate color value matching and a second judgment method based on optical character recognition result matching. The judgment parameters include the preset coordinate position and expected color value upon which the first judgment method relies, and the text recognition area and expected text content upon which the second judgment method relies.

[0090] For operation instructions categorized as "conditional jump" mode, the expected interface state described in its "judgment conditions" needs to be further parsed into executable and quantifiable detection parameters. The engine breaks down each judgment condition, first identifying the "judgment method" it employs. The main methods include: a "first judgment method" based on screen coordinate color value matching and a "second judgment method" based on optical character recognition results matching. Subsequently, the engine extracts the specific "judgment parameters" relied upon by each method. For the first judgment method, the parameters include one or more "preset coordinate positions" for color sampling, and the "expected color value" (represented in RGB format) expected to be seen at that position. For the second judgment method, the parameters include a rectangular "text recognition area" (defined by the coordinates of the top left and bottom right corners) for text recognition, and the "expected text content" expected to be recognized within that area. These parameters are passed to the subsequent interface recognition module as the precise basis for its real-time screen analysis and comparison with the expected state.

[0091] Through meticulous parsing of the configuration file, the high-level, descriptive BIOS configuration process is transformed into a series of low-level, atomically executable instructions and explicit state transition rules. Step S210, which extracts the "execution logic description," lays the foundation for intelligent decision-making, distinguishing between sequential and branching processes. Step S220 ensures the determinism of the process starting point. Step S230's instruction classification enables the execution engine to efficiently allocate resources and avoid unnecessary interface checks on linear steps. Step S240 then concretizes branch conditions into operable visual inspection parameters. The entire system not only "executes step by step" but also "decides based on state," thereby achieving reliable and efficient automated configuration of BIOSes with complex interactive logic and variable interface states. This is a key technological guarantee for achieving high success rates and cross-platform adaptability.

[0092] Furthermore, the first determination method based on screen coordinate color value matching in step S240 includes:

[0093] Step S2411: Obtain the color values ​​of several sample coordinate points associated with preset coordinate positions. The several sample coordinate points constitute a detection sample set used to characterize specific visual elements in the BIOS settings interface.

[0094] After acquiring the real-time view of the target server's BIOS settings interface via remote video streaming, it is necessary to accurately determine the presence or state of specific visual elements (such as a highlighted menu item, a checked checkbox, or a status icon of a specific color). To improve the robustness of the judgment, this step adopts a multi-point sampling strategy. Based on the "preset coordinate positions" predefined in the configuration file for the "first judgment method," a set of logically associated "sample coordinate points" is calculated and generated based on the expected geometric shape and display characteristics of the visual element. For example, for a "Save & Exit" button that is expected to be a blue rectangle, the sample point set may include multiple coordinate positions such as its upper left corner, upper right corner, center point, and lower edge midpoint. Subsequently, the pixel RGB color values ​​corresponding to these sample coordinate points are read from the currently captured video frame. These color values ​​together constitute a "detection sample set" for the interface element, describing the color characteristics that the element should present when displayed normally from multiple spatial dimensions. Compared with single-point sampling, this provides richer and more interference-resistant feature information.

[0095] Step S2412: Match the color values ​​of several sample coordinate points with the expected color value. When the number of successfully matched sample coordinate points reaches a preset threshold, the first judgment method is determined to be a successful match.

[0096] After obtaining the real-time color sample set, it needs to be compared with the "expected color value" defined in the configuration file to make a final state determination. For each sample coordinate point, the difference between its actual acquired RGB value and the expected RGB value specified for that point in the configuration file is calculated. If this difference is less than a preset color tolerance threshold (e.g., the difference between each channel in the RGB color space is less than 10), the sample point is considered a successful match. Subsequently, the number of successful matches among all sample points is counted. The judgment logic does not require all points to match perfectly; instead, a "preset threshold" is introduced (e.g., with a total of 5 sample points, the preset threshold is 4). When the number of successfully matched sample points reaches or exceeds this threshold, it is determined that "the first judgment method has succeeded," meaning the target visual element is recognized as being in the expected state. This threshold-based decision-making mechanism provides a certain degree of fault tolerance, allowing individual sample points to fail to match due to local screen noise, video compression distortion, or extremely subtle rendering differences. As long as most feature points meet expectations, a reliable judgment can still be made, thus significantly improving the recognition success rate and stability under non-ideal imaging conditions.

[0097] Furthermore, the second judgment method based on optical character recognition result matching in step S240 specifically includes:

[0098] Step S2421: Perform single-line optical character recognition within the text recognition area to obtain the recognized text result. The execution of the second judgment method satisfies the following preset conditions: the actual text corresponding to the expected text content is located in the center-adjacent area of ​​the text recognition area in the BIOS settings interface, and the background noise of the text recognition area is lower than a preset noise level.

[0099] When automated recognition and judgment of text information (such as menu item names, configuration option values, or status prompts) in the BIOS setup interface is required, single-line optical character recognition (OCR) technology is employed. This step first obtains a predefined "text recognition area" from the configuration file, which is a specific rectangular coordinate range on the screen. The corresponding area image is then extracted from the remote video stream and sent to the OCR engine for processing. However, to ensure a very high recognition success rate, this method incorporates two key preconditions. First, it requires that "the actual text corresponding to the expected text content is located in the center-adjacent area of ​​the text recognition area in the BIOS setup interface." This means that when defining the configuration file, the recognition area should be set slightly larger than the actual text area, and the expected position of the text should be planned in the center of that area. This design effectively prevents the target text from being truncated or moved out of the recognition area due to slight video stream jitter or pixel-level offsets in the interface element position. Second, it requires that "the background noise of the text recognition area is lower than a preset noise level." The BIOS interface is typically characterized by its simplicity and high contrast. This condition aims to ensure that the selected recognition area is free of complex textures, gradients, or interfering patterns similar in color to the text, guaranteeing that the OCR engine can clearly segment the foreground text. Before performing OCR, the region image can be preprocessed (e.g., binarization, noise reduction) and its background complexity assessed to meet this condition. Finally, the OCR engine outputs the "recognized text result" within that region.

[0100] Step S2422: Match the recognized text result with the expected text content to determine whether the second judgment method is successful.

[0101] After obtaining the text string recognized by OCR, the process enters the matching decision stage. This step compares the "recognized text result" with the "expected text content" defined in the configuration file for this decision step. The comparison typically uses exact string matching or fuzzy matching that allows for small edit distances (such as Levenshtein distance). For example, the expected text content might be "Boot Option #1," while the recognition result could be either "Boot Option #1" or "Boot Option #1." The process is then processed and judged according to preset matching rules (such as whether to ignore leading and trailing spaces, and whether to be case-insensitive). If both match the rules, the second judgment method is considered a successful match, confirming that the expected text is displayed on the current interface, and the interface state meets the conditions for continuing subsequent operations. If the match fails, it is considered unsuccessful, and the automated process may enter a waiting retry or error handling branch. This matching result is one of the key decision bases driving the entire configuration sequence forward.

[0102] Further, executing the current operation instruction in step S300 includes:

[0103] Step S310: Generate the corresponding simulated human-computer interaction device signal according to the type of the current operation instruction.

[0104] When the automated execution engine processes the configuration item operation sequence sequentially, it calls the corresponding signal generation module based on the operation type explicitly stated in the current operation instruction (such as mouse_move_click or key_press_sequence) to convert it into "analog human-machine interface device signals" that the underlying hardware can understand. For example, for an operation instruction of type mouse_move_click, its associated parameters may include target coordinates (x, y). The signal generation module converts these coordinates into absolute or relative displacements relative to the remote video resolution and generates a set of digital signal sequences conforming to the USB HID (Human Machine Interface Device) protocol standard. This sequence precisely describes the complete process of smoothly moving the cursor from its current position to the target coordinates and executing a left-click and release event. For an instruction of type key_press_sequence, the parameter may be a list of key codes ["F2", "Down", "Enter"]. The signal generation module is responsible for mapping these logical keys to standard keyboard scan codes or virtual-key codes and generating the corresponding "press" and "release" signal sequences. This conversion process translates upper-level, semantic operation instructions into lower-level control commands that can be directly recognized and executed by the server hardware interface.

[0105] Step S320: Send the simulated human-computer interaction device signal to the remote management interface of the target server. The simulated human-computer interaction device signal includes a simulated mouse signal and a simulated keyboard signal. The simulated mouse signal is used to control the movement and clicking of the cursor in the BIOS setup interface, and the simulated keyboard signal is used to input characters or control keys in the BIOS setup interface.

[0106] After generating standardized analog signals, they need to be accurately injected into the target server via an out-of-band management channel. In this step, the encapsulated analog signal data packets are sent to the virtual human-machine interface provided by the BMC, utilizing the established remote management session with the target server (BMC). The specific implementation depends on the remote management protocol used. For example, when using the IPMI protocol, specific raw commands (such as the 0x0c 0x02 network function command for simulating key presses) are sent to the BMC via tools like IPMITool or by directly calling IPMI library functions. The command payload contains the keyboard scan code sequence generated in step S310. For mouse signals, commands such as 0x0c 0x04 may be used to carry coordinates and button states. If the Redfish protocol is used, an HTTP POST request containing operation instructions is initiated to the BMC's Redfish server endpoint (such as / redfish / v1 / Managers / 1 / VirtualMedia / 1 / Actions / ComputerSystem.Reset or a dedicated virtual console extension interface). After receiving these signals, the BMC will simulate them as input from a locally connected USB keyboard and mouse, thereby enabling remote control of the server's BIOS settings interface; this step establishes the final connection from the automation control end to the target server's hardware input end.

[0107] Furthermore, before executing the current operation instruction in step S300, the following steps are also included:

[0108] Step S301: Send a system restart command to the target server via the remote management protocol.

[0109] When initiating an automated BIOS configuration process for a target server, the first step is to bring it into a configurable BIOS setup environment. To achieve this, a standard system reboot command is sent to the target server's baseboard management controller via an established out-of-band management channel (such as IPMI or Redfish). For example, this is done by executing `ipmitool -H` using IPMITool.<BMC_IP> The `chassis power reset` command, or a request with `ResetType` set to `GracefulRestart` or `PowerCycle`, sent to the ` / redfish / v1 / Systems / 1 / Actions / ComputerSystem.Reset` endpoint via the Redfish API, triggers a complete hardware reboot process on the server. This step is the starting point of the automation process, ensuring that the server transitions uniformly from any existing operating state (whether the operating system is running, hibernating, or powered off) to the power-on self-test (POST) phase, creating the necessary conditions for subsequently entering the BIOS interface, completely replacing manual operation of pressing the power button or reset button.

[0110] Remote operation is performed through a standardized protocol for interacting with the server board management controller. For example, when using the IPMI protocol, this can be achieved using the IPMITool tool. For instance, the command `ipmitool -H` can be used to view the BIOS configuration.<BMC_IP> BIOS list; Specific BIOS options can be set using the command ipmitool -H<BMC_IP> bios set<option_name> = <value>For batch configuration scenarios, this can be achieved by writing a loop script, for example: `for serverin $(cat server_list.txt); do ipmitool -H $server bios set BootMode=UEFI;done`. This specific embodiment illustrates how to use existing remote management tools to automate command issuance, demonstrating the compatibility of this solution with standard infrastructure.

[0111] Step S302: During the target server restart process, detect its video output signal to confirm that the BIOS setup interface has been successfully loaded.

[0112] After sending the reboot command, the server status needs to be monitored synchronously to accurately capture the timing of entering the BIOS setup interface. The virtual KVM (keyboard, video, mouse) function attached to the same remote management interface is used to receive the video output signal stream from the target server in real time. During the server reboot process, the video stream content is continuously analyzed, waiting for specific visual features to appear to confirm that the BIOS setup interface has been successfully loaded. For example, this might be configured to detect whether the manufacturer's logo (such as "Press F2 to enter Setup") appears in the upper left corner of the screen, or to detect whether a specific area of ​​the screen changes from black to displaying firmware version information. This detection process utilizes the aforementioned page judgment technology (such as coordinate-based color detection or OCR recognition). Once the preset interface features are successfully recognized, it is determined that the BIOS setup interface has been loaded, and the subsequent automated configuration operation sequence is initiated. This step achieves state synchronization from "reboot command issued" to "configuration interface ready," avoiding the entire process from stalling due to blindly waiting for a fixed time or reboot failure.

[0113] Furthermore, the result information of generating the target server BIOS auto-configuration in step S400 includes:

[0114] Step S410: After the target server restarts and enters the operating system, or after entering the BIOS settings interface again, obtain the actual settings of the key BIOS configuration items.

[0115] After the automated configuration process is completed and the server is restarted, it is essential to verify that the previous settings have truly taken effect at the hardware level. This is the final closed loop to ensure configuration accuracy. This step is responsible for obtaining the actual settings of key BIOS configuration items on the current server. Depending on the specific configuration item attributes and available technical paths, one of two main methods is used. The first method, after the target server restarts normally and enters the operating system, can read system information or specific register values ​​reflecting BIOS settings through a lightweight agent program deployed within the operating system, or through standard data models provided by out-of-band management protocols (such as Redfish or specific vendors' in-band management interfaces). For example, it can obtain the current boot mode (UEFI / Legacy) or virtualization support status. The second method, suitable for complex configurations that cannot be obtained through the operating system interface or require direct verification, can trigger a simplified process again, controlling the server to restart and briefly enter the BIOS setup interface. Using the same video stream capture and interface recognition technology (such as OCR), it can locate the specific configuration menu item and directly "read" the actual setting value text displayed on the screen, such as "Secure Boot: [Enabled]". Data obtained through any of the above methods is recorded as "actual set value" and used as benchmark data for verification.

[0116] Step S420: Compare the actual set value with the expected set value defined in the BIOS configuration file, and generate result information containing the configuration verification status based on the comparison result.

[0117] After obtaining the actual setpoints, they are automatically compared with the "expected setpoints" explicitly defined in the original "BIOS configuration file" upon which this configuration task is based. The expected setpoints are descriptions of the desired state for each target configuration item specified in the configuration file. The comparison logic depends on the type of configuration item: for enumerated options (such as Enabled / Disabled), exact or fuzzy string matching is performed; for numerical options (such as memory frequency), numerical equality or range judgment is performed. Each item is compared, and the result (successful or unsuccessful match) is recorded. Subsequently, the comparison results of all configuration items are combined to generate a structured "result information". This information not only includes the final overall success / failure status but also typically lists the expected value, actual value, and comparison status of each configuration item in detail. This result information is recorded in the log database and can be used to trigger notifications, generate reports, or drive downstream operation and maintenance processes (such as marking the server as "compliant", triggering failure retries or alarms), thereby providing auditable and traceable closed-loop evidence for configuration operations.

[0118] This mechanism elevates automated configuration from a simple "execution process" to a complete quality control loop that includes "result verification." It directly verifies the final effect of automated operations at the hardware level, rather than relying solely on process logs. This allows for the discovery and identification of configuration failures caused by underlying hardware differences, firmware characteristics, or a few rare execution anomalies. It makes the results of large-scale batch configurations measurable and reliable, providing automated tools to support configuration consistency auditing and compliance checks. This fundamentally solves the pain point of the difficulty in systematically verifying manual configurations.

[0119] In an optional embodiment of this invention, a configuration-driven approach is adopted to implement the above method. The logical architecture mainly includes a configuration management platform, a BIOS auto-configuration engine, and a target server connected via a remote management protocol. The configuration management platform provides a web interface and command-line tools, handling functions such as configuration template management, batch task distribution, and configuration result querying. The BIOS auto-configuration engine is the core processing unit, comprising a JSON parser, an interface recognition module, an operation executor, and a status monitoring module. The JSON parser is responsible for parsing the BIOS configuration template and extracting configuration items and operation sequences. The interface recognition module integrates an RGB coordinate detection unit and an OCR single-line recognition unit, responsible for recognizing BIOS interface elements and text. The operation executor performs simulated operations such as mouse movement, clicking, and keyboard input based on the parsed sequence. The status monitoring module monitors the configuration process in real time, completing configuration result verification and anomaly handling. The remote management protocol adopts the IPMI or Redfish standard to achieve communication with the server baseboard management controller, providing a channel for remote configuration.

[0120] Accordingly, a second aspect of the present invention provides an electronic device, including: at least one processor; and a memory connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to cause the at least one processor to perform the above-described BIOS auto-configuration method for a large-scale server cluster.

[0121] Accordingly, a third aspect of the present invention provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the above-described BIOS automatic configuration method for a large-scale server cluster.

[0122] This invention aims to protect a BIOS auto-configuration method for large-scale server clusters, and has the following effects:

[0123] 1. By introducing variable execution logic (sequential execution and conditional jump) based on configuration file definitions and the dynamic instruction jump mechanism driven by it, intelligent orchestration of the BIOS configuration process is achieved. When the configuration logic is defined as sequential execution, it efficiently advances along the predetermined path. When it is defined as conditional jump, it automatically triggers interface status detection and accurately selects and jumps to the correct subsequent steps from multiple candidate instructions based on real-time recognition results. It can easily handle complex interactive scenarios such as dialog boxes, error messages, and menu branches that are common in BIOS setup. It fundamentally solves the problem of process interruption or configuration failure caused by the inability of traditional batch configuration tools to handle graphical interface branches, and greatly improves the robustness and scenario coverage of the automated process.

[0124] 2. By constructing a configuration file repository strictly organized by motherboard model and combining it with a mechanism that automatically obtains and matches hardware identifiers through out-of-band management interfaces, precise and adaptive configuration management of large-scale heterogeneous server clusters is achieved. The motherboard model is authoritatively obtained through the server's BMC interface, and based on this as the sole basis, a set of configuration files designed and tested specifically for that model is located and loaded from the pre-set directory structure. The "one model, one policy" configuration management approach completely encapsulates the technical details of adapting to different hardware platforms in the corresponding configuration files, so that the core execution engine does not need to care about the underlying hardware differences.

[0125] 3. By integrating dual-mode interface judgment technology based on multi-point RGB coordinate detection and single-line OCR recognition, and setting strict activation conditions (such as multi-point sampling, center positioning, and low background noise), fast and highly reliable recognition of non-standardized BIOS graphical interface elements and text information is achieved. RGB detection determines specific graphic states by verifying a visual feature sample set composed of multiple coordinate points, effectively resisting single-point pixel noise interference. OCR recognition extracts key text information while optimizing success rate by limiting the recognition area and text position. This solves the problem that pure program interface methods cannot be adapted to all motherboards, while simple image matching lacks stability, providing an indispensable and solid technical foundation for achieving fully automatic configuration through simulated human-computer interaction.

[0126] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0127] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0128] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0129] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0130] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.< / value>

Claims

1. A BIOS auto-configuration method for a large-scale server cluster, characterized in that, Includes the following steps: Step S100: Obtain the BIOS configuration file corresponding to the target server; Step S200: Parse the BIOS configuration file and extract a start operation instruction, several subsequent operation instructions, and the execution logic description of each instruction; Step S300: Execute the current operation instruction and perform the corresponding setting action in the BIOS setting interface of the target server. The first current operation instruction executed is the starting operation instruction. Step S400: If the execution logic is defined as sequential execution, then a preset next subsequent operation instruction is selected as the operation instruction to be executed. If the execution logic is defined as conditional jump, then the BIOS setting interface after the current operation instruction is executed is detected, the interface detection result is determined according to the interface characteristics, and the corresponding subsequent operation instruction is selected from the plurality of subsequent operation instructions based on the interface detection result and jumps to execute. In step S500, steps S300 and S400 are repeated. In response to the completion of the process termination condition, result information indicating that the target server BIOS auto-configuration is complete is generated.

2. The method for BIOS auto-configuration of large-scale server cluster according to claim 1, wherein, The step of obtaining the BIOS configuration file corresponding to the target server includes: Obtain the motherboard model identifier of the target server; Based on the motherboard model identifier, match the target motherboard model subdirectory from the preset configuration file directory; Obtain at least one configuration file from the target motherboard model subdirectory as the BIOS configuration file, wherein the configuration file is a data file describing a single BIOS operation command in a structured data format.

3. The method of claim 2, wherein the BIOS auto-configuration method of a large-scale server cluster is characterized by, The step of obtaining at least one configuration file from the target motherboard model subdirectory as the BIOS configuration file includes: Identify the BIOS configuration operation types defined in the configuration file, where the BIOS configuration operation types are predefined identifiers used to instruct the automation interface to perform specific categories of actions; Obtain the execution parameters associated with the BIOS configuration operation type, the execution parameters being the input data necessary to drive the automation interface to complete the specific category of action; The combination of the BIOS configuration operation type and the execution parameters is used to fully describe a single BIOS operation command that can be executed by the automation interface.

4. The method of claim 2, wherein the BIOS auto-configuration method of a large-scale server cluster is characterized by, The step of obtaining the motherboard model identifier of the target server includes: A hardware information query request is sent to the target server through the baseboard management controller interface of the target server; The system receives response information from the baseboard management controller interface, parses the response information, and obtains the motherboard model identifier of the target server.

5. The BIOS automatic configuration method for a large-scale server cluster according to claim 1, characterized in that, The process of parsing the BIOS configuration file to extract a start operation instruction, several subsequent operation instructions, and an execution logic description for each instruction includes: The execution logic description of each operation instruction is extracted from the BIOS configuration file. The description of each operation instruction includes: a sequence definition for indicating sequential execution or at least one judgment condition for indicating conditional jump. Each judgment condition is associated with a target instruction identifier. The judgment condition is used to describe the interface characteristics that the BIOS settings interface should satisfy when it is in the expected state. The start operation command is determined based on the start identifier in the BIOS configuration file; The execution logic description is parsed to determine whether each operation instruction is suitable for sequential execution or conditional jump; If the execution logic description contains judgment conditions, then the judgment conditions are parsed to obtain the corresponding judgment method and judgment parameters; The judgment method includes a first judgment method based on screen coordinate color value matching and a second judgment method based on optical character recognition result matching. The judgment parameters include the preset coordinate position and expected color value on which the first judgment method depends, and the text recognition area and expected text content on which the second judgment method depends.

6. The method for BIOS auto-configuration of a large-scale server cluster according to claim 5, wherein, The first determination method based on screen coordinate color value matching includes: Obtain the color values ​​of several sample coordinate points associated with the preset coordinate position, and the several sample coordinate points constitute a detection sample set for characterizing specific visual elements in the BIOS settings interface; The color values ​​of the plurality of sample coordinate points are matched with the expected color value. When the number of successfully matched sample coordinate points reaches a preset threshold, the first judgment method is determined to be a successful match.

7. The BIOS automatic configuration method for a large-scale server cluster according to claim 5, characterized in that, The second judgment method based on optical character recognition result matching specifically includes: Perform single-line optical character recognition within the text recognition area to obtain the recognized text result; The execution of the second judgment method satisfies the following preset conditions: the actual text corresponding to the expected text content is located in the center of the text recognition area in the BIOS settings interface, and the background noise of the text recognition area is lower than the preset noise level; The identified text result is matched with the expected text content to determine whether the second judgment method is successful.

8. The BIOS automatic configuration method for a large-scale server cluster according to claim 1, characterized in that, The execution of the current operation instruction includes: Generate a corresponding simulated human-computer interaction device signal based on the type of the current operation instruction; The simulated human-computer interaction device sends signals to the remote management interface of the target server; The simulated human-computer interaction device signals include simulated mouse signals and simulated keyboard signals. The simulated mouse signals are used to control the movement and clicking of the cursor in the BIOS settings interface, and the simulated keyboard signals are used to input characters or control keys in the BIOS settings interface.

9. The method of claim 1-8, wherein the BIOS auto-configuration method of large-scale server cluster is characterized in that, Before executing the current operation instruction, the method further includes: Send a system restart command to the target server via a remote management protocol; During the restart process of the target server, its video output signal is detected to confirm that the BIOS settings interface has been successfully loaded.

10. The method of claim 1-8, wherein the BIOS auto-configuration method of large-scale server cluster is characterized in that, The result information of generating the target server BIOS auto-configuration completion includes: After the target server restarts and enters the operating system, or after entering the BIOS settings interface again, obtain the actual settings of key BIOS configuration items; The actual setting value is compared with the expected setting value defined in the BIOS configuration file, and the result information containing the configuration verification status is generated based on the comparison result.

Images