CN116594639A - Method, apparatus, storage medium, and program product for managing system installation package - Google Patents

Method, apparatus, storage medium, and program product for managing system installation package Download PDF

Info

Publication number
CN116594639A
CN116594639A CN202211261658.9A CN202211261658A CN116594639A CN 116594639 A CN116594639 A CN 116594639A CN 202211261658 A CN202211261658 A CN 202211261658A CN 116594639 A CN116594639 A CN 116594639A
Authority
CN
China
Prior art keywords
partition
data
group
dynamic
sub
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211261658.9A
Other languages
Chinese (zh)
Inventor
张赠辉
王艳召
陈超
李永潮
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Honor Device Co Ltd
Original Assignee
Honor Device Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Honor Device Co Ltd filed Critical Honor Device Co Ltd
Priority to CN202211261658.9A priority Critical patent/CN116594639A/en
Publication of CN116594639A publication Critical patent/CN116594639A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44536—Selecting among different versions
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The embodiment of the application provides a management method, equipment, a storage medium and a computer program product of a system installation package, wherein the method comprises the following steps: manufacturing a basic partition mirror image; manufacturing a first static partition image of the first static partition and a second static partition image of the second static partition; generating slot-data corresponding to the first static partition based on the names of the sub-partitions in the dynamic partition and the corresponding partition sizes; generating slot two data corresponding to the second static partition based on the slot one data; packaging the first slot data, the second slot data and the mirror images of all the sub-partitions in the dynamic partition into dynamic partition mirror images; and making a system installation package containing the basic partition image, the first static partition image, the second static partition image and the dynamic partition image. According to the method provided by the embodiment of the application, the device can be enabled to be started from any static partition.

Description

Method, apparatus, storage medium, and program product for managing system installation package
The application is a divisional application of an application patent application with the name of management method, equipment, storage medium and program product of a system installation package, which is submitted to a national intellectual property office with the application number of 202110662966.1 and the application date of 2021, 6 and 15.
Technical Field
The present application relates to the field of computer technology, and in particular, to a method, an apparatus, a storage medium, and a computer program product for managing a system installation package.
Background
In the application scenario of the prior art, the user terminal needs to install an operating system to be usable by the user. For example, a mobile phone operating system (e.g., IOS system, android system) needs to be installed on the mobile phone to be used by the user. Because the installation process of the operating system is complicated, and the operating system of some terminal devices needs special equipment to be installed, in order to facilitate the user to use the terminal device, a basic operating system is usually installed in the terminal device before the terminal device is sold. Thus, after purchasing the terminal device, the user can use the terminal device without performing complex operation system installation operation by himself. For example, a base handset operating system has been installed on a handset before the handset is sold into a user's hand. After purchasing the mobile phone, the user can directly use the basic functions of the mobile phone (e.g., connect to a mobile network, make a phone call).
After the terminal equipment is sold in the hands of a user, in the process that the terminal equipment is used, the situation that the equipment is in operation error or even can not be started due to the data error of an operating system exists. Under the condition, because the system is in error in operation, the user can hardly repair the system by himself and can only return the equipment to the factory to re-write the operating system, which not only can influence the use of the terminal equipment by the user, but also can greatly increase the maintenance cost of the equipment provider. Thus, there is a need for a method of handling operating system data errors.
Disclosure of Invention
In view of the above, the present application provides a method, apparatus, storage medium and computer program product for managing a system installation package, so as to solve the problem in the prior art that an operating system cannot be run due to a static partition data error of the operating system.
In a first aspect, an embodiment of the present application provides a method for managing a system installation package, including:
manufacturing a basic partition mirror image;
manufacturing a first static partition image of the first static partition and a second static partition image of the second static partition;
generating slot-one data corresponding to a first static partition based on names of all sub-partitions in a dynamic partition and corresponding partition sizes, wherein the sub-partitions of the dynamic partition comprise the first sub-partition, the slot-one data comprises a first description group and a second description group corresponding to the first sub-partition, the value of an address item of the first description group is a first value, and the value of an address item of the second description group is a second value;
generating slot two data corresponding to a second static partition based on the slot one data, wherein the slot data comprises a third description group and a fourth description group, the name item and the value of the group item of the third description group are consistent with the first description group, the name item and the value of the group item of the fourth description group are consistent with the second description group, and the value of the address item of the fourth description group is the first value;
Packaging the first slot data, the second slot data and the mirror images of all the sub-partitions in the dynamic partition into dynamic partition mirror images;
and manufacturing a system installation package comprising the basic partition image, the first static partition image, the second static partition image and the dynamic partition image.
In an implementation manner of the first aspect, the generating slot two data corresponding to the second static partition according to the slot one data includes:
copying the first slot data and storing the first slot data as first data;
modifying the first data, including modifying a value of an address item of the second description set in the first data to the first value;
and storing the corrected first data as the slot two data.
In an implementation manner of the first aspect, the modifying the first data further includes modifying a value of an address item of the second description set in the first data to the second value.
In one implementation of the first aspect, the second value is a null value.
In one implementation of the first aspect:
the sub-partition of the dynamic partition further comprises a second sub-partition, the slot-data further comprises a fifth description group and a sixth description group corresponding to the second sub-partition, the value of the address item of the fifth description group is a third value, and the value of the address item of the sixth description group is a fourth value;
The slot two data further comprises a seventh description group and an eighth description group, wherein the name item and the value of the group item of the seventh description group are consistent with the fifth description group, the name item and the value of the group item of the eighth description group are consistent with the sixth description group, and the value of the address item of the eighth description group is the third value;
in an implementation manner of the first aspect, the modifying the first data includes:
copying the slot one data and storing the slot one data as first table data;
deleting a description group with the suffix name of the value of the name item in the first table data as_b to generate second table data;
modifying the suffix name of the name item in the second table data from a value of a suffix name to a value of a suffix name of a name item in the second table data to a value of b, and generating third table data;
respectively assigning the values of the address items of each description group in the third table data to the address items of the description groups with the same values of the name items in the first data;
and setting the value of the address item in the description group with the suffix name of the name item in the assigned first data as_a.
In an implementation manner of the first aspect, the modifying the first data includes:
copying the slot one data and storing the slot one data as first table data;
Deleting a description group with the suffix name of the value of the name item in the first table data as_b to generate second table data;
modifying the suffix name of the name item in the second table data from a value of a suffix name to a value of a suffix name of a name item in the second table data to a value of b, and generating third table data;
setting values of address items in all description groups in the first data to be null;
and respectively assigning the values of the address items of each description group in the third table data to the address items of the description groups with the same values of the name items in the first data after the values of the address items are empty.
In one implementation manner of the first aspect, after the fabricating a system installation package including the base partition image, the first static partition image, the second static partition image, and the dynamic partition image, the method further includes:
and based on the basic partition image, the first static partition image, the second static partition image and the dynamic partition image in the system installation package, data burning is carried out, and operating system data is burnt to the basic partition, the first static partition, the second static partition image and the dynamic partition of the device.
In a second aspect, the present application provides an electronic device comprising a processor and a memory, the processor being configured to execute software code stored on the memory, to cause the electronic device to perform the method flow according to the first aspect.
In a third aspect, the present application provides a computer readable storage medium having a computer program stored therein, 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 provides a computer program product comprising a computer program which, when run on a computer, causes the computer to perform the method as described in 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 provided by the embodiment of the application, the equipment can be enabled to be started from any static partition, so that when one static partition data is in error, the equipment can be started from another static partition, and the smooth running of the operating system is ensured.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
Fig. 1 is a schematic diagram of a burning system frame structure for performing system burning before leaving a factory of a device in an application scenario;
FIG. 2 is a schematic diagram of a data storage structure according to an embodiment of the present application;
FIG. 3 is a flow chart illustrating an operating system upgrade according to one embodiment of the present application;
fig. 4 is a schematic diagram of a burning system frame structure for performing system burning before leaving the factory of the device in an application scenario;
FIG. 5 is a diagram of a portion of data stored in Slot0 in one embodiment;
FIG. 6 is a schematic diagram of a data storage architecture of an operating system on a device under an application scenario;
fig. 7 is a schematic diagram of a data storage structure of the device after the device is burned into an operating system before leaving the factory in an application scenario;
FIG. 8a is a flow chart illustrating the creation of a system installation package for an operating system;
FIG. 8b is a flow chart illustrating the creation of a system installation package for an operating system according to one embodiment of the present application;
FIG. 9 is a flow chart illustrating the creation of a system installation package for an operating system according to one embodiment of the present application;
FIG. 10 is a diagram of a portion of data for Slot1 in one embodiment;
FIG. 11 is a flow chart illustrating the creation of a system installation package for an operating system according to one embodiment of the present application.
Detailed Description
For a better understanding of the technical solution of the present application, the following detailed description of the embodiments of the present application refers to the accompanying drawings.
It should be understood that the described embodiments are merely some, but not all, embodiments of the application. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
The terminology used in the embodiments of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in 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 way of describing an association of associated objects, meaning that there may be three relationships, e.g., a and/or b, which may represent: the first and second cases exist separately, and the first and second cases exist separately. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.
Aiming at the problem that the equipment is in operation error or even can not be started due to the error of the operating system data after the terminal equipment is sold in the hands of a user, one feasible solution is to construct operating system backup data on the equipment before the equipment leaves the factory. Thus, after the terminal device is sold into the hand of the user, when the operating system data is wrong, the backup data can be utilized to roll back to the state before the operating system is wrong. However, the backup data occupies the storage space, which compresses the data space that the user can freely use, resulting in a waste of the storage space.
In order to solve the problems, the application analyzes the data storage structure of the operating system, and realizes data backup by utilizing the original storage space of the operating system before the equipment leaves the factory, thereby ensuring that the equipment can normally run and smoothly start when the error occurs in the operating system data on the premise of not compressing the data space which can be freely used by a user.
Specifically, fig. 1 is a schematic diagram of a burning system frame structure for performing system burning before leaving the factory of the device in an application scenario, as shown in fig. 1, after the device 100 is assembled by hardware, the device 100 is connected to the burning device 110, and the memory 120 is connected to the burning device 110. The installation package creation device 130 is used to create a system installation package for installing an operating system, the system installation package containing an image file of the operating system. The fabricated system installation package is sent to the memory 120 for storage (the system installation package may be transmitted by wire, wirelessly, or by using a mobile hard disk transfer, etc.). The burning device 110 reads the system installation package in the memory 120, analyzes the system installation package to obtain the image file of the operating system, performs data burning based on the image file of the operating system, and burns the operating system data corresponding to the image file of the operating system onto the memory of the device 100, thereby realizing the installation of the operating system on the device 100 before leaving the factory.
The device 100 of the embodiment of the present application includes, but is not limited to, a smart phone, a smart headset, a tablet computer, a smart refrigerator, a smart speaker, etc., in which an operating system may be installed. The device 100 may also be a control board within which an operating system may be installed. Exemplary embodiments of an operating system include, but are not limited toLinux, or other operating systems.
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. After the recording device 110 records the operating system on the device 100, as shown in fig. 2, the file structure of the operating system stored in the device 100 includes a base partition (Common), a static partition (a), a static partition (B), a dynamic partition (Super), and a user data partition (Userdata).
Userdata is used to store personal data of a user, such as APP installed by the user's person, pictures, documents, and videos saved by the user's person. The data stored in the base portion is system data that does not participate in an operating system upgrade. The static partition (a) and the static partition (B) are structurally corresponding to each other, and the sub-partition naming is distinguished from each other by suffixes_a and_b. For example, the static partition (a) includes bootloader_a, boot_a, vendor_boot_a, dtbo_a, 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 (system, system _ ext, product, vendor, odm).
At device start-up, it starts from a static partition. For example, the device boots from static partition (a): sequentially loading a basic partition (Common), a static partition (A) and a dynamic partition (Super); the device boots from static partition (B): the base partition (Common), the static partition (B), and the dynamic partition (Super) are loaded in sequence.
FIG. 3 is a flow chart illustrating an operating system upgrade for the system data storage structure of FIG. 2, the device implementing the operating system upgrade according to the flow shown in FIG. 3 when the device is currently booted from the static partition (A).
S300, the device sequentially loads a basic partition (Common), a static partition (A) and a dynamic partition (Super), and starts from the static partition (A).
S310, the device acquires an operating system upgrade installation package.
For example, in one possible implementation, the device periodically initiates a search request to the search server, where the search request contains the version number (e.g., version 1.1) of the operating system currently running by the device; the packet searching server searches whether an operating system installation packet (for example, version 1.2) with an updated version number exists currently according to the version number of the operating system in the packet searching request; when an operating system installation package of an updated version exists, the package searching server feeds back to the device a download address of the operating system upgrade installation package (for example, an operating system upgrade package upgraded from version 1.1 to version 1.2); the device downloads the operating system upgrade installation package according to the download address of the operating system upgrade installation package, and saves the operating system upgrade installation package to a user data partition (Userdata).
S320, the device reads the operating system upgrade installation package saved in S310 from the user data partition (Userdata), and performs data writing operation on the static partition (B) according to the operating system upgrade installation package to upgrade the static partition;
for example, the static partition data of version 1.2 is contained in the operating system upgrade installation package, and the device overwrites the static partition data of version 1.2 into static partition (B).
S330, the device creates a virtual dynamic partition in a user data partition (Userdata) according to the upgrade installation package of the operating system, and writes upgrade data of the dynamic partition (Super) in the virtual dynamic partition. For example, the operating system upgrade installation package contains the data of the dynamic partition of version 1.2, and the device writes the data of the dynamic partition (Super) of version 1.2 in the virtual dynamic partition.
Further, in the virtual A/B upgrade scheme, an incremental upgrade mode is adopted for dynamic partition (Super). In the upgrading process, all files of the dynamic partition (Super) of the new version after upgrading are not saved in the virtual dynamic partition of the user data partition (Userdata), but the upgrading result of the data to be upgraded in the dynamic partition (Super) of the old version after upgrading is obtained. That is, the update data of the dynamic partition is stored in the virtual dynamic partition of the user data partition (Userdata).
Taking the system sub-partition as an example, assume that in version 1.1, the data in the system sub-partition can be divided into two parts, system1 and system 2. The data system2 is updated from version 1.1 to version 1.2, and the data system1 is updated to system3. Then, in S330, 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, the system delta upgrade installation package for version 1.1 to version 1.2 contains the dynamic partition (Super) update data for version 1.1 to version 1.2, which contains data system3.
Further, in the virtual A/B upgrade scheme, incremental upgrades of dynamic partitions (Super) are implemented based on snapshot technology (snapshot). Specifically, in a virtual dynamic partition of a user data partition (Userdata), upgrade data of the dynamic partition (Super) is saved by using Copy-On-Write (COW) files.
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) to which the COW file is directed.
In the operating system upgrade installation package acquired in S310, the COW file of the upgrade data of the dynamic partition (Super) is compressed and saved in the form of binary code. In the operating system upgrade installation package, each COW file is named according to the dynamic partition (Super) sub-partition for which it is intended. For example, a COW file for a system sub-partition is named system-COW-img.img.0000.
In S330, the device unpacks the operating system upgrade installation package to obtain all the COW files, and attaches an a/B partition flag 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 the dynamic partition (B). Therefore, the name tag_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.img.0000 with the addition of_b.
Further, in S330, 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 to a user data partition (Userdata), the Update folder of the user data partition (Userdata) contains 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 a dynamic partition (Super) for which the COW file is directed. The file map of the sub-partition of the dynamic partition (Super) is used to describe all files in the sub-partition of the dynamic partition (Super) and the save addresses of the respective files of the operating system of the current version (version before the current upgrade, e.g., version 1.1).
The upgrade data in the COW file is updated files in the new version of sub-partition data compared with the current version of sub-partition data; the COW file map of the COW file itself is used for describing the correspondence between the updated file and the files 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 corresponding file in the sub-partition of the dynamic partition (Super) can be replaced by the upgrade data in the COW file, so that the upgrade of the dynamic partition (Super) data is realized. Specifically, when the file map of the sub-partition of the dynamic partition (Super) needs to be acquired, 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). 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 the system sub-partition as an example, assume that data is saved in the system sub-partition 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 the 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 save address (block address) of the file in the system sub-partition of the dynamic partition (Super).
Suppose that a current operating system upgrade requires update data/system/app/a 2.Xxx and/system/user/c 2.Xxx.
It can be considered that:
System/app/A2.XXX and/system/user/C2. XXX are the system1 portion of the 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 part of system2 of the system sub-partition data.
Then the COW file for the system sub-partition (system_b-COW-img. 0000) contains the latest version of/system/app/a 2.Xxx and/system/user/c 2.Xxx.
It can be seen that the latest version of/system/app/a 2.Xxx and/system/user/c 2.Xxx is system3. The goal of the upgrade is to update system1 using system3.
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 position of the update data in the COW file in the sub-partition after the data is updated is consistent with the storage position of the original data to be updated in the sub-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 original super partition): the starting address start:024018 (offset from system start address); offset size:2 (i.e. 024018 ～ 024020 address field data)
Map2 (address of update data stored in cow file): the starting address start:045033 (offset from the start address of the cow file store); offset size:2 (i.e., 045033 ～ 045035 address field data);
/system/user/C2.XXX：
map1 (address of data to be updated in original super partition): the starting address start:024036 (offset from system start address); offset size:4 (i.e. 024036 ～ 024040 address field data)
Map2 (address of update data stored in cow file): the starting address start:045036 (offset from the start address of the cow file store); offset size:4 (i.e., 045036 ～ 045040 address field data).
When the size of the update data in the COW file is inconsistent 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): the starting address start:024018 (offset from system start address); offset size:2 (i.e. 024018 ～ 024020 address field data)
Map2.1 (address of update data stored in the cow file, which needs to be overlaid with map1.1 address): the starting address start:045033 (offset from the start address of the cow file store); offset size:2 (i.e., 045033 ～ 045035 address field data);
map1.2 (address to be written in the original super partition for the portion of the cow file where the update data exceeds the size of the data to be updated): the starting address start:025018 (offset from system start address); offset size:1 (i.e. 025018 ～ 025020 address field data)
Map2.2 (address of update data stored in the cow file, which needs to be overlaid with map1.2 address): the starting address start:046033 (offset from the start address of the cow file store); offset size:2 (i.e., 046033 ～ 046035 address field data).
In the following description of the specification, for convenience of description, only an application scenario in which the size of update data in a COW file is consistent with the size of original data to be updated thereof, and the save position of update data in the COW file in a child partition after data update is consistent with the save position of original data to be updated thereof in the child partition is illustrated.
In the above example, the address fields (045033 ～ 045035 and 045036 ～ 045040) are the physical save addresses (block addresses) of the latest version of the system/app/a2.Xxx and the system/user/c2.Xxx in the COW file (system_b-COW-img. 0000), respectively.
Thus, if A2.XXX at address 045033 ～ 045035 is used to replace A2.XXX at address 024018 ～ 024020 and C2.XXX at address 024036 ～ 024040 is used to replace C2.XXX at address 045036 ～ 045040, a data upgrade of the system sub-partition of the dynamic partition (Super) may be accomplished.
Further, in S330, after writing the COW file into the user data partition (Userdata), it is further necessary to perform overall verification on the dynamic partition (Super) +cow file, verify the validity of the dynamic partition (Super) +cow file, and verify whether the result of synthesizing the dynamic partition (Super) data of the current version and the COW file is the dynamic partition (Super) data of the new version.
Specifically, taking upgrading from version 1.1 to version 1.3 as an example, calculating a hash value of a synthetic result of data (unchanged data from version 1.1 to version 1.2) which does not need to be upgraded in the dynamic partition (Super) and upgrading data (data which needs to be upgraded from version 1.1 to version 1.2) in the COW file, judging whether the hash value is consistent with the hash value of the complete data of the dynamic partition (Super) in version 1.3, and if so, indicating that the COW file is valid; if the COW files are inconsistent, the COW files are invalid, the upgrading is failed, the upgrading process is interrupted, and errors are reported; wherein, the hash value of the complete data of the dynamic partition (Super) in version 1.3 is saved in the operating system upgrade installation package.
Specifically, during the verification process, dynamic partition (Super) +cow files are merged based on snapshot. In the implementation process of the snapshot, the combination of the dynamic partition (Super) and the COW file is not combination in a physical sense, but the whole file map of the sub-partition in the COW file is combined with the own COW file map of the COW file, so that the file map of the new version of sub-partition data is generated.
For example, a file map that partitions a system sub-partition:
/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 (3) map with the COW file:
/system/app/A2.XXX：
map1: address start:024018; size:2 (i.e. 024018 ～ 024020 address field data)
Map2: address start:045033; size:2 (i.e., 045033 ～ 045035 address field data);
/system/user/C2.XXX：
map1: address start:024036; size:4 (i.e. 024036 ～ 024040 address field data)
Map2: address start:045036; size:4 (i.e., 045036 ～ 045040 address field data).
And (5) merging. A new version of the file map for the system child partition is obtained:
/system/app/A0.XXX：024010～024013；
(A0.XXX pointing to dynamic partition (Super)/system/app)
/system/app/A1.XXX：024014～024017；
(A1. XXX pointing to dynamic partitioning (Super)/system/app)
/system/app/A2.XXX：045033～045035；
(A2.XXX in user data partition (Userdata)/Update/system_b-cow-img. 0000)
/system/B0.XXX：024021～024026；
(B0.XXX in dynamic partition (Super)/under system)
/system/B1.XXX：024027～024028；
(directed to B1.XXX in dynamic partitioning (Super)/under system)
/system/user/C0.XXX：024029～024032；
(C0.XXX pointing to dynamic partitioning (Super)/system/user)
/system/user/C1.XXX：024033～024035；
(C1.XXX pointing to dynamic partitioning (Super)/system/user)
/system/user/C2.XXX：045036～045040；
(directed to C2.XXX in user data partition (Userdata)/Update/system_b-cow-img.img.0000)
/system/user/C3.XXX：024041～024044。
(C3.XXX pointing to dynamic partitioning (Super)/system/user)
In the new version of the system sub-partition's file map,/system/app/A2. XXX's save address is not directed to/system/app/A2. XXX on the dynamic partition (Super) on memory, but to A2.XXX in system_b-cow-img.img.0000 in the user data partition (Userdata) on memory; the save address of/system/user/C2. XXX is not directed to/system/user/C2. XXX on a dynamic partition (Super) on memory, but to C2.XXX in a system_b-cow-img.img.0000 in a user data partition (Userdata) on memory.
In the verification process, according to the above synthesis method, a new version of the file map of all the sub-partitions of the dynamic partition (Super) is obtained (if the corresponding COW file of a certain sub-partition is not written in the user data partition (Userdata), the file map of the sub-partition is directly used as the new version of the file map). Combining the file maps of the new versions of all the sub-partitions generates a file system of the new version of the dynamic partition (Super).
Based on the file system read data of the new version of the dynamic partition (Super), all files contained in the file system of the new version of the dynamic partition (Super) are read and hash values are calculated.
When the COW file is valid, the disk-drop status information in the metadata partition (/ metadata) of the base partition (Common) is changed from "dropped (merge)" to "not dropped (wait for merge)". The landing status information is used to indicate whether there is a COW file currently that needs landing to a dynamic partition (Super). Specifically, the drop status information includes an overall identification for a dynamic partition (Super) and a sub-partition identification for each sub-partition. When the whole mark is 'dropped', all sub-partitions representing the dynamic partition (Super) do not need to be dropped; when the overall identifier is "no disk for merge", one or more sub-partitions representing dynamic partitions (Super) need to perform a disk-drop operation; when the sub-partition is identified as "dropped (merge)", it is representative that the sub-partition does not need to perform a drop operation; when a child partition is identified as "not dropped (wait for merge)", it represents that the child partition needs to be dropped.
S331, changing the starting sequence of the device from the starting of the static partition (A) to the starting of the static partition (B).
For example, the boot sequence identifier of the master boot record (Master Boot Record, MBR) is rewritten, and the boot sequence identifier 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 starts from the static partition (A), and the static partition (A) is loaded in the starting process; when the device reads the starting sequence identifier as B, the device starts from the static partition (B), and the static partition (B) is loaded in the starting process.
S332, restarting the device. And exiting the current operating system, cutting off the power supply of the equipment, and starting the power supply of the equipment again.
S340, the device loads a basic partition (Common) and a static partition (B) in sequence.
For example, the device first loads a base partition (Common). During loading of the base partition (Common), the device reads a boot tag in the base partition (Common); when the start-up flag in the base partition (Common) is (A), the device will load the static partition (A) after loading the base partition (Common), thereby starting from the static partition (A); when the boot flag in the base partition (Common) is (B), the device will load the static partition (B) after loading the base partition (Common), thereby booting from the static partition (B).
In S340, the device reads a start-up flag in the base partition (Common). The boot up in the base partition (Common) is labeled (B), and the device loads the static partition (B) after loading the base partition (Common), and boots from the static partition (B).
S341, the device loads virtual dynamic partitions of dynamic partitions (Super) and user data partitions (Userdata).
Specifically, the device reads the disk-drop status information in the metadata (/ metadata), determines whether the COW file needs to be retrieved from the specified path of the user data partition (Userdata) based on the disk-drop status information, and loads the dynamic partition (Super) and the COW file by adopting the snapshot merge.
Further, in S341, the device does not load all the COW files in the dynamic partition (Super) and the user data partition (Userdata), but loads the corresponding files according to the operating system running requirements. Specifically, in S341, the device determines, according to the operating system running requirement, a file to be loaded, and extracts, based on snapshot, a corresponding file from a COW file in a dynamic partition (Super) or a virtual dynamic partition, and loads the file.
Specifically, in S341, when the corresponding COW file exists at the first of the sub-partitions 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 the new version of the file map may refer to S330. The device determines files to be loaded according to the operation requirement of an operating system, and loads the files based on a file map of a new version of a dynamic partition (Super) sub-partition.
For example, operating system running requirements load all data in a directory user (/ system/user) under a system sub-partition. The device reads the disk-drop status information in the metadata (/ metadata), and the sub-partition of the system sub-partition in the disk-drop status information is identified as "no disk for merge", so the device searches the COW file in the user data partition (Userdata) under Update, and after searching the COW file system_b-COW-img.img.0000 under Update, generates a file map of a new version of the system sub-partition from the file map of the COW file in the system_b-COW-img.img.0000 based on the snapshot. Data loading is performed according to the storage addresses of all files in the file map of the new version of the system sub-partition/under the system/user, for example, according to the file map of the new version 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。
c0.xxx at address 024029 ～ 024032, c1.xxx at address 024033 ～ 024035, c2.xxx at address 045036 ～ 045040, and c3.xxx at address 024041 ～ 024044 are loaded.
Further, when all data in the directory user (/ system/user) under the system sub-partition is loaded, and the sub-partition of the system sub-partition is identified as "dropped (merge)" in the drop status information, the device does not search the user data partition (Userdata) for the COW file/Update, but directly loads all data in the directory user (/ system/user) under the system sub-partition.
Further, when all data in the directory user (/ system/user) under the system sub-partition is loaded, when the sub-partition identifier of the system sub-partition in the drop state information is "no drop (wait for merge)", if the device does not search the COW file of the corresponding system sub-partition in the user data partition (Userdata) or under Update, it indicates a data writing error (COW file writing error or drop state information writing error) in the upgrading process, and at this time, the device rolls back the system and reports the error.
Further, in S341, the device also needs to verify the loaded file before loading the file. Unlike S330, in S341, the dynamic partition (Super) +cow file is not authenticated as a whole, but only the file to be loaded. For example, checking is performed based on dm-quality (dm-quality is a target of dm (device mapper), which is a virtual block device, specifically used for checking of the file system). And if the verification is successful, loading the file, and if the verification is failed, restarting the device, rolling back the system or attempting to load the file again.
S350, the device is successfully started and enters a user interaction interface.
S351, the device drops the data of the virtual dynamic partition to the dynamic partition (Super) in the background.
In the description of the present application, the disk-dropping 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 the process of upgrading an operating system, so that the file of the dynamic partition (Super) completes data upgrading, so that the device does not need to load the dynamic partition (Super) and the virtual dynamic partition when being started next time, and can complete device starting only by loading the dynamic partition (Super).
Specifically, the device performs a boot broadcast after the device is successfully started, and starts an upgrade process after the boot broadcast. The upgrade process reads the disk-drop status information in the metadata (/ metadata) of the base partition (Common), and if the disk-drop status information is "dropped (merge)", the device enters a normal operation mode.
If the drop status information is "no drop (wait for merge)", the upgrade process drops the COW file in the user data partition (Userdata) into the dynamic partition (Super).
Specifically, the upgrade process writes upgrade data in the COW file in the user data partition (Userdata) to a corresponding address in the dynamic partition (Super), so that all data in the dynamic partition (Super) are data of the new version after upgrade.
For example, in a system sub-partition based file map/system/app/a 2.Xxx:024018 ～ 024020/system/app/a 2.Xxx in COW file map: 045033 ～ 045035 writing the data at address 045033 ～ 045035 to address 024014 ～ 024017; system/user/c2.Xxx in system sub-partition based file map: 024036 ～ 024040/system/user/c 2.Xxx in COW file map: 045036 ～ 045040, the data at address 045036 ～ 045040 is written to address 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 state information in the metadata (/ metadata) of the base partition (Common) is changed from "no disk for merge" to "dropped disk (merge)".
In S320, the data operation of the static partition upgrade is for the operating system data in the static partition (B), which does not affect the operating system data of the currently started static partition (a); also, in S330, the data operation of the dynamic partition upgrade is completed 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 operating system upgrading process, the user can normally use the equipment; after the step S331 is completed, the device does not need to be restarted immediately, and the user can select the restart time by himself; therefore, the upgrading process of the operating system does not influence the normal mobile phone operation of the user, so that 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 the user data partition (Userdata) needs to be updated, so that the data storage space utilization rate is effectively improved.
In the system data storage structure shown in fig. 2, the partition structures of the static partition (a) and the static partition (B) are consistent, and only one static partition needs to be read when the operating system runs, so in theory, when one static partition is not available, the other static partition can be used to maintain the normal running of the operating system. However, in the actual application scenario, after the terminal device of the android system adopting the virtual a/B upgrade mode completes the installation of the operating system before leaving the factory, the terminal device can only be started from the static partition (a) but cannot be started from the static partition (B). That is, after the terminal device of the android system adopting the virtual a/B upgrade mode completes the installation of the operating system before leaving the factory, if the static partition (a) has a data error, the device cannot be started from the static partition (B), and only the device can return to the factory to repair the operating system data.
Specifically, fig. 4 is a schematic diagram of a burning system frame structure for performing system burning before leaving the factory of the device in an application scenario. In the android system adopting the virtual A/B upgrading mode, only the static partition adopts the A/B scheme, and the dynamic partition adopts the scheme for constructing the virtual dynamic partition during upgrading. Therefore, for matching of the static partition and the dynamic partition, as shown in fig. 4, the metadata (/ supermetadata) of the header of the dynamic partition (Super) includes the Slot0 corresponding to the static partition (a) and the Slot1 of the static partition (B). Slot0 and Slot1 are used to store the partition table for the Super partition. When the equipment is started, according to the different static partitions started, selecting to acquire partition information of the Super partition from one of Slot0 or Slot1. For example, when the device is started by the static partition a, when loading the Super partition, the device first reads Slot0 to obtain the sub-partition address of the Super partition; when the device is started by the static partition B, the device first reads Slot1 to obtain the child partition address of the Super partition when loading the Super partition.
Specifically, slot0 and Slot1 include a plurality of sub-partition description groups, each of which corresponds to a sub-partition of the Super partition. Each sub-partition description group contains:
a Name (Name) item whose value is the Name of the child partition;
a Group (Group) entry whose value is a child partition type;
an attribute (Attributes) item whose value is a partition read-write attribute, for example, a read-only attribute (read only);
an address (extensions) entry whose value is the address of the child partition.
In the Name item and the Group item, if the suffix of the value is a, the value corresponds to the static partition (A); the suffix of the value is B, then it corresponds to static partition (B).
When the Super partition is loaded, starting with static partition A, slot0 is read first. When the Slot0 is read, because the suffix is that the_a corresponds to the static partition (A), the device reads the value of the names item in the Slot0 and/or the values of the extensions item in the partition description Group of which the Group item suffix is that the_a so as to acquire the sub-partition address of the Super partition.
When the Super partition is loaded, starting with static partition B, slot1 is read first. When the Slot1 is read, because the suffix is_b, the device reads the value of the Name item in the Slot0 and/or the value of the extensions item in the partition description Group of which the suffix is_b, so as to obtain the sub-partition address of the Super partition.
In general, in Slot0 and Slot1, for each sub-partition of the Super partition, there are two sets of sub-partition descriptions, one set of sub-partition descriptions corresponding to static partition (A) and one set of sub-partition descriptions corresponding to static partition (B). When the Slot0 or Slot1 is read, the device selects the sub-partition description to be read according to the suffix (a or b).
FIG. 5 shows a portion of data stored in Slot0 in one embodiment. As shown in fig. 5, in the partition description Group with suffix_a of the Name item and the value of the Group item, the value of the extensions item is the real address of the child partition. In the partition description Group with suffix_b of the value of the Name item and the Group item, the value of the extensions item is left empty.
When the Super partition is loaded, starting with static partition A, slot0 is read first. When the Slot0 is read, because the suffix is that the_a corresponds to the static partition (A), the device reads the value of the Extents item in the partition description Group of which the Name item and/or the Group item suffix is that the_a in the Slot0 so as to acquire the sub-partition address of the Super partition, thereby smoothly loading the Super partition.
When the Slot0 is read, since the suffix of the Name item and/or the Group item in the Slot0 corresponds to the static partition (B), the device does not need to read the partition description Group with the suffix of the Name item and/or the Group item of the static partition (B), and therefore, in the partition description Group with the suffix of the Name item and the Group item value of the static partition (B), the loading of the Super partition is not affected by the fact that the value of the Extents item is emptied.
Further, in one embodiment, the data stored in Slot1 is similar to the data structure shown in FIG. 5, except that, in order to ensure smooth loading of the Super partition, in the data of Slot1, the value of the Name item and the value of the Group item are real addresses of the sub-partition in the partition description Group with suffix_b. In the partition description Group with suffix_a of the value of the Name item and the Group item, the value of the extensions item is left empty.
FIG. 6 is a schematic diagram of a data storage architecture of an operating system on a device under an application scenario. Taking the System sub-partition of the Super partition as an example, as shown in fig. 6, data for the System sub-partition in Slot0 is:
Name：system_a
Group：qti_dynamic_partitions_a
Attributes：readonly
Extents：0..6995967linear super 2048
Name：system_b
Group：qti_dynamic_partitions_b
Attributes：readonly
Extents：
thus, when the device boots from the static partition (A), the device reads the system_a sub-partition data with suffix_a in Slot 0. Based on the system_a data in Slot0, the device can smoothly load the System child partition.
As shown in fig. 6, the data for the System sub-partition in Slot1 is:
Name：system_a
Group：qti_dynamic_partitions_a
Attributes：readonly
Extents：
Name：system_b
Group：qti_dynamic_partitions_b
Attributes：readonly
Extents：0..6995967linear super 2048
thus, when the device boots from the static partition (B), the device reads the system_b sub-partition data with suffix_b in Slot 1. Based on the system_b data in Slot0, the device can smoothly load the System child partition.
However, when the operating system is burned before the device leaves the factory, the same data is burned in the Slot1 and the Slot 0. That is, in the partition description Group in which the suffix of the value of the Name item and the Group item is _a in Slot1, the value of the extensions item is the real address of the child partition. In the partition description Group with suffix_b of the value of the Name item and the Group item, the value of the extensions item is left empty. Thus, if an attempt is made to boot the device from the static partition (B) after the device is burned before leaving the factory, the value of the extensions item is read from the partition description Group with suffix_b of the Name item and the Group item in the Slot1 when loading the Super partition. Because the values of the extensions in the partition description Group with suffix_b of the Name item and the Group item in Slot1 are set to be null, address reading failure occurs, and thus the Super partition cannot be loaded smoothly. Thus, the static partition (B) cannot boot the device.
For example, fig. 7 is a schematic diagram of a data storage structure of the device after the device is burned into an operating system before leaving the factory in an application scenario. Taking the System sub-partition of the Super partition as an example, as shown in fig. 7, data for the System sub-partition in Slot0 is:
Name：system_a
Group：qti_dynamic_partitions_a
Attributes：readonly
Extents：0..6995967linear super 2048
Name：system_b
Group：qti_dynamic_partitions_b
Attributes：readonly
Extents：
as shown in fig. 7, the data for the System sub-partition in Slot1 is identical to that in Slot0, and is:
Name：system_a
Group：qti_dynamic_partitions_a
Attributes：readonly
Extents：0..6995967linear super 2048
Name：system_b
Group：qti_dynamic_partitions_b
Attributes：readonly
Extents：
thus, when the device boots from the static partition (B), the device reads the system_b sub-partition data with suffix_b in Slot 1. Since the extensions of the system_b data in Slot1 are empty, the device cannot smoothly load the System child partition.
In view of the above problems, the present application provides a method for installing an operating system before shipping, and before installing the operating system before shipping, modifying a native manufacturing flow of a dynamic partition (Super) image in a system installation package of the operating system, and creating a corrected image manufacturing flow. And adopting a correction mirror image manufacturing flow to manufacture a correction dynamic partition (Super) mirror image so that Slot0 and Slot1 of a dynamic partition (Super) in the correction dynamic partition (Super) mirror image are correct configuration data. The system installation package containing the modified dynamic partition (Super) is used for carrying out operation system installation before leaving a factory, and after the operation system is installed, the static partition (A) and the static partition (B) on the equipment can both start the equipment, so that when the data error occurs in the static partition (A), a user can start the equipment through the static partition (B), and the normal operation of the operation system is maintained and data restoration is carried out.
FIG. 8a is a flow chart illustrating the native fabrication of a system installation package for an operating system. The installation package creation device 130 performs the flow shown in fig. 8a to generate an operating system installation package.
S810a, making a basic partition (Common) mirror image. Specifically, a file of a base partition (Common) is obtained, and is packaged into a base partition (Common) image.
S820a, making a static partition (A) image and a static partition (B) image. Specifically, the images of all the sub-partitions of the static partition are obtained and packaged into the image of the static partition (A) and the image of the static partition (B).
S830a, obtaining the names of each sub-partition in the dynamic partition (Super) and the corresponding partition size.
S831a, generating Slot0 data according to the names of the sub-partitions in the dynamic partition (Super) and the corresponding partition sizes. For example, slot0 data as shown in fig. 5 is generated.
S832a, copying the Slot0 data and storing the Slot1 data.
S833a, obtaining sub-partition images of all sub-partitions in the dynamic partition (Super).
In S833a, the sub-partition images of the sub-partitions may be prefabricated, and the sub-partition images may be obtained by directly reading the sub-partition images from the storage device storing the sub-partition images. Or, the files of the sub-partition can be directly obtained, and the files of the sub-partition are packaged into sub-partition images through an image making tool.
S834a, packaging the sub-partition images of all sub-partitions in the Slot0 data and Slot1 data dynamic partition (Super) into a dynamic partition (Super) image.
S840a, making a system installation package comprising a base partition (Common) image, a static partition (A) image, a static partition (B) image and a dynamic partition (Super) image.
In one embodiment of the present application, the dynamic partition mirror creation flow shown in FIG. 8a is modified. FIG. 8b is a flow chart illustrating the creation of a system installation package for an operating system according to one embodiment of the present application. The installation package creation device 130 performs the flow as shown in fig. 8b to generate an operating system installation package.
S810b to S831b, refer to S810a to S831a.
S832B, generating Slot1 data according to the Slot0 data, wherein Super partition sub-partition description data corresponding to the static partition B in the Slot1 data is a true value.
S833b to S840b, refer to S833a to S840a.
Specifically, in S832b, the Slot0 data is copied, saved as Slot11 data, and the Slot11 data is corrected to generate Slot1 data. In the process of correcting the Slot11 data, the values of the extensions in the partition description Group with the suffix of the Name item and the Group item of the Slot11 data being the value of b are modified from null to true values.
Further, in S832b, in the process of correcting the Slot11 data, the values of the names and the values of the Group items in the Slot11 data are also nulled by the values of the extensions items in the partition description Group with suffix_a.
Or, considering that the static partition (B) starts the device, when reading the Slot1, the partition description Group with suffix_a of the value of the Name item and the Group item is not read, so in S832B, in the process of correcting the Slot11 data, the value of the extensions item in the partition description Group with suffix_a of the value of the Name item and the Group item in the Slot11 data is not modified.
After S840b, the system installation package fabrication is completed. The system installation package is sent to the memory 120 to store the system installation package in the memory 120 read by the burning device 110, the system installation package is analyzed to obtain the image file of the operating system, the data burning is performed based on the image file of the operating system, and the operating system data corresponding to the image file of the operating system is burned to the memory of the device 100, so that the installation of the operating system on the device 100 before delivery is realized. At this time, the device 100 may be started from either the static partition (a) or the static partition (B).
Further, the specific implementation of S832b is not specifically limited by the present application, and those skilled in the art may implement S832b in a variety of possible implementations. The following describes specific embodiments and exemplifies the specific implementation flow of S832b with reference to the drawings. The following illustrates a specific implementation procedure of the embodiment of the present application through a specific embodiment.
FIG. 9 is a flow chart illustrating the creation of a system installation package for an operating system according to one embodiment of the present application. The installation package fabricating apparatus 130 performs the flow shown in fig. 9 to realize S832b.
S931, copying the Slot0 data and storing the Slot01 data;
slot0 data is:
a first description group:
Name：system_a
Group：qti_dynamic_partitions_a
Attributes：readonly
extensions: 6995967linear super 2048 (first value)
A second description group:
Name：system_b
Group：qti_dynamic_partitions_b
Attributes：readonly
extensions: (second value)
Fifth description group:
Name：system_ext_a
Group：qti_dynamic_partitions_a
Attributes：readonly
extensions: 262143linear super 6998016 (third value)
Sixth description group:
Name：system_ext_b
Group：qti_dynamic_partitions_b
Attributes：readonly
extensions: (fourth value)
S932, deleting a sub-partition description Group with the suffix of the Name item or the Group item value of the Slot01 data as_b, and generating Slot02 data;
for example, assuming that part of the data in the Slot0 data is as shown in fig. 10 (part of the data in the Slot11 data is as shown in fig. 5), the Slot0 data is copied and stored as Slot01 data, and after the Slot02 data is generated from the Slot01 data, the data corresponding to the part of the data shown in fig. 5 in the Slot02 data is as follows:
Name：system_a
Group：qti_dynamic_partitions_a
Attributes：readonly
Extents：0..6995967linear super 2048
Name：system_ext_a
Group：qti_dynamic_partitions_a
Attributes：readonly
Extents：0..262143linear super 6998016
s933, modifying the suffix (a) of the values of the Name item and the Group item in the Slot02 data to (_b) to generate Slot03 data;
for example, as shown in fig. 10, the data corresponding to the partial data shown in fig. 5 in the Slot03 data is:
Name：system_b
Group：qti_dynamic_partitions_b
Attributes：readonly
Extents：0..6995967linear super 2048
Name：system_ext_b
Group：qti_dynamic_partitions_b
Attributes：readonly
Extents：0..262143linear super 6998016
in S933, the suffix of the value of the Group entry may not be modified.
S934, copying the Slot0 data and storing the Slot0 data as Slot11 data;
s935, selecting an unselected sub-partition description group (first sub-partition description group) in the Slot03 data;
specifically, all sub-partition descriptions in the Slot03 data are unselected before S935. In S933, a selection (blocked) item is added to all the child partition description groups, and the value of the blocked item of all the child partition description groups is 0. In S935, the unselected child partition description groups (child partition description groups having a value of 0 for the closed item) are determined from the value of the closed item. In S935, when an unselected child partition description group is selected, the value of the blocked entry in the group is set to 1.
S936, matching the value of the Name item of each sub-partition description group in the Slot11 data with the value of the Name item of the first sub-partition description group, and determining a sub-partition description group (second sub-partition description group) with the value of the Name item of the first sub-partition description group consistent with the value of the Name item of the first sub-partition description group in the Slot11 data;
s937, configuring the value of the extensions in the second sub-partition description group in the Slot11 data to be the value of the extensions in the first sub-partition description group in the Slot03 data;
s938, judging whether unselected sub-partition description groups exist in the Slot03 data;
If so, return to S935;
if not, execute S939;
for example, as shown in fig. 10, the Slot11 data matches the Slot0 data immediately after creation (before correction), and after correction, the data corresponding to the partial data shown in fig. 5 among the Slot11 data is:
Name：system_a
Group：qti_dynamic_partitions_a
Attributes：readonly
Extents：0..6995967linear super 2048
Name：system_b
Group：qti_dynamic_partitions_b
Attributes：readonly
Extents：0..6995967linear super 2048
Name：system_ext_a
Group：qti_dynamic_partitions_a
Attributes：readonly
Extents：0..262143linear super 6998016
Name：system_ext_b
Group：qti_dynamic_partitions_b
Attributes：readonly
Extents：0..262143linear super 6998016
s939, the value of the extensions in the child partition description Group with the suffix of the Name item or the Group item value of the Slot11 data being _ a is set to be null, and the Slot11 data is saved as Slot1 data.
For example, as shown in fig. 10, after S941 is executed (after the emptying), the data corresponding to the partial data shown in fig. 5 in the Slot1 data is:
third description group:
Name：system_a
Group：qti_dynamic_partitions_a
Attributes：readonly
extensions: (second value)
Fourth description group:
Name：system_b
Group：qti_dynamic_partitions_b
Attributes：readonly
extensions: 6995967linear super 2048 (first value)
Seventh description group:
Name：system_ext_a
Group：qti_dynamic_partitions_a
Attributes：readonly
extensions: (fourth value)
Eighth description group:
Name：system_ext_b
Group：qti_dynamic_partitions_b
Attributes：readonly
extensions: 262143linear super 6998016 (third value)
FIG. 11 is a flow chart illustrating the creation of a system installation package for an operating system according to one embodiment of the present application. The installation package creation device 130 executes the flow shown in fig. 11 to generate an operating system installation package.
S1131 to S1134, refer to S931 to S934.
S1135, the values of all the extensions in Slot11 are nulled.
S1136 to S1138, refer to S935 to S937.
S1139, judging whether unselected sub-partition description groups exist in the Slot03 data;
If so, return to S1136;
if not, the flow ends.
It is to be understood that some or all of the steps or operations in the above-described embodiments are merely examples, and that embodiments of the present application may also perform other operations or variations of the various operations. Furthermore, the various steps may be performed in a different order presented in the above embodiments, and it is possible that not all of the operations in the above embodiments are performed.
Further, in general, improvements to a technology can be clearly distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by an accessing party. The designer programs itself to "integrate" a digital device onto a single PLD without having to ask the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.
Therefore, the method flow proposed by the embodiment of the present application may be implemented in hardware, for example, using a controller, where the controller controls a 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, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.
Corresponding to the embodiment, the application also provides 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 according to embodiments of the 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.
It will be apparent to those skilled in the art that the techniques of embodiments of the present application may be implemented in software plus a necessary general purpose hardware platform. Based on such understanding, the technical solutions in the embodiments of the present application may be embodied in essence or what contributes to the prior art in the form of a software product, which may be stored in a storage medium, such as a ROM/RAM, a magnetic disk, an optical disk, etc., including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the method described in the embodiments or some parts of the embodiments of the present application.
The same or similar parts between the various embodiments in this specification are referred to each other. In particular, for the device embodiment and the terminal embodiment, since they are substantially similar to the method embodiment, the description is relatively simple, and reference should be made to the description in the method embodiment for relevant points.

Claims (10)

1. A method for burning system data, wherein the system data includes a base partition image, a first static partition image, a second static partition image, and a dynamic partition image, the first static partition image and the second static partition image include identical data, the dynamic partition image includes slot one data and slot two data, the slot one data includes a first description group and a second description group, the slot two data includes a third description group and a fourth description group, a name item and a value of a group item of the third description group are consistent with the first description group, a name item and a value of a group item of the fourth description group are consistent with the second description group, and a value of an address item of the first description group and a value of a fourth description group are first values, the method includes:
burning the base partition mirror image to the base partition of the electronic equipment;
Burning the first static partition image to a first static partition of the electronic device;
burning the second static partition image to a second static partition of the electronic device;
and burning the dynamic partition mirror image to a dynamic partition of the electronic device, wherein the dynamic partition of the electronic device comprises a first slot, a second slot and a first sub-partition, the first slot data corresponds to the first static partition, the second slot data corresponds to the second static partition, and the first description group and the second description group correspond to the first sub-partition.
2. The method of claim 1, wherein the first value is a real address of the first sub-partition.
3. The method of claim 2, wherein the address items of the second description set and the third description set have a second value.
4. A method according to claim 3, wherein the second value is a null value.
5. The method of claim 1, wherein the slot-one data further includes a fifth description group and a sixth description group, the slot-two data further includes a seventh description group and an eighth description group, the name item and the value of the group item of the seventh description group are consistent with the fifth description group, the name item and the value of the group item of the eighth description group are consistent with the sixth description group, and the address items of the fifth description group and the eighth description group are a third value.
6. The method of claim 5, wherein the dynamic partition of the electronic device further comprises a second sub-partition, the fifth description set and the sixth description set corresponding to the second sub-partition.
7. The method of claim 6, wherein the third value is a real address of the second sub-partition.
8. The method of claim 7, wherein the address items of the sixth description set and the seventh description set have a fourth value.
9. The method of claim 8, wherein the fourth value is a null value.
10. A recording device, characterized in that it comprises a processor and a memory, the processor being configured to execute software code stored on the memory, so that the recording device executes the method flow according to any one of claims 1-9.
CN202211261658.9A 2021-06-15 2021-06-15 Method, apparatus, storage medium, and program product for managing system installation package Pending CN116594639A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211261658.9A CN116594639A (en) 2021-06-15 2021-06-15 Method, apparatus, storage medium, and program product for managing system installation package

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110662966.1A CN113900673B (en) 2021-06-15 2021-06-15 System installation package management method, device, storage medium and program product
CN202211261658.9A CN116594639A (en) 2021-06-15 2021-06-15 Method, apparatus, storage medium, and program product for managing system installation package

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
CN202110662966.1A Division CN113900673B (en) 2021-06-15 2021-06-15 System installation package management method, device, storage medium and program product

Publications (1)

Publication Number Publication Date
CN116594639A true CN116594639A (en) 2023-08-15

Family

ID=79187473

Family Applications (2)

Application Number Title Priority Date Filing Date
CN202211261658.9A Pending CN116594639A (en) 2021-06-15 2021-06-15 Method, apparatus, storage medium, and program product for managing system installation package
CN202110662966.1A Active CN113900673B (en) 2021-06-15 2021-06-15 System installation package management method, device, storage medium and program product

Family Applications After (1)

Application Number Title Priority Date Filing Date
CN202110662966.1A Active CN113900673B (en) 2021-06-15 2021-06-15 System installation package management method, device, storage medium and program product

Country Status (1)

Country Link
CN (2) CN116594639A (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115562695B (en) * 2022-01-10 2023-10-27 荣耀终端有限公司 Operating system upgrading method, electronic device, storage medium and chip system
CN116467015B (en) * 2023-06-20 2023-10-20 荣耀终端有限公司 Mirror image generation method, system start verification method and related equipment

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102004700A (en) * 2010-11-26 2011-04-06 华为终端有限公司 Memory space distribution method and device for flash memory
CN102999436B (en) * 2012-11-28 2015-09-09 华为终端有限公司 The method and apparatus of dynamic partition information is generated in Nand flash memory
US20150277934A1 (en) * 2014-03-25 2015-10-01 Microsoft Technology Licensing, Llc One time dual boot mobile phone device
CN104484625B (en) * 2014-12-29 2017-11-03 北京明朝万达科技股份有限公司 A kind of computer and its implementation with dual operating systems
KR102266533B1 (en) * 2015-04-29 2021-06-17 솔 밍소 리 Systems and methods for programming, controlling and monitoring wireless networks
CN106155589B (en) * 2016-06-30 2018-12-14 数普金通数据技术有限公司 A kind of virtual dynamic partition image file generation method and system
CN110083374B (en) * 2019-03-25 2023-06-23 深圳猛犸电动科技有限公司 Upgrade rollback method, system and terminal equipment
CN112416411B (en) * 2019-08-23 2023-08-18 百度在线网络技术（北京）有限公司 Upgrading method and device, equipment end, server and computer readable medium
CN110780890B (en) * 2019-10-24 2023-06-06 百度在线网络技术（北京）有限公司 System upgrading method, device, electronic equipment and medium
CN111522569B (en) * 2020-05-09 2023-08-18 中瓴智行(成都)科技有限公司 Hypervisor-based embedded multi-system upgrading method and computer readable storage medium
CN111857854A (en) * 2020-08-04 2020-10-30 闻泰通讯股份有限公司 Shutdown resource loading method and device, storage medium and electronic equipment
CN112328358A (en) * 2020-10-28 2021-02-05 惠州华阳通用电子有限公司 Dual-system starting method based on virtual machine and storage medium
CN112631609A (en) * 2021-01-05 2021-04-09 北京字节跳动网络技术有限公司 Compiling method, device, terminal and storage medium

Also Published As

Publication number Publication date
CN113900673A (en) 2022-01-07
CN113900673B (en) 2022-10-28

Similar Documents

Publication Publication Date Title
CN115480798B (en) Operating system upgrade method, device, storage medium and computer program product
CN113821235B (en) Operating system data updating method, device, storage medium and program product
CN115729586B (en) Operating system upgrade method, device, storage medium and computer program product
CN114116023B (en) Operating system starting method, device, storage medium and computer program product
CN113821221B (en) Method, apparatus and storage medium for installing operating system
CN115686584B (en) Operating system upgrading method, device, storage medium and computer program product
CN116594639A (en) Method, apparatus, storage medium, and program product for managing system installation package
CN113805956B (en) Configuration method and device of operating system and storage medium
WO2022262748A1 (en) Management method for operating system, device, storage medium, and computer program product
CN114489813B (en) Method, equipment and storage medium for configuring operating system
CN114780019A (en) Electronic device management method and device, electronic device and storage medium
CN114461257B (en) Operating system data configuration method, operating system data configuration device, storage medium and program product
CN113806139B (en) Operating system recovery method, operating system recovery device, storage medium and computer program product
CN113821234B (en) Operating system upgrade method, apparatus, storage medium, and computer program product
CN115686644B (en) Method, equipment and storage medium for configuring operating system
CN115562695A (en) Operating system upgrading method, electronic equipment, storage medium and chip system

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination