Mirror image file flashing method and device, electronic equipment and storage medium
By obtaining the target object's identification information during board startup and using a public key library to decrypt and verify the image file, the problem of insufficient accuracy in image file flashing is solved, ensuring that the image file matches the target object and improving the accuracy and security of flashing.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-30
- Publication Date
- 2026-04-10
AI Technical Summary
The accuracy of flashing image files in existing technologies is insufficient, and there is a risk of flashing errors.
When the board starts up, it obtains the identification information of the target object, uses the target public key file in the pre-configured public key file library to decrypt and verify the image file, ensures that the image file matches the target object, and performs flashing after the verification is successful.
It improves the accuracy and security of image file flashing, avoiding problems such as incorrect image flashing or version incompatibility.
Smart Images

Figure CN121832980A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computers, and more specifically, to a method, apparatus, electronic device, and storage medium for flashing image files. Background Technology
[0002] To ensure the continuous, efficient, and stable operation of large servers, it is necessary to monitor the server's operating status and determine its operational condition through monitoring data.
[0003] In related technologies, the Baseboard Management Controller (BMC) is widely used in the server field as a core component for server hardware status management, responsible for monitoring the server's health status. To meet the customized server needs of different customers, the BMC needs to refresh the server image file.
[0004] However, the image file refresh method in related technologies has the problem of insufficient accuracy in image file writing, which leads to the risk of writing errors. Summary of the Invention
[0005] This application provides a method, apparatus, electronic device, computer-readable storage medium, and computer program product for flashing image files, in order to at least solve the problems of insufficient accuracy in flashing image files and the risk of flashing errors in related technologies.
[0006] This application provides a method for flashing an image file, comprising: when the board is booting up, obtaining the identification information of a target object, wherein the board is pre-configured with a public key file library, the public key file library including public key files of different objects; querying the target public key file of the target object in the board's public key file library according to the identification information; when the board triggers the image flashing process, using the target public key file to decrypt and verify the image file to be flashed on the board; and when the image file to be flashed on the board passes verification, flashing the image file to be flashed to the board.
[0007] This application also provides a device for flashing / writing image files, including:
[0008] The reading module is used to obtain the identification information of the target object when the board starts up. The board is pre-configured with a public key file library, which includes public key files of different objects.
[0009] The query module is used to query the target public key file of the target object in the public key file library of the board based on the identification information;
[0010] The verification module is used to decrypt and verify the image file to be flashed on the board using the target public key file when the board triggers the image flashing process.
[0011] The flashing module is used to flash the image file to be flashed onto the board if the image file to be flashed is verified to be valid.
[0012] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any of the above-described image file flashing methods.
[0013] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of any of the above-described image file flashing methods.
[0014] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above-described image file flashing methods.
[0015] This application achieves this by obtaining the target object's identification information during the board's boot phase and performing subsequent image flashing steps based on this identification information. This ensures that the flashed image matches the target object, effectively preventing incorrect image flashing or version incompatibility issues. By using the target object's identification information to match a target public key file obtained from a pre-configured public key library to decrypt and verify the image file, it ensures that only image files that pass the target public key file decryption verification can be used for upgrades, enhancing the security and accuracy of image upgrades. This guarantees that the image file flashed on the board is the one required by the target object, improving the accuracy of image file flashing and avoiding image file flashing errors. Attached Figure Description
[0016] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 This is a hardware structure block diagram of a server device for a method of flashing an image file according to an embodiment of this application;
[0018] Figure 2 This is one of the flowcharts of a method for flashing an image file according to an embodiment of this application;
[0019] Figure 3 This is a second flowchart of a method for flashing an image file according to an embodiment of this application;
[0020] Figure 4 This is the third flowchart of a method for flashing an image file according to an embodiment of this application;
[0021] Figure 5 This is the fourth flowchart of a method for flashing an image file according to an embodiment of this application;
[0022] Figure 6 This is the fifth flowchart of a method for flashing an image file according to an embodiment of this application;
[0023] Figure 7 This is a flowchart of a method for flashing an image file according to an embodiment of this application;
[0024] Figure 8 This is flowchart number seven of a method for flashing an image file according to an embodiment of this application;
[0025] Figure 9 This is a structural block diagram of a mirror file writing device according to an embodiment of this application. Detailed Implementation
[0026] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0027] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.
[0028] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0029] The specific application environment architecture or specific hardware architecture on which the image file flashing method depends is described here.
[0030] The image file flashing method provided in this application embodiment can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of a server device for a method of flashing an image file according to an embodiment of this application. For example... Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown in the diagram. A processor 102 (which may include, but is not limited to, a central processing unit (CPU), microprocessor, or programmable logic device) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.
[0031] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the image file flashing method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.
[0032] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.
[0033] This application provides a method for flashing an image file, applied to the aforementioned server device. The method is described in detail below, along with its execution flow. Figure 2 As shown, the method includes the following steps S200-230:
[0034] Step S200: When the board is started, obtain the identification information of the target object.
[0035] The board is pre-configured with a public key file library, which includes public key files for different objects.
[0036] Specifically, when a server board (such as a BMC board) boots up, it identifies the target object it interacts with. Here, "target object" can refer to a specific client of the server or its specific configuration. Obtaining identification information is the foundation for subsequent image matching and flashing processes, ensuring that each operation points to the correct client or configuration.
[0037] For example, in the early stages of board startup, its operating system or firmware actively reads identification information, such as the customer index or hardware configuration ID, stored in non-volatile storage media (such as EEPROM). This process can be completed automatically through preset system calls or drivers without manual intervention.
[0038] In this context, the board can be a management component within the server, such as a Baseboard Management Controller (BMC) board, which handles remote management and monitoring functions. Identification information is a unique code used to distinguish different clients or configurations, such as a client index, which helps the server identify the specific client or configuration currently being served. The public key repository is a collection storing public key files corresponding to multiple clients; these public key files are pre-configured by the system and used for subsequent image authentication.
[0039] Step S210: Query the target public key file of the target object in the public key file library of the board according to the identification information.
[0040] Specifically, after obtaining the target object's identification information, the server board needs to search for a target public key file in the public key library that matches the identification information. This is for the subsequent image decryption and verification process, ensuring the consistency between the certificate and the image, and preventing unauthorized image flashing.
[0041] For example, the server parses identification information (such as the client's index), queries a built-in public key lookup table, and finds the path to the public key file that matches the identification information. Then, the found public key file is loaded into memory or a temporary buffer, ready for subsequent image decryption verification. By accurately matching the target public key, subsequent image verification is ensured to proceed smoothly, avoiding upgrade failures due to incorrect public key file selection and improving the accuracy of image flashing.
[0042] The target public key file is a public key file corresponding to specific identification information (such as the customer index) and is used to verify the target image file. In server management, the image flashing process refers to the process of flashing a new firmware or operating system image to the server's firmware storage area.
[0043] Step S220: When the board triggers the image flashing process, the target public key file is used to decrypt and verify the image file to be flashed on the board.
[0044] Specifically, when the server board performs the image flashing process, a specific target public key file obtained from the public key file library is used to verify the signature of the image file to be flashed, ensuring the legitimacy and integrity of its source.
[0045] For example, before flashing the image, the board applies the target public key file to the digital signature verification of the image to be flashed. By decrypting the signature in the image file, it compares it with the public key provided in the public key file. Only after confirming that there is no error will the flashing process continue.
[0046] The decryption verification process involves using the public key to decrypt the digital signature generated by the private key in the image file and checking whether it matches the public key, thereby verifying the authenticity and integrity of the image file.
[0047] Step S230: If the image file to be flashed on the board passes the verification, flash the image file to be flashed onto the board.
[0048] Specifically, once the image file to be flashed has passed decryption verification, confirming its legitimate origin and undamaged status, the server board can safely perform the image flashing operation to update its firmware to the latest version.
[0049] For example, after successful verification, the server board copies the image file to be flashed from the storage medium to the firmware area, replacing the original image and completing the entire image flashing process.
[0050] In this embodiment, by obtaining the target object's identification information during the board's boot phase and performing subsequent image flashing steps based on this identification information, it is ensured that the flashed image matches the target object, effectively preventing issues such as incorrect image flashing or version mismatch. By using the target object's identification information to match a target public key file obtained from a pre-configured public key file library to decrypt and verify the image file, it is ensured that only image files that have passed the target public key file decryption verification can be used for upgrades during the image flashing process, enhancing the security and accuracy of image upgrades. This ensures that the image file flashed on the board is the one required by the target object, improving the accuracy of image file flashing and avoiding image file flashing errors.
[0051] In one embodiment, such as Figure 3 As shown, step S210 involves retrieving the target public key file of the target object from the public key file library of the board based on the identification information. This includes steps S300-S330:
[0052] Step S300: Determine the index value corresponding to the target object based on the identification information.
[0053] Specifically, during startup or maintenance, the server board reads identification information stored in non-volatile memory (such as EEPROM). This information indicates the object currently being served (such as a specific client or configuration). Based on this identification information, the system can determine a corresponding index value, which plays a crucial role in subsequent public key file matching.
[0054] For example, after the server board reads the identification information from the storage unit, it converts the identification information into an index value using a predefined conversion function or mapping table. This index value is usually in numerical form, facilitating quick lookup in the public key lookup table later.
[0055] The identification information can be a customer index, hardware configuration ID, or other unique code used to distinguish different service objects. The index value is a converted numerical value used for quick location in the public key lookup table.
[0056] Step S310: Search the preset public key lookup table according to the index value corresponding to the target object to determine the public key file name corresponding to the target object.
[0057] The public key mapping table includes the correspondence between different index values and public key file names.
[0058] Specifically, after obtaining the index value of the target object, the server board will search for the public key file name that matches the index value in the preset public key lookup table. This is a key step in the verification process before image flashing, ensuring the targeting and security of the flashing operation.
[0059] For example, the server board uses the index value as the key to look up the public key lookup table stored internally. This lookup table has been pre-loaded into the board's memory and contains a series of entries corresponding to index values and public key file names, such as 0 corresponding to "A_public", 1 corresponding to "B_public", etc.
[0060] The public key lookup table is a database or list containing the correspondence between index values and public key filenames, used to guide server boards in selecting the correct public key file for image verification. The public key filename is the identifier of the public key file stored in the board's public key file library; the required public key file can be quickly retrieved by its filename.
[0061] Step S320: Search the public key file library of the board according to the public key file name to obtain the target public key file of the target object.
[0062] Specifically, after determining which public key filename needs to be used, the next task of the server board is to use this information to extract the matching target public key file from its internal public key file library for the upcoming image file security verification.
[0063] For example, the server board searches its internal public key file repository storage area based on the determined public key file name. This repository may be organized as a directory structure containing all preset public key files. The system loads the target public key file into memory via file system calls such as open() and read(), preparing it for image verification.
[0064] The public key file library of the board is a collection of pre-configured public key files within the server board, used for secure verification during image upgrades. The target public key file is a public key file corresponding to the index value of a specific target object, used to verify the integrity and legitimacy of the image associated with that object.
[0065] In this embodiment, the accuracy of object identification before image flashing is first addressed by converting it into an index value, simplifying the lookup process and ensuring the accuracy of the public key file selection. Secondly, a public key lookup table is used to quickly locate the target public key file, avoiding image verification failures caused by incorrect public key file selection. Finally, the accurate acquisition of the target public key file ensures the security and effectiveness of image verification, fundamentally reducing the probability of image flashing errors. During startup or maintenance operations, the server board can accurately determine the corresponding index value based on the target object's identification information, then look up the exact public key file name using the public key lookup table, and finally retrieve the target public key file from the board's internal public key file library for security verification and subsequent image flashing. This improves the accuracy and security of server image flashing.
[0066] In one embodiment, such as Figure 4 As shown, in step S200, before obtaining the identification information of the target object when the board is started, the method further includes: steps S400-S430:
[0067] Step S400: Set the index value corresponding to the identification information of the target object in the board to a preset default value.
[0068] Specifically, during the server board production or initialization phase, it is necessary to map the identification information of the target object (such as a specific customer) to a preset index value and set this index value as the default value. This operation lays the foundation for the default image loading and security verification during the subsequent image flashing process.
[0069] For example, when a server board is first started or in an unassigned client state, the system writes a pre-set default index value to an EEPROM or similar non-volatile storage medium. By default, the board uses this index value to locate and load the default image until explicit client assignment information updates the index value.
[0070] The default value is the index value used to instruct the server board to use a generic or vendor-preset image when there is no specific customer information.
[0071] Step S410: Find the corresponding default public key file name in the preset public key lookup table according to the default value.
[0072] Specifically, based on the default index value, the server board will look up the corresponding default public key filename in its preset public key lookup table. This filename will then be used to retrieve the specific public key file from the public key file repository for subsequent image verification.
[0073] For example, the server board reads a default index value stored in the EEPROM and uses it as a lookup key into a public key lookup table (typically a hash table or lookup table). In the lookup table, each index value corresponds to a public key filename. The system then retrieves the public key filename that matches the default index value based on the lookup result.
[0074] The public key lookup table stores the mapping between index values and corresponding public key filenames, used for quickly locating public key files. The default public key filename is the public key filename corresponding to the default index value, used to retrieve the default public key file from the public key file repository.
[0075] Step S420: Query the default public key file in the board's public key file library based on the default public key file name.
[0076] Specifically, based on the default public key filename, the server board will further search for and load the corresponding default public key file in the public key file library. This file is used to verify the preset initial image file, ensuring its legitimacy and integrity.
[0077] For example, the server board uses the default public key filename as the query criterion to locate and load the corresponding default public key file from the public key file repository into memory or temporary storage. The public key file repository is typically stored in the board's flash memory or similar non-volatile storage area to ensure the security and persistence of the public key files.
[0078] Step S430: Use the default public key file to decrypt and verify the preset initial image file in order to flash the initial image file to the board.
[0079] The digital signature of the initial image file matches the default public key file.
[0080] Specifically, the server board uses the default public key file to decrypt and verify the preset initial image file, checking whether its digital signature matches the default public key file. Only when the verification passes, meaning the image file's signature completely matches the default public key file, will the server board perform the image flashing operation to update its internal firmware image.
[0081] For example, the server board uses a security algorithm to decrypt the digital signature of the initial image file, while using a default public key file as the decryption key. If the decrypted signature matches the signature embedded in the image file, it indicates that the image file is legitimate and has not been tampered with. At this point, the board flashes the image file to its firmware storage area. For images of complex programmable logic devices, power supply units, and other hardware components on the server backplane, since their customization requirements are relatively low, most customers choose to use a unified, vendor-provided standard image. This image reuse strategy means that different customers can securely use the same image (default image) without needing to customize it for each customer, thus simplifying the image management process, reducing maintenance costs, and ensuring good compatibility and stability in various environments since shared images are usually rigorously tested.
[0082] The initial image file is the first image file used by the server board when no specific customer information is configured, and it is used for system startup or initialization.
[0083] In this embodiment, firstly, setting a default index value simplifies the board production process and initialization stage, ensuring that the system can start smoothly; secondly, the default public key file name is quickly located in the public key lookup table using the default index value, further improving initialization efficiency; thirdly, the default public key file is accurately retrieved from the public key file library, ensuring the availability of the security verification mechanism; finally, the legality and integrity of the initial image file are confirmed by decryption verification, ensuring the security and accuracy of image flashing.
[0084] In one embodiment, such as Figure 5 As shown, in step S220, when the board triggers the image flashing process, the target public key file is used to decrypt and verify the image file to be flashed on the board. This includes steps S500-S530:
[0085] In step S500, upon receiving an image upgrade request, the board's image flashing process is triggered to receive the image file to be flashed.
[0086] Specifically, when the server system or remote management interface receives an image upgrade request from a user or automated process, the board (such as a BMC board) will start its internal image flashing process to prepare to receive the image file to be flashed.
[0087] For example, upon receiving an image upgrade request, the board enters receive mode and listens for a specific port or interface used for image uploads. Once the image file arrives via the network or a direct connection, the board's firmware saves it to a temporary staging area to avoid writing it directly to the main storage area. This prevents irreversible damage to the existing system should the image file be corrupted.
[0088] An image upgrade request is a command sent by a user or automated process to the server system, requesting an update or replacement of the current board image. The image flashing process is a series of automated operations designed for the server board to receive, verify, and install new image files. The temporary storage area is a storage area on the board used to temporarily store the image file to be flashed; it is typically located in non-volatile memory to ensure data security.
[0089] Step S510: Save the image file to the board's temporary storage area and perform an integrity check on the image file.
[0090] Specifically, after the image file is received and temporarily stored, the server board will immediately perform an integrity check on the image file to ensure that the uploaded file has not been damaged or tampered with during the transmission process.
[0091] For example, the board firmware uses a specific verification algorithm to calculate the hash value of the image file and compares it with the hash value provided during upload. If the two hash values match, it means the image file is complete and error-free; otherwise, it indicates that the file may have a problem and needs to be re-uploaded.
[0092] The integrity check involves calculating the hash value of the image file and comparing it with the known correct hash value to confirm that the file has not been modified or corrupted during transmission.
[0093] Step S520: After the image file passes the integrity verification, extract the digital signature of the image file.
[0094] The digital signature is obtained by signing the object to which the image file belongs using a private key.
[0095] Specifically, once the integrity of the image file is confirmed, the server board will further extract the digital signature from the image file for subsequent public and private key verification processes.
[0096] For example, the board's image flashing program reads the end of the image file, where a digital signature is typically stored as part of the image file. After reading, the digital signature is stored in memory, ready for decryption and verification with the target public key.
[0097] Digital signatures are obtained by encrypting the hash value or part of the content of a file using a private key. Their purpose is to verify the integrity of the file and the credibility of its source.
[0098] Step S530: Decrypt and verify the digital signature using the target public key file to determine whether the image file to be flashed matches the target object.
[0099] Specifically, after obtaining the digital signature of the image file, the server board will use the previously determined target public key file to decrypt and verify the digital signature, ensuring that the image file was signed by the target object (such as a specific customer) using its private key, thereby confirming the legality and applicability of the image file.
[0100] For example, the server board uses a decryption algorithm and the target public key file to decrypt the extracted digital signature. If the hash value obtained after decryption matches the original hash value of the image file, the verification is successful, proving that the image file was signed by the target object with its private key and is suitable for upgrading the current server board.
[0101] In this embodiment, firstly, upon receiving an upgrade request, the board initiates the image flashing process, securely saving the image file to a temporary storage area to avoid risks to the existing system. Then, the image file undergoes an integrity check to ensure it has not been damaged or tampered with during transmission. Next, a digital signature is extracted to verify the legitimacy of the image file's origin. Finally, the digital signature is decrypted and verified using the target public key file, ensuring that only legitimate image files suitable for the current server board can be flashed. This effectively prevents the flashing of unauthorized or unknown image files, improving the security and accuracy of the image upgrade process.
[0102] In one embodiment, such as Figure 6 As shown, the method further includes steps S600-S620:
[0103] Step S600: Obtain the set of objects to which the board is applicable.
[0104] Specifically, a set of all potential objects (such as different customers) applicable to the server board is identified to ensure that the subsequent public key library construction can cover all possible service objects, thereby enabling secure image flashing operations to be performed under any circumstances.
[0105] For example, server manufacturers or management systems collect information about all customers who might use the board by querying databases, reading configuration files, or communicating with external services. This information typically includes customer names, customer IDs, or other identifiers for later use in building public key lookup tables.
[0106] Step S610: Based on the set of objects applicable to the board, obtain the public key files corresponding to the multiple objects respectively.
[0107] Specifically, based on the set of objects, a public key file is obtained for each object. These public key files will be used for digital signature verification of the image file to ensure the legality and integrity of the image file's origin.
[0108] For example, the manufacturer or system administrator obtains the public key file from each object (customer), typically via secure network transmission or physical media exchange. The obtained public key file is stored in a designated directory or database for later use when building a public key repository.
[0109] Step S620: Construct the board's public key file library based on the public key files corresponding to the multiple objects respectively.
[0110] Specifically, after collecting the public key files of all objects, these public key files are organized into a board public key file library so that the correct public key file can be quickly found and used during image flashing.
[0111] For example, all acquired public key files are copied to the board's public key file library directory, ensuring that the public key file library's structure allows for quick lookup and location of public key files. Access efficiency can be optimized by creating indexes, using hash tables, or other data structures. Building the public key file library enables centralized management and efficient access to public key files, ensuring that the public key file corresponding to the target object can be quickly located during image flashing, thereby performing an accurate verification process.
[0112] In this embodiment, firstly, a set of service objects is obtained, ensuring that all possible clients or configurations are considered, thus enhancing the system's compatibility and flexibility. Next, a corresponding public key file is obtained for each object, effectively preventing unauthorized image writing and ensuring the security of the server system. Finally, a public key file library is constructed, which not only achieves centralized management of public key files and improves the efficiency of image writing, but also enhances the accuracy of the verification process by quickly finding and locating public key files, reducing system risks caused by failure to find public key files.
[0113] In one embodiment, such as Figure 7 As shown, in step S230, if the image file to be flashed on the board passes verification, the image file to be flashed is flashed to the board. This includes steps S700-S730:
[0114] Step S700: Monitor the real-time resource status of the board.
[0115] Real-time resource status includes remaining storage space, processor utilization, and network bandwidth.
[0116] Specifically, before the server or its management components prepare for an image upgrade, the system first monitors the real-time resource status of the cards to ensure that the cards have the minimum resource conditions required to perform the upgrade operation. Real-time resource status monitoring includes checking whether there is enough remaining storage space to hold the new image file, whether the processor utilization rate allows for the image flashing process, and whether the network bandwidth can support the fast transmission of the image file, thus avoiding upgrade failures or system performance degradation due to insufficient resources.
[0117] For example, the system utilizes the board's internal resource management module to monitor storage space, processor load, and network connection status in real time. Storage space monitoring checks the available capacity of the board's storage units (such as flash memory) to ensure sufficient space to store the fragmented image files. Processor utilization monitoring periodically reads CPU usage to determine if the current load is below a preset threshold, thus determining whether the upgrade operation can be safely performed. Network bandwidth monitoring monitors the upload and download speeds of the current network connection to assess whether the network environment is stable enough to handle the transmission of image files. By monitoring the board's resource status in real time, the system ensures that image upgrades are performed in a resource-sufficient environment, effectively avoiding upgrade failures caused by insufficient storage space, excessive processor load, or network instability, ensuring the smooth progress of the image upgrade process, and improving the system's stability and reliability.
[0118] Real-time resource status refers to the current usage of system resources, including but not limited to storage space, CPU utilization, and network connection status. Remaining storage space is the unused storage capacity on the board available for storing new data. Processor utilization is the percentage of the CPU's total processing capacity that is currently being processed. Network bandwidth is the maximum amount of data a network connection can transmit per unit of time, reflecting the speed of network transmission.
[0119] Step S710: Based on the real-time resource status of the board, the image file is split into multiple file fragments.
[0120] The size of the file fragments is determined based on the real-time resource status of the board.
[0121] Specifically, based on the monitored resource status, the server system divides the original image file into multiple smaller file fragments for more efficient and secure transmission and flashing. Determining the fragment size requires consideration of remaining storage capacity, processor load, and network bandwidth stability to ensure that each fragment size guarantees transmission speed without excessively consuming system resources.
[0122] For example, the board upgrade procedure calculates the optimal fragment size based on the current resource status. For instance, when there is ample remaining storage space, file fragments can be appropriately increased to reduce the number of network transfers; when processor utilization is high, a smaller fragment size should be chosen to avoid excessive CPU load during the flashing process; and when network bandwidth is limited, the fragment size should also be reduced to decrease transmission time. Fragmentation processing is typically performed using a file system or specialized partitioning tools, ensuring that each fragment can be independently verified and flashed, thus improving the flexibility and security of the entire upgrade process. File fragments are small files obtained after fragmentation processing, typically containing a portion of the original file's data and metadata.
[0123] Step S720: Determine the writing order of multiple file segments based on the priority and dependency of the functional modules corresponding to the multiple file segments.
[0124] Specifically, after the image file is divided into multiple fragments, the system needs to determine a reasonable flashing order based on the priority and dependencies of the functional modules represented by each fragment. The priority of functional modules is usually based on their necessity for the normal operation of the system, while dependencies take into account possible mutual calls or configuration requirements between modules. Determining the flashing order ensures that important modules are upgraded first, while avoiding system failures caused by improper handling of dependencies.
[0125] For example, the system reads the metadata of the image file to understand the functional modules corresponding to each shard and their roles in the system. Then, based on a preset module upgrade strategy, such as prioritizing critical modules over non-critical ones and lower-level modules over higher-level ones, and considering the dependencies between shards (e.g., some modules must be upgraded before other modules can be updated), a flashing order list is generated. This list guides subsequent shard flashing operations, ensuring that each module is updated at the correct time, avoiding system conflicts or anomalies caused by improper upgrade order.
[0126] Functional modules are independent units that constitute the complete functionality of the system, such as network drivers, storage management, and the system kernel. Priority refers to the importance of a functional module to the normal operation of the system and is used to determine the order in which modules are upgraded. Dependencies are the mutual dependencies or calling relationships between different functional modules in the system, and they need to be properly handled during upgrades to avoid incompatibility issues between modules.
[0127] Step S730: Flash multiple files to the board in the order they are to be flashed.
[0128] In the process of flashing multiple file fragments, the flashing speed is adjusted according to the network bandwidth of the board.
[0129] Specifically, according to the determined flashing order, the system begins to flash the file fragments sequentially onto the server boards. This process requires continuous monitoring of network bandwidth and dynamic adjustment of the flashing speed to ensure that the image upgrade is completed without affecting other system services. The adjustment of the flashing speed can adapt to fluctuations in the network environment, avoiding long waiting times caused by network congestion, while also preventing excessive consumption of processor and storage resources due to excessively fast flashing speeds, which could lead to system instability.
[0130] For example, during execution, the flashing program monitors network bandwidth in real time and adjusts the file fragment transmission rate based on the available bandwidth. For instance, when network bandwidth is sufficient, the flashing speed can be increased to speed up the upgrade process; when network bandwidth is limited, the flashing speed is reduced to avoid affecting other network services.
[0131] In this embodiment, firstly, real-time resource status monitoring ensures that the board has sufficient resources for the upgrade operation, avoiding upgrade failure due to insufficient resources; secondly, the image file fragment processing adjusts the fragment size according to the current resource status, optimizing network transmission efficiency and reducing the burden on the processor and storage; thirdly, a reasonably determined flashing order avoids system failures caused by improper handling of functional module priorities and dependencies, ensuring a smooth upgrade process; finally, a flashing speed mechanism that dynamically adjusts based on network bandwidth ensures that image flashing is completed under optimal network conditions, while also avoiding interference with other system services, improving the overall stability and efficiency of the upgrade operation.
[0132] In one embodiment, such as Figure 8 As shown, the method further includes steps S800-S830:
[0133] Step S800: If the first image file of the board to be upgraded is obtained, the configuration file of the first image file is extracted to determine the first set of functional modules contained in the first image file.
[0134] Specifically, when a server system or its management component receives a new image file as an upgrade version, it first extracts the configuration file from the image file to parse and identify all the functional modules contained in the image. This process forms the basis for subsequent comparison of upgrade modules and determination of the upgrade order.
[0135] For example, the system reads a specific configuration file from the first image file, which details the names, versions, and other metadata of all functional modules in the image file. By parsing this information, the system can generate a first set containing all functional modules, which serves as the basis for subsequent processing.
[0136] The first image file is the image file to be upgraded, containing the new version's functional modules and corresponding configuration information. The configuration file, stored within the image file, describes the functional modules and other system configuration information, facilitating system reading and parsing. The first set of functional modules is extracted by parsing the configuration file of the first image file, representing a collection of all functional modules for subsequent comparison and upgrade operations.
[0137] Step S810: Read the current second image file of the board and extract the configuration file of the second image file to determine the second set of functional modules contained in the second image file.
[0138] Specifically, before preparing for an upgrade, the system needs to understand which functional modules are contained in the currently running image file. This involves reading and parsing configuration files. The purpose is to generate a second set of current functional modules, which is used to compare with the functional modules in the image file to be upgraded, and to identify the actual modules to be upgraded.
[0139] For example, the server board or its management system reads the configuration file from the currently running second image file and extracts a list of all functional modules using similar parsing techniques, forming a second set. This set will be used for subsequent comparison with the first set to determine the modules that actually need to be upgraded. By generating a second set of current functional modules, the system can clearly understand the existing configuration, providing accurate information for comparing old and new images and identifying upgrade needs, effectively avoiding unnecessary upgrade operations and reducing the waste of system resources.
[0140] The second image file is the image file currently running on the server board, containing all functional modules and configuration information of the current system. The second set of functional modules is a collection of all functional modules extracted by parsing the configuration file of the second image file, used for comparison with the functional modules in the image file to be upgraded.
[0141] Step S820: Compare the functional modules in the first set and the second set to determine the target functional module to be upgraded.
[0142] Among them, the target functional module belongs to the first set and not to the second set.
[0143] Specifically, after the configuration file is parsed, the system will compare the first set with the second set to identify the functional modules that exist in the first set but are missing in the second set. These modules are the target functional modules to be upgraded.
[0144] For example, the system compares the first set (the list of functional modules in the new image) with the second set (the list of functional modules in the current image) to identify the differences between the two sets. This is typically achieved through the difference operation of the sets, identifying modules that exist in the first set but not in the second set, which are the target functional modules to be upgraded. By accurately comparing the differences between the old and new functional modules, the system can clearly identify the list of modules to be upgraded, avoiding redundant operations on duplicate or unnecessary modules and effectively improving upgrade efficiency.
[0145] The target functional module is a functional module that exists in the first set but not in the second set, that is, a module that needs to be added or updated during the upgrade process.
[0146] Step S830: Extract the image file containing the target functional module from the first image file as the image file to be flashed.
[0147] Specifically, after identifying the target functional modules to be upgraded, the system extracts an image file containing only these target functional modules from the first image file (i.e., the image to be upgraded), which serves as the actual image file to be flashed. This process not only reduces the amount of data during the flashing process but also ensures the accuracy and efficiency of the flashing operation.
[0148] For example, the system uses file processing and packaging tools to extract data segments related to the target functional module from the first image file and recombine them into an image file to be flashed. This process may involve data compression, encryption, and regenerating configuration files to ensure that the extracted image file can completely and securely upgrade the target functional module, while being compatible with the server board flashing process.
[0149] The image file to be flashed is an image file extracted from the first image file that contains only the target functional module to be upgraded, and is used for subsequent flashing operations.
[0150] In this embodiment, firstly, the system accurately identifies all functional modules in the new image file; secondly, it understands the functional module configuration of the current image file, providing a basis for subsequent comparison and upgrade decisions; thirdly, by accurately comparing the new and old functional modules, the system identifies the target functional module that truly needs to be upgraded, avoiding unnecessary operations on duplicate modules; finally, the system extracts the image file containing the target functional module from the image file to be upgraded, as the actual image to be flashed. This process effectively reduces the amount of data transmission during the upgrade process, lowers the demand on system resources, and improves the efficiency and accuracy of the upgrade. The entire process, centered on efficient and accurate resource management, significantly reduces the system load caused by upgrade operations and enhances the security and stability of the upgrade process.
[0151] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.
[0152] Embodiments of this application also provide a device for flashing / writing image files. Figure 9 This is a structural block diagram of a mirror file flashing device according to an embodiment of this application. The device includes:
[0153] The reading module 901 is used to obtain the identification information of the target object when the board starts up. The board is pre-configured with a public key file library, which includes public key files of different objects.
[0154] The query module 902 is used to query the target public key file of the target object in the public key file library of the board based on the identification information.
[0155] The verification module 903 is used to decrypt and verify the image file to be flashed on the board using the target public key file when the board triggers the image flashing process.
[0156] The flashing module 904 is used to flash the image file to the board if the image file to be flashed passes the verification.
[0157] In one exemplary embodiment, the device is further configured to determine the index value corresponding to the target object based on the identification information. A lookup is performed in a preset public key lookup table based on the index value corresponding to the target object to determine the public key file name corresponding to the target object. The public key lookup table includes the correspondence between different index values and public key file names. A query is then performed in the board's public key file library based on the public key file name to obtain the target public key file for the target object.
[0158] In one exemplary embodiment, the device is further configured to set the index value corresponding to the identification information of the target object in the board to a preset default value. The corresponding default public key filename is then looked up in a preset public key lookup table based on the default value. The default public key file is then searched in the board's public key file library based on the default public key filename. The preset initial image file is decrypted and verified using the default public key file to write the initial image file to the board, wherein the digital signature of the initial image file matches the default public key file.
[0159] In one exemplary embodiment, the device is further configured to trigger a board image flashing process upon receiving an image upgrade request, to receive the image file to be flashed. The image file is saved to the board's temporary storage area, and its integrity is verified. After the image file passes the integrity verification, the digital signature of the image file is extracted, wherein the digital signature is obtained by signing the object to which the image file belongs using a private key. The digital signature is decrypted and verified using the target public key file to determine whether the image file to be flashed matches the target object.
[0160] In one exemplary embodiment, the apparatus is further configured to obtain a set of objects to which the board is applicable. Based on multiple objects in the set of objects to which the board is applicable, public key files corresponding to each of the multiple objects are obtained. A public key file library for the board is constructed based on the public key files corresponding to the multiple objects.
[0161] In one exemplary embodiment, the device is further configured to monitor the real-time resource status of the board, wherein the real-time resource status includes remaining storage space, processor utilization, and network bandwidth. Based on the real-time resource status of the board, the image file is fragmented to obtain multiple file fragments, wherein the size of each file fragment is determined according to the real-time resource status of the board. The writing order of the multiple file fragments is determined based on the priority and dependencies of the functional modules corresponding to the multiple file fragments. The multiple file fragments are written to the board in the writing order, wherein the writing speed is adjusted according to the network bandwidth of the board during the writing process.
[0162] In one exemplary embodiment, the apparatus is further configured to, upon obtaining a first image file of the board to be upgraded, extract a configuration file from the first image file to determine a first set of functional modules contained in the first image file. It then reads the current second image file of the board, extracts a configuration file from the second image file to determine a second set of functional modules contained in the second image file. The functional modules in the first and second sets are compared to determine the target functional module to be upgraded, wherein the target functional module belongs to the first set and not to the second set. Finally, an image file containing the target functional module is extracted from the first image file as the image file to be flashed.
[0163] For a description of the features of the image file flashing device in the corresponding embodiment, please refer to the relevant description of the image file flashing method in the corresponding embodiment, which will not be repeated here.
[0164] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described methods for flashing image files.
[0165] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described methods for flashing image files.
[0166] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0167] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described methods for flashing image files.
[0168] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described image file flashing method embodiments.
[0169] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0170] The foregoing has provided a detailed description of the image file flashing method, apparatus, electronic device, computer-readable storage medium, and computer program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.
Claims
1. A method for flashing a mirror file, characterized in that, The method comprises: In the case of starting the board card, obtaining the identification information of the target object, wherein the board card is pre-configured with a public key file library, and the public key file library comprises public key files of different objects; According to the identification information, the target public key file of the target object is queried in the public key file library of the board card; In the case that the board card triggers the image flashing process, the target public key file is used to decrypt and verify the image file to be flashed of the board card; In the case that the image file to be flashed of the board card is verified, the image file to be flashed is flashed to the board card.
2. The mirror file flashing method according to claim 1, wherein, According to the identification information, the target public key file of the target object is queried in the public key file library of the board card, comprising: According to the identification information, the index value corresponding to the target object is determined; According to the index value corresponding to the target object, the public key file name corresponding to the target object is determined by searching in the preset public key correspondence table, wherein the public key correspondence table comprises the correspondence between different index values and public key file names; According to the public key file name, the target public key file of the target object is queried in the public key file library of the board card.
3. The mirror file flashing method according to claim 2, wherein, Before obtaining the identification information of the target object in the case of starting the board card, the method further comprises: The index value corresponding to the identification information of the target object in the board card is set to a preset default value; According to the default value, the corresponding default public key file name is found in the preset public key correspondence table; According to the default public key file name, the default public key file is queried in the public key file library of the board card; The default public key file is used to decrypt and verify the preset initial image file, so as to flash the initial image file to the board card, wherein the digital signature of the initial image file matches the default public key file.
4. The mirror file flashing method according to any one of claims 1 to 3, wherein In the case that the board card triggers the image flashing process, the target public key file is used to decrypt and verify the image file to be flashed of the board card, comprising: In the case that the image upgrade request is received, the image flashing process of the board card is triggered to receive the image file to be flashed; The image file is saved to the temporary area of the board card, and the integrity of the image file is verified; After the image file passes the integrity verification, the digital signature of the image file is extracted, wherein the digital signature is signed by the object to which the image file belongs by using a private key; The target public key file is used to decrypt and verify the digital signature, so as to determine whether the image file to be flashed matches the target object.
5. The mirror file flashing method according to any one of claims 1 to 3, wherein The method further comprises: Obtaining a set of objects applicable to the board card; According to the plurality of objects in the set of objects applicable to the board card, the public key files corresponding to the plurality of objects are respectively obtained; According to the public key files corresponding to the plurality of objects respectively, the public key file library of the board card is constructed.
6. The flashing method of mirror image file according to any one of claims 1-3, characterized in that, In the case that the image file to be flashed of the board card is verified, the image file to be flashed is flashed to the board card, comprising: monitoring a real-time resource state of the board card, wherein the real-time resource state comprises a storage remaining space, a processor occupancy rate, and a network bandwidth; performing a file fragmentation on the image file according to the real-time resource state of the board card to obtain a plurality of file fragments, wherein a size of the file fragment is determined according to the real-time resource state of the board card; determining a flashing order of the plurality of file fragments according to a priority and a dependency relationship of a function module corresponding to the plurality of file fragments; flashing the plurality of file fragments to the board card in the flashing order, wherein a flashing speed is adjusted according to the network bandwidth of the board card during the flashing of the plurality of file fragments.
7. The flashing method of mirror image files according to any one of claims 1-3, characterized in that, The method further comprises: in a case where a first image file to be upgraded of the board card is acquired, extracting a configuration file of the first image file to determine a first set of function modules contained in the first image file; reading a second image file of the board card at present, extracting a configuration file of the second image file to determine a second set of function modules contained in the second image file; comparing the function modules in the first set and the second set to determine a target function module to be upgraded, wherein the target function module belongs to the first set and does not belong to the second set; extracting an image file containing the target function module from the first image file as an image file to be flashed.
8. A mirror file flashing device, characterized in that, comprise: a reading module, configured to acquire identification information of a target object in a case where a board card is started, wherein the board card is pre-configured with a public key file library, and the public key file library comprises public key files of different objects; a querying module, configured to query a target public key file of the target object in the public key file library of the board card according to the identification information; a verifying module, configured to, in a case where the board card triggers an image flashing process, perform decryption verification on an image file to be flashed of the board card by using the target public key file; a flashing module, configured to, in a case where the image file to be flashed of the board card passes the verification, flash the image file to be flashed to the board card.
9. An electronic device, comprising: comprise: a memory, configured to store a computer program; a processor, configured to implement steps of the method in any one of claims 1 to 7 when the computer program is executed.
10. A computer-readable storage medium, characterized in that, The computer program is stored in the computer readable storage medium, and the computer program is executed by the processor to implement steps of the method in any one of claims 1 to 7.