Guided partition recovery method and electronic device

Abstract

This application discloses a boot partition recovery method and electronic device, relating to the field of computer technology. It continuously monitors the operating system's startup status through a management controller independent of the operating system, and automatically triggers a system restart when a startup failure is detected. This achieves real-time perception and response to system faults. After a system restart and before the operating system loads, the system initializes the system, reads the startup flag set by the management controller, and retrieves pre-backed boot partition data from the management controller through a standard management interface when the flag indicates a startup failure. This completes the automated recovery of the boot partition. Independent of the operating system's running state, it can reliably execute even when the operating system itself cannot start, reducing business interruption time caused by system crashes and improving the availability and business continuity of the server system.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a boot partition recovery method and electronic device. Background Technology

[0002] With the rapid development of information technology, servers and data centers are playing an increasingly important role in enterprise-level operations and maintenance, cloud computing, virtualization, and mission-critical systems. The operating system (OS), as the core software platform for server operation, stores the critical data and configurations required for startup in its boot partition. If the boot partition is damaged or lost, the server will be unable to complete the startup process successfully, directly leading to system crashes and severely impacting business continuity, service availability, and data security.

[0003] In related technologies, the recovery of the operating system's boot partition often requires the operating system to be running normally, otherwise it cannot be implemented. Moreover, when the operating system's boot partition is damaged, manual on-site intervention or repair through external media is required, which is inefficient. Therefore, how to perform efficient and reliable recovery of the operating system's boot partition is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a boot partition recovery method and electronic device to at least solve the problem of how to efficiently and reliably recover the boot partition of an operating system in related technologies.

[0005] This application provides a boot partition recovery method applied to a server system, the server system including a management controller and an operating system, wherein:

[0006] The management controller monitors the boot status of the operating system and sets the corresponding boot flag for the operating system;

[0007] The management controller responds to a startup status indication that the operating system has failed to boot, triggering an operating system restart.

[0008] During the current boot process, the operating system activates the initialization system, which reads the boot flag and responds to the boot flag indicating boot failure. It then obtains the first boot partition data from the management controller through the second standard management interface. The first boot partition data is the data that the operating system uploaded and stored to the management controller through the first standard management interface during its historical normal operation.

[0009] The initialization system performs boot partition recovery processing on the operating system based on the data from the first boot partition.

[0010] This application also provides a server system, wherein the server is used to perform the steps of the above-described boot partition recovery method, including: a management controller and an operating system.

[0011] The management controller is configured to monitor the startup status of the operating system running on the system module and set the startup flag corresponding to the operating system.

[0012] The management controller is also configured to trigger an operating system restart in response to a startup status indication that the operating system has failed to boot.

[0013] The operating system activates and initializes the system during the current boot process;

[0014] The initialization system is configured to read the boot flag through the operating system's initialization system, and in response to the boot flag indicating boot failure, obtain the first boot partition data from the management controller through the second standard management interface. The first boot partition data is the data that the operating system uploaded and stored to the management controller through the first standard management interface during its historical normal operation.

[0015] The system is initialized and configured to perform boot partition recovery processing on the operating system based on the data from the first boot partition.

[0016] 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 boot partition recovery methods.

[0017] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of any of the above-described boot partition recovery methods.

[0018] 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 boot partition recovery methods.

[0019] This application provides a boot partition recovery method and electronic device. By constructing an automated recovery mechanism that coordinates the server's management controller and the operating system's initialization system, it solves the inherent drawback of relying on manual on-site intervention or external media repair when the system fails to boot due to boot partition corruption. Through a management controller independent of the operating system, it continuously monitors the operating system's boot status and automatically triggers a system restart upon detecting boot failure, achieving real-time detection and response to system faults. After system restart and before the operating system loads, the initialization system reads the boot flag set by the management controller. When the flag indicates boot failure, it retrieves pre-backed boot partition data from the management controller via a standard management interface, thereby completing the automated recovery of the boot partition. Independent of the operating system's running state, it can reliably execute even when the operating system itself cannot boot, reducing business interruption time caused by system downtime and improving server system availability and business continuity. Attached Figure Description

[0020] 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.

[0021] Figure 1 A schematic flowchart illustrating a boot partition recovery method provided in an embodiment of this application;

[0022] Figure 2 This application provides a schematic diagram of the architecture of a server system.

[0023] Figure 3 This is a flowchart illustrating another boot partition recovery method provided in an embodiment of this application. Detailed Implementation

[0024] 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.

[0025] 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.

[0026] This application relates to the field of server system management technology, specifically a boot partition recovery method applied to a server system including a management controller and an operating system. This method, through a collaborative mechanism between the management controller and the operating system, enables automated detection, backup, and recovery of the operating system's boot partition. This allows for rapid and reliable recovery of the boot environment when the operating system fails to boot, improving server availability and business continuity.

[0027] A server system is a computing device typically used in enterprise-level operations and maintenance, data center, or cloud computing environments. Its core components include a hardware platform, a management controller, and an operating system. The management controller is an embedded controller independent of the main operating system, such as a Baseboard Management Controller (BMC). It has an independent operating environment and network connectivity, enabling remote monitoring, fault diagnosis, and system management functions through a standard management interface. The operating system (OS) is the core software running on the server hardware platform, responsible for managing hardware resources, executing applications, and providing system services. The operating system's startup depends on a boot partition, which stores critical data required for startup, including the boot loader, kernel image, initial random access memory (RAM) disk, and boot parameter configuration files.

[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] Figure 1 This document provides a flowchart illustrating a boot partition recovery method as an embodiment of the present application. The method is described in detail below in conjunction with its execution flow.

[0030] Step 101: The management controller monitors the startup status of the operating system and sets the corresponding startup flag for the operating system.

[0031] In the embodiments of this application, the startup state refers to the operating status of the operating system during the startup process, including states such as successful startup or startup failure. The management controller monitors the operation of the operating system through a built-in monitoring mechanism, such as a watchdog timer. A watchdog timer is a hardware or software monitoring technology that detects whether the system is operating normally by periodically feeding the watchdog signal; if the operating system fails to successfully feed the watchdog within a preset time, the management controller determines that the startup state has failed.

[0032] A boot flag is a status flag stored in the persistent storage space within the management controller, used to record the boot outcome of the last operating system boot. For example, the boot flag can be set to a binary value, where 0 indicates successful boot and 1 indicates boot failure. The management controller dynamically updates this flag based on monitoring results, thus providing a status basis for subsequent recovery processes.

[0033] Step 102: In response to the startup status indication that the operating system has failed to start, the management controller triggers an operating system restart.

[0034] In the embodiments of this application, when the management controller detects an operating system startup failure through a watchdog timeout mechanism, it automatically generates a restart signal and sends it to the Central Processing Unit (CPU) via the system bus or management interface, triggering a hardware restart of the entire system. This process ensures that if the operating system cannot recover on its own, the system can re-enter the startup process, creating conditions for subsequent recovery operations.

[0035] Step 103: During the current boot process, the operating system activates the initialization system, reads the boot flag, and responds to the boot flag indicating boot failure by obtaining the first boot partition data from the management controller through the second standard management interface. The first boot partition data is the data that the operating system uploaded and stored to the management controller through the first standard management interface during its historical normal operation.

[0036] In the embodiments of this application, the initialization system typically refers to the Basic Input Output System (BIOS) or the Unified Extensible Firmware Interface (UEFI), which is the firmware layer executed first during the boot process of the server's operating system and is responsible for hardware initialization, self-test, and loading the operating system bootloader.

[0037] During the current startup process, after the initialization system is activated, it communicates with the management controller through a standard management interface. The second standard management interface is a remote management protocol based on open standards, such as the Intelligent Platform Management Interface (IPMI) or the Redfish protocol, which allows the initialization system to access data stored in the management controller out of band.

[0038] The initialization system reads the boot flag through the second standard management interface. If the flag indicates a previous boot failure, it requests the first boot partition data from the management controller. The first boot partition data is backup data uploaded and stored to the management controller by the operating system during its historical normal operation via the first standard management interface. The first standard management interface is also a standard management protocol, such as the Redfish protocol, which supports data transmission based on the Representational State Transfer API (RESTful API) and JavaScript Object Notation (JSON). During normal operation, the operating system uploads critical boot partition data (such as a complete image or a set of critical files) to the management controller through this interface. After receiving the data, the management controller performs compression, encryption, and verification processing, and assigns a unique version number for storage, ensuring data integrity and security.

[0039] Step 104: Initialize the system and perform boot partition recovery processing on the operating system based on the data of the first boot partition.

[0040] In the embodiments of this application, the boot partition recovery process refers to writing the acquired first boot partition data into the boot partition area of ​​the storage device, overwriting the original damaged or abnormal data. The initialization system uses hardware detection logic to identify the specific location of the operating system boot partition in the storage device (e.g., disk partition number, starting sector address, partition size, etc.), ensuring accurate location of the partition to be recovered. Subsequently, the initialization system sends a data writing instruction to the storage device, writing the first boot partition data segment by segment into the corresponding partition area according to the boot partition's storage structure. During this process, the first boot partition data overwrites the original damaged or abnormal boot partition data in the storage device, thereby restoring the operating system's boot partition to its historical normal operating state. During the data writing process, the initialization system strictly controls the writing scope, operating only on the boot partition to avoid accidentally writing to other partitions in the storage device (e.g., user data partition, application installation partition), preventing additional data loss or system failure.

[0041] Before writing data, the initialization system performs integrity checks and signature verification to prevent data tampering or corruption. After writing is complete, the initialization system notifies the management controller via the management interface to reset the boot flag to a successful state, and then continues the normal boot process to load the operating system. This recovery process ensures that the operating system can restart based on reliable backup data, thus avoiding system crashes caused by boot partition corruption.

[0042] Once the boot partition recovery process is complete, the initialization system will continue with the normal operating system boot process: it will read the boot loader from the recovered boot partition, load the kernel image and initial RAM disk through the boot loader, perform kernel initialization and driver loading, and finally boot the operating system. Since the boot partition data has been restored to a complete and normal state, the operating system can successfully complete all boot stages and enter normal operation. After successful boot, the operating system will, according to preset logic, upload the current normal boot partition data to the management controller through the first standard management interface, updating the version of the first boot partition data and preparing for potential boot failures in the future.

[0043] This application achieves automated recovery of the operating system boot partition through a collaborative mechanism between the management controller and the initialization system. It enhances the system's autonomous repair capabilities, triggering the recovery process upon boot failure without manual intervention; strengthens system reliability by ensuring a rapid return to normal operation under abnormal conditions through a closed-loop design of status monitoring, data backup, and recovery operations; optimizes recovery efficiency by backing up and restoring only the boot partition, avoiding redundant operations on the entire disk image and shortening recovery time; enhances remote operation and maintenance support by leveraging the out-of-band management capabilities of the management controller, enabling remote repair even when the operating system fails to boot, suitable for unattended scenarios; furthermore, this application is based on a standard management interface, possessing excellent compatibility and seamlessly integrating into existing server architectures.

[0044] In one possible implementation of this application embodiment, when the management controller monitors the startup status of the operating system, it can be implemented in the following ways, but not limited to: the management controller monitors whether the operating system performs a reset operation on the watchdog timer within a preset time period; the management controller determines that the startup status of the operating system is a startup failure in response to the operating system not performing a reset operation on the watchdog timer within the preset time period; the management controller determines that the startup status of the operating system is a startup success in response to the operating system performing a reset operation on the watchdog timer within the preset time period.

[0045] In the embodiments of this application, the management controller relies on a watchdog timer monitoring mechanism when monitoring the operating system's startup status. A watchdog timer is a hardware or software-implemented timer circuit whose core function is to monitor the system's operating status by periodically resetting it to detect whether the system is running normally. In server systems, the watchdog timer is typically configured and managed by the management controller, and its timing period is defined by a preset time period. This time period can be set according to system requirements, for example, from tens of seconds to several minutes, to adapt to the startup time characteristics of different operating systems.

[0046] The management controller monitors whether the operating system performs a reset operation on the watchdog timer within a preset time period. This reset operation, often called "feeding the dog," refers to the operating system periodically sending a signal to the watchdog timer during normal operation to reset its timer and prevent timeout. This mechanism ensures that the operating system can actively prove its active state. If the operating system successfully performs the reset operation within the preset time period, the management controller determines the operating system's startup status as "Startup Success," indicating that the operating system has successfully completed the startup process and entered a stable operating phase. Conversely, if the operating system does not perform a reset operation within the preset time period, the management controller determines the startup status as "Startup Failure," indicating that the operating system may have encountered an anomaly, crashed, or failed to complete initialization during the startup process.

[0047] The watchdog timer's timeout mechanism provides the management controller with operating system-independent fault detection capabilities. The management controller monitors the timer's status in real time via hardware interrupts or status registers, and automatically triggers a status determination process upon detecting a timeout event. This monitoring method does not rely on the operating system's internal logs or software agents, thus ensuring reliable operation even when the operating system is completely unresponsive. The startup status determination result is recorded in the management controller's persistent storage and associated with a startup flag, providing input for subsequent recovery decisions.

[0048] This application utilizes a watchdog monitoring mechanism to achieve efficient and automated startup status detection, improving the real-time performance and reliability of fault detection. Hardware-level monitoring avoids misjudgments caused by operating system software layer anomalies; it enhances system autonomy, enabling status determination and recording without manual intervention; and it optimizes resource utilization by implementing status monitoring through a simple timer reset operation, eliminating the need for complex software agents or additional computational overhead.

[0049] In one possible implementation of this application embodiment, when setting the startup flag corresponding to the operating system, it can be implemented in the following ways, but not limited to: the management controller responds to the startup status as startup failure by setting the startup flag to a first value indicating startup failure; the management controller responds to the startup status as startup success by setting the startup flag to a second value indicating startup success.

[0050] In the embodiments of this application, the startup flag is a state variable stored in the persistent storage area within the management controller. Essentially, it is a readable and writable numerical flag used to accurately record the result of the operating system's most recent startup attempt. The management controller dynamically updates the flag's value based on the monitored startup status, thus forming a key state node in the system's self-healing logic. The startup flag's value setting adopts a binary design, using different values ​​to represent different system states. This design simplifies the state judgment logic and improves the reliability of the system response.

[0051] When the management controller detects a startup failure, it sets the startup flag to the first value indicating the failure. This first value is typically defined as a non-zero value, such as 1, which logically means the system failed to complete the startup process in the previous cycle. Upon detecting a watchdog timer timeout and not receiving a reset signal from the operating system, the management controller immediately performs a write operation in non-volatile memory, updating the startup flag to this first value. This setting action is synchronized with fault detection, ensuring the real-time nature and accuracy of status recording and providing a clear trigger condition for the recovery process after a subsequent system restart.

[0052] Accordingly, when the management controller responds to a successful startup status, it sets the startup flag to a second value indicating successful startup. This second value is typically defined as zero, for example, 0, which logically means that the system successfully completed the startup process and entered a stable operating state in the previous cycle. After confirming that the operating system has successfully performed a watchdog reset operation within a preset time period, the management controller will proactively update the startup flag to this second value. This reset operation signifies that the system has entered the normal operating phase, while simultaneously clearing any previously existing fault state records, preparing for monitoring in the next startup cycle.

[0053] The numerical management mechanism of the boot flag forms the core of system state awareness. The management controller implements atomic operations on the flag through internal firmware logic, ensuring the consistency of the flag value in multi-tasking or interrupt environments. Persistent storage guarantees that the state information carried by the boot flag is retained even after a system power failure and restart, enabling the initialization system to obtain accurate historical states in subsequent boot phases. This numerical state recording method allows initialization systems such as BIOS or UEFI to quickly complete state judgments through simple numerical comparison instructions, without parsing complex log files or performing lengthy diagnostic processes, thus significantly improving the execution efficiency of the system self-healing process.

[0054] This application achieves controllable recording and transmission of system status through a startup flag setting mechanism. By defining explicit values, it avoids ambiguity in status determination, improving the accuracy of status management; it ensures the persistence and transmission of historical startup states during restart cycles, enhancing system consistency; and it provides a simple and direct basis for system initialization, accelerating the triggering of recovery processes and optimizing decision-making efficiency.

[0055] In one possible implementation of this application embodiment, in order to ensure that critical data of the boot partition is reliably backed up in a healthy system state and to provide a data foundation for possible subsequent recovery operations, the operating system needs to upload boot partition data to the management controller during normal historical operation. Specifically, but not limited to the following methods, the operating system can also use: During normal historical operation, the operating system sends the boot partition data in the boot partition to the management controller through a first standard management interface; the management controller performs compression and encryption processing on the received boot partition data, and assigns a first version identifier to the processed boot partition data based on the timestamp of the boot partition data sent by the operating system; the management controller determines the processed boot partition data with the first version identifier as the first boot partition data, and stores the first boot partition data in non-volatile storage space.

[0056] In the embodiments of this application, the historical normal operation process of the operating system refers to the stage where the server system is in a stable working state, the operating system has completed startup, and all necessary services have been successfully loaded. During this stage, the operating system can proactively perform data backup tasks through its internal agents or scripts to ensure that the boot partition data is captured in an up-to-date and consistent state. The historical normal operation process is typically confirmed by the management controller through a watchdog mechanism or heartbeat signal, and its time point can cover any stable operating period after system startup, thereby avoiding backup operations during system initialization or when the load is too high.

[0057] The operating system sends the boot partition data from its boot partition to the management controller via the first standard management interface (LSI). The LSI is a remote management protocol based on open standards, such as the Redfish protocol. It uses a RESTful architecture and JSON data format, supporting secure and efficient out-of-band communication. The operating system encapsulates the locally stored boot partition data into a standardized request and sends it to the management controller by calling a specific endpoint of this interface. Boot partition data refers to critical startup information stored in the boot partition, including the boot loader, kernel image, initial RAM disk image, and boot parameter configuration files. This data collectively forms the foundation for the operating system's boot process, and its integrity and correctness directly affect whether the system can boot normally.

[0058] The management controller performs compression and encryption on the received boot partition data. Compression refers to reducing data volume through algorithms, such as lossless compression algorithms like LZ77 or DEFLATE, aiming to reduce storage space usage and network transmission load. Encryption processing involves encoding the data using cryptographic algorithms to ensure its confidentiality and security, such as using encryption standards like Advanced Encryption Standard (AES) or RSA, combined with a security key built into the management controller. These processing steps are automatically executed by the management controller's firmware logic, optimizing storage efficiency and preventing unauthorized access or tampering of data during transmission or storage.

[0059] The management controller assigns a first-version identifier to the processed boot partition data based on the timestamp of the boot partition data sent by the operating system. The timestamp is the system time information recorded when the data upload occurred, typically stored in Coordinated Universal Time (UTC) format, accurate to the millisecond level, and used to uniquely identify the time point of the backup operation. The first-version identifier is a unique string or numeric label generated by the management controller, which may include a hash value of the timestamp, a sequence number, or a combination of codes, such as v20240915_103000. This identifier is bound to the backup data, facilitating accurate identification and selection of a specific version of the data in subsequent recovery processes.

[0060] The management controller identifies the processed boot partition data, marked with a first version identifier, as the first boot partition data and stores it in non-volatile storage. The first boot partition data refers to a compressed, encrypted, and version-tagged backup data set, the contents of which correspond to the boot partition state of the operating system during its historical normal operation. Non-volatile storage is a persistent storage medium, either internal or external to the management controller, such as Flash memory or EEPROM, characterized by its ability to retain data even after system power loss. The management controller manages this data through a file system or key-value database, ensuring its long-term accessibility and integrity.

[0061] This application achieves automated and secure storage of boot partition data through a data backup mechanism. It ensures the availability and consistency of backup data through standard interfaces and preprocessing, improving the reliability of data backup; it enables fine-grained management of backup data through timestamps and identifiers, supports multi-version recovery strategies, and enhances version management capabilities; it reduces storage overhead and ensures data security through compression and encryption, optimizing storage resource utilization; and it provides a foundation for long-term retention and fast retrieval of data in non-volatile storage, improving system maintainability.

[0062] In one possible implementation of this application embodiment, in order to ensure that the system still has subsequent recovery capabilities even if the first recovery fails, and to provide support for remote operation and maintenance through an intelligent alarm mechanism, a complete recovery verification and emergency handling mechanism needs to be constructed. Specifically, the following methods may also be used, but are not limited to: the management controller continues to monitor the operating system's post-recovery startup status; if the post-recovery startup status indicates that the operating system has failed to start, the system initializes and obtains the second boot partition data from the management controller, and performs boot partition recovery processing on the operating system, wherein the second boot partition data is the boot partition data sent by the operating system to the management controller before the first boot partition data; the management controller records the number of consecutive startup failures of the operating system, and in response to the number of consecutive startup failures exceeding a preset failure number threshold, generates fault alarm information and sends the fault alarm information to the remote management platform; if the post-recovery startup status indicates that the operating system has started successfully, the management controller clears the number of consecutive startup failures to zero and resets the startup flag to the second value indicating successful startup.

[0063] In the embodiments of this application, after the initialization system completes the boot partition recovery process for the operating system based on the first boot partition data, the management controller continues to monitor the post-recovery boot status of the operating system. The post-recovery boot status refers to the operating status of the operating system when it attempts to boot again after the boot partition data recovery operation. The management controller continuously monitors this status using the same watchdog timer mechanism to ensure consistency in monitoring standards. This continuous monitoring constitutes a key verification step in the system's self-healing closed loop, used to determine the actual effectiveness of the initial recovery operation.

[0064] If the boot status after recovery indicates that the operating system failed to boot, the initialization system will retrieve the second boot partition data from the management controller and perform a new round of boot partition recovery processing on the operating system. The second boot partition data is the boot partition data that the operating system sent and stored to the management controller before the backup time point corresponding to the first boot partition data. This data typically corresponds to an earlier system backup state, and its version identifier's timestamp is earlier than the first boot partition data. This design implements a multi-version recovery mechanism. When the latest version of the backup data may fail to restore the system for some reason (such as incompatibility with the current hardware configuration or potential problems), the system can automatically roll back to a historical version and attempt to complete the recovery using an earlier backup, significantly improving the final success rate of system recovery.

[0065] Meanwhile, the management controller records the number of consecutive startup failures of the operating system. When this number exceeds a preset failure threshold, it generates a fault alarm and sends it to the remote management platform. The consecutive startup failure count is a cumulative counter that specifically records the number of times the system fails to start without a single successful boot. The preset failure threshold is a configurable integer value, such as 3 or 5, used to define the upper limit of the system's autonomous recovery attempts. When the consecutive failure count exceeds this threshold, the management controller determines that the system may have encountered a complex fault that cannot be resolved through automatic recovery. It then generates an alarm message containing detailed fault context (such as the number of failures, the backup version used, and timestamps) and sends it to the remote centralized operation and maintenance management system via the network interface, notifying the administrator to intervene manually.

[0066] If the boot status indicates that the operating system has booted successfully after recovery, it means that the recovery process was effective and the system has returned to normal. At this point, the management controller performs two key operations: First, it resets the consecutive boot failure count to zero, clearing the previous failure record and resetting the counter for the next possible fault cycle; second, it resets the boot flag to the second value indicating a successful boot, thereby updating the system status record and marking the beginning of the current operating cycle with a successful boot. These two operations together complete the normalization of the system status, ensuring the accuracy and closed-loop nature of system status management.

[0067] This application deepens and improves the system's self-healing process through a post-recovery processing mechanism. A multi-version recovery mechanism avoids recovery deadlocks caused by problems with a single backup data source, enhancing system fault tolerance; failure count statistics and threshold alarms enable proactive fault reporting and precise fault location, enhancing the intelligence of operation and maintenance; successful state resets and zeroing of failure counts maintain the clarity and accuracy of system state logic, ensuring the rigor of state management; ultimately, a complete fault handling chain is constructed, from automatic recovery to requesting manual intervention when necessary, greatly improving the reliability and serviceability of the server system in unattended environments.

[0068] In one possible implementation of this application embodiment, in order to ensure that the data source used for recovery is intact and undamaged, thus forming an important security barrier in the system self-healing process, a data integrity verification process needs to be performed before using the boot partition data for recovery. Specifically, the following methods may also be used, but are not limited to: the initialization system performs integrity verification processing on the first boot partition data through a preset verification algorithm to obtain an integrity verification result; in response to the integrity verification result indicating that the first boot partition data meets the preset verification conditions, the initialization system performs boot partition recovery processing on the operating system based on the first boot partition data, and notifies the management controller to reset the boot flag to a second value; in response to the integrity verification result indicating that the first boot partition data does not meet the preset verification conditions, the initialization system obtains the second boot partition data from the management controller and performs boot partition recovery processing on the operating system.

[0069] In the embodiments of this application, the preset verification algorithm is a cryptographic hash function or checksum algorithm pre-embedded in the initialization system firmware, such as SHA-256, MD5, or CRC32. Its working principle is to perform mathematical calculations on the input first boot partition data to generate a fixed-length, unique digital fingerprint, i.e., a hash value or checksum. The initialization system compares this calculated value with the original checksum generated during backup by the management controller for storing the first boot partition data.

[0070] The integrity verification result is the conclusion of this comparison operation, clearly indicating whether the data in the first boot partition meets the preset verification conditions. The core of the preset verification conditions is to determine whether the calculated check value is completely consistent with the stored original check value. If they are consistent, the verification result indicates that the data meets the conditions, meaning that the data has not been tampered with or damaged since the backup and has maintained its complete original state; if they are inconsistent, the verification result indicates that the data does not meet the conditions, indicating that the data may have been accidentally changed or maliciously tampered with during storage, transmission, or processing.

[0071] Upon initialization, if the integrity verification result indicates that the data in the first boot partition meets the preset verification conditions, the system performs two consecutive critical operations. First, it trusts the data and performs boot partition recovery processing on the operating system accordingly, writing the verified and intact data into the boot partition. Immediately after processing, it notifies the management controller via the management interface to reset the boot flag to a second value indicating successful boot.

[0072] Conversely, if the integrity check result indicates that the first boot partition data does not meet the preset check conditions, the initialization system determines that the backup data of that version is unusable. In this case, the system will not attempt to recover using this contaminated or corrupted data, but will automatically trigger a backup recovery strategy. The initialization system will obtain the second boot partition data from the management controller and immediately perform boot partition recovery processing on the operating system based on this earlier backup data. This mechanism reflects the system's fault tolerance and degradation strategy; when the preferred latest backup data fails, it can seamlessly switch to a historical backup, maximizing the continuation of the recovery process.

[0073] This application introduces an integrity verification mechanism, adding a crucial quality control step to the boot partition recovery process. This significantly improves the security and reliability of the recovery operation, fundamentally preventing secondary failures or recovery failures caused by using corrupted backup data. Automated data verification and failover reduce reliance on manual judgment and enhance the system's intelligent decision-making capabilities. A deeper defense system is constructed to ensure the data written to the boot partition is trustworthy, thereby improving the robustness and success rate of the entire self-healing system.

[0074] In one possible implementation of this application embodiment, when the initialization system reads the startup flag, it can be implemented in the following ways, but not limited to: the initialization system reads the startup flag from the management controller through the intelligent platform management interface command.

[0075] In the embodiments of this application, the process of initializing the system to read the startup flag is completed through Intelligent Platform Management Interface (IPMI) commands. The Intelligent Platform Management Interface (IPMI) is an open, operating system- and main processor-independent hardware management standard protocol that defines a complete set of commands and data structures for implementing out-of-band management functions. IPMI commands are predefined specific operation instructions in the IPMI protocol, such as commands for reading sensor data, controller status, or non-volatile storage data. In this scenario, the initialization system initiates a status query request to the management controller by calling a dedicated IPMI read command. This command typically includes parameters such as the storage address and data length of the target data to ensure accurate access to the storage location of the startup flag.

[0076] The mechanism of reading the boot flag via IPMI commands has several inherent advantages. First, as an industry-standard protocol, IPMI's command format and communication process are highly standardized and consistent, ensuring seamless interaction between initialization systems and management controllers from different vendors. Second, IPMI communication is based on the system management bus or other low-level hardware interfaces, and its operation is independent of the operating system's running state. Therefore, even if the operating system fails to boot completely, the initialization system can still reliably obtain the boot flag. Third, the IPMI protocol has built-in error detection and retransmission mechanisms, such as using checksums and sequence numbers to ensure the integrity of data transmission and avoid misjudgments of status due to communication errors.

[0077] The reading process of this application improves the reliability and timeliness of status acquisition, ensuring that key status information can be accurately captured in the early stages of startup through a hardware-level standard interface; it enhances the interoperability of the system, enabling this application to be widely used in various server platforms that support the IPMI standard; and it optimizes the intelligence level of the system initialization process, providing a basis for decision-making for system initialization, enabling it to dynamically adjust the startup strategy based on historical status.

[0078] In one possible implementation of this application embodiment, after the system is initialized to read the boot flag, the following method may also be used, but is not limited to: the system is initialized to respond to the read boot flag as a first value, and it is determined that the operating system failed to start in the last boot process, wherein the last boot process is the previous adjacent boot process of the current boot process.

[0079] In the embodiments of this application, the previous startup process is a specific concept in a time sequence, referring to the startup process immediately preceding the current startup process. During the server's runtime cycle, each system power-on or restart is considered an independent startup process, and these processes are arranged sequentially in time. The previous startup process is the complete startup attempt that occurred immediately before the current startup process, including the entire sequence from hardware initialization to operating system loading. This preceding-adjacent relationship ensures the timeliness and accuracy of state determination, avoiding misjudgments caused by historical legacy states or discontinuous events. The initialization system establishes this correlation between processes by maintaining internal timing logic or referencing the hardware clock, thereby precisely defining the scope of the previous startup process.

[0080] This application achieves accurate interpretation of the operating system's boot history through a state determination mechanism. It improves the accuracy of system decision-making by ensuring the reliability and consistency of state determination through explicit numerical comparisons and timing correlations; enhances the intelligence level of the initialization system, enabling it to adaptively adjust boot strategies based on historical states; optimizes fault response speed by tightly integrating state reading with decision logic, reducing the triggering delay of the recovery process; and ensures the predictability of system behavior by strictly defining the preceding adjacent boot process, avoiding state confusion or cyclical recovery problems.

[0081] In one possible implementation of this application embodiment, after the operating system initialization system reads the boot flag, the following method may also be used, but is not limited to: the initialization system responds to the boot flag indicating successful boot and continues to execute the operating system boot process.

[0082] In the embodiments of this application, the Startup Flag Indicating Startup Success is a clear status signal, typically manifested as a flag being set to a specific second value (such as 0). This status indicates that during the previous startup process, the operating system successfully completed the entire startup procedure and entered a stable operating state. The management controller confirms this successful status through its monitoring mechanism (such as a normal reset of the watchdog timer) and persistently stores the startup flag at this value before the system shuts down or restarts. The initialization system can accurately determine the status by comparing the read flag value with the preset success identifier.

[0083] In response to this decision, the initialization system chooses to continue the operating system boot process. This means that the initialization system will follow a standard, unmodified boot sequence. Specifically, the initialization system will not trigger any operations related to boot partition recovery, such as requesting backup data from the management controller via the Redfish interface or performing write operations to the boot partition. Instead, it will load the boot loader from the boot partition of the specified storage device (e.g., hard drive, SSD) according to the boot order preset in its firmware, then transfer control to the boot loader, which will load the operating system kernel image, the initial RAM disk, and finally boot the operating system. This process is the standard boot procedure for servers in a fault-free state, with the highest execution efficiency and minimal system resource overhead.

[0084] The normal path in this application ensures efficient system startup in a healthy state, avoiding time delays and resource consumption caused by unnecessary recovery operations; it maintains the purity of the startup process, ensuring that the system runs according to the predetermined path when no faults occur, reducing uncertainties introduced by complex logic; together with the recovery path, it constitutes a complete, condition-triggered intelligent startup system, enabling the system to adaptively select the optimal startup strategy based on historical states. This demonstrates efficient coordination between fault handling and normal operation, ensuring both recovery capabilities in abnormal situations and operational performance under normal conditions.

[0085] Figure 2 A schematic diagram of the architecture of a server system provided for embodiments of this application, such as... Figure 2 As shown, it includes: Business Controller (BMC) and Operating System (OS).

[0086] The management controller is configured to monitor the startup status of the operating system running on the system module and set the startup flag corresponding to the operating system.

[0087] The management controller is also configured to trigger an operating system restart in response to a startup status indication that the operating system has failed to boot.

[0088] The operating system activates and initializes the system during the current boot process;

[0089] The initialization system (BIOS / UEFI) is configured to read the boot flag through the operating system's initialization system, and in response to the boot flag indicating boot failure, obtain the first boot partition data from the management controller through the second standard management interface. The first boot partition data is the data that the operating system uploaded and stored to the management controller through the first standard management interface during its historical normal operation.

[0090] The system is initialized and configured to perform boot partition recovery processing on the operating system based on the data from the first boot partition.

[0091] Furthermore, regarding the implementation process of the embodiments of this application, the embodiments of this application also provide a flowchart of another boot partition recovery method, such as... Figure 3 As shown, it includes:

[0092] 1) Operating system normal operation and backup

[0093] Under normal system operation:

[0094] The OS successfully booted up and fed the watchdog; the watchdog remained active, and the BMC determined that the boot was normal.

[0095] The OS calls the Redfish API to upload the current boot partition data to the BMC. This data can include: a complete boot partition image, boot loader, kernel image, boot configuration files, and other key files.

[0096] After receiving the data, BMC performs compression, encryption, and verification on it, and stores it in persistent storage space;

[0097] BMC assigns a unique version number to each piece of data for selection during subsequent recovery.

[0098] 2) Startup failure detection and Flag setting

[0099] When the operating system fails to feed the dog within the preset time during the startup phase:

[0100] The watchdog timeout signal was triggered, and the BMC determined that the OS boot process had failed.

[0101] The BMC sets Flag = 1 in its internal storage to indicate that the last OS boot failed.

[0102] The BMC simultaneously triggers a CPU restart, causing the system to re-enter the BIOS boot phase.

[0103] 3) Flag detection and recovery during the BIOS phase

[0104] When the system powers on again and enters the BIOS phase:

[0105] The BIOS reads the Flag from the BMC via IPMI commands;

[0106] If Flag = 0, the BIOS determines that the previous OS boot was successful and then enters the normal boot process;

[0107] If Flag = 1, the BIOS determines that the previous OS boot failed and performs the following operations:

[0108] 1. Request the latest version of the boot partition data from the BMC via the Redfish interface;

[0109] 2. Write the data to the boot partition of the storage device, overwriting any existing damaged or faulty data;

[0110] 3. After the write is complete, the BIOS notifies the BMC to reset the Flag to 0 via the IPMI command;

[0111] 4. The BIOS continues the boot process and boots the operating system.

[0112] 4) Closed-loop process

[0113] If the OS boots successfully after recovery, proceed to step 1) and perform the boot partition backup again;

[0114] If the recovery still fails, BMC will set the Flag again when the Watchdog times out next time, triggering a new round of recovery, or enter safe mode for remote administrator intervention.

[0115] Exception handling mechanisms include

[0116] Multi-version recovery: If the latest version recovery fails, the BIOS can use policy options to roll back to an earlier version of the boot partition backup.

[0117] Alarm mechanism: The BMC counts the number of consecutive failures. If the number exceeds a preset threshold, an alarm is sent to the remote management platform via the network.

[0118] Integrity verification: Before writing to the boot partition, the BIOS performs signature verification on the data obtained from the BMC to ensure that the data has not been tampered with.

[0119] 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.

[0120] 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 boot partition recovery method embodiments.

[0121] 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 boot partition recovery method embodiments when it is run.

[0122] 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.

[0123] 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 boot partition recovery method embodiments.

[0124] 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 boot partition recovery method embodiments.

[0125] 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.

[0126] The above provides a detailed description of a boot partition recovery method and electronic device 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 merely for the purpose of helping to understand the method and its core ideas. 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 boot partition recovery method, applied to a server system, the server system including a management controller and an operating system, characterized in that, include: The management controller monitors the startup status of the operating system and sets the startup flag corresponding to the operating system; The management controller, in response to the startup status indicating that the operating system has failed to start, triggers a restart of the operating system; During the current boot process, the operating system activates the initialization system. The initialization system reads the boot flag and, in response to the boot flag indicating boot failure, obtains first boot partition data from the management controller through a second standard management interface. The first boot partition data is data uploaded and stored to the management controller by the operating system through the first standard management interface during its historical normal operation. The second standard management interface is a standard management protocol interface that allows the initialization system to access the management controller out of band. The initialization system performs boot partition recovery processing on the operating system based on the first boot partition data; The method further includes: During normal historical operation, the operating system sends the boot partition data in the boot partition to the management controller through the first standard management interface; The management controller performs compression and encryption processing on the received boot partition data, and assigns a first version identifier to the processed boot partition data based on the timestamp of the boot partition data sent by the operating system. The management controller identifies the processed boot partition data with the first version identifier as the first boot partition data and stores the first boot partition data in non-volatile storage space.

2. The boot partition recovery method according to claim 1, characterized in that, The management controller monitors the startup status of the operating system, including: The management controller monitors whether the operating system performs a reset operation on the watchdog timer within a preset time period; The management controller determines that the startup state of the operating system is a startup failure if the operating system does not perform a reset operation on the watchdog timer within the preset time period. The management controller, in response to the operating system performing a reset operation on the watchdog timer within the preset time period, determines that the startup status of the operating system is successful.

3. The boot partition recovery method according to claim 2, characterized in that, The setting of the boot flag corresponding to the operating system includes: In response to the startup status being startup failure, the management controller sets the startup flag to a first value indicating startup failure; In response to the startup status being successful, the management controller sets the startup flag to a second value indicating successful startup.

4. The boot partition recovery method according to claim 3, characterized in that, After the initialization system performs boot partition recovery processing on the operating system based on the first boot partition data, the method further includes: The management controller continues to monitor the operating system's post-recovery boot status; If the recovery startup status indicates that the operating system has failed to start, the initialization system obtains the second boot partition data from the management controller and performs boot partition recovery processing on the operating system. The second boot partition data is the boot partition data that the operating system sent and stored in the management controller before the first boot partition data. The management controller records the number of consecutive startup failures of the operating system. In response to the number of consecutive startup failures exceeding a preset failure threshold, it generates a fault alarm and sends the fault alarm to the remote management platform. If the recovery startup status indicates that the operating system has started successfully, the management controller will reset the number of consecutive startup failures to zero and reset the startup flag to the second value indicating a successful startup.

5. The boot partition recovery method according to claim 4, characterized in that, Before the initialization system performs boot partition recovery processing on the operating system based on the first boot partition data, the method further includes: The initialization system performs integrity verification on the data in the first boot partition using a preset verification algorithm to obtain the integrity verification result. The initialization system responds to the integrity verification result indicating that the first boot partition data meets the preset verification conditions, performs boot partition recovery processing on the operating system based on the first boot partition data, and notifies the management controller to reset the boot flag to the second value; In response to the integrity verification result indicating that the first boot partition data does not meet the preset verification conditions, the initialization system obtains the second boot partition data from the management controller and performs boot partition recovery processing on the operating system.

6. The boot partition recovery method according to claim 1, characterized in that, The initialization system reads the startup flag including: The initialization system reads the startup flag from the management controller through the intelligent platform management interface command.

7. The boot partition recovery method according to claim 3, characterized in that, After the initialization system reads the startup flag, the method further includes: The initialization system, in response to the read startup flag being the first value, determines that the operating system failed to start during the previous startup process, wherein the previous startup process is the startup process preceding the current startup process.

8. The boot partition recovery method according to claim 1, characterized in that, After the initialization system of the operating system reads the boot flag, the method further includes: The initialization system responds to the boot flag indicating successful boot and continues the boot process of the operating system.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the boot partition recovery method as described in any one of claims 1 to 8 when executing the computer program.

Images