CN114116023A

CN114116023A - Operating system starting method, operating system starting device, storage medium and computer program product

Info

Publication number: CN114116023A
Application number: CN202110662962.3A
Authority: CN
Inventors: 王艳召; 张赠辉; 陈超; 李永潮
Original assignee: Honor Device Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2021-06-15
Filing date: 2021-06-15
Publication date: 2022-03-01
Anticipated expiration: 2041-06-15
Also published as: WO2022262753A1; CN114116023B

Abstract

An embodiment of the present application provides an operating system starting method, an operating system starting device, a storage medium, and a computer program product, where the method is applied to an electronic device, the electronic device includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, the first static partition includes a first sub-partition, the second static partition includes a second sub-partition, and the first sub-partition and the second sub-partition are sub-partitions corresponding to each other, and the method includes: loading data of the base partition; loading static partition data, including: performing first verification operation on the data of the first sub-partition, and loading the data of the first sub-partition when the first verification operation is successful; when the first check operation fails, performing a second check operation on the data of the second sub-partition, and when the second check operation succeeds, loading the data of the second sub-partition; the data of the dynamic partition is loaded to run a first operating system.

Description

Operating system starting method, operating system starting device, storage medium and computer program product

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a storage medium, and a computer program product for starting an operating system.

Background

In the application scenario of the prior art, the user terminal needs to install the operating system to be available to the user. For example, a mobile phone operating system (e.g., an IOS system, an android system) needs to be installed on the mobile phone to be used by the user.

In the process of using a terminal device installed with an operating system, the device cannot be started due to data errors of the operating system, and therefore, a device starting method for the data errors of the operating system is needed to ensure that the device can be started smoothly.

Disclosure of Invention

In view of this, the present application provides a method, an apparatus, a storage medium, and a computer program product for starting an operating system, so as to solve the problem in the prior art that the apparatus cannot be started due to an operating system data error.

In a first aspect, an embodiment of the present application provides an operating system starting method, which is applied to an electronic device, where the electronic device includes a processor and a memory, the memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, the first static partition includes a first sub-partition, the second static partition includes a second sub-partition, and the first sub-partition and the second sub-partition are sub-partitions corresponding to each other, and the method includes:

loading data of the base partition;

loading static partition data, including: performing a first verification operation on the data of the first sub-partition, and loading the data of the first sub-partition when the first verification operation is successful; when the first check operation fails, performing a second check operation on the data of the second sub-partition, and when the second check operation succeeds, loading the data of the second sub-partition;

and loading the data of the dynamic partition to run a first operating system.

In one implementation form of the first aspect, the method further comprises:

and when the second check operation fails, restarting the electronic equipment, or outputting prompt information of the starting failure of the operating system.

In an implementation manner of the first aspect, the first static partition further includes a third sub-partition, the second static partition further includes a fourth sub-partition, the third sub-partition and the fourth sub-partition are sub-partitions corresponding to each other, and the loading static partition data further includes:

performing a third verification operation on the data of the third sub-partition, and loading the data of the third sub-partition when the third verification operation is successful; and when the third verification operation fails, performing a fourth verification operation on the data of the fourth sub-partition, and when the fourth verification operation succeeds, loading the data of the fourth sub-partition.

In an implementation manner of the first aspect, after the loading the data of the dynamic partition, the method further includes:

when the first verification operation fails, the starting sequence of the electronic equipment is changed from starting from the first static partition to starting from the second static partition.

and modifying the data of the second static partition.

In an implementation manner of the first aspect, the modifying the data of the second static partition includes:

and synchronizing the data of other sub-partitions except the first sub-partition in the first static partition into corresponding sub-partitions in the second static partition.

In an implementation manner of the first aspect, before the loading the static partition data, the method further includes synchronizing the data of the first static partition to the second static partition.

In an implementation manner of the first aspect, before the loading the data of the base partition, the method further includes:

loading data of the base partition, the second static partition, and the dynamic partition to run a second operating system;

obtaining an upgrade installation package, wherein the upgrade installation package comprises a static partition upgrade file;

upgrading the data of the first static partition based on the static partition upgrading file;

restarting the electronic equipment, and confirming that the current starting sequence is started from the first static partition;

loading data of the base partition, the first static partition, and the dynamic partition to run the first operating system;

wherein the synchronizing data of the first static partition to the second static partition is performed after the rebooting the electronic device confirms that a current boot sequence is booting from the first static partition.

In an implementation manner of the first aspect, in a process of loading the data of the first static partition, after the data of the static partition is successfully verified, the synchronization of the data of the first static partition to the second static partition is performed.

In an implementation manner of the first aspect, in a process of loading the data of the dynamic partition, after a file of the dynamic partition to be loaded is successfully verified, the data of the first static partition is synchronized to the second static partition.

In one implementation of the first aspect:

the upgrade installation package further comprises a dynamic partition upgrade file, the electronic device is restarted, and a current starting sequence is confirmed to be before starting from the first static partition, the method further comprises the steps of creating a virtual dynamic partition in the user data partition, and storing the dynamic partition upgrade file in the virtual dynamic partition;

the loading of the dynamic partition data comprises loading the data of the dynamic partition and the dynamic partition upgrading file;

after the loading of the dynamic partition data, the method further comprises: the dynamic partition upgrading file in the user data partition is landed to the dynamic partition;

after the dynamic partition upgrade file in the user data partition is landed to the dynamic partition, the data of the first static partition is synchronized to the second static partition.

In a second aspect, the present application further provides an electronic device, where the electronic device includes a processor and a memory, where the memory includes a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, the first static partition includes a first sub-partition, the second static partition includes a second sub-partition, and the first sub-partition and the second sub-partition are mutually corresponding sub-partitions, and the processor is configured to execute software codes stored in the memory, so that the electronic device executes the method flow according to the first aspect.

In a third aspect, the present application also provides a computer-readable storage medium having stored thereon a computer program which, when run on a computer, causes the computer to perform the method according to the first aspect.

In a fourth aspect, the present application also provides a computer program product comprising a computer program which, when run on a computer, causes the computer to perform the method according to the first aspect.

According to the technical scheme provided by the embodiment of the application, at least the following technical effects can be realized:

according to the method of the embodiment of the application, when the currently loaded static partition data is wrong, the data of another static partition can be loaded, so that the equipment is ensured to be smoothly started and an operating system is operated; according to the method provided by the embodiment of the application, the success rate of starting the equipment can be greatly improved, and the running stability of the equipment is improved.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without inventive labor.

Fig. 1 is a schematic diagram illustrating a data storage structure of an android system on a terminal device;

FIG. 2 is a flow chart illustrating a startup device according to an embodiment of the present application;

FIG. 3 is a schematic diagram illustrating a device boot loading process according to an embodiment of the present application;

FIG. 4 is a flow diagram illustrating an operating system upgrade according to an embodiment of the present application;

FIG. 5 is a flow diagram illustrating static partition synchronization according to an embodiment of the present application;

FIG. 6 is a flow diagram illustrating static partition synchronization according to an embodiment of the present application;

FIG. 7 is a flow diagram illustrating static partition synchronization according to an embodiment of the present application;

FIG. 8 is a flowchart illustrating an operating system upgrade according to an embodiment of the present application;

FIG. 9 is a flowchart illustrating an operating system upgrade according to an embodiment of the present application;

FIG. 10 is a flowchart illustrating device boot loading according to an embodiment of the present application;

FIG. 11 is a schematic diagram illustrating a device boot loading process according to an embodiment of the present application;

FIG. 12 is a flowchart illustrating device boot loading according to an embodiment of the present application;

FIG. 13 is a flow chart illustrating data modification for a static partition (A) according to an embodiment of the present application;

FIG. 14 is a flowchart illustrating device boot loading according to an embodiment of the present application.

Detailed Description

For better understanding of the technical solutions of the present application, the following detailed descriptions of the embodiments of the present application are provided with reference to the accompanying drawings.

It should be understood that the embodiments described are only a few embodiments of the present application, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The terminology used in the embodiments of the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the examples of this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should be understood that the term "and/or" as used herein is merely one type of associative relationship that describes an associated object, meaning that three types of relationships may exist, e.g., A and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" herein generally indicates that the former and latter related objects are in an "or" relationship.

Aiming at the problem that the equipment cannot be started due to data errors of the operating system, a feasible solution is to construct operating system backup data on the equipment, and in the process of starting the equipment, when the operating system data is loaded incorrectly, the backed-up operating system data can be loaded to ensure the smooth starting of the equipment. However, the backup data occupies a storage space, which compresses a data space that can be freely used by a user, and causes a waste of the storage space.

In order to solve the problem, the data which can be replaced mutually in the data of the operating system is determined by analyzing the storage file structure of the operating system. In the process of starting the equipment, when the data of the operating system is loaded incorrectly, calling the data which can replace the incorrect data for loading, thereby ensuring the smooth starting of the equipment.

Specifically, taking an android system adopting a virtual a/B upgrade mode as an example, fig. 1 is a schematic diagram of a data storage structure of the android system on a terminal device. As shown in fig. 1, the android system data storage area includes a basic partition (Common), a static partition (a), a static partition (B), a dynamic partition (Super), and a user data partition (Userdata).

The user data partition (Userdata) is used for storing personal data of users, such as personal data of APPs installed by the users, pictures, documents and videos stored by the users. The data stored in the base portion is system data that does not participate in the upgrade of the operating system. The static partition (a) and the static partition (B) have structures corresponding to each other, and the subpartition names are distinguished from each other by suffixes _ a and _ B. The static partition (A) comprises bootloader _ a, boot _ a, vendor _ boot _ a, dtbo _ a and vbmeta _ a; the static partition (B) includes bootloader _ B, boot _ B, vendor _ boot _ B, dtbo _ B, vbmeta _ B. The dynamic partition (Super) comprises a plurality of sub-partitions.

At device boot time, it boots from a static partition. For example, a device starts from a static partition (a): sequentially loading a basic partition (Common), a static partition (A) and a dynamic partition (Super); the device starts from the static partition (B): the basic partition (Common), the static partition (B) and the dynamic partition (Super) are loaded in sequence.

In the system storage structure shown in fig. 1, partition structures of the static partition (a) and the static partition (B) are consistent, when data burned in the static partition (a) and the static partition (B) are consistent (for example, in some application scenarios, after a device is installed in a system before leaving a factory, data burned in the static partition (a) and the static partition (B) are consistent), and in the static partition (a) and the static partition (B), corresponding sub-partitions may be replaced with each other.

To sum up, an embodiment of the present application provides an operating system starting method, which is directed to an android system adopting a virtual a/B upgrade mode, and when a sub-partition fails to be loaded during a process of starting and loading a static partition (a), the sub-partition corresponding to the sub-partition in the static partition (B) is tried to be loaded, so that smooth starting of the device is ensured.

Fig. 2 is a flowchart illustrating a device booting process for the system data storage structure shown in fig. 1, where when the device is booted from the static partition (a) (generally, after an operating system is installed before the device leaves a factory, a default device is booted from the static partition (a)), the device is booted according to the flowchart shown in fig. 2.

S200, the device obtains the partition table from a file system (for example, UFS) of the device, and generates a device node to be loaded with the partition, where the device node is path information of the partition.

For example, Universal Flash Storage (UFS) in Master Boot Record (MBR) format. And reading the size and position information of each partition on the UFS from an MBR (master boot sector, the first sector of the UFS, namely 0 cylinder 0 head 1 sector of a C/H/S address) of the UFS to obtain a partition table (Dpt).

Taking a static partition as an example, a device starts from a static partition (a), a to-be-loaded sub-partition of the static partition includes bootloader _ a, boot _ a, vendor _ boot _ a, dtbo _ a, and vbmeta _ a, and a to-be-loaded device node includes:

/dev/block/by-name/bootloader_a；

/dev/block/by-name/boot_a；

/dev/block/by-name/vendor_boot_a；

/dev/block/by-name/dtbo_a；

/dev/block/by-name/vbmeta_a。

it should be noted here that the above description of the device node is only an example description of an actual application scenario. The specific form and the specific content of the device node are not limited in detail in the scheme of the present application.

And carrying out partition loading based on the equipment node of the partition to be loaded acquired in the S200. S202, loading a basic partition (Common).

And loading the bootloader sub-partition of the static partition based on the device node/dev/block/by-name/bootloader _ a (first sub-partition) to be loaded acquired in the S200.

S210, verifying data (first verification operation) under the device node/dev/block/by-name/bootloader _ a.

Specifically, data under the device node/dev/block/by-name/bootloader _ a is read, and mirror integrity and validity check are performed on the read data.

If the verification is successful, S211 is executed, the data under the/dev/block/by-name/bootloader _ a is loaded, and S220 is executed after the data loading is completed.

If the check fails, S212, modifying the device node to be loaded, and modifying the device node to be loaded from/dev/block/by-name/bootloader _ a to/dev/block/by-name/bootloader _ b (second sub-partition) (modifying the suffix of the device node, modifying _ a to _ b).

S213, verifying the data under the device node/dev/block/by-name/bootloader _ b (second verification operation).

If the verification is successful, S214 is executed, the data under the/dev/block/by-name/bootloader _ b is loaded, and S220 is executed after the data loading is completed.

If the verification fails, S201 is executed to restart the device, or a prompt that the device cannot be started is output.

And loading the boot sub-partition of the static partition based on the device node/dev/block/by-name/boot _ a (third sub-partition) to be loaded acquired in the S200.

S220, checking data under the device node/dev/block/by-name/boot _ a.

Specifically, data under the device node/dev/block/by-name/boot _ a is read, and mirror integrity and validity check are performed on the read data.

If the verification is successful, S221 is executed, the data in the/dev/block/by-name/boot _ a is loaded, and S230 is executed after the data loading is completed.

If the check fails, S222 is executed, the device node to be loaded is modified, and the device node to be loaded is modified from/dev/block/by-name/boot _ a to/dev/block/by-name/boot _ b (fourth sub-partition) (the suffix of the device node is modified, and _ a is modified to _ b).

And S223, verifying the data under the device node/dev/block/by-name/boot _ b.

If the verification is successful, S224 is executed, the data under/dev/block/by-name/boot _ b is loaded, and S230 is executed after the data loading is completed.

And loading the vector _ boot sub-partition of the static partition based on the device node/dev/block/by-name/vector _ boot _ a to be loaded acquired in the S200.

And S230, checking data under the device node/dev/block/by-name/vector _ boot _ a.

Specifically, data under the device node/dev/block/by-name/vector _ boot _ a is read, and mirror integrity and validity check are performed on the read data.

If the verification is successful, S231 is executed, the data in the/dev/block/by-name/vector _ boot _ a is loaded, and S240 is executed after the data loading is completed.

If the check fails, S232 is executed, the device node to be loaded is modified, and the device node to be loaded is modified from/dev/block/by-name/vector _ boot _ a to/dev/block/by-name/vector _ boot _ b (the suffix of the device node is modified, and _ a is modified to _ b).

S233, checking data under the device node/dev/block/by-name/vector _ boot _ b.

If the verification is successful, S234 is executed to load/dev/block/by-name/vector _ boot _ b data, and S240 is executed after the data loading is completed.

And loading the dtbo sub-partition of the static partition based on the device node/dev/block/by-name/dtbo _ a to be loaded acquired in the S200.

S240, checking data under the device node/dev/block/by-name/dtbo _ a.

Specifically, data under the device node/dev/block/by-name/dtbo _ a is read, and mirror integrity and validity check are performed on the read data.

If the verification is successful, S241 is executed, the data in the/dev/block/by-name/dtbo _ a is loaded, and S250 is executed after the data loading is completed.

If the check fails, S242 is executed, the device node to be loaded is modified, and the device node to be loaded is modified from/dev/block/by-name/dtbo _ a to/dev/block/by-name/dtbo _ b (the suffix of the device node is modified, and _ a is modified to _ b).

S243, checking the data under the device node/dev/block/by-name/dtbo _ b.

If the verification is successful, S244 is executed, the data under the/dev/block/by-name/dtbo _ b is loaded, and S250 is executed after the data loading is completed.

And loading the vbmeta sub-partition of the static partition based on the device node/dev/block/by-name/vbmeta _ a to be loaded acquired in the S200.

And S250, checking data under the equipment node/dev/block/by-name/vbmeta _ a.

Specifically, data under the device node/dev/block/by-name/vbmeta _ a is read, and mirror integrity and validity check are performed on the read data.

If the verification is successful, S251 is executed, the data under the/dev/block/by-name/vbmeta _ a is loaded, and S260 is executed after the data loading is completed.

If the check fails, S252 is executed, the device node to be loaded is modified, and the device node to be loaded is modified from/dev/block/by-name/vbmeta _ a to/dev/block/by-name/vbmeta _ b (the suffix of the device node is modified, and _ a is modified to _ b).

And S253, checking data under the equipment node/dev/block/by-name/vbmeta _ a.

If the verification is successful, S254 is executed, the data under the/dev/block/by-name/vbmeta _ a is loaded, and S260 is executed after the data loading is completed.

If the verification fails, S201 is executed to restart the device, or a prompt that the device cannot be started is output. S260, loading a dynamic partition (Super); and S270, successfully starting the equipment.

Based on the method flow shown in fig. 2, when the sub-partition in the static partition (a) fails to be loaded, the corresponding sub-partition in the static partition (B) is loaded to ensure that the device is started successfully, so that the success rate of starting the device is greatly increased.

For example, fig. 3 is a schematic diagram illustrating a device boot loading process according to an embodiment of the present application. In an application scenario, data errors exist in the vector _ boot _ a and the vbmeta _ a in the static partition (a). The method flow based on the embodiment shown in fig. 2 starts the device, as shown in fig. 3:

loading a base partition (Common);

checking the bootloader _ a sub-partition (success), and loading the bootloader _ a sub-partition;

checking the boot _ a sub-partition (success), and loading the boot _ a sub-partition (success);

checking the vector _ boot _ a child partition (failure);

checking the vendor _ boot _ b sub-partition (success), and loading the vendor _ boot _ b sub-partition;

checking the dtbo _ a sub-partition (success), and loading the dtbo _ a sub-partition;

checking the vbmeta _ a child partition (failure);

checking the vbmeta _ b sub-partition (success), and loading the vbmeta _ b sub-partition;

dynamic partitions (Super) are loaded.

Finally, the device boots the loaded operating system data from the static partition (a) as: a base partition (Common), a bootloader _ a sub-partition, a boot _ a sub-partition, a vendor _ boot _ b sub-partition, a dtbo _ a sub-partition, a vbmeta _ b sub-partition, and a dynamic partition (Super).

Further, after the device leaves the factory, in an actual application scenario, the device still has an upgrade requirement. Fig. 4 is a flowchart illustrating an operating system upgrade performed on the system data storage structure shown in fig. 1, where when a device is currently booted from a static partition (a), the device implements the upgrade of the operating system according to the flowchart shown in fig. 4.

S400, the device loads a basic partition (Common), a static partition (A) and a dynamic partition (Super) in sequence and starts from the static partition (A);

s410, the equipment acquires an operating system upgrade installation package;

for example, in a possible implementation scheme, the device periodically initiates a packet searching request to the packet searching server, where the packet searching request includes a version number (e.g., version 1.1) of an operating system currently running by the device; the packet searching server searches whether an operating system installation packet (such as version 1.2) with an updated version number exists at present according to the operating system version number in the packet searching request; when the operating system installation package with the updated version exists, the package searching server feeds back a download address of the operating system upgrading installation package (for example, the operating system upgrading package upgraded from version 1.1 to version 1.2) to the equipment; the equipment downloads the operating system upgrading installation package according to the downloading address of the operating system upgrading installation package, and stores the operating system upgrading installation package into a user data partition (Userdata).

S420, the device reads the operating system upgrading installation package stored in the S410 from a user data partition (Userdata), and performs data writing operation on the static partition (B) according to the operating system upgrading installation package to upgrade the static partition;

for example, the data of the static partition of version 1.2 is contained in the operating system upgrade installation package, and the device overwrites the data of the static partition of version 1.2 in the static partition (B).

And S430, the equipment creates a virtual dynamic partition in a user data partition (Userdata) according to the operating system upgrading installation package, and writes upgrading data of the dynamic partition (Super) into the virtual dynamic partition. For example, the data of the dynamic partition of version 1.2 is contained in the operating system upgrade installation package, and the device writes the data of the dynamic partition (Super) of version 1.2 in the virtual dynamic partition.

Furthermore, in the virtual A/B upgrading scheme, an incremental upgrading mode is adopted for dynamic partitions (Super). In the upgrading process, all files of the dynamic partition (Super) of the new version after upgrading are not stored in the virtual dynamic partition of the user data partition (Userdata), but the upgrading result of the data needing to be upgraded in the dynamic partition (Super) of the old version after upgrading is stored in the virtual dynamic partition of the user data partition (Userdata). That is, the virtual dynamic partition of the user data partition (Userdata) stores therein update data of the dynamic partition.

Taking a system sub-partition as an example, suppose that in version 1.1, data in the system sub-partition can be divided into two parts, system1 and system 2. The upgrade from version 1.1 to version 1.2, no change in data system2 occurred and data system1 was upgraded to system 3. Then, in S430, the device creates a virtual dynamic partition in the user data partition (Userdata) and writes the data system3 in the virtual dynamic partition.

For example, a system incremental upgrade installation package with version 1.1 upgraded to version 1.2 contains dynamic partition (Super) update data with version 1.1 upgraded to version 1.2, which contains data system 3.

Further, in the virtual a/B upgrade scheme, incremental upgrade of dynamic partitions (Super) is implemented based on snapshot technology (snapshot). Specifically, in a virtual dynamic partition of a user data partition (Userdata), a Copy-On-Write (COW) file is used to store upgrade data of a dynamic partition (Super).

Specifically, the upgrade data of the dynamic partition (Super) stored in the user data partition (Userdata) includes a plurality of COW files, each COW file corresponds to a sub-partition of the dynamic partition (Super), and the name of the COW file corresponds to the sub-partition of the dynamic partition (Super).

In the os upgrade installation package acquired in S410, the COW file of the upgrade data of the dynamic partition (Super) is compressed and stored in the form of binary code. In the operating system upgrade installation package, each COW file is named according to the dynamic partition (Super) child partition to which it is directed. For example, the COW file for a system child partition is named system-COW-img.img.0000.

In S430, the device unpacks the os upgrade installation package to obtain all the COW files, and attaches a/B partition flags to each COW file. Specifically, when the device is currently started from the static partition (a), it can be understood that the dynamic partition (Super) loaded by the device currently running the operating system is the dynamic partition (a). When the operating system is upgraded, the virtual dynamic partition created in the user data partition (Userdata) is for dynamic partition (B). Therefore, the name flag _ B of the corresponding dynamic partition (B) is attached to the COW file. For example, system _ b-cow-img.img.0000 is generated for system-cow-img.0000 to attach _ b.

Further, in S430, an Update folder is created in the user data partition (Userdata), and the renamed COW file is saved under the Update folder. For example, in an application scenario, after writing a COW file into a user data partition (Userdata), an Update folder of the user data partition (Userdata) includes the following files:

system_b-cow-img.img.0000；

system_ext_b-cow-img.img.0000；

vendor_b-cow-img.img.0000；

product_b-cow-img.img.0000；

cust_b-cow-img.img.0000；

odm_b-cow-img.img.0000。

specifically, the COW file includes a COW file map (snapshot map) of the COW file itself and upgrade data.

The COW file map (snapshot) corresponds to a file map of a child partition of the dynamic partition (Super) to which the COW file is directed. The file map of the sub-partition of the dynamic partition (Super) is used for describing all files in the sub-partition of the dynamic partition (Super) and saving addresses of the files of the operating system of the current version (version before the upgrade, for example, version 1.1).

The upgrading data in the COW file is a file which is updated in the sub-partition data of the new version compared with the sub-partition data of the current version; the COW file map of the COW file is used for describing the corresponding relation between the updated file and the file in the current version of the sub-partition and the storage address of the updated file.

Based on the file map of the sub-partition of the dynamic partition (Super) and the COW file map in the COW file, the upgrade data in the COW file can be used for replacing the corresponding file in the sub-partition of the dynamic partition (Super), so that the upgrade of the data of the dynamic partition (Super) is realized. Specifically, when the file map of the sub-partition of the dynamic partition (Super) needs to be acquired, a snapshot operation may be performed on the data of the sub-partition of the dynamic partition (Super) based on the snapshot to generate the file map of the sub-partition of the dynamic partition (Super). Or, when the operating system upgrade installation package is manufactured, a file map of a sub-partition of a dynamic partition (Super) may be generated in advance, and the file map may be added to the COW file.

Taking a system sub-partition as an example, suppose that the system sub-partition stores data according to the following path:

/system/app/A0.XXX；

/system/app/A1.XXX；

/system/app/A2.XXX；

/system/B0.XXX；

/system/B1.XXX；

/system/user/C0.XXX；

/system/user/C1.XXX；

/system/user/C2.XXX；

/system/user/C3.XXX。

the file map for a system sub-partition may be:

/system/app/A0.XXX：024010～024013；

/system/app/A1.XXX：024014～024017；

/system/app/A2.XXX：024018～024020；

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

/system/user/C0.XXX：024029～024032；

/system/user/C1.XXX：024033～024035；

/system/user/C2.XXX：024036～024040；

/system/user/C3.XXX：024041～024044。

the value after the file name (e.g.,/system/app/A0.XXX: 024010-024013 in 024010-024013) is the physical storage address (block address) of the file in the system sub-partition of the dynamic partition (Super).

Assume that the current operating system upgrade requires updating data/system/app/A2. XXX and/system/user/C2. XXX.

Can be regarded as:

system/app/A2.XXX and system/user/C2.XXX are system1 portions of system sub-partition data;

system/app/A0.XXX,/system/app/A1.XXX,/system/B0.XXX,/system/B1.XXX,/system/user/C0.XXX,/system/user/C1.XXX, and/system/user/C3.XXX are parts of system2 for system sub-partition data.

Then the COW file for the system sub-partition (system _ b-COW-img.img.0000) contains the latest version/system/app/a 2.xxx and/system/user/c 2.xxx.

It can be seen that the latest version/system/app/A2. XXX and/system/user/C2. XXX is system 3. The upgrade target is to update system1 with system 3.

When the size of the update data in the COW file is consistent with the size of the original data to be updated, and the storage location of the update data in the COW file in the child partition after the data update is consistent with the storage location of the original data to be updated in the child partition, the COW file map of the COW file (system _ b-COW-img.img.0000) itself may be:

/system/app/A2.XXX：

map1 (address of data to be updated in the original super partition): start address start: 024018 (offset from the system start address); offset size: 2 (i.e., data of address segments 024018-024020)

Map2 (address of update data stored in cow file): start address start: 045033 (offset from the start address of the cow file storage); offset size: 2 (i.e., data in address segments 045033-045035);

/system/user/C2.XXX：

map1 (address of data to be updated in the original super partition): start address start: 024036 (offset from the system start address); offset size: 4 (i.e. data of 024036 ~ 024040 address field)

Map2 (address of update data stored in cow file): start address start: 045036 (offset from the start address of the cow file storage); offset size: 4 (i.e., data in address segments 045036-045040).

When the size of the update data in the COW file is not consistent with the size of the original data to be updated, the COW file map of the COW file (system _ b-COW-img.img.0000) itself may be:

/system/app/A2.XXX：

map1.1 (address of data to be updated in original super partition): start address start: 024018 (offset from the system start address); offset size: 2 (i.e., data of address segments 024018-024020)

Map2.1 (the address of the update data stored in the cow file that needs to cover the Map1.1 address): start address start: 045033 (offset from the start address of the cow file storage); offset size: 2 (i.e., data in address segments 045033-045035);

map1.2 (address to be written in the original super partition of the part of the update data in the cow file exceeding the size of the data to be updated): start address start: 025018 (offset from system start address); offset size: 1 (i.e. 025018 ~ 025020 address field data)

Map2.2 (the address of the update data stored in the cow file that needs to cover the Map1.2 address): start address start: 046033 (offset from the start address of the cow file storage); offset size: 2 (i.e., data in address segments 046033-046035).

In the description of the specification that follows, for convenience of description, an application scenario will be illustrated only when the size of the update data in the COW file coincides with the size of the original data to be updated, and the storage location of the update data in the COW file after data update in the sub-partition coincides with the storage location of the original data to be updated in the sub-partition.

In the above example, the address fields (045033-045035 and 045036-045040) are the physical storage addresses (block addresses) of the latest version of/system/app/A2.XXX and/system/user/C2.XXX in the user data partition (Userdata) in the COW file (system _ b-COW-img.img.0000).

Thus, if A2.XXX on the addresses 024018-024020 is replaced by A2.XXX on the addresses 045033-045035, and C2.XXX on the addresses 024036-024040 is replaced by C2.XXX on the addresses 045036-045040, the data upgrading of the system sub-partition of the dynamic partition (Super) can be completed.

Further, in S430, after the COW file is written into the user data partition (Userdata), the dynamic partition (Super) + COW file needs to be integrally checked, the validity of the dynamic partition (Super) + COW file is checked, and whether the synthesis result of the current version of the dynamic partition (Super) data + the COW file is the new version of the dynamic partition (Super) data is verified.

Specifically, taking upgrading from the version 1.1 to the version 1.3 as an example, calculating a hash value of a synthesis result of data (data which is not changed from the version 1.1 to the version 1.2) which does not need to be upgraded in the dynamic partition (Super) and upgrading data (data which is required to be upgraded from the version 1.1 to the version 1.2) in the COW file, judging whether the hash value is consistent with a hash value of complete data of the dynamic partition (Super) in the version 1.3, and if so, indicating that the COW file is valid; if not, indicating that the COW file is invalid and the upgrading fails, interrupting the upgrading process and reporting errors; wherein, the hash value of the complete data of the dynamic partition (Super) in the 1.3 version is stored in the operating system upgrade installation package.

Specifically, in the checking process, dynamic partition (Super) + COW files are merged based on snapshot. In the realization process of snapshot, the combination of the dynamic partition (Super) and the COW file is not the combination in the physical sense, but the whole file map of the sub-partition in the COW file and the COW file map of the COW file are combined to generate the file map of the sub-partition data of the new version.

For example, a file map that sub-partitions the system:

/system/app/A0.XXX：024010～024013；

/system/app/A1.XXX：024014～024017；

/system/app/A2.XXX：024018～024020；

/system/B0.XXX：024021～024026；

/system/B1.XXX：024027～024028；

/system/user/C0.XXX：024029～024032；

/system/user/C1.XXX：024033～024035；

/system/user/C2.XXX：024036～024040；

/system/user/C3.XXX：024041～024044。

and COW file map:

/system/app/A2.XXX：

map 1: address start: 024018, respectively; size: 2 (i.e., data of address segments 024018-024020)

Map 2: address start: 045033, respectively; size: 2 (i.e., data in address segments 045033-045035);

/system/user/C2.XXX：

map 1: address start: 024036, respectively; size: 4 (i.e. data of 024036 ~ 024040 address field)

Map 2: address start: 045036, respectively; size: 4 (i.e., data in address segments 045036-045040).

And (6) merging. Then get the new version of the file map for the system sub-partition:

/system/app/A0.XXX：024010～024013；

(Direction to A0.XXX in dynamic partition (Super)/under system/app)

/system/app/A1.XXX：024014～024017；

(Direction to A1.XXX in dynamic partition (Super)/under system/app)

/system/app/A2.XXX：045033～045035；

(points to A2.XXX in user data partition (Userdata)/Update/system _ b-cow-img.img.0000)

/system/B0.XXX：024021～024026；

(Direction dynamic zoning (Super) in/under system B0.XXX)

/system/B1.XXX：024027～024028；

(Direction dynamic zoning (Super) in/under system B1.XXX)

/system/user/C0.XXX：024029～024032；

(Direction dynamic partitioning (Super) Medium/System/user C0.XXX)

/system/user/C1.XXX：024033～024035；

(Direction dynamic partitioning (Super) Medium/System/user C1.XXX)

/system/user/C2.XXX：045036～045040；

(pointing to C2.XXX in user data partition (Userdata)/Update/system _ b-cow-img.img.0000)

/system/user/C3.XXX：024041～024044。

(Direction dynamic partitioning (Super) Medium/System/user under C3.XXX)

In the file map of the new version of the system subpartition, the saved address of/system/app/A2. XXX points not to/system/app/A2. XXX on the dynamic partition (Super) on the memory, but to A2.XXX in system _ b-cow-img.img.0000 in the user data partition (Userdata) on the memory; the save address of/system/user/C2. XXX does not point to/system/user/C2. XXX on the dynamic partition (Super) on memory, but to C2.XXX in system _ b-cow-img. img.0000 in the user data partition (Userdata) on memory.

In the verification process, according to the synthesis mode, obtaining new version file maps of all sub-partitions of the dynamic partition (Super) (if the corresponding COW file of a certain sub-partition is not written in the user data partition (Userdata), directly taking the file map of the sub-partition as the new version file map). And combining the new versions of the file maps of all the sub partitions to generate a new version of a file system of the dynamic partition (Super).

And reading data based on the file system of the new version of the dynamic partition (Super), reading all files contained in the file system of the new version of the dynamic partition (Super) and calculating a hash value.

When the COW file is valid, the disk-down status information in the metadata partition (/ metadata) of the base partition (Common) is changed from "dropped disk (merged)" to "not dropped disk (wait for merge)". The disk-drop status information is used to indicate whether there is a COW file that needs to be dropped to a dynamic partition (Super) currently. Specifically, the landing status information includes an overall identification for the dynamic partition (Super) and a sub-partition identification for each sub-partition. When the whole is marked as 'fallen disk (merged'), all the sub-partitions representing the dynamic partition (Super) do not need to carry out the fallen disk operation; when the whole is marked as 'not-dropped-disk (wait for merge'), one or more sub-partitions representing dynamic partitions (Super) need to be subjected to a disk-dropping operation; when the sub-partition is identified as "dropped-disk" (merged), it represents that the sub-partition does not need to perform a disk-dropping operation; when a sub-partition is identified as "wait for merge", it represents that the sub-partition needs to perform a disk-drop operation.

S431, the boot sequence of the device is changed from boot from the static partition (a) to boot from the static partition (B).

For example, a Boot sequence flag of a Master Boot Record (MBR) is rewritten, and the Boot sequence flag is rewritten from a to B. After the equipment is powered on, when the equipment reads that the starting sequence identifier is A, the equipment is started from the static partition (A), and the static partition (A) is loaded in the starting process; when the device reads that the starting sequence identifier is B, the device starts from the static partition (B), and the static partition (B) is loaded in the starting process.

And S432, restarting the equipment. And exiting the current operating system, cutting off the power supply of the equipment, and starting the power supply of the equipment again.

S440, the device loads the basic partition (Common) and the static partition (B) in sequence.

In S440, the device reads the startup flag in the base partition (Common). The boot flag in the base partition (Common) is (B), and the device loads the static partition (B) after loading the base partition (Common), booting from the static partition (B).

S441, the device loads the virtual dynamic partition of the dynamic partition (Super) and the user data partition (Userdata).

Specifically, the device reads the disk-dropping state information in the metadata (/ metadata), determines whether a COW file needs to be retrieved from a specified path of a user data partition (Userdata) or not based on the disk-dropping state information, and loads a dynamic partition (Super) and the COW file by using snapshot merging.

Further, in S441, the device does not load all COW files in the dynamic partition (Super) and the user data partition (Userdata), but loads corresponding files according to the operating system operating requirements. Specifically, in S441, the device determines a file to be loaded according to the operating system operating requirement, and extracts a corresponding file from a COW file in a dynamic partition (Super) or a virtual dynamic partition based on a snapshot to load the file.

Specifically, in S441, when the corresponding COW file first exists in the sub-partition of the dynamic partition (Super), a new version of the file map of each sub-partition of the dynamic partition (Super) is generated based on the snapshot. The process of generating a new version of the file map may refer to S430. The device determines files needing to be loaded according to the operation requirements of the operating system, and loads the files based on the new version file map of the dynamic partition (Super) sub-partition.

For example, an operating system runtime requirement loads all data in a directory user (/ system/user) under a system sub-partition. The device reads the disk-dropping state information in the metadata (/ metadata), wherein the child partition identification of the system child partition in the disk-dropping state information is 'disk-not-dropped (merge)', therefore, the device searches the COW file in the user data partition (Userdata)/Update under the Update, searches the COW file system _ b-COW-img.img.0000 under the Update, and generates a new version file map of the system child partition according to the file map of the COW file in the system _ b-COW-img.img.0000 based on the snapshot. And loading data according to the storage addresses of all files in the new version file map of the system sub-partition/under the system/user, for example, according to the storage addresses of all files in the new version file map of the system sub-partition:

/system/user/C0.XXX：024029～024032；

/system/user/C1.XXX：024033～024035；

/system/user/C2.XXX：045036～045040；

/system/user/C3.XXX：024041～024044。

load C0.XXX at addresses 024029-024032, C1.XXX at addresses 024033-024035, C2.XXX at addresses 045036-045040, and C3.XXX at addresses 024041-024044.

Further, when all data in the directory user (/ system/user) under the system sub-partition is loaded, when the sub-partition of the system sub-partition is identified as "landed" in the landing state information, the device does not search the COW file in the user data partition (Userdata)/under Update, but directly loads all data in the directory user (/ system/user) under the system sub-partition.

Further, when all data in the user (/ system/user) under the system sub-partition is loaded, when the sub-partition of the system sub-partition in the drop state information is identified as "no-drop (wait for means)", if the device does not search the COW file corresponding to the system sub-partition in the user data partition (user data)/under Update, it indicates that the data write error (COW file write error or drop state information write error) occurs in the upgrade process, and at this time, the device rolls back the system and reports an error.

Further, in S441, before loading the file, the device needs to check the loaded file. Unlike S430, in S441, the dynamic partition (Super) + COW file is not authenticated as a whole, but only the file that needs to be loaded is authenticated. For example, checking is performed based on dmverity (dm-verity is a target of dm (device map), which is a virtual block device dedicated to checking of file systems). And if the verification is successful, loading the file, and if the verification is failed, restarting the equipment, rolling back the system or trying to load the file again.

S450, the equipment is started successfully, and a user interaction interface is entered.

S451, the device destages the data of the virtual dynamic partition to the dynamic partition (Super) in the background.

In the description of the present application, the disk-down operation refers to writing a dynamic partition (Super) upgrade file (COW file) stored in a virtual dynamic partition on a user data partition (Userdata) into a dynamic partition (Super) in an upgrade process of an operating system, so that the file of the dynamic partition (Super) completes data upgrade, and the device can be started only by loading the dynamic partition (Super) without loading the dynamic partition (Super) and the virtual dynamic partition when the device is started next time.

Specifically, the device performs a startup broadcast after being successfully started, and starts an upgrade process after the startup broadcast. The upgrade process reads the disk-down status information in the metadata (/ metadata) of the base partition (Common), and if the disk-down status information is "dropped" the device enters a normal operation mode.

If the disk-dropping status information is 'not-dropped disk (wait for merge'), the upgrading process drops the COW file in the user data partition (Userdata) into the dynamic partition (Super).

Specifically, the upgrade process writes the upgrade data in the COW file in the user data partition (Userdata) into a corresponding address in the dynamic partition (Super), so that all the data in the dynamic partition (Super) are upgraded new version data.

For example,/system/app/a 2.xxx in a file map based on system sub-partitions: 024018-024020 and/system/app/A2.XXX in the COW file map: 045033-045035, writing the data at addresses 045033-045035 to addresses 024014-024017; system/user/c2.xxx in system sub-partition based file map: 024036-024040 and/system/user/C2.XXX in COW file map: 045036-045040, write the data at addresses 045036-045040 to addresses 024036-024040.

After that, the upgrading process deletes the COW file in the user data partition (Userdata) and returns the storage space to the user data partition (Userdata); and, the disk-drop status information in the metadata (/ metadata) of the base partition (Common) is changed from "not disk-dropped (wait for merge)" to "dropped (merged)".

In S420, the data operation of the static partition upgrade is directed to the operating system data in the static partition (B), which does not affect the operating system data of the currently started static partition (a); in S430, the data operation of the dynamic partition upgrade is performed on the virtual dynamic partition created in the user data partition (Userdata), which does not affect the currently mounted dynamic partition (Super). Therefore, in the whole process of upgrading the operating system, the user can normally use the equipment; after S431 is completed, the device does not need to be restarted immediately, and a user may select a restart time by himself; therefore, the upgrading process of the operating system does not influence the normal mobile phone operation of the user, and the user experience is greatly improved. Further, for the dynamic partition (Super), a virtual dynamic partition is created on the user data partition (Userdata) only when upgrading is needed, so that the utilization rate of the data storage space is effectively improved.

Based on the system upgrade flow shown in fig. 4, after the system version is upgraded, a system version difference exists between the data of the static partition (a) and the data of the static partition (B). For example, assuming that the static partition (a) corresponds to the operating system of version 1.1, the device starts up the operating system of running version 1.1 from the static partition (a); when the operating system is upgraded to 1.2, according to the flow shown in fig. 2, the operating system is upgraded from the static partition (B) to the version 1.2, and the operating system running the version 1.2 is started from the static partition (B) after the device is restarted; at this time, the device runs the version 1.2 os, the static partition (a) corresponds to the version 1.1 os, and the static partition (B) corresponds to the version 1.2 os.

Generally, when an operating system is upgraded from one version to another version, the data of the operating system is not changed as a whole, but only a certain part of the data is changed. That is, when the operating system is upgraded from one version to another version, the data in the static partition may not be modified, i.e., the data in the static partition in the operating system of version 1.1 may be the same as the data in the static partition in the operating system of version 1.2. Alternatively, when the operating system is upgraded from one version to another, the data in the static partition may only be modified in a portion, i.e., a portion of the data in the static partition in the operating system of version 1.1 may be the same as a portion of the data in the static partition in the operating system of version 1.2.

In the system memory structure shown in fig. 1, the partition structures of the static partition (a) and the static partition (B) are consistent. Then, when the static partition (a) corresponds to the operating system of version 1.1 and the static partition (B) corresponds to the operating system of version 1.2, there may be a case where one or more sub-partitions in the static partition (a) have the same data as the corresponding one or more sub-partitions in the static partition (B). At this time, between the static partition (a) and the static partition (B), there is a case where one or more sub-partitions may be substituted for each other.

Further, since in the system memory structure shown in fig. 1, the partition structure of the static partition (a) is consistent with that of the static partition (B); the functions of the static partition (a) and the corresponding sub-partitions of the static partition (B) are consistent during device boot. Thus, even if the corresponding inter-child data of static partition (A) and static partition (B) are inconsistent due to an operating system upgrade, the functionality implemented when the child partitions are loaded is similar when no change in functionality is made by a change in data, and therefore, the child partitions can be approximately replaced by each other.

Thus, in an application scenario, the device initially boots from the static partition (a), after which the device upgrades the operating system based on the process shown in fig. 4, upgrades the data of the static partition (B) and boots from the static partition (B).

After that, after the device is used for a period of time (during which the device remains booted from the static partition (B)), if the static partition (B) is damaged, and data errors exist in one or more sub-partitions in the static partition (B), at this time, still referring to the embodiment shown in fig. 2, in the process of booting the device from the static partition (B), smooth booting of the device is achieved by loading one or more sub-partitions in the static partition (a), so as to improve the success rate of booting the device.

Further, in order to further improve the success rate of starting the device, in an application scenario, the device initially starts from the static partition (a), then the device upgrades the operating system based on the flow shown in fig. 4, upgrades the data of the static partition (B) and from the static partition (B), and then (after S451), the device synchronizes the data of the static partition (B) to the static partition (a), so as to ensure that the data between the corresponding sub-partitions in the static partition (a) and the static partition (B) are consistent, and the corresponding sub-partitions can be replaced by each other. At this time, the data in the static partition (B) and the data in the static partition (a) can support the smooth startup of the device.

After that, after the device is used for a period of time during which the device remains booted from the static partition (B), if the static partition (B) is corrupted, one or more sub-partitions in the static partition (B) have data errors. In the process of starting the device from the static partition (B), with reference to the embodiment shown in fig. 2, the device is started successfully by loading one or more sub-partitions in the static partition (a), so as to improve the success rate of starting the device.

Further, the present application does not specifically limit the specific implementation manner of synchronizing the data of the static partition (B) to the static partition (a), and those skilled in the art may implement data synchronization in various feasible implementation manners. The following describes a specific implementation flow of synchronizing data of the static partition (B) to the static partition (a) by using a specific embodiment.

In S420, the device writes the data of the static partition in the operating system upgrade installation package to the static partition (B). Therefore, if the same operating system upgrade installation package is used, the data of the static partition in the operating system upgrade installation package is written into the static partition (a), so that the data in the static partition (a) is consistent with the data in the static partition (B).

Thus, in an embodiment, synchronizing data of the static partition (B) to the static partition (a) comprises: and reading the operating system upgrade installation package stored in the step S410 from the user data partition (Userdata), and writing the data of the static partition in the operating system upgrade installation package into the static partition (A).

Further, the static partition (a) and the static partition (B) are completely identical in partition structure and partition size. Thus, the data of the static partition (a) may be mirrored directly to the static partition (B), or alternatively, the data of the static partition (B) may be mirrored to the static partition (a).

FIG. 5 is a flow diagram illustrating one implementation of static partition synchronization. The terminal device executes the following flow as shown in fig. 4 to achieve data synchronization of the static partition (B) to the static partition (a).

S500, reading all data in the static partition (B), and packaging and compressing the data to prepare a mirror image file B;

and S510, unpacking the mirror image file B and then restoring the mirror image file B to the static partition (A), so that the data of the static partition (B) is overwritten to the static partition (A).

Further, the static partition (a) is consistent in partition structure with the static partition (B), which contains the same sub-partitions. Therefore, the data in the static partition (B) can be synchronized to the static partition (A) by overwriting the file of each sub-partition in the static partition (B) into the corresponding sub-partition in the static partition (A).

FIG. 6 is a flow diagram illustrating one implementation of static partition synchronization. The terminal device executes the following flow as shown in fig. 6 to achieve data synchronization of the static partition (B) to the static partition (a).

S600, reading parameters related to the partition table on the device memory (the parameters are pre-stored in the device when the device leaves the factory), and synthesizing a total partition table of the memory.

S610, reading all static sub-partitions with suffix name _ B from the total partition table, and generating a list 1 for describing each sub-partition of the static partition (B), wherein the list 1 comprises the name and the address of each sub-partition in the static partition (B). For example:

numbering	Sub-partition name	Sub-partition address (File Path)	Is selected to be in a selected state
				1	bootloader_b	/dev/block/by-name/bootloader_b	0
2	boot_b	/dev/block/by-name/boot_b	0
				3	vendor_boot_b	/dev/block/by-name/vendor_boot_b	0
4	dtbo_b	/dev/block/by-name/dtbo_b	0
				5	vbmeta_b	/dev/block/by-name/vbmeta_b	0

TABLE 1

S620, reading all static sub-partitions with suffix names _ a from the total partition table, and generating a list 2 for describing each sub-partition of the static partition (A), wherein the list 2 comprises the name and the address of each sub-partition in the static partition (A). For example:

numbering	Sub-partition name	Sub-partition address (File Path)
			1	bootloader_a	/dev/block/by-name/bootloader_a
2	boot_a	/dev/block/by-name/boot_a
			3	vendor_boot_a	/dev/block/by-name/vendor_boot_a
4	dtbo_a	/dev/block/by-name/dtbo_a
			5	vbmeta_a	/dev/block/by-name/vbmeta_a

TABLE 2

It should be noted that, in table 1 and table 2, the address of the sub-partition is referred to in a file path manner, and in an actual application scenario, a person skilled in the art may use a variety of different manners to describe the address of the sub-partition. For example, a linear address description is used.

S630, select an unselected sub-partition (first sub-partition) in the list 1, and obtain the name (first sub-partition name) and address (first file path) of the sub-partition.

Specifically, none of the sub-partitions in list 1 were selected prior to S630. In S630, the sub-partitions may be sequentially selected according to the arrangement order (number order) of the sub-partitions in the list 1, or may be randomly selected from all the sub-partitions that are not selected.

Further, after a sub-partition is selected, the sub-partition is marked to subsequently confirm whether the sub-partition has been selected. For example, as shown in table 1, a selected state column is added to table 1, the initial value of the selected state is 0, and if a sub-partition is selected, the selected state is modified to 1.

S640, carrying out suffix removal matching on the selected sub-partition in the S630 and each sub-partition in the list 2; determining a sub-partition (second sub-partition name) in the list 2, which is consistent with the name of the sub-partition selected in the step S630 after the suffix is removed, and a sub-partition address (second file path) corresponding to the second sub-partition name in the list 2;

s641, reading data in the first file path;

and S642, overwriting the read data to a second file path.

S650, judging whether the unselected sub-partitions exist in the list 1;

if yes, returning to the step S630, and reselecting the first sub-partition;

if not, the static partition synchronization ends.

Taking table 1 and table 2 as an example, in an application scenario, the device executes the following processes:

selecting a first sub-partition (bootloader _ b sub-partition with the number 1) with the selected state of 0 in the table 1, and modifying the selected state of the number 1 into 1;

using bootloader _ b to perform suffix removal matching in all the sub-partition names in the table 2, wherein bootloader _ a and bootloader _ b are consistent after respectively removing _ a and _ b, so that bootloader _ a is matched according to bootloader _ b;

reading a file path/dev/block/by-name/bootloader _ b corresponding to bootloader _ b from the table 1;

reading a file path/dev/block/by-name/bootloader _ a corresponding to bootloader _ a from the table 2;

reading data under the/dev/block/by-name/bootloader _ b, and overwriting the read data to the/dev/block/by-name/bootloader _ a;

the sub-partition with the selected state of 0 still exists in table 1, the first sub-partition with the selected state of 0 in table 1 (boot _ b sub-partition with the number of 2) is selected, and the selected state of the number 2 is modified into 1;

suffix removal matching is carried out on all the sub-partition names in the table 2 by using the boot _ b, and the boot _ a and the boot _ b are consistent after the removal of the _ a and the _ b respectively, so that the boot _ a is matched according to the boot _ b;

reading a file path/dev/block/by-name/boot _ b corresponding to boot _ b from the table 1;

reading a file path/dev/block/by-name/boot _ a corresponding to boot _ a from the table 2;

reading data under the/dev/block/by-name/boot _ b, and overwriting the read data to the/dev/block/by-name/boot _ a;

the sub-partition with the selected state of 0 still exists in table 1, the first sub-partition with the selected state of 0 (the vector _ boot _ b sub-partition with the number of 3) in table 1 is selected, and the selected state of the number of 3 is modified into 1;

using the vector _ boot _ b to perform suffix removal matching on all the sub-partition names in the table 2, wherein the vector _ boot _ a and the vector _ boot _ b are consistent after removing the _ a and the _ b respectively, so that the vector _ boot _ a is matched according to the vector _ boot _ b;

reading a file path/dev/block/by-name/vendor _ boot _ b corresponding to the vendor _ boot _ b from the table 1;

reading a file path/dev/block/by-name/vendor _ boot _ a corresponding to the vendor _ boot _ a from the table 2;

reading data under the/dev/block/by-name/video _ boot _ b, and overwriting the read data to the/dev/block/by-name/video _ boot _ a;

the sub-partition with the selected state of 0 still exists in table 1, the first sub-partition with the selected state of 0 in table 1 (dtbo _ b sub-partition with the number 4) is selected, and the selected state of the number 4 is modified to be 1;

suffix removal matching is performed on all sub-partition names in table 2 by using dtbo _ b, and dtbo _ a and dtbo _ b are consistent after removing _ a and _ b respectively, so that dtbo _ a is matched according to dtbo _ b;

reading a file path/dev/block/by-name/dtbo _ b corresponding to dtbo _ b from the table 1;

reading a file path/dev/block/by-name/dtbo _ a corresponding to the vector _ boot _ a from the table 2;

reading data under the/dev/block/by-name/dtbo _ b, and overwriting the read data to the/dev/block/by-name/dtbo _ a;

the sub-partition with the selected state of 0 still exists in table 1, the first sub-partition with the selected state of 0 in table 1 (vbmeta _ b sub-partition with the number 5) is selected, and the selected state of the number 5 is modified to be 1;

suffix matching is performed on all the sub-partition names in the table 2 by using vbmeta _ b, and vbmeta _ a and vbmeta _ b are consistent after removing _ a and _ b respectively, so that vbmeta _ a is matched according to vbmeta _ b;

reading a file path/dev/block/by-name/vbmeta _ b corresponding to vbmeta _ b from the table 1;

reading a file path/dev/block/by-name/vbmeta _ a corresponding to the vector _ boot _ a from the table 2;

reading data under the/dev/block/by-name/vbmeta _ b, and overwriting the read data to the/dev/block/by-name/vbmeta _ a;

in table 1, there is no child partition with a selected state of 0, and the static partition synchronization is completed.

Further, in the above scheme, table 1 and table 2 are transition data, and table 1 and table 2 are deleted after the static partition synchronization is completed.

Further, in the process of upgrading the operating system, in S420, when the data of the static partition (B) is read and written according to the operating system upgrade installation package, all the sub-partitions in the static partition (B) may not necessarily be rewritten. That is, if the data in the static partition (a) and the data in the static partition (B) are completely consistent before the operating system is upgraded, after the operating system is upgraded by using the flow shown in fig. 5, the data in some sub-partitions of the static partition (a) and the static partition (B) may still be consistent. Therefore, in the process of synchronizing the data of the static partition (B) to the static partition (A), if the sub-partitions with inconsistent data of the static partition (B) and the static partition (A) are firstly identified, and only the sub-partitions with inconsistent data are synchronized, the data read-write quantity can be greatly reduced on the basis of realizing data consistency.

FIG. 7 is a flow diagram illustrating one implementation of static partition synchronization. The terminal device executes the following flow as shown in fig. 7 to achieve data synchronization of the static partition (B) to the static partition (a).

S710 to S740 refer to S610 to S640.

S741, performing hash calculation on the data in the first path to obtain a first hash value;

s742, performing hash calculation on the data under the second sub-path to obtain a second hash value;

s743, verifying whether the first hash value is consistent with the second hash value;

if the two are consistent, jumping to S750;

if not, S745, reading the data in the first path;

and S746, overwriting the read data under the second path.

S750, refer to S750;

if yes, returning to the step S730 to reselect the first sub-partition;

if not, the static partition synchronization ends.

Further, in the solution of the present application, the execution node performing data synchronization between the static partition (a) and the static partition (B) is any one of the static partition (a) and the static partition (B) after the upgrade data is written in.

Specifically, after S420, the upgrade data is written in the static partition (B), but since the operating system is running to load the static partition (a), the data of the static partition (B) cannot be synchronized to the static partition (a). After S431, during the execution of S440, the device loads the static partition (B) to run the operating system, and the operating system does not need to load the static partition (a), so that the data of the static partition (B) can be synchronized to the static partition (a). Therefore, in the embodiment of the present application, the static partition synchronization may be performed at any time after S431. The application does not specifically limit the execution time sequence from the data synchronization of the static partition (B) to the static partition (a), and those skilled in the art may set the synchronization time of the static partition or the trigger condition for triggering the synchronization of the static partition according to actual requirements. The execution timing of the data synchronization of the static partition (B) to the static partition (a) is described below by way of a specific embodiment example.

Fig. 8 is a flowchart illustrating an operating system upgrade according to an embodiment of the present application, where when a device is currently started from a static partition (a), the device implements the upgrade of the operating system and synchronization of the static partition according to the flowchart illustrated in fig. 8.

S800 to S832, refer to S400 to S432;

s840, the device loads a basic partition (Common);

s850, the equipment loads the static partition (B);

s851, judging whether the static partition (B) is loaded successfully;

if the loading of the static partition (B) fails, S852, restarting the device and starting from the static partition (A);

if the static partition (B) is successfully loaded, S853, the data of the static partition (B) is synchronized to the static partition (A).

S860, loading the dynamic partition (Super) + the virtual dynamic partition; refer to S441.

S870, the equipment is started successfully, and a user interaction interface is entered; refer to S450.

S871, the device diskettes the data of the virtual dynamic partition to a dynamic partition (Super); refer to S451.

Further, in the virtual a/B upgrade scheme, after the device is restarted and started from the upgraded static partition, the device may verify the file that needs to be loaded during the current system operation in the dynamic partition + the virtual dynamic partition, and only after the verification is successful, the file that needs to be loaded during the current system operation in the dynamic partition + the virtual dynamic partition may be loaded. If the verification fails, the system is restarted and rolled back, and the system is failed to be upgraded.

Therefore, in order to avoid performing static partition synchronization under the failure of upgrade, in an embodiment of the present application, the static partition synchronization is performed only after the files required to be loaded by the dynamic partition and the virtual dynamic partition are successfully verified, or the files required to be loaded by the dynamic partition and the virtual dynamic partition are successfully loaded.

Fig. 9 is a flowchart illustrating an operating system upgrade according to an embodiment of the present application, where when a device is currently started from a static partition (a), the device implements the upgrade of the operating system and synchronization of the static partition according to the flowchart illustrated in fig. 9.

S900 to S952, refer to S800 to S852;

if the static partition (B) is loaded successfully, S953, verifying files needing to be loaded in the dynamic partition and the virtual dynamic partition; for example, dmverity is used.

S954, determine whether the verification is successful.

Such as a failed check, S960, the device is restarted and the system is rolled back, e.g., started from the static partition (a).

If the verification is successful, execute S955;

s955, synchronizing the data of the static partition (B) to the static partition (a);

s956 to S958, refer to S860 to S871.

Further, in an application scenario, the device is initially booted from the static partition (B), and if the static partition (B) is damaged, one or more sub-partitions in the static partition (B) have data errors. At this time, although the device may refer to the embodiment shown in fig. 2, in the process of starting the device from the static partition (B), the smooth start of the device is realized by loading one or more sub-partitions in the static partition (a). However, in the process of starting the device, the error data in the static partition (B) is not repaired, and when the device starts the static partition (B) again, it is still necessary to load one or more sub-partitions in the static partition (a) to achieve smooth start of the device with reference to the embodiment shown in fig. 2.

Therefore, in an embodiment of the present application, after a static partition is upgraded, data of the static partition with the data upgrade is synchronized to another static partition, so as to ensure that data of the two static partitions are consistent.

After that, if the static partition for starting the device has data errors, in the process of starting the device from the static partition, referring to the embodiment shown in fig. 2, the data in another static partition is loaded to smoothly start the device. After the equipment is started successfully, the starting sequence of the equipment is modified, so that the equipment is started from a static partition without data errors when being started next time.

For example, FIG. 10 is a flow chart illustrating booting a device for the system data storage structure shown in FIG. 1. Assuming that the device is initially started from the static partition (a), the operating system is upgraded based on the flow shown in fig. 4, the data of the static partition (B) is upgraded, and the device is started from the static partition (B) after the device is restarted. Thereafter, the data of the static partition (B) is synchronized to the static partition (A) to ensure that the data of the two static partitions are consistent.

After that, the device starts up from the static partition (B) according to the flow shown in fig. 10.

S1000 to S1070, refer to S200 to S270, except that in addition to the sub-partition data, it is necessary to mark that the static partition (B) has a data error in S1014, S1024, S1034, S1044, and S1054.

For example, static partition status information is stored in the metadata of the base partition (Common), and the static partition status information is used to describe whether the static partition (a) and the static partition (B) have data errors. For example, the static partition state information may be as shown in the following table:

numbering	Parameter name	Parameter value
			1	Error_static partition_a	0
2	Error_static partition_b	0

In table 3, Error _ static partition _ a corresponds to static partition (a), Error _ static partition _ B corresponds to static partition (B), a value of 0 indicates no data Error, and a value of 1 indicates data Error. In S1014, S1024, S1034, S1044, and S1054, in addition to the sub-partition data, the value of Error _ static partition _ b needs to be set to 1.

After S1070, the device further needs to perform:

s1071, read the state information of static partition, judge whether there is data error in static partition (B). Specifically, the device reads the value of Error _ static partition _ b and determines whether the value is 1.

If the static partition (B) has a data error, S1072 is executed, and the device modifies the current boot sequence from boot from the static partition (B) to boot from the static partition (a). Thus, the device will start from the static partition (A) when the device is started next time, and the data error in the static partition (B) will not interfere with the execution of the device start.

Further, in an actual application scenario, there is a case where both the static partition (B) and the static partition (a) have data errors. In this case, if the static partition (B) and the sub-partition that cannot be successfully loaded in the static partition (a) do not correspond, the device can be successfully started with reference to the embodiment shown in fig. 2. For example, fig. 11 is a schematic diagram illustrating a device boot loading process according to an embodiment of the present application. In an application scenario, there is a data error in the vector _ boot _ a in the static partition (a) and the vbmeta _ B in the static partition (B). The device starts from the static partition (B), and the starting flow is shown in fig. 11:

loading a base partition (Common);

checking the bootloader _ b sub partition (success), and loading the bootloader _ b sub partition;

checking the boot _ b sub-partition (success), and loading the boot _ b sub-partition;

checking the dtbo _ b sub-partition (success), and loading the dtbo _ b sub-partition;

checking the vbmeta _ b child partition (failure);

checking the vbmeta _ a sub-partition (success), and loading the vbmeta _ a sub-partition;

dynamic partitions (Super) are loaded.

Finally, the device boots the loaded operating system data from the static partition (B) as: basic partition (Common), bootloader _ b subpartition, boot _ b subpartition, vendor _ boot _ b subpartition, dtbo _ b subpartition, vbmeta _ a subpartition and dynamic partition (Super). During the boot from the static partition (B), the device needs to load the vbmeta _ a child partition.

If the device is started from the static partition (B), the starting sequence is modified to be started from the static partition (A). Because the vector _ boot _ a in the static partition (a) has data errors, the device still needs to load the vector _ boot _ B sub-partition of the static partition (B) in the process of starting from the static partition (a) to smoothly start. This results in a device that may never start successfully based on only one static partition.

In view of the above problem, in an embodiment of the present application, it is assumed that a device is initially started from a static partition (a), an operating system is upgraded based on the flow shown in fig. 4, data of the static partition (B) is upgraded, and the device is started from the static partition (B) after the device is restarted. Thereafter, the data of the static partition (B) is synchronized to the static partition (A) to ensure that the data of the two static partitions are consistent.

After this, the device remains booted from the static partition (B). If the static partition (B) has data errors, in the process of starting the device from the static partition (B), referring to the embodiment shown in fig. 2, the data in the static partition (a) is loaded to smoothly start the device. After the device is started successfully, the data in the static partition (A) is corrected, and the starting sequence of the device is changed from starting from the static partition (B) to starting from the static partition (A), so that the device can be started independently from the static partition (A) when the device is started next time.

FIG. 12 is a flow chart illustrating a boot device for the system data storage structure of FIG. 1. In an embodiment of the present application, it is assumed that a device is initially started from a static partition (a), an operating system is upgraded based on the flow shown in fig. 4, data of the static partition (B) is upgraded, and the device is started from the static partition (B) after the device is restarted. Thereafter, the data of the static partition (B) is synchronized to the static partition (A) to ensure that the data of the two static partitions are consistent.

After that, the device starts from the static partition (B) according to the flow shown in fig. 12.

S1200 to S1270, refer to S1000 to S1070.

After S1270, the apparatus further needs to perform:

s1271, reads the static partition status information, and determines whether the static partition (B) has a data error. Specifically, the device reads the value of Error _ static partition _ b and determines whether the value is 1.

If the static partition (B) has data errors, executing:

s1272, correcting data in the static partition (A);

s1273, the device changes the current boot sequence from boot from the static partition (B) to boot from the static partition (a). Thus, the device will start from the static partition (A) when the device is started next time, and the data error in the static partition (B) will not interfere with the execution of the device start. Further, it is assumed that a data error is present in the static partition (a) before S1200, and in S1272, the data error is not present in the static partition (a) any more by performing data correction on the static partition (a). Thus, after S1273, during the device boot from the static partition (a), there is no need to load the data of the static partition (B).

Further, the present application does not specifically limit the specific implementation manner of S1272, and those skilled in the art may adopt many possible implementations of S1272. The following describes a specific implementation procedure of S1272 by way of specific examples.

Assume that the device is initially booted from the static partition (a). The device completes the operating system upgrade and synchronizes the static partition (B) data to the static partition (a) based on the embodiment shown in fig. 4. The boot sequence of the device is then from the static partition (B). After that, it is assumed that data errors occur in both the static partition (B) and the static partition (a) of the device, for example, as shown in fig. 11, data errors occur in the vector _ boot _ a in the static partition (a) and the vbmmeta _ B in the static partition (B).

Fig. 13 is a flowchart illustrating data modification of the static partition (a) according to an embodiment of the present application. The terminal device executes the following flow as shown in fig. 13 to realize S1272.

S1300, determining the operating system version corresponding to the static partition (B);

s1310, obtaining a static partition installation image of the operating system version corresponding to the static partition (B);

s310 may be referred to for the execution of S1300 and S1310. And after the operating system full installation package is obtained, extracting the static partition installation mirror image from the operating system full installation package.

S1320, the static partition installation image is restored to the static partition (A).

FIG. 14 is a flow chart illustrating the booting of a device for the system data storage architecture shown in FIG. 1. Assuming that the device is initially started from the static partition (a), the operating system is upgraded based on the flow shown in fig. 4, the data of the static partition (B) is upgraded, and the device is started from the static partition (B) after the device is restarted. Thereafter, the data of the static partition (B) is synchronized to the static partition (A) to ensure that the data of the two static partitions are consistent.

After that, the device starts up from the static partition (B) according to the flow shown in fig. 14.

S1400 to S1470 refer to S200 to S270, except that in addition to the sub-partition data, the sub-partitions of the static partition (B) need to be marked for data errors in S1414, S1424, S1434, S1444, and S1454.

numbering	Parameter name	Parameter value
			1	Error_bootloader_a	0
2	Error_boot_a	0
			3	Error_vendor_boot_a	0
4	Error_dtbo_a	0
			5	Error_vbmeta_a	0
6	Error_bootloader_b	0
			7	Error_boot_b	0
8	Error_vendor_boot_b	0
			9	Error_dtbo_b	0
10	Error_vbmeta_b	0

In table 4, the Error _ bootloader _ a, the Error _ boot _ a, the Error _ vector _ boot _ a, the Error _ dtbo _ a, and the Error _ vbmeta _ a respectively correspond to the bootloader _ a sub-partition, the boot _ a sub-partition, the vector _ boot _ a sub-partition, the dtbo _ a sub-partition, and the vbmeta _ a sub-partition of the static partition (a); the Error _ bootloader _ B, the Error _ boot _ B, the Error _ vector _ boot _ B, the Error _ dtbo _ B, and the Error _ vbmeta _ B respectively correspond to the bootloader _ B sub-partition, the boot _ B sub-partition, the vector _ boot _ B sub-partition, the dtbo _ B sub-partition, and the vbmeta _ B sub-partition of the static partition (B), a value of 0 represents no data Error, and a value of 1 represents data Error. In S1414, S1424, S1434, S1444, and S1454, in addition to loading the sub-partition data, the value of the corresponding parameter needs to be set to 1.

After S1470, the device also needs to perform:

s1471, reading the state information of the static partition, judging whether the static partition (B) has data errors or not, and determining the sub-partition with the data errors. Specifically, the device reads values of Error _ bootloader _ b, Error _ boot _ b, Error _ vector _ boot _ b, Error _ dtbo _ b, and Error _ vbmeta _ b, and determines whether each value is 1.

If the static partition (B) has data errors, S1473 is executed, the device performs static partition data synchronization according to the static partition state information, and specifically synchronizes data of the sub-partition corresponding to the entry whose median is not 1 in the Error _ bootloader _ B, the Error _ boot _ B, the Error _ vector _ boot _ B, the Error _ dtbo _ B, and the Error _ vbmeta _ B to the corresponding sub-partition of the static partition (a).

For example, as shown in fig. 11, there is a data error in the vector _ boot _ a in the static partition (a) and the vbmeta _ B in the static partition (B). After S1470, the static partition state information is shown in the following table:

numbering	Parameter name	Parameter value
			1	Error_bootloader_a	0
2	Error_boot_a	0
			3	Error_vendor_boot_a	0
4	Error_dtbo_a	0
			5	Error_vbmeta_a	0
6	Error_bootloader_b	0
			7	Error_boot_b	0
8	Error_vendor_boot_b	0
			9	Error_dtbo_b	0
10	Error_vbmeta_b	1

TABLE 5

In S1473, the data of the bootloader _ b sub-partition, the boot _ b sub-partition, the vector _ boot _ b sub-partition, and the dtbo _ b sub-partition are synchronized to the bootloader _ a sub-partition, the boot _ a sub-partition, the vector _ boot _ a sub-partition, and the dtbo _ a sub-partition, respectively

S1474, the current starting sequence is changed from starting from the static partition (B) to starting from the static partition (A).

It is to be understood that some or all of the steps or operations in the above-described embodiments are merely examples, and other operations or variations of various operations may be performed by the embodiments of the present application. Further, the various steps may be performed in a different order presented in the above-described embodiments, and it is possible that not all of the operations in the above-described embodiments are performed.

Further, in general, improvements to a technology can be clearly distinguished as hardware improvements (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements to process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by an accessing party. A digital device is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate a dedicated integrated circuit chip. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

Therefore, the method flow proposed by the embodiment of the present application may be implemented in a hardware manner, for example, by using a controller, and the controller controls the touch screen to implement the method flow proposed by the embodiment of the present application.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

Corresponding to the embodiment, the application further provides the electronic equipment. The electronic device comprises a memory for storing computer program instructions and a processor for executing the program instructions, wherein the computer program instructions, when executed by the processor, trigger the electronic device to perform the method steps as described in embodiments of the present application.

The present application also provides a computer program product comprising a computer program which, when run on a computer, causes the computer to perform some or all of the steps provided by embodiments of the present application.

Those skilled in the art will readily appreciate that the techniques of the embodiments of the present invention may be implemented as software plus a required general purpose hardware platform. Based on such understanding, the technical solutions in the embodiments of the present invention may be essentially or partially implemented in the form of a software product, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and includes several instructions for enabling a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method according to the embodiments or some parts of the embodiments.

The same and similar parts in the various embodiments in this specification may be referred to each other. Especially, as for the device embodiment and the terminal embodiment, since they are basically similar to the method embodiment, the description is relatively simple, and the relevant points can be referred to the description in the method embodiment.

Claims

1. An operating system starting method applied to an electronic device, wherein the electronic device comprises a processor and a memory, the memory comprises a base partition, a first static partition, a second static partition, a dynamic partition and a user data partition, the first static partition comprises a first sub-partition, the second static partition comprises a second sub-partition, and the first sub-partition and the second sub-partition are mutually corresponding sub-partitions, the method comprises:

loading data of the base partition;

and loading the data of the dynamic partition to run a first operating system.

2. The method of claim 1, further comprising:

3. The method of claim 1, wherein the first static partition further comprises a third sub-partition, wherein the second static partition further comprises a fourth sub-partition, and wherein the third sub-partition and the fourth sub-partition are mutually corresponding sub-partitions, and wherein the loading static partition data further comprises:

4. The method of claim 1, wherein after the loading the data of the dynamic partition, the method further comprises:

5. The method of claim 4, wherein after the loading the data of the dynamic partition, the method further comprises:

and modifying the data of the second static partition.

6. The method of claim 5, wherein modifying the data of the second static partition comprises:

7. The method of any of claims 1-6, wherein prior to said loading static partition data, said method further comprises synchronizing data of said first static partition to said second static partition.

8. The method of claim 7, wherein prior to said loading data of said base partition, said method further comprises:

9. The method of claim 8, wherein the synchronizing the data of the first static partition to the second static partition is performed after a static partition data check is successful during the loading of the data of the first static partition.

10. The method according to claim 8, wherein during the process of loading the data of the dynamic partition, after the verification of the file of the dynamic partition to be loaded is successful, the synchronization of the data of the first static partition to the second static partition is performed.

11. The method of claim 8, wherein:

12. An electronic device comprising a processor and a memory, the memory comprising a base partition, a first static partition, a second static partition, a dynamic partition, and a user data partition, the first static partition comprising a first sub-partition, the second static partition comprising a second sub-partition, the first sub-partition and the second sub-partition being mutually corresponding sub-partitions, the processor configured to execute software code stored on the memory to cause the electronic device to perform the method flow of any of claims 1-11.

13. A computer-readable storage medium, in which a computer program is stored which, when run on a computer, causes the computer to carry out the method according to any one of claims 1 to 11.

14. A computer program product, characterized in that it comprises a computer program which, when run on a computer, causes the computer to carry out the method according to any one of claims 1 to 11.