Data processing method and electronic equipment

Abstract

The embodiment of the invention discloses a data processing method. The method comprises the steps of obtaining first information; in response to the first information, representing that the electronic equipment is in a target state, and obtaining a target parameter; the electronic equipment cannot enter an operating system in the target state, and the target parameter is used for reflecting the access permission of the electronic equipment entering the operating system; and adjusting a parameter value of the target parameter to meet a target condition, so that the electronic equipment can enter the operating system after being restarted.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of information technology, and in particular to a data processing method and an electronic device. Background Technology

[0002] In related technologies, when an electronic device malfunctions while entering the operating system, the device's display screen will remain stuck on the faulty screen, preventing it from entering the operating system and thus affecting the device's usability. Summary of the Invention

[0003] In view of this, embodiments of this application provide at least one data processing method and an electronic device.

[0004] The technical solution of this application embodiment is implemented as follows:

[0005] This application provides a data processing method, including:

[0006] Obtain first information;

[0007] In response to the first information indicating that the electronic device is in the target state, the target parameters are obtained; in the target state, the electronic device cannot enter the operating system, and the target parameters are used to reflect the access permissions of the electronic device to enter the operating system;

[0008] Adjust the target parameter values ​​to meet the target conditions so that the electronic device can boot into the operating system after restarting.

[0009] This application provides a data processing method, including:

[0010] Based on the historical installation data corresponding to the historical installation process of the operating system of the first electronic device and the historical boot data corresponding to at least one historical boot process of the second electronic device, at least one fault type and the root cause data of each fault type are determined; during the historical boot process, the second electronic device is in a target state, the target state corresponds to at least one fault type, the second electronic device cannot enter the operating system in the target state, and the first electronic device can enter the operating system during the historical installation process.

[0011] At least one type of fault and the backup data of the root cause of each fault type are stored in the first storage space of the third electronic device so that the device can adjust the parameter values ​​of the target parameters to meet the target conditions.

[0012] The first electronic device, the second electronic device, and the third electronic device have the same type of operating system, and the first electronic device, the second electronic device, and the third electronic device may be the same or different.

[0013] This application provides an electronic device, including:

[0014] Display components, at least for displaying the operating system installation interface;

[0015] The display component is also used to obtain target frame buffer data during the installation process, record editing operations on the installation interface based on the target frame buffer data, and obtain historical installation data; historical installation data is used to generate backup data so that the parameter values ​​of the device can be adjusted to meet the target conditions.

[0016] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0017] Figure 1 A schematic diagram of the implementation flow of a data processing method provided in this application embodiment. Figure 1 ;

[0018] Figure 2 A schematic diagram of the implementation flow of a data processing method provided in this application embodiment. Figure 2 ;

[0019] Figure 3 A schematic diagram of the storage structure of a first storage space provided in an embodiment of this application;

[0020] Figure 4 This application provides a schematic diagram of a process for writing backup data.

[0021] Figure 5 This application provides a schematic diagram illustrating the composition structure of historical installation data in an embodiment.

[0022] Figure 6 A schematic diagram of the composition structure of an electronic device provided in this application embodiment. Figure 1 ;

[0023] Figure 7 This application provides a schematic diagram of a related technology for handling OS missing.

[0024] Figure 8 A schematic diagram of the implementation flow of a data processing method provided in this application embodiment. Figure 3 ;

[0025] Figure 9 A schematic diagram of the implementation flow of a data processing method provided in this application embodiment. Figure 4 ;

[0026] Figure 10 A schematic diagram of the composition structure of a data processing device provided in this application embodiment. Figure 1 ;

[0027] Figure 11 A schematic diagram of the composition structure of a data processing device provided in this application embodiment. Figure 2 ;

[0028] Figure 12 A schematic diagram of the composition structure of an electronic device provided in this application embodiment. Figure 2 . Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0030] In the following description, the terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of the objects. It is understood that "first / second / third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application. It should also be noted that, for ease of description, only the parts relevant to the application are shown in the accompanying drawings.

[0031] In cases where a malfunction occurs when an electronic device boots up its operating system (such as during the first startup or update of the operating system), the system's access settings may be modified, preventing the device from accessing the operating system at the software level and leaving it stuck on the error screen. In this situation, even restarting the device will not grant it permission to access the operating system, causing the operating system to fail to start successfully and thus affecting the device's usability.

[0032] In related technologies, when the above problems occur, the equipment needs to be returned to the factory for repair, thereby repairing or reinstalling the system, which is time-consuming, labor-intensive, and affects user operation.

[0033] Based on this, embodiments of this application provide a data processing method that can be executed by an electronic device. The electronic device refers to a server, laptop computer, tablet computer, desktop computer, smart TV, set-top box, mobile device (e.g., mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device), or any other device with data processing capabilities.

[0034] like Figure 1As shown, the processing method includes the following steps S101 to S103:

[0035] Step S101: Obtain the first information.

[0036] Step S102: In response to the first information indicating that the electronic device is in the target state, obtain the target parameters; in the target state, the electronic device cannot enter the operating system, and the target parameters are used to reflect the access permissions of the electronic device to enter the operating system.

[0037] Here, in the case where the operating system is determined to be missing or unreadable (OS missing), to prevent further problems, the access permissions for the electronic device to enter the operating system (the parameter value corresponding to the target parameter) are modified to prevent the electronic device from continuing to attempt to enter the operating system, thus causing the electronic device to enter the target state. In this situation, even if the device is restarted, the access permissions for the electronic device to enter the operating system will not change, and the electronic device will still be unable to enter the operating system.

[0038] In some implementations, the operating system can be detected as missing or unreadable through the operating system detection mechanism of the electronic device.

[0039] The first piece of information is used to determine whether the electronic device is in the target state.

[0040] In some implementations, the initial information can be obtained by reading system logs, error codes, framebuffer data, etc.

[0041] For example, if the system detects an error code indicating a problem with the kernel file in the system files, it can indicate that the electronic device is in the target state.

[0042] The target state can include the operating state of an electronic device when its operating system fails to boot or update. In the target state, the operating system may not detect system files or may detect corrupted system files. This could be due to missing or corrupted system files, or it could be due to an unexpected interruption of the system boot or update process.

[0043] The target parameter can be a parameter that characterizes whether an electronic device has permission to access the operating system. The value of the target parameter differs when the electronic device is in the target state and when it is not in the target state.

[0044] Step S103: Adjust the parameter values ​​of the target parameters to meet the target conditions so that the electronic device can enter the operating system after restarting.

[0045] Here, by adjusting the value of the target parameter, the parameter value is made to meet the target condition that enables the electronic device to have access permission to enter the operating system. This allows the electronic device to successfully enter the operating system after restarting, provided it has access permission.

[0046] In some implementations, if a system file is mistakenly identified as abnormal and the value of the target parameter is modified to put the electronic device in a target state and prevent it from entering the operating system, the target condition can be met by directly adjusting the value of the target parameter so that the electronic device can restart and enter the operating system.

[0047] The target condition can characterize the conditions that the target parameters need to meet when an electronic device has the permission to access the operating system.

[0048] For example, target conditions may include target parameter values ​​that are preset values ​​or default values ​​set by the device at the factory, which indicate that the electronic device has permission to access the operating system.

[0049] In this embodiment, first information is obtained to detect whether the electronic device is in a target state. If the electronic device is in the target state, target parameters are obtained, and the target parameters are further adjusted to meet the target conditions, thereby enabling the electronic device to normally enter the operating system after restarting. Thus, when the electronic device cannot enter the operating system, on the one hand, there is no need to return the electronic device to the factory or reinstall the system, reducing maintenance costs; on the other hand, the target parameters can be automatically adjusted in response to the inability of the electronic device to enter the operating system, thereby enabling the electronic device to enter the operating system and improving the user experience.

[0050] In some embodiments, steps S101 to S102 may include one of steps S111 to S112:

[0051] Step S111: Detect an interrupt instruction obtained in the target stage and obtain target parameters; the interrupt instruction is triggered by the target object performing a shutdown or restart operation on the electronic device. The target stage includes the first boot stage or the operating system update stage.

[0052] If an electronic device receives an interrupt instruction during its first boot and operation of the operating system or during an operating system update, it may result in an OS missing error. This would cause the electronic device's access permissions to the operating system to be modified, preventing the device from completing the first boot or update of the operating system.

[0053] By detecting the interruption instructions of the target stage, it is possible to determine whether the electronic device is unable to enter the operating system due to the interruption of the target stage operation. In this way, the target parameters can be obtained upon receiving the interruption instructions, and the target parameters can be adjusted subsequently to restart the electronic device and complete the target stage.

[0054] Here, the interrupt instruction can be an instruction used by the target object to interrupt the operation performed on the electronic device within the target phase, such as, but not limited to, operations like powering off or restarting. The target object can include, but is not limited to, the user or the system.

[0055] The interrupt instruction obtained in the target phase can correspond to the first information that represents the electronic device being in the target state.

[0056] Step S112: Detect a fault indicator that indicates the electronic device cannot enter the operating system and obtain the target parameters.

[0057] Here, fault indicators can include error codes or abnormal signals generated during the operation of the electronic device, indicating that the electronic device is currently unable to enter the operating system normally. For example, fault indicators may include, but are not limited to, the aforementioned Errorcode and error logs.

[0058] By detecting fault indicators, it is possible to promptly identify when an electronic device cannot enter the operating system and obtain the corresponding target parameters for subsequent repair processes, thereby achieving automatic identification and repair of the electronic device's ability to enter the operating system.

[0059] In some implementations, fault indicators can be associated with critical steps in the system boot process, such as verification failures, missing files, or partition errors.

[0060] In some implementations, the fault identifier may correspond to a fault type. When a fault identifier is detected, the system can identify the corresponding fault type based on the fault identifier and perform the corresponding repair operation.

[0061] In some implementations, different error flags can correspond to faults in different partitions of the operating system.

[0062] In some implementations, after the electronic device detects that an interrupt instruction has been received at the target stage, it can simultaneously generate a fault flag to indicate that the electronic device cannot enter the operating system.

[0063] In this embodiment, target parameters are obtained by detecting fault indicators or detecting whether an interrupt command is received at the target stage. This improves the timeliness and accuracy of obtaining target parameters by using detected fault indicators or interrupt commands detected at the target stage.

[0064] In some embodiments, obtaining the target parameter in step S102 above may include the following step S121:

[0065] Step S121: Obtain the current value of the target parameter; the current value indicates that the electronic device does not have access permission to enter the operating system.

[0066] Here, the current value of the target parameter is the value of the target parameter when the electronic device is in the target state at the current moment. Since the current value of the target parameter indicates that the electronic device does not have access permissions to enter the operating system, it can be determined that the electronic device is in the target state at least because the value of the target parameter is set to its current value.

[0067] The adjustment of the target parameter value to meet the target condition in step S104 above may include the following step S122:

[0068] Step S122: Adjust the current value of the target parameter to a preset value; the preset value indicates that the electronic device has access permission to enter the operating system.

[0069] Here, the preset values ​​are pre-defined configuration information. By adjusting the current value of the target parameter to the preset value, the operating state of the electronic device can be changed from being unable to access the operating system to having at least the permission to access the operating system. In the absence of other root causes of the fault, the electronic device can access the operating system.

[0070] In this embodiment, the current value of the target parameter is obtained and adjusted to a preset value that represents the electronic device's access permission to enter the operating system. Thus, by adjusting the target parameter value, the access permission of the electronic device to enter the operating system is modified without manual intervention. This enables automatic and seamless restoration of the electronic device's access to the operating system based on the target parameter, thereby improving the usability of the electronic device and the user experience.

[0071] In some embodiments, adjusting the parameter value of the target parameter in step S104 above to meet the target condition may include the following steps S131 to S134:

[0072] Step S131: Determine the target fault type corresponding to the target state.

[0073] Here, an electronic device being in a target state where it cannot access the operating system can indicate a malfunction. Different causes leading to this target state can correspond to different fault types. By obtaining the target fault type corresponding to the target state, the root cause of the fault can be quickly determined.

[0074] In some implementations, when a fault identifier indicating that an electronic device cannot access the operating system is detected, the target fault type can be determined based on the fault identifier.

[0075] For example, after detecting a fault code, the target fault type can be determined based on the different fault codes, such as a corrupted or missing operating system image file or a failed key verification.

[0076] Step S132: Obtain target backup data corresponding to the target fault type from the first storage space of the electronic device; the first storage space stores backup data of at least one fault type and the root cause data of each fault type, and the root cause data is part of the data in the system partition of the operating system.

[0077] Here, by storing backup data of at least one type of fault and the root cause data corresponding to each fault type in the first storage space in advance, the backup data of the corresponding root cause data can be quickly retrieved from the first storage space after the target fault type of the electronic device is determined, thereby completing the repair of the data in the system partition of the operating system.

[0078] The first storage space is a relatively stable storage area within a pre-defined electronic device, such as a solid-state drive (SSD), embedded memory (eMMC), or other non-volatile storage media, used for long-term storage of backup data for at least one type of failure and the corresponding root cause data for each failure type. For example, the first storage space can be a read-only memory (ROM), so that even if the power is cut off, the data stored in the ROM will not be lost or changed, thereby improving the reliability and integrity of the backup data.

[0079] The root cause data is abnormal data related to the root cause of the fault corresponding to the fault type. Different fault types have different root causes, and the corresponding root cause data is also different.

[0080] For example, if the fault type is "operating system kernel file abnormality", the root cause data corresponds to the operating system kernel file.

[0081] For example, if the fault type is "operating system key file verification failure", the root cause data corresponds to the operating system key file.

[0082] In some implementations, root cause data may include partial files from a system file of a system partition of the operating system, or partial files from system files corresponding to multiple system partitions of the operating system.

[0083] For example, an operating system may include multiple system partitions, and root cause data may include system files corresponding to each of these system partitions.

[0084] For example, an operating system may include multiple system partitions, and the root cause data of a fault may be a subset of system files within one of these partitions. Understandably, if the first storage space contains backup data corresponding to the root cause data, the fault can be repaired simply by storing a subset of system files from one of the system partitions. This reduces the size of the files needed to repair the fault corresponding to the root cause data in the first storage space, thus saving storage resources.

[0085] In some implementations, the correspondence between backup data of the root cause data corresponding to different fault types can be stored in the first storage space.

[0086] For example, the fault identifier corresponding to each fault type, along with the backup data of the fault root cause data corresponding to each fault type and its corresponding index, can be stored in different units of the first storage space.

[0087] Step S133: Repair the root cause data corresponding to the target fault type using the target backup data, based on the target starting address and target length of the root cause data corresponding to the target fault type in the system partition.

[0088] Here, based on the target start address and target length of the root cause data in the system partition, the specific location of the root cause data in the system partition can be determined. In this way, after obtaining the target backup data of the root cause data corresponding to the target fault type, the root cause data can be located and repaired quickly and accurately, improving the overall repair efficiency.

[0089] Step S134: Adjust the target parameter values ​​to meet the target conditions.

[0090] Here, if an abnormal system file is detected and the parameter value of the target parameter is modified to put the electronic device in the target state and prevent it from entering the operating system, the abnormal system file data needs to be repaired before the parameter value of the target parameter is adjusted to meet the target conditions. This is to ensure that the electronic device can enter the operating system after restarting. Otherwise, the electronic device will adjust the parameter value of the target parameter again after restarting due to the abnormal system file, resulting in the electronic device not having the access permission to enter the operating system and enter the target state.

[0091] In this embodiment, by identifying the target fault type, the root cause data corresponding to the target fault type is repaired based on backup data pre-stored in the first storage space. Simultaneously, the parameter values ​​of the target parameters are adjusted to meet the target conditions. This approach, on the one hand, targeted repair of the root cause data reduces the impact on other parts of the operating system, improving the accuracy and efficiency of fault repair. On the other hand, adjusting the target parameters after repairing the fault data to grant the electronic device access to the operating system reduces the possibility that the target parameters might be modified again after a reboot due to unrepaired fault data, thus preventing the electronic device from regaining operating system access and increasing the probability of the electronic device successfully accessing the operating system after a reboot.

[0092] This application provides a data processing method that can be executed by an electronic device. The electronic device refers to a server, laptop computer, tablet computer, desktop computer, smart TV, set-top box, mobile device (e.g., mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device), or any other device with data processing capabilities. Figure 2 As shown, the processing method includes the following steps S201 to S202:

[0093] Step S201: Based on the historical installation data corresponding to the historical installation process of the operating system of the first electronic device and the historical boot data corresponding to at least one historical boot process of the second electronic device, determine at least one fault type and the root cause data corresponding to each fault type; during the historical boot process, the second electronic device is in a target state, the target state corresponds to at least one fault type, the second electronic device cannot enter the operating system in the target state, and the first electronic device can enter the operating system during the historical installation process.

[0094] Here, the historical installation process refers to the process of installing the operating system on the first electronic device at a historical moment, and the historical installation data includes at least the data information recorded during the historical installation process. This data information includes, at least, the attribute information of the operating system's system files. For example, the attribute information may include, but is not limited to, the size, tag, type, number, and corresponding operating system access permissions of the system files.

[0095] The historical boot process refers to the boot process of the second electronic device at a historical moment. During the historical boot process, the second electronic device needs to enter the operating system. Historical boot data includes at least the data information recorded during the historical boot process.

[0096] In some implementations, the historical startup data records may include information that characterizes the type of fault, such as fault identifiers, in addition to the attribute information of system files.

[0097] By comparing historical installation data and historical boot data, the differences between the process of successfully entering the operating system and the process of unsuccessfully entering the operating system can be obtained at the data level. This allows us to identify data that causes abnormalities and failures, thereby determining at least one type of failure and the root cause data corresponding to that type of failure.

[0098] In some implementations, the historical installation process can be the process of installing or updating the operating system for the first time. During the initial installation or update of the operating system, the display component of the electronic device with a display component will display the attribute information of the system files corresponding to each system partition of the operating system (such as the size, label, type, number, corresponding operating system access permissions, and address of the system files).

[0099] Step S202: Store backup data of at least one fault type and the root cause data corresponding to each fault type in the first storage space of the third electronic device, so as to enable the device to adjust the parameter values ​​of the target parameters to meet the target conditions.

[0100] The first electronic device, the second electronic device, and the third electronic device have the same type of operating system, and the first electronic device, the second electronic device, and the third electronic device may be the same or different.

[0101] Here, the same operating system type means that the first electronic device, the second electronic device, and the third electronic device all run the same operating system version and architecture, that is, the first electronic device, the second electronic device, and the third electronic device are consistent in terms of system structure, partition layout, boot process, etc.

[0102] Furthermore, when the operating system types are consistent, cross-device data comparison and analysis can be achieved. For example, the first electronic device can be a factory testing device, the second electronic device can be a user terminal device, and the third electronic device can be a maintenance server, cloud device, or other user terminal device. In this way, the first, second, and third electronic devices can all be used for fault handling and repair based on the same operating system logic.

[0103] Therefore, at least one fault type determined based on historical startup data and historical installation data, as well as the root cause data corresponding to each fault type, are applicable to the third electronic device. That is, when the third electronic device experiences a fault of the type stored in the first storage space, the corresponding backup data can be used to repair the fault.

[0104] It is understood that the first electronic device, the second electronic device, and the third electronic device may differ in terms of hardware platform, model, brand, etc., but the same type of operating system can be applied to different electronic devices. Therefore, the first electronic device, the second electronic device, and the third electronic device may be the same or different, and the embodiments of this application do not limit this.

[0105] The parameter value used to adjust the target parameter of the device to meet the target condition can be corresponding to the parameter value used by the third electronic device to adjust the target parameter to meet the target condition after repairing the fault using the backup data of the fault root cause data corresponding to the fault type.

[0106] For example, such as Figure 3 As shown, the first storage space is a read-only memory. The operating system includes thirteen system partitions. The read-only memory includes at least four storage units. Storage unit 1 is used to store fault code 1 indicating an anomaly in the kernel file of the system partition, and backup data 1 used to repair the kernel file. The storage size is 8 bits (Byte). Storage unit 2 is used to store fault code 2 indicating an anomaly in the key file of the system partition, and backup data 2 used to repair the key file. The storage size is 1 megabit (MB). Storage unit 3 is used to store fault code 3 indicating an anomaly in the encrypted file of the system partition, and backup data 3 used to repair the encrypted file. The storage size is 2 megabits (MB). Storage unit 4 is used to store fault codes indicating anomalies in other files in the system partition besides the kernel file, key file, and encrypted file. The fault codes stored in storage unit 4 can indicate that the corresponding root cause file has not yet been stored. After the corresponding root cause file is determined later, a new storage unit can be allocated to store the corresponding fault code and the backup file of the root cause file.

[0107] In this embodiment, at least one fault type and its corresponding root cause data are determined by using historical installation data corresponding to the historical installation process of the operating system of the first electronic device and historical boot data corresponding to at least one historical boot process of the second electronic device. Backup data of the at least one fault type and its corresponding root cause data are then stored in the first storage space of the third electronic device for adjusting the parameter values ​​of the target parameters to meet the target conditions. Thus, by analyzing historical installation and boot data of the same type of operating system, extracting each fault type and its corresponding root cause data, and storing the corresponding backup data in an electronic device with the same operating system type, the device storing the backup data can quickly retrieve the backup data when it cannot enter the operating system due to system file anomalies. This allows for the repair of the root cause data, enabling the restarted device to enter the operating system after repairing the root cause data and adjusting the target parameters to meet the target conditions, thereby improving the self-repair capability of the electronic device upon entering the operating system.

[0108] In some implementations, such as Figure 4 As shown, when the third electronic device is a device awaiting shipment, it is necessary to store backup data of at least one fault type and the corresponding root cause data of each fault type in the ROM before the write protection step is initiated before shipment. This ensures that the backup data is protected and improves the stability of the backup data storage. Writing the backup data may include the following steps S2021 to S2024:

[0109] Step S2021: Verify whether the test identifier has been cleared.

[0110] During implementation, before the equipment leaves the factory, relevant tools in the operating system can be used to verify whether the test marks generated during the test have been cleared.

[0111] Step S2022: Determine the backup data.

[0112] During implementation, the root cause data of each fault that causes the OS to miss can be obtained through testing, and the backup files corresponding to each root cause data can be obtained from the database storing the test results.

[0113] Step S2023: Write the backup file to the read-only memory.

[0114] During implementation, backup files of the root cause data corresponding to each fault type can be written into preset storage units according to different fault types.

[0115] Step S2024: Enable write protection.

[0116] In some embodiments, step S201 may include steps S211 to S212:

[0117] Step S211: Based on the historical startup data corresponding to each historical startup process, determine at least one fault type, including the fault type of startup fault that occurred in each historical startup process.

[0118] Step S212: For each fault type, compare the historical startup data corresponding to the fault type with the historical installation data to obtain the root cause data of the fault type; the historical startup data corresponding to the fault type includes the historical startup data corresponding to the historical startup process in which the fault type occurred.

[0119] Here, the root cause data corresponding to the fault type will cause the operating system to experience a boot failure corresponding to that fault type. Therefore, different historical boot processes may have different fault types and corresponding root cause data.

[0120] For each type of failure, by comparing the same and different data in the historical startup data and historical installation data, the root cause data of the startup failure in the historical startup process corresponding to that failure type can be accurately and quickly determined.

[0121] In this embodiment, for each fault type, the historical startup data corresponding to the fault type is compared with the historical installation data to obtain the root cause data corresponding to the fault type. This improves the accuracy and efficiency of determining the root cause data for each fault type by using data that both caused and did not cause the fault.

[0122] In some embodiments, the historical boot data includes first target parameters corresponding to each system file of the operating system during the corresponding historical boot process, and the historical installation data includes second target parameters corresponding to each system file of the operating system during the corresponding historical installation process.

[0123] The step S212 above, which compares the historical startup data corresponding to the fault type with the historical installation data to obtain the root cause data corresponding to the fault type, may include the following step S221:

[0124] Step S221: If the first target parameter corresponding to the target file in the historical startup data is different from the second target parameter corresponding to the target file in the historical installation data, the target file is identified as the root cause data of the fault type.

[0125] Here, the target file is the system file corresponding to the system partition of the operating system in the historical boot data.

[0126] The difference between the first target parameter and the first target parameter indicates that, for the same system file, the value of the target parameter corresponding to that system file differs between the historical boot data and the historical installation data. This can be understood as the target parameter being modified due to an anomaly in the system file, preventing the electronic device from booting into the operating system; in other words, the system file is the root cause of the fault, leading to the modification of the target parameter.

[0127] For example, in the historical startup data corresponding to the first fault type, the parameter value of the first target parameter corresponding to the first target file is 0, and in the historical installation data, the parameter value of the first target parameter corresponding to the first target file is 1. That is, the first target file is the root cause data of the first fault type.

[0128] In this embodiment, if the first target parameter corresponding to the target file in the historical startup data differs from the second target parameter corresponding to the target file in the historical installation data, the target file is identified as the root cause data corresponding to the fault type. This allows for further improvement in the accuracy and efficiency of the root cause data corresponding to each fault type based on the differences in target parameters between data that caused the fault and those that did not.

[0129] In some embodiments, the historical startup data is in text format, and the above data processing method may further include the following steps S231 to S232:

[0130] Step S231: Obtain the target frame buffer data of the first electronic device during the historical installation process; the target frame buffer data is used at least to display the attribute information of each system file of the operating system during the historical installation process.

[0131] Here, in the case of an electronic device including a display component, framebuffer data is generated to drive the display component to display corresponding content on the display interface. Since the attribute information of each system file of the operating system is displayed on the display interface of the display component during the historical installation process, the attribute information of each system file of the operating system can be obtained by acquiring the target framebuffer data of the first electronic device during the historical installation process.

[0132] Step S232: Convert the target frame buffer data to obtain historical installation data; the historical installation data is in text format.

[0133] Here, by converting the acquired target frame buffer data to obtain historical installation data in text format, the attribute information of each system file of the operating system in the target frame buffer data can be edited. Furthermore, by unifying the data format of historical installation data and historical boot data to text format, the consistency of comparing historical installation data and historical boot data and the processing efficiency can be improved.

[0134] In this embodiment, the target frame buffer data of the first electronic device during the historical installation process is converted into a text format to obtain historical installation data, which is the same as the historical startup data. Thus, by converting the original graphical information from the historical installation process into editable text format information, on the one hand, the originally uneditable graphical information can be converted into editable text information, improving the editability and scalability of the data; on the other hand, based on the obtained attribute information of each system file of the editable operating system, the format of the historical startup data and the historical installation data can be unified, thereby improving the consistency and processing efficiency when comparing the two types of data.

[0135] In some embodiments, step S232 may include steps S241 to S243:

[0136] Step S241: Convert the format of the target frame buffer data to obtain the initial installation data.

[0137] Here, the initial installation data is text format data obtained by simply converting the target frame buffer data; the content of the target frame buffer data is not modified.

[0138] Step S242: From the initial installation data, filter out the attribute data that characterizes the target attributes of each system file; the target attributes include the file identifier of the system file and the target parameters corresponding to the system file.

[0139] Here, the file identifier can be at least one identifying information that can be used to distinguish each system file. For example, the file identifier may include the attribute information in the above embodiments. Based on the file identifier, the accuracy of identifying each system file can be improved, and thus the accuracy of determining the target parameters of the unified system file in historical installation data and historical boot data can be improved.

[0140] For example, a file identifier may include, but is not limited to, at least one of the following: system file size, tag, type, number, corresponding operating system access permissions, and address.

[0141] In some implementations, the text corresponding to the attribute data of the target attributes of each system file in the text corresponding to the initial installation data can be extracted by extracting key fields.

[0142] It is understandable that the size of the target attribute data of each system file obtained after filtering is smaller than the size of the initial installation data.

[0143] The target parameters corresponding to system files can characterize whether an electronic device has permission to enter the operating system after loading the system file. Based on the target parameters corresponding to system files, the accuracy of determining whether each system file is the root cause of the fault that prevents the electronic device from entering the operating system can be improved.

[0144] Step S243: Obtain historical installation data based on attribute data.

[0145] Here, historical installation data can be obtained based solely on attribute data; alternatively, it can be obtained by combining attribute data with other data from the initial installation data.

[0146] For example, such as Figure 5 As shown, initial installation data can be obtained based on the target frame buffer data through format conversion. Furthermore, the starting address of each system partition, the size of each system partition, the partition number corresponding to each system partition, and the attribute information (tags, format types, identifier characters, and target parameter values) of each system file contained in each system partition can be saved as historical installation data in text format. Specifically, the starting address and size of each system partition determine its storage location; the tags corresponding to each system file can determine its content type (e.g., kernel file, root file, key file); the format types corresponding to each system file determine its data format; the identifier characters corresponding to each system file serve as a unique identifier for each system file; and the target parameters corresponding to each system file determine whether the electronic device has permission to access the operating system after loading that system file.

[0147] In this embodiment, attribute data representing the target attributes of each system file is filtered out from the initial installation data obtained by format conversion of the target frame buffer data; and historical installation data is obtained based on the attribute data. Thus, through structured processing of the target frame buffer data, attribute data related to the identifiers corresponding to each system file and the electronic device's access permissions to the operating system are extracted, resulting in standardized historical installation data. This facilitates subsequent comparison and analysis, further improving the automation level of data processing.

[0148] In related technologies, the frame buffer data during the operating system installation process is only used to display the attribute information of each system file of the operating system during the installation process, and cannot be edited or saved.

[0149] Based on this, embodiments of this application provide an electronic device for displaying a screen interface during the operating system installation process. For example... Figure 6 As shown, the electronic device 600 may include:

[0150] Display component 610, for displaying at least the operating system installation interface;

[0151] The display component can also be used to obtain target frame buffer data during the installation process. Based on the target frame buffer data, the editing operations on the installation interface are recorded to obtain historical installation data. The historical installation data is used to generate backup data so that the parameter values ​​of the device can be adjusted to meet the target conditions.

[0152] Here, historical installation data is used to generate backup data for the device to adjust the target parameter value to meet the target condition. The device may include the first electronic device, the second electronic device, and / or the third electronic device in the above data processing method. Adjusting the target parameter value to meet the target condition can correspond to the above step S103.

[0153] During the use of electronic devices, OS missing issues are difficult to avoid. Analysis revealed that these problems may be caused by users interrupting the update or startup process during system updates or the first boot, leading the system to mistakenly determine that the system is missing. The system then actively modifies the access permission parameters for the electronic device to enter the system (for example, using 0 to 15 from low to high to represent the access priority of the electronic device to the operating system) and marks an Errorcode, preventing the electronic device from entering the operating system at the software level and leaving it stuck on the OS missing display screen.

[0154] like Figure 7 As shown, the method for handling OS missing in related technologies includes the following steps S701 to S708:

[0155] Step S701: Start the equipment.

[0156] Step S702: Start the Trusted Platform Module.

[0157] Step S703: Firmware startup.

[0158] Step S704: Load the kernel file.

[0159] If loading the kernel file fails, step S705 is executed; if it succeeds, step S707 is executed.

[0160] Step S705: OS missing is displayed.

[0161] Step S706: Restart.

[0162] Step S707: Start the root file.

[0163] Step S708: Operating system starts.

[0164] As can be seen, once the machine enters the OS missing state using the above methods, even if it is restarted, the electronic device will eventually display the OS missing screen because it does not have permission to access the operating system, until the system is reinstalled.

[0165] In this context, the following solutions exist in the relevant technologies to address the related problems:

[0166] A) Restore system.

[0167] When the system is restored, the system files and access settings will be restored to the data corresponding to the previous historical point in time (also known as the "restore point").

[0168] Furthermore, when repairing files, it is usually necessary to back up and repair multiple files simultaneously.

[0169] B) Repair by deploying image servicing and management tools such as DISM.

[0170] In related technologies, the DISM command-line tool can manage components, drivers, service information, application settings, etc., and perform system repair by deploying image services and management tools. Its principle is to check data such as the registry in the system. These operations are in the later stages of the boot process when entering the operating system, and different systems may use fixed or dynamically changing configuration information. It is difficult to quickly and accurately determine the problem by focusing on drivers and services.

[0171] C) Check the hard drive for file system errors.

[0172] This means troubleshooting hardware-related problems; if the problem lies in the software, it will be difficult to detect.

[0173] Based on the principle that the system determines that the device does not have the system's access permission, by pre-acquiring and storing the data that needs to be verified or repaired for different OS missing error codes, when an error code-corresponding exception occurs, the pre-stored data can be dynamically restored according to the error code, thereby meeting the conditions for entering the system on the next reboot.

[0174] Based on this, embodiments of this application provide a data processing method that can be executed by an electronic device, which can dynamically retrieve corresponding backup data from a protected read-only memory and repair the root cause data of the corresponding location when the device enters an OS missing state.

[0175] like Figure 8 As shown, the data processing method includes the following steps S801 to S812:

[0176] Step S801: Start the device.

[0177] Step S802: Start the Trusted Platform Module.

[0178] Step S803: Firmware startup.

[0179] Step S804: Load the kernel file.

[0180] If loading the kernel file fails, step S805 is executed; if it succeeds, step S806 is executed.

[0181] Step S805: OS missing error occurs.

[0182] When an OS missing problem is detected, the display interface does not show any information related to OS missing, and step S808 is executed.

[0183] Step S806: Start the root file.

[0184] Step S807: Operating system starts.

[0185] Step S808: Obtain the error code.

[0186] Here, the error code can correspond to the fault identifier of the target state in the above data processing method.

[0187] Step S809: Obtain the corresponding backup data from the read-only memory and repair the corresponding data.

[0188] Specifically, based on the different fault identifiers parsed, the root cause data corresponding to the fault identifier is determined, and the backup data corresponding to the root cause data is obtained from the corresponding storage unit in the read-only memory.

[0189] Step S810: Repair the root cause data of the fault according to the corresponding data.

[0190] During implementation, the location of the root cause data can be determined based on the target address and target length of the root cause data, and the device can enter the self-repair phase based on the backup data.

[0191] Step S811: Restore the target parameters.

[0192] After completing the repair operation on the root cause data of the fault, the current value of the target parameter is restored to the preset value that the device can enter the system.

[0193] Step S812: Restart the device.

[0194] Here, since the abnormal root cause data has been repaired and the target parameters have been restored to the default values ​​that allow the device to enter the system, the device can enter the operating system after restarting.

[0195] In this embodiment, devices experiencing OS missing issues can be dynamically repaired based on different error codes, without requiring factory repair or system reinstallation, and without affecting user data on the device.

[0196] This application provides a data processing method that can be executed by an electronic device, used to acquire and store backup files of fault root cause data corresponding to fault codes in the device.

[0197] like Figure 9 As shown, the data processing method includes the following steps S901 to S911:

[0198] Step S901: Add the target attribute to the property information of the installed operating system.

[0199] The target attribute can be corresponding to: Figure 5 The starting address of each system partition, the size of each system partition, the partition number of each system partition, and the attribute information of each system file contained in each system partition.

[0200] Step S902: Convert the visual process of installing the operating system into an editable process.

[0201] During implementation, the acquired frame buffer data can be formatted and stored in memory to obtain an editable text format sample file. The acquired frame buffer data and the sample file can respectively correspond to the target frame buffer data and initial installation data of the first electronic device in the aforementioned data processing method.

[0202] Step S903: Obtain historical installation data based on the initial installation data.

[0203] During implementation, the newly added target attributes can be stored as key-value pairs by parsing the sample file. In this way, the final results corresponding to each target attribute can be obtained as historical installation data.

[0204] Step S904: Obtain historical startup data.

[0205] Because in related technologies, process data related to startup failures cannot be output in user mode (Normal mode) during device startup, it is necessary to enable the device to output process data related to startup failures in user mode before OS Missing occurs. Then, by taking a snapshot, the data of hardware initialization and loading of the operating system modules during system startup is scanned to obtain historical startup data including attribute data related to target attributes.

[0206] Step S905: Obtain the attribute data related to the target attribute from the historical startup data.

[0207] During implementation, strings or values ​​corresponding to target attributes in historical startup data (such as tags, format types, identifier characters, target parameters, etc.) can be extracted.

[0208] Step S906: Compare historical installation data with historical startup data.

[0209] Specifically, the first target parameter and the second target parameter corresponding to each system file can be compared. If the first target parameter and the second target parameter corresponding to the target file are different, the target file is determined to be the root cause file of the fault.

[0210] Step S907: Associate the root cause data of the fault with the corresponding error code.

[0211] Here, since different error codes represent different causes of OS missing (root cause files), but the current value of the target parameter corresponding to OS missing is the same, the root cause of OS missing can be determined by combining the current value of the target parameter and the error code.

[0212] Step S908: Determine the system partition where the root cause data of the fault is located.

[0213] During implementation, the system partition where the root cause data is located can be determined based on the value corresponding to the target attribute of the root cause data.

[0214] Step S909: Determine the location of the root cause data within the system partition.

[0215] In implementation, the two attributes of each system partition can be obtained by decoding the data in the system partition: key-related attributes and data encoding attributes. The key-related attributes include important information such as the encryption method and signature type (e.g., public or private). The data encoding attributes include important information such as the data size, address, and length.

[0216] Step S910: Identify and obtain the backup file of the root cause data of the fault.

[0217] Step S911: Associate the backup file of the Error code and the root cause data of the fault and store it in read-only memory.

[0218] During implementation, the index corresponding to the error code and the backup file of the root cause data is stored in read-only memory.

[0219] In this embodiment, the corresponding root cause file can be determined based on historical boot data corresponding to different types of error codes. On the one hand, the root cause file causing the OS missing error can be located and backed up before the device leaves the factory, enabling automatic repair in the event of an OS missing error. On the other hand, compared to related technologies where a single repair operation requires repairing multiple system files, this embodiment can directly locate and repair at least one specific system file in at least one system partition.

[0220] This application provides a data processing apparatus, such as... Figure 10 As shown, the data processing device 1000 includes:

[0221] Module 1010 is used to obtain the first information;

[0222] The obtaining module 1020 is further configured to obtain target parameters in response to the first information indicating that the electronic device is in a target state; in the target state, the electronic device cannot enter the operating system, and the target parameters are used to reflect the access permission of the electronic device to enter the operating system;

[0223] The adjustment module 1020 is used to adjust the parameter value of the target parameter to meet the target conditions so that the electronic device can enter the operating system after restarting.

[0224] In some embodiments, the obtaining module may also be used to: detect an interrupt instruction obtained in a target stage and obtain target parameters; the interrupt instruction is triggered by a target object performing a shutdown or restart operation on the electronic device, and the target stage includes an initial startup stage or an operating system update stage; or, detect a fault identifier indicating that the electronic device cannot enter the operating system and obtain target parameters.

[0225] In some embodiments, the obtaining module can also be used to: obtain the current value of the target parameter; the current value indicates that the electronic device does not have access permission to enter the operating system;

[0226] The adjustment module can also be used to: adjust the current value of the target parameter to a preset value; the preset value indicates that the electronic device has access permission to enter the operating system.

[0227] In some embodiments, the adjustment module can also be used to: determine the target fault type corresponding to the target state; obtain target backup data corresponding to the target fault type from the first storage space of the electronic device; the first storage space stores backup data of at least one fault type and the root cause data of each fault type, wherein the root cause data is part of the data in the system partition of the operating system; repair the root cause data corresponding to the target fault type using the target backup data according to the target starting address and target length of the root cause data corresponding to the target fault type in the system partition; and adjust the parameter value of the target parameter to meet the target condition.

[0228] This application provides a data processing apparatus, such as... Figure 11 As shown, the processing device 1100 includes:

[0229] The determination module 1110 is used to determine at least one fault type and fault root cause data corresponding to each fault type based on historical installation data corresponding to historical installation process of the operating system of the first electronic device and historical boot data corresponding to at least one historical boot process of the second electronic device; during the historical boot process, the second electronic device is in a target state, the target state corresponds to at least one fault type, the second electronic device cannot enter the operating system in the target state, and the first electronic device can enter the operating system during the historical installation process.

[0230] Storage module 1120 is used to store backup data of the at least one fault type and the fault root cause data corresponding to each fault type into the first storage space of the third electronic device, so as to allow the device to adjust the parameter value of the target parameter to meet the target condition.

[0231] The first electronic device, the second electronic device, and the third electronic device all have the same type of operating system, and the first electronic device, the second electronic device, and the third electronic device may be the same or different.

[0232] In some embodiments, the determining module may further be used to: determine at least one fault type based on historical startup data corresponding to each historical startup process, wherein the at least one fault type includes the fault type of startup fault that occurred in each historical startup process; for each fault type, compare the historical startup data corresponding to the fault type with the historical installation data to obtain the root cause data of the fault type; wherein the historical startup data corresponding to the fault type includes the historical startup data corresponding to the historical startup process in which the startup fault of the fault type occurred.

[0233] In some embodiments, the historical boot data includes first target parameters corresponding to each system file of the operating system during the corresponding historical boot process, and the historical installation data includes second target parameters corresponding to each system file of the operating system during the corresponding historical installation process; the determining module can also be used to: determine the target file as the root cause data of the fault type when the first target parameter corresponding to the target file in the historical boot data is different from the second target parameter corresponding to the target file in the historical installation data.

[0234] In some embodiments, the historical startup data is in text format, and the data processing device may further include an acquisition module for:

[0235] Obtain the target frame buffer data of the first electronic device during the historical installation process; the target frame buffer data is used to display the attribute information of each system file of the operating system during the historical installation process; convert the target frame buffer data to obtain the historical installation data; the data format of the historical installation data is text format.

[0236] In some embodiments, the obtaining module can also be used to: perform format conversion on the target frame buffer data to obtain initial installation data; filter attribute data representing the target attributes of each system file from the initial installation data; the target attributes include the file identifier of the system file and the target parameters corresponding to the system file; and obtain the historical installation data based on the attribute data.

[0237] This application provides an electronic device, including a memory and a processor. For example... Figure 12 As shown, the electronic device 1200 includes:

[0238] Memory 1210 is used to store computer programs that can run on processor 1220;

[0239] The processor 1220 is used to execute the program stored in the memory 1210 to implement the data processing method applied to the data processing device described above.

[0240] This application provides a computer program including computer-readable code. When the computer-readable code is run in a computer device, the processor in the computer device executes some or all of the steps in the above-described processing method.

[0241] This application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement some or all of the steps in the above-described processing method.

[0242] This application provides a computer-readable storage medium storing a computer program that can be executed by a processor to implement the above-described processing method.

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

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

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

[0246] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

[0247] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0248] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0249] It should be noted that, in this document, 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. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0250] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0251] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0252] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0253] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0254] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0255] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. A data processing method, comprising: Obtain first information; In response to the first information indicating that the electronic device is in the target state, target parameters are obtained; In the target state, the electronic device cannot access the operating system, and the target parameter is used to reflect the access permission of the electronic device to access the operating system; The parameter values ​​of the target parameters are adjusted to meet the target conditions so that the electronic device can enter the operating system after restarting.

2. The method according to claim 1, wherein obtaining the first information, in response to the first information indicating that the electronic device is in a target state, and obtaining the target parameters, includes: An interrupt instruction was detected during the target phase, and the target parameters were obtained. The interrupt command is triggered by the target object performing a shutdown or restart operation on the electronic device, and the target phase includes the initial boot phase or the operating system update phase; Alternatively, a fault indicator indicating that the electronic device cannot access the operating system can be detected, and target parameters can be obtained.

3. The method according to claim 2, wherein obtaining the target parameter includes: Obtain the current value of the target parameter; The current value indicates that the electronic device does not have access permission to enter the operating system; The adjustment of the target parameter value to satisfy the target condition includes: Adjust the current value of the target parameter to a preset value; The preset value indicates that the electronic device has access permission to enter the operating system.

4. The method according to any one of claims 1 to 3, wherein adjusting the parameter value of the target parameter to satisfy the target condition includes: Determine the target fault type corresponding to the target state; Obtain target backup data corresponding to the target fault type from the first storage space of the electronic device; The first storage space stores backup data of at least one type of fault and the root cause data of each type of fault, wherein the root cause data is a portion of the data in the system partition of the operating system. Based on the target starting address and target length of the root cause data corresponding to the target fault type in the system partition, the root cause data corresponding to the target fault type is repaired using the target backup data; Adjust the value of the target parameter to satisfy the target condition.

5. A data processing method, comprising: Based on the historical installation data corresponding to the historical installation process of the operating system of the first electronic device and the historical boot data corresponding to at least one historical boot process of the second electronic device, at least one fault type and fault root cause data corresponding to each fault type are determined; during the historical boot process, the second electronic device is in a target state, the target state corresponds to at least one fault type, the second electronic device cannot enter the operating system in the target state, and the first electronic device can enter the operating system during the historical installation process. The backup data of the at least one fault type and the root cause data of each fault type are stored in the first storage space of the third electronic device so that the device can adjust the parameter value of the target parameter to meet the target condition. The first electronic device, the second electronic device, and the third electronic device have the same type of operating system, and the first electronic device, the second electronic device, and the third electronic device may be the same or different.

6. The method according to claim 5, wherein determining at least one fault type and root cause data corresponding to each fault type based on the historical installation data corresponding to the historical installation process of the operating system of the first electronic device and the historical boot data corresponding to at least one historical boot process of the second electronic device includes: Based on the historical startup data corresponding to each of the historical startup processes, at least one fault type is determined, and the at least one fault type includes the fault type of startup fault that occurred in each of the historical startup processes; For each of the aforementioned fault types, the historical startup data corresponding to the fault type is compared with the historical installation data to obtain the root cause data corresponding to the fault type; the historical startup data corresponding to the fault type includes the historical startup data corresponding to the historical startup process in which the startup fault of the aforementioned fault type occurred.

7. The method according to claim 6, wherein the historical boot data includes first target parameters corresponding to each system file of the operating system in the corresponding historical boot process, and the historical installation data includes second target parameters corresponding to each system file of the operating system in the corresponding historical installation process; The step of comparing the historical startup data corresponding to the fault type with the historical installation data to obtain the root cause data corresponding to the fault type includes: If the first target parameter corresponding to the target file in the historical startup data is different from the second target parameter corresponding to the target file in the historical installation data, the target file is determined as the root cause data of the fault type.

8. The method according to claim 5, wherein the historical startup data is in text format, and the method further comprises: Obtain the target frame buffer data of the first electronic device during the historical installation process; The target frame buffer data is used at least to display the attribute information of each system file of the operating system during the historical installation process; The target frame buffer data is format-converted to obtain the historical installation data; the historical installation data is in text format.

9. The method according to claim 8, wherein the format conversion of the target frame buffer data to obtain the historical installation data includes: The target frame buffer data is format-converted to obtain initial installation data; From the initial installation data, attribute data characterizing the target attributes of each system file is selected; the target attributes include the file identifier of the system file and the target parameters corresponding to the system file; Based on the attribute data, the historical installation data is obtained.

10. An electronic device, comprising: Display components, at least for displaying the operating system installation interface; The display component is also used to obtain target frame buffer data during the installation process, record editing operations on the installation interface based on the target frame buffer data, and obtain the historical installation data; the historical installation data is used to generate backup data so that the device can adjust the parameter values ​​of the target parameters to meet the target conditions.

Images