A system recovery method and system

Abstract

This invention discloses a system recovery method and system. The method includes: configuring an environment variable partition; pre-storing network rescue server parameters in the environment variable partition, and defining a first-stage startup command, a second-stage startup command, a third-stage startup command, a network rescue command, and a main startup command, with the main startup command initially pointing to the first-stage startup command; upon initial startup, a general bootloader reads and executes the first-stage startup command from the environment variable partition; after the first-stage startup command fails and triggers a system restart, the general bootloader reads the updated main startup command from the environment variable partition and executes the second-stage startup command and the third-stage startup command sequentially; when the third-stage startup command fails, the general bootloader executes the network rescue command, downloads recovery files from the network rescue server, and repairs the system.

Description

Technical Field

[0001] This invention relates to the field of embedded system startup and fault recovery technology, specifically to a system recovery method and system. Background Technology

[0002] Embedded Linux systems are widely used in resource-constrained devices such as smart security systems and IoT terminals. Single-partition storage architectures, due to their low hardware cost and simple implementation, have become the preferred solution for many small and medium-sized manufacturers. Over-the-air (OTA) updates, as the mainstream method for firmware iteration, are highly susceptible to sudden anomalies during the upgrade process, such as power outages or write errors, which can cause kernel corruption or root file system mounting failures, triggering kernel verification errors and virtual file system mounting failures, leading to boot failures.

[0003] When the above-mentioned fault occurs, the device will freeze and cannot automatically restart or recover. Technicians need to manually input commands via serial port to trigger the rescue process, which not only significantly increases after-sales maintenance costs but also seriously affects the end-user experience. Existing solutions to this problem have significant limitations: one type of solution relies on a dual-partition redundancy design, achieving fault recovery through primary / backup partition switching. However, this solution requires additional hardware storage resources, significantly increasing hardware costs and making it unsuitable for low-cost embedded device scenarios. Another type of solution relies on a fully functional bootloader, using conditional checks, startup counting, and other commands to build a state machine for automatic recovery. However, in practical applications, most embedded devices use highly trimmed bootloaders to reduce system size and resource consumption. These programs lack key commands such as conditional checks, counting, and debug printing, making this type of solution unfeasible.

[0004] In the prior art, environmental variables are only used as passive configuration storage carriers. For example, the environmental variable partition of the invention patent with patent publication number CN115904450A is used to store partition parameters and upgrade number parameters for firmware upgrades, and relies on a dual-partition architecture to achieve startup switching; the environmental variable partition of the invention patent with patent publication number CN121255538A is used to store environmental variables as well as backups and checksums.

[0005] In existing technologies, OTA upgrade failures and firmware downloads from the server are only passively triggered after local redundancy recovery or backup failure, or used for proactive upgrade pushes. This requires a dual-partition architecture, a fully functional bootloader, or multi-module interactive verification, and does not form an independent rescue download logic that is unattended after a failure.

[0006] Therefore, there is an urgent need in this field for an automatic recovery technology for embedded Linux systems that requires no additional hardware resources, is compatible with highly customized bootloaders, and can automatically trigger a rescue process after a device startup failure, in order to solve the problem of unattended recovery after a single-partition embedded device OTA upgrade failure. Summary of the Invention

[0007] In view of this, the purpose of this invention is to provide a system recovery method and system to solve the problems in the prior art such as kernel corruption or abnormal root file system mounting after OTA upgrade failure of single-partition embedded devices, inability of highly trimmed bootloaders to support traditional state machine recovery logic, high maintenance costs requiring manual serial port intervention after device failure, and high hardware costs and poor adaptability of dual-partition redundancy schemes. This invention achieves unattended automatic recovery without additional hardware modifications and is compatible with minimal bootloaders, improving the operational reliability and fault tolerance of embedded devices, and meeting the needs of low-cost embedded devices for simplified production and maintenance and reduced after-sales costs.

[0008] The specific plan is as follows:

[0009] Firstly, this application provides a systematic recovery method, which mainly includes:

[0010] Configure environment variable partitions; pre-store network rescue server parameters in the environment variable partitions, and define the first-stage startup command, the second-stage startup command, the third-stage startup command, the network rescue command, and the main startup command. The main startup command is initialized to point to the first-stage startup command.

[0011] Upon system startup, the general bootloader reads and executes the first-stage boot command from the environment variable partition, executes the current primary boot command, and performs the first update on the current primary boot command to point to the second-stage boot command; if the execution is successful, the system starts and runs normally.

[0012] If the first-stage startup command fails, a system restart is triggered. The generic bootloader reads the first updated master boot command from the environment variable partition, executes the current first-updated master boot command, and then updates the current master boot command to point to the third-stage startup command. If the execution is successful, the system starts and runs normally. If the execution fails, after a system restart, the generic bootloader reads the second updated master boot command from the environment variable partition, executes the current second-updated master boot command, and updates the master boot command to point to the network rescue command. If the execution is successful, the system starts and runs normally. If the third-stage startup command fails, the generic bootloader executes the network rescue command, downloads recovery files from the network rescue server, and repairs the system.

[0013] Furthermore, when the master boot command points to the first-stage boot command, the general bootloader executes the current master boot command, loads the kernel from the flash kernel area and attempts to boot, and updates the master boot command to point to the second-stage boot command and saves it before execution; when the master boot command points to the second-stage or third-stage boot command, the general bootloader loads the kernel according to a preset process and attempts to boot; the attempt to boot includes loading the kernel and completing the root file system mounting.

[0014] Furthermore, if the startup attempt fails, the system will automatically restart after a preset delay.

[0015] Furthermore, the environment variable partition is located in flash memory and is set independently from the kernel partition and the root file system partition.

[0016] Furthermore, the general bootloader only retains commands for setting environment variables, saving environment variables, executing commands, serial peripheral interface flash operations, dynamic host configuration protocol, simple file transfer protocol, kernel boot and system loading commands.

[0017] Furthermore, the parameters of the network rescue server are Internet Protocol (IP) addresses.

[0018] Furthermore, when the network rescue command is executed, the network configuration is obtained through the Dynamic Host Configuration Protocol (DHCP) and the recovery file is downloaded from the server through the Simple File Transfer Protocol (SLTP).

[0019] Furthermore, after repairing the system using the recovery file, a system restart is triggered; after the system successfully starts, the primary boot command in the environment variable partition is reset to point to the first stage boot command through an initialization script.

[0020] Furthermore, the initialization script is also used to rewrite the initial definitions of the first-stage startup command, the second-stage startup command, the third-stage startup command, and the network rescue command into the environment variable partition.

[0021] Secondly, this application provides a system recovery system for implementing the system recovery method described above, the system including an environment variable partition management module, a state transition control module, and a network rescue execution module;

[0022] The environment variable partition management module is used to set up independent environment variable partitions, pre-store server parameters, and define startup commands, network rescue commands, and main startup commands for each stage.

[0023] The state transition control module is used to control the general bootloader to execute the startup commands of each stage in sequence, and update the pointer of the main boot command in the environment variable partition during execution;

[0024] The network rescue execution module is used to control the general bootloader to execute network rescue commands after the local three-stage boot fails, and to download and use recovery files to repair the system based on the server parameters in the partition.

[0025] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0026] (1) Automatic detection and recovery of startup failures are achieved through persistent storage and state migration mechanism of environment variable partitions. This eliminates the need for hardware redundancy or additional storage partitions, greatly reducing hardware costs and design complexity, and providing a feasible self-healing solution for resource-constrained single-partition embedded systems.

[0027] (2) The entire recovery process is fully automated and requires no manual intervention. After consecutive startup failures, the system can autonomously switch states and ultimately recover by obtaining a secure image from the server through network rescue, which significantly improves the reliability and availability of the device in scenarios such as abnormal power outages or upgrade failures.

[0028] (3) Relying on the initialization script reset mechanism after the system starts successfully, the system is prevented from repeatedly entering the rescue process. At the same time, the validity of environment variables can be quickly verified, making it easier to troubleshoot startup anomalies and improve the stability of system operation. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0030] Figure 1 A flowchart of a system recovery method provided in an embodiment of the present invention;

[0031] Figure 2 A system recovery system structure block diagram provided in an embodiment of the present invention;

[0032] Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application;

[0033] Figure 4 This is another structural schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] This invention discloses a system recovery method and system. The method constructs a three-stage startup state transition logic by configuring independent environment variable partitions, completes state reset based on initialization scripts, and realizes network rescue based on dynamic host configuration protocol and simple file transfer protocol. It breaks through the limitation of highly customized general bootloaders without judgment and counting commands, and achieves unattended automatic recovery after startup failure of single-partition embedded devices without additional hardware modifications. It achieves the design goals of automated recovery process, controllable hardware cost, and stable system operation.

[0036] Example 1

[0037] Please see Figure 1 In this embodiment of the invention, a system recovery method is provided. Specifically, it includes:

[0038] S101, Configure environment variable partition; Pre-store network rescue server parameters in the environment variable partition, and define the first stage startup command, the second stage startup command, the third stage startup command, the network rescue command and the main startup command, wherein the main startup command is initialized to point to the first stage startup command;

[0039] In this embodiment, the environment variable partition configuration uses a single-partition storage architecture to complete the flash memory partitioning. The address range of the core partition is clearly defined, where 0x00000-0x03F000 is the boot partition, used to store a highly trimmed version of the generic bootloader image; 0x03F000-0x040000 is the environment variable partition, which is independent of the kernel partition and the root file system partition, and is specifically used to store network rescue server parameters, startup commands at each stage, master boot commands, and network rescue commands, avoiding the impact of kernel or root file system corruption; 0x040000-0x320000 is the kernel partition, storing the Linux kernel image; 0x320000-0xC20000 is the root file system partition, used to store the root file system, and the remaining areas are configuration and data areas. The generic bootloader in this embodiment does not require conditional judgment, debug printing, or technical arithmetic commands, and only retains core commands such as setting environment variables, saving environment variables, executing commands, serial peripheral interface flash operations, dynamic host configuration protocol, simple file transfer protocol, kernel boot, and loading the system.

[0040] In this embodiment, the pre-stored network rescue server parameter is a fixed Internet Protocol address, specifically set to 115.159.210.72. This parameter is used to guide the general bootloader to obtain recovery files from the correct server during the network rescue phase. The first-stage boot command, the second-stage boot command, and the third-stage boot command are all designed to load the kernel from the kernel partition and attempt to boot. If the boot fails, the system waits three seconds before restarting. Before each command is executed, the main boot command is updated to point to the next-stage boot command and saved to the environment variable partition, thereby achieving automatic state migration. The network rescue command is used to obtain the network location via Dynamic Host Configuration Protocol (DHCP) and download the recovery files from the aforementioned server via File Transfer Protocol (LTP) after all three local boot attempts have failed. The main boot command is initially set to execute the first-stage boot command, forming the entry point of the boot process.

[0041] S102, Start the system. The general bootloader reads and executes the first-stage boot command from the environment variable partition, executes the current primary boot command, and performs the first update to point to the second-stage boot command on the current primary boot command; if the execution is successful, the system starts and runs normally.

[0042] In this embodiment, after the device is powered on, the general bootloader first reads the main boot command from the environment variable partition. Since it initially points to the first-stage boot command, this command will be executed on the first system boot. When executing the first-stage boot command bootcmd_1, the general bootloader first updates the main boot command to point to the second-stage boot command (run bootcmd_2) by setting the environment variable command, and saves it to the environment variable partition; then, it sequentially executes to enable data caching, initialize the serial peripheral interface flash memory, and then loads the kernel image from the flash kernel partition according to the header information by loading the system command, and attempts to start the kernel by booting the kernel command. If the kernel is loaded successfully and the root file system is mounted normally, the system boots successfully; if the kernel is corrupted or the root file system fails to mount, the system boots unsuccessfully, and then waits three seconds for automatic restart, thus entering the next round of state transition process. The logic code of the first-stage boot command is as follows:

[0043] bootcmd_1 = setenv bootcmd run bootcmd_2; saveenv; dcache on; sfprobe 0; loados nor 0x23000000 KERNEL by_header; bootm 0x23000000; sleep 3;reset

[0044] S103, if the first-stage startup command fails to execute, a system restart is triggered. The general bootloader reads the first updated master boot command from the environment variable partition, executes the current first-updated master boot command, and then executes the second update pointing to the third-stage startup command on the current master boot command. If the execution is successful, the system starts and runs normally. If the execution fails, after the system restart is triggered, the general bootloader reads the second updated master boot command from the environment variable partition, executes the current second-updated master boot command, and updates the master boot command to point to the network rescue command. If the execution is successful, the system starts and runs normally. If the third-stage startup command fails to execute, the general bootloader executes the network rescue command, downloads recovery files from the network rescue server, and repairs the system.

[0045] In this embodiment, if the first-stage boot fails due to kernel loading failure or root file system mounting failure, the system will wait three seconds before restarting. After restarting, the generic bootloader reads the primary boot command from the environment variable partition again. At this time, the primary boot command points to the second-stage boot command. The execution flow of the second-stage boot command `bootcmd_2` is consistent with the logic of the first stage. Before attempting to boot the kernel, the generic bootloader updates the primary boot command to point to the third-stage boot command (`run bootcmd_3`) and saves it. Only when the kernel loads successfully and the root file system is mounted normally is the boot considered successful, and the system runs normally. If a kernel verification error occurs or the root file system fails to mount, the boot is considered to have failed, and the system waits three seconds before restarting. After the system restarts, the primary boot command read by the generic bootloader points to the third-stage boot command `bootcmd_3`. When this command is executed, the primary boot command is first updated to point to the network rescue command and saved, and then executed according to the above-described boot attempt process. At the same time, the primary boot command is updated to point to the network rescue command (`run tftp_rescue`) and saved, and then executed according to the above-described boot attempt process. If this startup attempt fails, the system will wait three seconds and then restart, preparing to enter the network rescue process. The logic code for the second-stage startup command and the third-stage startup command is as follows:

[0046] bootcmd_2 = setenv bootcmd run bootcmd_3; saveenv; dcache on; sfprobe 0; loados nor 0x23000000 KERNEL by_header; bootm 0x23000000; sleep 3;reset

[0047] bootcmd_3 = setenv bootcmd run tftp_rescue; saveenv; dcache on; sfprobe 0; loados nor 0x23000000 KERNEL by_header; bootm 0x23000000; sleep 3;reset

[0048] If three consecutive local boot attempts fail, it indicates that the local firmware is corrupted. At this point, the primary boot command has been updated to point to the network rescue command. After the system reboots, the generic bootloader executes the network rescue command. This command first obtains the network configuration via Dynamic Host Configuration Protocol (DHCP), and then downloads the recovery file from the network rescue server via Simple File Transfer Protocol (SLTP) based on the pre-stored server internet protocol address. After downloading, the recovery file is used to repair the system. Once the system is successfully repaired and boots, the initialization script resets the primary boot command in the environment variable partition to point to the first-stage boot command. Subsequently, the initial definitions of the first-stage, second-stage, and third-stage boot commands, as well as the network rescue command, are rewritten to the environment variable partition, and the automatic restart mechanism of the kernel boot parameters is verified to ensure its effectiveness. This ensures that the system can delay its reboot and re-enter the state transition process in the event of subsequent boot failures. The logic code for the network rescue command is as follows:

[0049] tftp_rescue = dhcp; setenv serverip 115.159.210.72; estar; setenvbootcmd run bootcmd_1; saveenv; reset

[0050] See Figure 2 , Figure 2 The present invention provides a system recovery system structure block diagram, which may include:

[0051] The environment variable partition management module is used to set up an environment variable storage area in flash memory that is independent of the kernel and root file system partitions, pre-store the Internet protocol address parameters of the network rescue server, and define the initial content and pointer relationship of the first-stage boot command, the second-stage boot command, the third-stage boot command, the network rescue command, and the main boot command.

[0052] The state transition control module is used to control the general bootloader to read and execute the main boot command in the environment variable partition at each startup, and to automatically update the main boot command to point to the next stage command and save it before executing the startup commands of each stage, so as to realize the automatic state transition after local startup failure.

[0053] The network rescue execution module is used to control the general bootloader to execute network rescue commands after the state migration control module fails three times in a local boot attempt. Based on the server address pre-stored in the partition, it downloads recovery files over the network and performs system repair operations.

[0054] This application also provides an electronic device and a computer-readable storage medium, both of which have the corresponding effects of the system recovery method provided in the embodiments of this application. Please refer to... Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0055] An electronic device provided in this application includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, it implements the steps of the shelf display detection method described in any of the above embodiments.

[0056] Please see Figure 4 Another electronic device provided in this application embodiment may further include: an input port connected to a processor for transmitting commands input from the outside to the processor; a display unit connected to the processor for displaying the processor's processing results to the outside; and a communication module connected to the processor for enabling communication between the electronic device and the outside. The display unit may be a display panel, a laser scanner, or the like; the communication method used by the communication module includes, but is not limited to, Mobile High-Definition Link (MHL), Universal Serial Bus (USB), High-Definition Multimedia Interface (HDMI), wireless connectivity: Wireless Fidelity (WiFi), Bluetooth communication technology, Bluetooth Low Energy communication technology, and communication technology based on IEEE 802.11s.

[0057] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the shelf display detection method described in any of the above embodiments.

[0058] The computer-readable storage media involved in this application include random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs (compact disc read-only memory), or any other form of storage media known in the art.

[0059] Example 2

[0060] In this embodiment, if the kernel loading and root file system mounting are successful after the first-stage boot command is executed, the system boots normally. At this time, the main boot command has been updated to point to the second-stage boot command during the execution of the first-stage boot command. After the system boots successfully, the Linux system initialization process executes the pre-configured initialization script ` / etc / init.d / SO0CorrectEnv`. This script detects that the current pointer of the main boot command does not match the baseline initial state, and then resets it to point to the first-stage boot command and persists it. At the same time, the script restores all predefined boot commands and network rescue commands to their initial state.

[0061] If the system enters the second-stage startup command after the first-stage startup command fails, and starts successfully during the second-stage startup command execution, then the process described above for a successful first-stage startup command execution will be executed. The initialization script will detect and perform a reset operation, redirecting the main startup command back to the first-stage startup command, and synchronously initializing the predefined startup commands and network rescue commands.

[0062] If the system fails to start in the first and second stages, but starts successfully when the third stage startup command is executed, the process for successfully executing the first stage startup command will be executed. At this time, although the third stage startup command has updated the main startup command to point to the network rescue command, the initialization script that runs after successful startup will perform status checks and resets again to ensure that the main startup command and all related command definitions are restored to their initial state.

[0063] In summary, this invention achieves a fully automated recovery mechanism in resource-constrained embedded Linux systems without relying on redundant hardware partitions or complex logical commands. It leverages the persistent storage characteristics of general bootloader environment variables, designs a three-stage startup state machine and network rescue process, and automatically resets the state using a Linux initialization script. This effectively solves the problems of requiring manual intervention after a failed OTA upgrade in a single-partition system, the inability of traditional general bootloaders to implement complex recovery logic due to missing condition judgments and counting commands, and the potential for loops into rescue mode due to the inability to automatically reset the state after recovery. It achieves fully unattended operation from detection to recovery, significantly improving the reliability of the device in harsh or unattended environments, greatly reducing on-site maintenance costs and user service requests, and enhancing product competitiveness and user satisfaction.

[0064] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. 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 process, method, article, or apparatus.

[0065] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A system recovery method, characterized in that, include: Configure environment variable partitions; pre-store network rescue server parameters in the environment variable partitions, and define the first-stage startup command, the second-stage startup command, the third-stage startup command, the network rescue command, and the main startup command. The main startup command is initialized to point to the first-stage startup command. The environment variable partition configuration uses a single-partition storage architecture to complete the flash partitioning. The environment variable partition is located in the flash memory and is set independently from the kernel partition and the root file system partition. The system starts up, and the general bootloader reads and executes the first-stage boot command from the environment variable partition, executes the current primary boot command, and performs the first update on the current primary boot command to point to the second-stage boot command; If the execution is successful, the system will start and run normally. If the first-stage startup command fails to execute, the system restarts. The general bootloader reads the first-updated master boot command from the environment variable partition, executes the current first-updated master boot command, and executes the second-updated master boot command pointing to the third-stage startup command. If execution is successful, the system will start and run normally; if execution fails, the system will be restarted, and the general bootloader will read the second updated master boot command from the environment variable partition, execute the current second updated master boot command, and update the master boot command to point to the network rescue command; if execution is successful, the system will start and run normally; if the third stage boot command fails to execute, the general bootloader will execute the network rescue command, download recovery files from the network rescue server, and repair the system.

2. The system recovery method according to claim 1, characterized in that, When the master boot command points to the first-stage boot command, the general bootloader executes the current master boot command, loads the kernel from the flash kernel area and attempts to boot, and updates the master boot command to point to the second-stage boot command and saves it before execution; when the master boot command points to the second-stage or third-stage boot command, the general bootloader loads the kernel according to a preset process and attempts to boot; the attempt to boot includes loading the kernel and completing the root file system mounting.

3. The system recovery method according to claim 2, characterized in that, If the startup attempt fails, the system will automatically restart after a preset delay.

4. The system recovery method according to claim 1, characterized in that, The general bootloader only retains the functions of setting environment variables, saving environment variables, executing commands, serial peripheral interface flash operations, dynamic host configuration protocol, simple file transfer protocol, kernel boot and system loading commands.

5. The system recovery method according to claim 1, characterized in that, The parameters of the network rescue server are Internet Protocol (IP) addresses.

6. The system recovery method according to claim 1, characterized in that, When the network rescue command is executed, the network configuration is obtained through the Dynamic Host Configuration Protocol (DHCP) and the recovery file is downloaded from the server through the Simple File Transfer Protocol (SLTP).

7. The system recovery method according to claim 6, characterized in that, After the system is repaired using the recovery file, a system restart is triggered. After the system starts successfully, the initialization script resets the primary boot command in the environment variable partition to point to the first-stage boot command.

8. The system recovery method according to claim 7, characterized in that, The initialization script is also used to rewrite the initial definitions of the first-stage startup command, the second-stage startup command, the third-stage startup command, and the network rescue command into the environment variable partition.

9. A system recovery system for implementing the method as described in any one of claims 1 to 8, characterized in that, include: Environment variable partitioning management module, state transition control module, network rescue execution module; The environment variable partition management module is used to set up independent environment variable partitions, pre-store server parameters, and define startup commands, network rescue commands, and main startup commands for each stage. The state transition control module is used to control the general bootloader to execute the startup commands of each stage in sequence, and update the pointer of the main boot command in the environment variable partition during execution; The network rescue execution module is used to control the general bootloader to execute network rescue commands after the local three-stage boot fails, and to download and use recovery files to repair the system based on the server parameters in the partition.

Images