System recovery method and device and electronic equipment

Abstract

The invention belongs to the field of fault recovery, and discloses a system recovery method and device and electronic device.The method comprises the steps that when terminal equipment enters a recovery mode, the cache function of a nonvolatile memory in the terminal equipment is closed; and reading the software package from the preset storage path, and performing system recovery by using the software package. According to the method and the device, the caching function of the nonvolatile memory can be closed when the terminal equipment enters the recovery mode, and the software package is read from the preset storage path to perform system recovery, so that the problems of data inconsistency caused by caching and recovery failure caused by frequent power failure are effectively avoided, the system stability and the data integrity are improved, and the user experience is improved. Compared with the prior art, maintenance cost is reduced, user experience is optimized, the self-repairing capability of the equipment is enhanced, the method is particularly suitable for the equipment which is difficult to maintain on site, and the overall system reliability and user satisfaction are remarkably improved.

Description

Technical Field

[0001] The present invention relates to the field of fault recovery, and more particularly, to a method, apparatus, electronic device, and computer-readable storage medium for system recovery.

Background Art

[0002] In the fields of embedded systems and mobile devices, system recovery is a crucial process for restoring a device to its normal operating state when an operating system upgrade fails or encounters a serious error. However, when performing system recovery on storage devices with poor performance, a series of problems caused by caching are often encountered. In these devices, data is first written to a fast cache and then gradually written to a slower main storage medium. This can lead to serious system recovery failure problems in test scenarios with frequent power outages.

[0003] When the device suddenly loses power during the writing process, the data in the cache may not have been persisted to the storage medium, resulting in data loss. During the next system recovery attempt, since the expected data was not correctly written to the storage medium, the system cannot verify the integrity of the data and thus cannot correctly load the operating system. Additionally, if the system erroneously believes that the data has been successfully written, it may delete or overwrite the data in the cache partition, further increasing the risk of system recovery failure.

[0004] Therefore, how to reduce the probability of system recovery failure is a technical problem to be solved in this field.

Summary of the Invention

[0005] To effectively solve the problem of high system recovery failure rate in the prior art, the present invention provides a method for system recovery.

[0006] A method for system recovery, applied to a terminal device, the method comprising:

[0007] When the terminal device enters the recovery mode, turn off the caching function of the non-volatile memory of the terminal device;

[0008] Read a software package from a preset storage path and use the software package for system recovery.

[0009] Optionally, before turning off the caching function of the non-volatile memory of the terminal device, the method further comprises:

[0010] When the terminal device is powered on and booted, start a bootloader and update a marker file;

[0011] Detect whether the operating system is entered;

[0012] If not, confirm whether to restart and enter the recovery mode according to the update result of the marker file;

[0013] When the terminal device enters the recovery mode, initialize the marker file.

[0014] Optionally, starting the bootloader and updating the marker file includes:

[0015] After the bootloader starts, increment by one the number of boot times recorded in the marker file;

[0016] Confirming whether to restart and enter the recovery mode according to the update result of the marker file includes:

[0017] Determine whether the number of boot times recorded in the marker file exceeds a preset threshold;

[0018] If so, confirm to restart and enter the recovery mode;

[0019] If not, confirm to restart and enter the normal boot mode;

[0020] Initializing the marker file includes:

[0021] Set to zero the number of boot times recorded in the marker file.

[0022] Optionally, before determining whether the number of boot times in the marker file exceeds the preset threshold, the method further includes:

[0023] Execute the input modification command to modify the preset threshold.

[0024] Optionally, after starting the bootloader and updating the marker file, and before detecting whether to enter the operating system, the method further includes:

[0025] Determine whether the current boot mode is the normal boot mode;

[0026] If so, execute the step of detecting whether to enter the operating system;

[0027] If not, execute the current boot mode and initialize the marker file.

[0028] Optionally, after detecting whether to enter the operating system, the method further includes:

[0029] When entering the operating system, initialize the marker file.

[0030] Optionally, after starting the bootloader, the method further includes:

[0031] Detect whether there is an external storage device;

[0032] If so, mount the external storage device;

[0033] Reading the software package from the preset storage path includes:

[0034] Reading the software package from the external storage device.

[0035] A system recovery device includes:

[0036] A cache closing module, configured to close the cache function of the non-volatile memory of the terminal device when the terminal device enters the recovery mode;

[0037] A system recovery module, configured to read a software package from a preset storage path and perform system recovery by using the software package.

[0038] An electronic device includes:

[0039] A processor and a memory, where the memory is used to store at least one instruction, and when the instruction is loaded and executed by the processor, it is used to implement the system recovery method described in any one of the above.

[0040] A computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the system recovery method described in any one of the above.

[0041] The system recovery method provided by the embodiments of the present invention has at least the following beneficial effects:

[0042] In the present invention, when the terminal device enters the recovery mode, the cache function of the non-volatile memory of the terminal device is closed; then a software package is read from a preset storage path, and system recovery is performed by using the software package. The present invention can effectively avoid problems such as data inconsistency caused by caching and recovery failure caused by frequent power outages by closing the cache function of the non-volatile memory when the terminal device enters the recovery mode and reading the software package from the preset storage path for system recovery, improve system stability and data integrity, reduce maintenance costs, optimize the user experience, and enhance the self-repair ability of the device. It is especially suitable for devices that are difficult to maintain on-site, significantly improving the overall system reliability and user satisfaction.

BRIEF DESCRIPTION OF THE DRAWINGS

[0043] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings required to be used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0044] Figure 1 It is a flowchart of a system recovery method provided by an embodiment of the present invention;

[0045] Figure 2 It is a flowchart of another method for system recovery provided by an embodiment of the present invention;

[0046] Figure 3 It is a schematic diagram of the startup process of a device with an Android operating system;

[0047] Figure 4 It is a flowchart of yet another method for system recovery provided by an embodiment of the present invention;

[0048] Figure 5 It is a schematic structural diagram of a system recovery device provided by an embodiment of the present invention.

Specific Embodiments

[0049] In order to better understand the technical solution of the present invention, the embodiments of the present invention will be described in detail below with reference to the accompanying drawings.

[0050] It should be clear that the described embodiments are only a part of the embodiments of the present invention, rather than all of the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without making creative efforts fall within the scope of protection of the present invention.

[0051] The terms used in the embodiments of the present invention are only for the purpose of describing specific embodiments, and are not intended to limit the present invention. The singular forms of "a", "the" and "said" used in the embodiments of the present invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0052] It should be understood that the term " / and" used herein is only a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / " herein generally represents an "or" relationship between the associated objects before and after.

[0053] In the fields of embedded systems and mobile devices, system recovery is a key process for restoring a device to a normal working state when an operating system upgrade fails or encounters a serious error. However, when performing system recovery on storage devices with poor performance, a series of problems caused by caching are often faced. In these devices, data is first written into a fast cache and then gradually written into a slower main storage medium. This may lead to serious system recovery failure problems in test scenarios with frequent power outages.

[0054] When the device suddenly loses power during the writing process, the data in the cache may not have been persisted to the storage medium, resulting in data loss. During the next system recovery attempt, since the expected data was not correctly written to the storage medium, the system cannot verify the data integrity and thus cannot correctly load the operating system. Additionally, if the system erroneously believes that the data has been successfully written, it may delete or overwrite the data in the cache partition, further exacerbating the risk of system recovery failure. Therefore, the present invention provides a system recovery method to solve the above problems.

[0055] Please refer to Figure 1 , which is a flowchart of a system recovery method provided by an embodiment of the present invention and is applied to a terminal device. The method includes the following steps:

[0056] Step S01, when the terminal device enters the recovery mode, turn off the cache function of the non-volatile memory in the terminal device.

[0057] In this embodiment, turning off the cache function of the non-volatile memory in the terminal device is a preventive measure aimed at ensuring that data can be directly written to the storage medium during system recovery, avoiding data loss or inconsistency problems caused by the cache, especially in the face of unstable power conditions such as frequent power outages. The reason for this is that although the cache can improve the data writing speed, the data that has not been written to the main memory in time will be lost in the event of a power outage, which may lead to system recovery failure. Turning off the cache function can reduce this risk, ensure the accuracy and reliability of the data during system recovery, improve the recovery success rate, and ensure the stable operation of the terminal device.

[0058] In some embodiments, after the system bootloader detects that the terminal device is transitioning to the recovery mode, it can automatically execute a pre-set configuration process, which may include modifying the settings of the storage controller or sending instructions to it to disable the cache function. For example, the firmware or driver of the storage device can be programmed to ensure that all data transfers bypass the cache and are directly written to the storage medium. Subsequently, the system will continue to execute the recovery operation according to this new configuration, including reading software packages from a preset storage path, ensuring the integrity and accuracy of the data during system recovery, and reducing the risk of recovery failure caused by the cache.

[0059] The embodiment of the present invention turns off the cache function of the current non-volatile memory to ensure that data is directly written into the storage particles, avoiding data inconsistency problems caused by the cache. It has been verified that after turning off the cache function, the problem of upgrade failure has been significantly improved, thereby reducing the risk of the device becoming bricked due to upgrade failure.

[0060] Step S02, read a software package from a preset storage path and use the software package for system recovery.

[0061] In this embodiment, after the terminal device is restarted and enters the recovery mode, the system will automatically search for and load the software package stored in the preset location in the device, which contains the necessary data and programs for restoring the operating system. The purpose of this is to provide an automated recovery mechanism to ensure that the terminal device can restore the system to an operational state through the pre-stored software package, thereby improving the stability and reliability of the system.

[0062] In some embodiments, after the boot program of the terminal device successfully detects that the device has entered recovery mode, it can automatically navigate to a pre-set storage path, which can be a specific directory or partition, and retrieve the stored system recovery software package. The software package may contain necessary files such as an operating system image, driver updates, or system patches. The boot program will then load and execute the recovery scripts or programs in the software package. These scripts will perform necessary repair operations on the system in a predetermined order and instructions, such as replacing damaged system files, resetting system settings, or reinstalling the operating system to ensure that the device can be restored to normal working condition. The entire process does not require user intervention, realizes automated system recovery, improves efficiency, and reduces human errors.

[0063] Based on the above technical solution, the present invention turns off the cache function of the non-volatile memory in the terminal device when the terminal device enters the recovery mode; then reads the software package from the preset storage path, and uses the software package to perform system recovery. The present invention can turn off the cache function of the non-volatile memory when the terminal device enters the recovery mode, and read the software package from the preset storage path to perform system recovery, effectively avoiding data inconsistency caused by cache and recovery failure caused by frequent power failures, improving system stability and data integrity, reducing maintenance costs, optimizing user experience, and enhancing the self-repair ability of the device. It is particularly suitable for devices that are difficult to maintain on site, and significantly improves the overall system reliability and user satisfaction.

[0064] In versions before Android 11, due to the cost limitations of non-volatile memory, many mid- and low-end devices did not adopt a dual-partition system architecture, but instead adopted a single-partition operating system design. Although this design can reduce costs, it also brings a series of problems. Especially during the system upgrade process, if the upgrade fails, the device may fail to start, resulting in the so-called "brick" phenomenon. For devices such as car computers installed on large mechanical equipment such as cars, once an upgrade fails, since only USB ports are usually reserved and there are no other download ports, maintenance personnel often need to disassemble the equipment for repair, which not only increases maintenance costs, but also brings a very poor experience to users.

[0065] Traditional system recovery methods usually require manual intervention by the user or rely on physical recovery buttons, which are inadequate when the computer cannot be connected. In addition, the durability of the physical recovery button is also a problem. Therefore, a more automated and user-friendly system recovery method is needed to reduce maintenance costs and improve system stability. Therefore, based on the above embodiments, in some embodiments, the present invention provides another system recovery method to solve the above problems.

[0066] Please refer to Figure 2 , is a flowchart of another system recovery method provided by an embodiment of the present invention, which is applied to a terminal device, and the method comprises the following steps:

[0067] Step S11, when the terminal device is powered on, the boot program is started and the tag file is updated.

[0068] In some embodiments, please refer to Figure 3 , which is a schematic diagram of the device startup process of an Android operating system, such as Figure 3 As shown, it can usually be divided into the following main stages:

[0069] 1) Power on: When the vehicle is started, the vehicle terminal equipment is powered on and turned on.

[0070] 2) Boot: This is the first stage of device startup. The boot program is responsible for initializing the hardware and loading the kernel of the operating system. At this stage, the device will check whether there is an upgrade operation to be performed, such as upgrading from a USB flash drive or SD card.

[0071] 3) Kernel: The kernel is the core of the operating system and is responsible for managing system resources, controlling hardware devices, etc. During the startup process, the kernel will load the necessary drivers to provide hardware support for the Android system.

[0072] 4) Android operating system: This is the user space part of the Android operating system, including the application framework, system services, applications, etc. After the kernel is loaded, the Android system will be started to complete the remaining startup process.

[0073] System Initialization:

[0074] After the Android system starts, a series of initialization operations will be performed, including starting system services, loading applications, etc.

[0075] In this embodiment, with respect to the booting process of the above-mentioned device, when the terminal device is powered on, the boot program is first run to initialize the hardware and set the environment required for system startup. At the same time, a specific mark file in the system storage is updated. The mark file serves as a status indicator, records the relevant information of the terminal device startup, and can provide a basis for whether the system automatically recovers.

[0076] In some embodiments, the mark file may record the number of boot program startups, the number of times the terminal device is powered on, or status mark bit information.

[0077] When the tag file records the number of boot program startups, as mentioned in step S01, when the terminal device is powered on, the boot program is started and the tag file is updated, which may be specifically:

[0078] When the boot program is started, the startup count recorded in the tag file is increased by one;

[0079] In this embodiment, after the boot program is started, the number of boot attempts recorded in the marker file is increased by one, thereby recording the number of attempts to boot the device. This allows the boot program to determine whether to enter the recovery mode based on the updated marker file content. If the number of boot attempts increases abnormally, it indicates that the device has encountered a problem during the normal boot process. In this way, the terminal device can automatically record and update the number of boot attempts each time it is started, providing basic data for system stability monitoring and fault recovery.

[0080] In some embodiments, when the mark file records the number of times the terminal device is powered on or status mark information, for example, the status mark information can mark the time taken for the last operating system to attempt to start, the boot program can also update the number of times the terminal device is powered on or the status mark information in the mark file, and use it as the basis for whether to enter the recovery mode, thereby achieving system self-recovery, and ultimately improving the reliability of the device and the user experience.

[0081] Step S12, detecting whether the operating system has been entered.

[0082] If not, execute step S13.

[0083] In this embodiment, detecting whether to enter the operating system is a key function performed by the boot program during the startup process of the terminal device, and whether the system is successfully started is determined by checking the loading status of the operating system. The reason for doing so is to ensure that the device can identify and respond to problems that may occur during the startup process, so as to take corresponding measures, such as automatically entering the recovery mode or displaying an error message, to ensure the stability of the system and the user's experience.

[0084] In some embodiments, after executing step S13 to detect whether the operating system has been entered, the method may further include:

[0085] When entering the operating system, the mark file is initialized.

[0086] The marker file in this embodiment is used to provide a basis for whether the system performs automatic recovery. When the terminal device can enter the operating system, it proves that the terminal device can be used normally and does not require system recovery. At this time, the marker file is initialized to avoid affecting the subsequent judgment of whether the system performs automatic recovery.

[0087] In some embodiments, the detection of whether to enter the operating system mentioned in step S12 may specifically be:

[0088] The boot program monitors the loading status of the operating system during the device startup process.

[0089] For example, when the car starts, the bootloader will first load and execute, and then try to load the operating system kernel and related startup scripts. If the operating system loads successfully, the device will enter the home screen normally and the user can start using the car. If the operating system fails to load within the predetermined time, or the kernel reports an error, the bootloader will identify this situation, for example, by checking specific system status flags, error codes, or timeout mechanisms.

[0090] Step S13, confirming whether to restart and enter the recovery mode according to the update result of the mark file.

[0091] In this embodiment, the boot program analyzes the system startup conditions recorded in the marker file, such as the number of consecutive failures or specific error markers. If the marker file indicates that the system fails to start normally or encounters a preset error condition, the boot program will decide to restart the terminal device and enter the recovery mode. The purpose of doing this is to provide a backup plan so that when the operating system upgrade fails or encounters a serious error, the system can be restored to a normal state through the recovery mode using a pre-stored software package or an external storage device connected by the user, thereby reducing the risk of the terminal device becoming bricked, optimizing the user experience, and reducing maintenance costs.

[0092] In some embodiments, when the marker file records the number of boot program startups, the step S03 mentioned above determines whether to restart and enter the recovery mode according to the update result of the marker file, which can be specifically:

[0093] Determine whether the number of startups recorded in the marking file exceeds a preset threshold;

[0094] If yes, confirm to reboot into recovery mode;

[0095] If not, confirm the reboot to enter normal boot mode;

[0096] In this embodiment, by judging whether the number of startups recorded in the tag file exceeds the preset threshold, once it exceeds the preset threshold, the boot program intelligently decides to restart the terminal device into the recovery mode, so as to perform system repair or data recovery operations in time; if the number of startups does not exceed the threshold, the boot program confirms that the terminal device restarts into the normal startup mode to avoid frequent entry into the recovery mode, avoid unnecessary recovery processes, and improve startup efficiency. This mechanism not only reduces manual intervention and maintenance costs, but also effectively improves user experience and device stability by responding to system failures quickly and accurately, ensuring the continuous operation of the system and data security.

[0097] In some embodiments, before determining whether the number of startup times in the marker file exceeds a preset threshold, the method may further include:

[0098] Execute the entered modification command to modify the preset threshold.

[0099] In this embodiment, the preset threshold is dynamically adjusted by allowing the input modification command to be executed before judging whether the number of startup times in the tag file exceeds the preset threshold, so that the boot program can intelligently adjust its sensitivity for system recovery according to actual usage or external input. This allows the present invention to optimize the system recovery strategy in different environments or usage modes, reduce frequent recovery attempts caused by misjudgment, and also allows users or system administrators to manually set stricter thresholds according to specific needs or foreseen high-risk situations, thereby improving system stability and user satisfaction, ensuring that the device can reliably enter the recovery mode at critical moments, and avoiding potential system failures.

[0100] Step S14, when the terminal device is restarted and enters the recovery mode, the mark file is initialized and the cache function of the non-volatile memory in the terminal device is turned off.

[0101] In this embodiment, when the terminal device enters the recovery mode, the content in the marker file is automatically reset or cleared to restore it to its initial state. The reason for doing so is to ensure that when the system is restored or reset in the recovery mode, there will be no old, possibly erroneous boot records interfering with the new boot attempt, thereby ensuring that the system can be started cleanly and avoiding misjudgments or repeated failures caused by old marker file data. This helps to improve the success rate of system recovery and ensure that the device can be reliably restarted after the recovery process.

[0102] In some embodiments, when the marker file records the number of boot program startups, the initialization of the marker file mentioned in step S04 may specifically be:

[0103] Clear the startup times recorded in the tag file to zero.

[0104] In some embodiments, the initialization mark file mentioned in step S04 may specifically be:

[0105] When the recovery mode is activated, the recovery mode environment automatically detects the current boot failure state and then performs a series of initialization operations, including resetting the marker file to a predefined initial value or restoring it to a clean state, such as resetting the boot failure counter to zero, clearing the error log, and deleting any old data that may affect the normal startup of the system.

[0106] Step S15, reading the software package from the preset storage path, and using the software package to perform system recovery.

[0107] In some embodiments, the software package may be pre-stored in a preset storage path in a non-volatile memory of the terminal device, or may be stored in a built-in storage device or an external storage device of the terminal device.

[0108] In some embodiments, after executing step S11 to start the boot program, the method further includes:

[0109] Detect whether there is an external storage device;

[0110] If yes, mount the external storage device;

[0111] On this basis, the software package is read from the preset storage path mentioned in step S15, which may specifically be:

[0112] Read the software package from the external storage device.

[0113] In this embodiment, by detecting an external storage device after starting the boot program, mounting the external storage device when it is detected, and then reading the software package from the device to perform system recovery, the flexibility and reliability of system recovery are improved, allowing the user to provide the software package required for recovery through an external storage device such as a USB flash drive or an SD card, and the system can be restored even when there is a problem with the built-in storage or it is unavailable. Such automated processing reduces the reliance on built-in storage media and reduces the risk of system recovery failure due to damage to the storage media. At the same time, for terminal devices that are only equipped with USB ports, users or maintenance personnel only need to connect the external storage device through the USB port without disassembling the device or using complex recovery tools, reducing the need for on-site service caused by built-in storage problems, thereby reducing maintenance costs and downtime, making system recovery easier and more direct.

[0114] Based on the above technical solution, the present invention detects whether to enter the operating system by starting the boot program and updating the marker file; if not, confirming whether to restart and enter the recovery mode according to the update result of the marker file; when the terminal device restarts and enters the recovery mode, the marker file is initialized; the software package is read from the preset storage path, and the software package is used to perform system recovery. The present invention can automatically update the marker file when the terminal device is powered on, and when the operating system cannot be entered, it can determine whether it is necessary to enter the recovery mode according to the marker file to avoid frequently entering the recovery mode. At the same time, in the recovery mode, the system can initialize the marker file and read the software package from the preset storage path, and use the software package to perform system recovery, thereby eliminating the need to disassemble the device or manual intervention, significantly reducing maintenance costs, reducing user inconvenience, greatly improving the efficiency of system recovery and user experience, and enhancing the stability and reliability of the terminal device.

[0115] Based on the above embodiments, in some embodiments, in order to avoid affecting other startup modes of the terminal device, it is also possible to determine whether the current startup mode is a normal startup mode after starting the boot program and updating the marker file and before detecting whether to enter the operating system.

[0116] Please refer to Figure 4 , is a flowchart of another system recovery method provided by an embodiment of the present invention, which is applied to a terminal device, and the method includes the following steps:

[0117] Step S21, when the terminal device is powered on, the boot program is started, the tag file is updated and the external storage device is mounted.

[0118] Step S22, determining whether the current startup mode is a normal startup mode.

[0119] If yes, execute step S23, if no, execute step S24.

[0120] In this embodiment, step S22 is used to identify whether the current startup mode is a normal startup mode. This step is introduced to ensure that other startup modes of the terminal device, such as engineering test mode, factory mode or security mode, are not interfered with or affected before executing system recovery or special startup process.

[0121] Specifically, if the judgment result confirms that the current startup mode is another startup mode, the system will execute the other startup mode and clear the startup times recorded in the mark file in step S23 to prepare for the regular use of the other startup mode. Such processing helps maintain the normal operation of the system and ensure the consistency of user data and system settings.

[0122] On the contrary, if the determination result indicates that the current startup mode is the normal startup mode, the system will execute step S24 to detect whether the operating system is successfully entered.

[0123] This embodiment allows the system to make adaptive responses according to different startup requirements, while avoiding unnecessary mode switching or erroneous recovery operations, reducing confusion or errors that may occur during system startup, and improving the stability of the terminal device and the user experience.

[0124] Step S23, executing the current startup mode, and clearing the startup times recorded in the mark file.

[0125] Step S24, detecting whether the operating system has been entered.

[0126] If yes, execute step S25; if no, execute step S26.

[0127] Step S25, clearing the number of startup times recorded in the mark file.

[0128] Step S26, determining whether the number of startup times recorded in the mark file exceeds a preset threshold;

[0129] If not, execute step S27; if so, execute step S28.

[0130] Step 27, reboot into normal startup mode.

[0131] In this embodiment, after executing step S27, the process returns to executing step S21 to continue detecting whether system recovery is required.

[0132] Step S28, restarting to enter the recovery mode, clearing the number of startup times recorded in the mark file, and turning off the cache function of the non-volatile memory in the terminal device.

[0133] Step S29, reading the software package from the external storage device, and using the software package to perform system recovery.

[0134] Based on the above technical solution, when the current startup mode is another startup mode, the present invention executes another startup mode and clears the startup times recorded in the tag file to prepare for the regular use of the other startup mode. This is beneficial to maintaining the normal operation of the system and ensuring the consistency of user data and system settings.

[0135] Please refer to Figure 5 , is a schematic diagram of the structure of a system recovery device provided by an embodiment of the present invention, the system recovery device comprising:

[0136] The cache closing module 100 is used to close the cache function of the non-volatile memory in the terminal device when the terminal device enters the recovery mode;

[0137] The system recovery module 200 is used to read the software package from a preset storage path and use the software package to perform system recovery.

[0138] Based on the above embodiment, in a specific embodiment, the system recovery device may further include:

[0139] The update module is used to start the boot program and update the tag file when the terminal device is powered on;

[0140] A detection module, used to detect whether the operating system has been entered;

[0141] A confirmation module, used to confirm whether to restart and enter the recovery mode according to the update result of the marker file when the operating system is not entered;

[0142] The first initialization module is used to initialize the mark file when the terminal device restarts and enters the recovery mode.

[0143] Based on the above embodiment, in a specific embodiment, the update module can be specifically used for:

[0144] When the boot program is started, the startup count recorded in the tag file is increased by one;

[0145] The confirmation module can be specifically used for:

[0146] Determine whether the number of startups recorded in the marking file exceeds a preset threshold;

[0147] If yes, confirm to reboot into recovery mode;

[0148] If not, confirm the reboot to enter normal boot mode;

[0149] The first initialization module can be specifically used for:

[0150] Clear the startup times recorded in the tag file to zero.

[0151] Based on the above embodiment, in a specific embodiment, the confirmation module can also be used for:

[0152] Execute the entered modification command to modify the preset threshold.

[0153] Based on the above embodiment, in a specific embodiment, the device may further include:

[0154] The judgment module is used to judge whether the current startup mode is the normal startup mode; if so, return to the detection module to execute the step of detecting whether to enter the operating system; if not, execute the current startup mode and initialize the mark file.

[0155] Based on the above embodiment, in a specific embodiment, the device may further include:

[0156] The second initialization module is used to initialize the mark file when entering the operating system.

[0157] Based on the above embodiment, in a specific embodiment, the device may further include:

[0158] A detection module, used for detecting whether an external storage device exists;

[0159] A mounting module, used for mounting an external storage device when there is one;

[0160] The system recovery module can be used specifically for:

[0161] Read the software package from the external storage device.

[0162] This embodiment provides an electronic device, including a processor and a memory, the memory is used to store at least one instruction, and when the instruction is loaded and executed by the processor, the above-mentioned system recovery method is implemented. Its execution method and beneficial effects are similar and will not be repeated here.

[0163] An embodiment of the present invention provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the above-mentioned system recovery method is implemented. Its execution method and beneficial effects are similar and will not be repeated here.

[0164] It should be noted that although the above describes the various steps in a specific order, it does not mean that the various steps must be executed in the above specific order. In fact, some of these steps can be executed concurrently or even in a different order as long as the required functions can be achieved.

[0165] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A system recovery method, characterized in that: Applied to a terminal device, the method comprises: When the terminal device enters the recovery mode, turning off the cache function of the non-volatile memory in the terminal device; The software package is read from the preset storage path, and the system is restored using the software package.

2. The method according to claim 1, characterized in that Before disabling the cache function of the non-volatile memory in the terminal device, the method further includes: When the terminal device is powered on, the boot program is started and the tag file is updated; Detect whether the operating system has been entered; If not, confirm whether to restart and enter the recovery mode according to the update result of the marking file; When the terminal device enters the recovery mode, the marker file is initialized.

3. The method according to claim 2, characterized in that The booting program and updating the tag file include: When the boot program is started, the startup number recorded in the mark file is increased by one; The step of confirming whether to restart and enter the recovery mode according to the update result of the marking file includes: Determine whether the number of startups recorded in the marking file exceeds a preset threshold; If yes, confirm to reboot into recovery mode; If not, confirm the reboot to enter normal startup mode; The initializing the tag file comprises: The number of startup times recorded in the mark file is cleared to zero.

4. The method according to claim 3, characterized in that Before determining whether the number of startup times in the marker file exceeds a preset threshold, the method further includes: The input modification command is executed to modify the preset threshold.

5. The method according to claim 2, characterized in that: After starting the boot program and updating the marker file, and before detecting whether to enter the operating system, the method further includes: Determine whether the current startup mode is the normal startup mode; If yes, then executing the step of detecting whether to enter the operating system; If not, the current startup mode is executed and the tag file is initialized.

6. The method according to claim 2, characterized in that After detecting whether the operating system has been entered, the method further includes: When entering the operating system, the tag file is initialized.

7. The method according to claim 2, characterized in that After the booting procedure is started, the method further comprises: Detect whether there is an external storage device; If yes, mounting the external storage device; The step of reading the software package from the preset storage path includes: The software package is read from the external storage device.

8. A system recovery device, characterized in that: include: A cache closing module, used to close the cache function of the non-volatile memory in the terminal device when the terminal device enters the recovery mode; The system recovery module is used to read the software package from the preset storage path and use the software package to perform system recovery.

9. An electronic device, characterized in that: include: A processor and a memory, wherein the memory is used to store at least one instruction, and when the instruction is loaded and executed by the processor, the method for system recovery as described in any one of claims 1 to 7 is implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the system recovery method according to any one of claims 1 to 7 is implemented.

Images