A differential upgrade method for multi-operating system devices

Abstract

The present invention provides a differential upgrade method for a multi-operating system device, comprising: making a differential upgrade package according to the system type of the partition to be upgraded in each guest operating system and the available memory of the host operating system; obtaining the differential upgrade package and parsing it to obtain a differential file and an upgrade script file when the verification is successful; for each partition to be upgraded in each guest operating system, judging whether the system type of the partition is a fourth-generation extended file system: if so, modifying the partition data of the partition according to the corresponding differential file and the upgrade script file; if not, performing a restoration operation according to the source version of the acquired partition and the differential file to obtain a target version, and writing the target version back to the partition; repeating the above process until all the partitions to be upgraded in all guest operating systems are upgraded. The beneficial effect is to achieve a balance between a smaller upgrade package, a faster upgrade speed and a smaller memory consumption, and meet the upgrade requirements of partitions of different system types.

Description

Technical Field

[0001] The present invention relates to the technical field of over-the-air downloading, and in particular to a differential upgrade method for multi-operating system equipment. Background Art

[0002] Hypervisor, also known as virtual machine monitor, is software, firmware or hardware used to build and execute virtual machines. The computer used by the hypervisor to execute one or more virtual machines is called the host machine, and these virtual machines are called guest machines. Hypervisor provides a virtual operating platform to execute guest operating systems and is responsible for managing the execution phase of other guest operating systems; these guest operating systems share virtualized hardware resources.

[0003] Based on the development of Hypervisor technology, more and more manufacturers are integrating multiple complex operating systems from the software level into a single system on chip, thereby achieving the goal of saving costs, reducing power consumption, improving interaction efficiency, and making each operating system relatively safe and independent. However, this brings new challenges to the implementation of differential upgrades based on over-the-air download technology: if different operating systems are upgraded independently, the overall upgrade time will be longer, the user experience will be poor, and the coupling degree of the overall implementation of over-the-air download technology will be increased; if a certain operating system and other operating systems are upgraded uniformly within a certain operating system, the file system file differential method cannot be used because the file system partition types used by each operating system may be different, and some operating systems also use dm-verity technology. Summary of the invention

[0004] In view of the problems existing in the prior art, the present invention provides a differential upgrade method for a multi-operating system device, wherein the multi-operating system device includes a host operating system and multiple guest operating systems, each of the guest operating systems includes at least one partition, and the host operating system has the partition read and write permissions of each guest operating system;

[0005] The differential upgrade method comprises:

[0006] Step S1, for each guest operating system to be upgraded, a differential upgrade package is prepared and released according to the system type of the partition to be upgraded in the guest operating system and the available memory of the host operating system;

[0007] The differential upgrade package includes a differential file and a corresponding upgrade script file;

[0008] Step S2, the host operating system obtains the differential upgrade package and performs verification to determine whether the verification is successful:

[0009] If not, it will prompt that the upgrade failed and exit;

[0010] If yes, the host operating system parses the differential upgrade package to obtain the differential file and the upgrade script file, and then turns to step S3;

[0011] Step S3: for each partition to be upgraded of each guest operating system, the host operating system determines whether the system type of the partition is a fourth-generation extended file system:

[0012] If yes, modify the partition data of the partition according to the corresponding differential file and the upgrade script file, and then go to step S4;

[0013] If not, a restoration operation is performed based on the obtained source version of the partition and the differential file to obtain a target version, and the target version is written back to the partition, and then the process goes to step S4;

[0014] Step S4, repeating step S3 until all the partitions to be upgraded of all the guest operating systems are upgraded.

[0015] Preferably, the step S1 comprises:

[0016] Step S11, obtaining the system type of the partition to be upgraded of the guest operating system, and determining for each partition whether the system type is a file system type:

[0017] If yes, go to step S12;

[0018] If not, go to step S14;

[0019] Step S12, determining whether the file system type is a fourth-generation extended file system:

[0020] If yes, a source version and a target version corresponding to the partition are obtained, and the corresponding differential file and the upgrade script file are generated according to the difference of each file between the source version and the target version;

[0021] If not, go to step S13;

[0022] Step S13, determining whether the file system type can be recognized and mounted by the host operating system:

[0023] If yes, then performing a differential operation on each of the files according to the source version and the target version to obtain the corresponding differential file and recording the file attributes of each of the files in the upgrade script file;

[0024] If not, go to step S14;

[0025] Step S14, obtaining the available memory of the host operating system, obtaining the memory required for the upgrade according to the source version and the target version of the partition, and performing a differential operation on the memory required for the upgrade and the available memory to obtain the corresponding differential file and the upgrade script file;

[0026] Step S15: generating the differential upgrade package of the guest operating system according to the differential files of all the partitions to be upgraded of the guest operating system and the upgrade script file.

[0027] Preferably, in step S12, when the file system type is the fourth-generation extended file system, the generation process of the differential file and the upgrade script file includes:

[0028] For the file data area in the fourth-generation extended file system, compare the source version and each file in the target version corresponding to the file data area, and generate the corresponding differential file and the upgrade script file according to the differences in the file content and storage location of each file between the source version and the target version;

[0029] For the non-file data area in the fourth-generation extended file system, the non-data files in the non-file data area are read from the target version, and the non-data files are stored in a full-package manner as the differential file. The storage location of the non-data files in the target version is recorded in the upgrade script file, and a full-package write command is configured in the upgrade script file as an upgrade processing command for the file.

[0030] Preferably, the differences in the file content and the storage location include:

[0031] If the file is in the source version but not in the target version, then in step S12, the storage location of the file in the source version is recorded in the upgrade script file, and a delete command is configured in the upgrade script file as an upgrade processing command for the file; or

[0032] If the file is not in the source version but in the target version, then in step S12, the file is used as a differential file, the storage location of the file in the target version is recorded in the upgrade script file, and an insert command is configured in the upgrade script file as an upgrade processing command for the file; or

[0033] If the file is stored in different locations in the source version and the target version respectively and the file content of the file remains unchanged, then in step S12, the storage location of the file in the target version is recorded in the upgrade script file, and a move command is configured in the upgrade script file as an upgrade processing command for the file; or

[0034] If the file is in both the source version and the target version and the content of the file has changed, a differential operation is performed on the file in the source version and the target version to obtain the differential file, the storage location of the file in the target version is recorded in the upgrade script file, and a restore command is configured in the upgrade script file as an upgrade processing command for the file.

[0035] Preferably, the step S14 includes:

[0036] Step S141, obtaining the available memory of the host operating system, obtaining the memory required for upgrading according to the source version and the target version of the partition, and determining whether the memory required for upgrading is less than the available memory:

[0037] If yes, perform a differential operation on the source version and the target version corresponding to the partition to obtain the differential file, and then go to step S15;

[0038] If not, the source version and the target version are divided into multiple data blocks, and the memory required for the upgrade of each data block is smaller than the available memory, and then the process goes to step S142;

[0039] Step S142, performing differential operation on each of the data blocks in sequence according to the block order to obtain the differential file.

[0040] Preferably, before executing the step S15, the method further includes recording the hash values ​​of the source version and the target version of each partition to be upgraded in the upgrade script file.

[0041] Preferably, step S2 comprises:

[0042] Step S21, the host operating system obtains the differential upgrade package and performs a validity check on the differential upgrade package to determine whether the check is successful:

[0043] If not, it will prompt that the upgrade failed and exit;

[0044] If yes, go to step S22;

[0045] Step S22, the host operating system reads the partition data of each partition that needs differential upgrade in all the guest operating systems to be upgraded, calculates the hash value of the partition data, and determines whether the hash value is consistent with the hash value of the source version recorded in the differential upgrade package:

[0046] If yes, the host operating system parses the differential upgrade package to obtain the differential file and the upgrade script file, and then turns to step S3;

[0047] If not, it will prompt that the upgrade failed and exit.

[0048] Preferably, in step S3, after modifying the partition data of the partition according to the corresponding differential file and the upgrade script file, the method further includes:

[0049] Calculate the hash value of the modified partition data, and determine whether the hash value is consistent with the hash value of the target version recorded in the differential upgrade package:

[0050] If yes, go to step S4;

[0051] If not, exit with an error.

[0052] Preferably, in step S3, after writing the target version back to the partition, the step further includes:

[0053] Calculate the hash value of the partition data written back to the partition, and determine whether the hash value is consistent with the hash value of the target version:

[0054] If yes, go to step S4;

[0055] If not, exit with an error.

[0056] Preferably, when the hash value of the partition data written back to the partition is inconsistent with the hash value of the target version, a process of repeatedly performing the write-back action is further included, including:

[0057] Step A1, the host operating system repeatedly executes a write-back action of writing the target version back to the partition, and after executing the write-back action, determines whether the hash value of the partition data is consistent with the hash value of the target version:

[0058] If yes, go to step S4;

[0059] If not, go to step A2;

[0060] Step A2, the host operating system counts the number of repeated executions of the write-back action, and determines whether the number of repeated executions is less than a preset number:

[0061] If yes, return to step A1;

[0062] If not, exit with an error.

[0063] The above technical solution has the following advantages or beneficial effects:

[0064] 1) A differential upgrade package is produced according to the system type of the partition to be upgraded in the guest operating system and the available memory of the host operating system, so as to achieve a balance between a smaller upgrade package, a faster upgrade speed and a smaller memory consumption;

[0065] 2) All guest operating systems are upgraded simultaneously, effectively shortening the overall upgrade time and improving user experience;

[0066] 3) Differentiated upgrade methods are adopted according to the system type of the partition to be upgraded in the guest operating system to meet the upgrade requirements of partitions of different system types. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] Figure 1 A flowchart of a differential upgrade method for a multi-operating system device in a preferred embodiment of the present invention;

[0068] Figure 2 A schematic diagram of a process flow of making a differential upgrade package in a preferred embodiment of the present invention;

[0069] Figure 3 This is a flow chart of generating a differential file and an upgrade script file according to the available memory of the host operating system and the memory required for the upgrade in a preferred embodiment of the present invention;

[0070] Figure 4 A schematic diagram of a flow chart of a differential upgrade package verification process in a preferred embodiment of the present invention;

[0071] Figure 5 FIG. 4 is a flow chart of a process of repeatedly executing a write-back action in a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0072] The present invention is described in detail below in conjunction with the accompanying drawings and specific embodiments. The present invention is not limited to this embodiment, and other embodiments may also fall within the scope of the present invention as long as they conform to the gist of the present invention.

[0073] In a preferred embodiment of the present invention, based on the above problems existing in the prior art, a differential upgrade method for a multi-operating system device is provided, wherein the multi-operating system device includes a host operating system and multiple guest operating systems, each guest operating system includes at least one partition, and the host operating system has the partition read and write permissions of each guest operating system;

[0074] like Figure 1 As shown, the differential upgrade method includes:

[0075] Step S1, for each guest operating system to be upgraded, a differential upgrade package is prepared and released according to the system type of the partition to be upgraded in the guest operating system and the available memory of the host operating system;

[0076] The differential upgrade package includes the differential file and the corresponding upgrade script file;

[0077] Step S2: The host operating system obtains the differential upgrade package and verifies whether the verification is successful:

[0078] If not, it will prompt that the upgrade failed and exit;

[0079] If yes, the host operating system parses the differential upgrade package to obtain a differential file and an upgrade script file, and then turns to step S3;

[0080] Step S3: for each partition to be upgraded of each guest operating system, the host operating system determines whether the system type of the partition is a fourth-generation extended file system:

[0081] If yes, the partition data of the partition is modified according to the corresponding differential file and the upgrade script file, and then the process goes to step S4;

[0082] If not, a restoration operation is performed based on the obtained source version of the partition and the differential file to obtain a target version, and the target version is written back to the partition, and then the process goes to step S4;

[0083] Step S4, repeating step S3 until all partitions to be upgraded of all guest operating systems are upgraded.

[0084] Specifically, in this embodiment, the multi-operating system device of the present technical solution can be connected to a remote server, and the manufacturer of the multi-operating system device can save the source version and the target version in the remote server. At the same time, the remote server can be configured with a differential package production tool, and step S1 is executed by the differential package production tool to produce and publish a differential upgrade package. When the multi-operating system device detects the published differential upgrade package, the remote server downloads the differential upgrade package for upgrading. As a preferred embodiment, the above-mentioned differential package production tool can be configured on a production terminal, and the production terminal is connected to the above-mentioned remote server. After the differential upgrade package is produced, the differential upgrade package is published on the remote server. When the multi-operating system device detects the published differential upgrade package, the remote server downloads the differential upgrade package for upgrading. Preferably, the above-mentioned production terminal can be a computer terminal, and the computer terminal can be configured in the manufacturer of the multi-operating system device.

[0085] Preferably, the host operating system may be pre-configured with a corresponding upgrade boot program, through which the differential upgrade process of each partition to be upgraded of each guest operating system is implemented. The upgrade boot program may be a UA upgrade program.

[0086] As a preferred implementation, the upgrade script file may correspond to the guest operating system one-to-one, in other words, one upgrade script file is generated for each guest operating system to be upgraded. The upgrade script file may also correspond to the partition to be upgraded one-to-one, in other words, one upgrade script file is generated for each partition to be upgraded. Configuration may be performed according to requirements, wherein one upgrade script file is generated for each partition to be upgraded, which may allow for more flexible configuration of the upgrade process, such as independent configuration of the verification method for each partition.

[0087] Further, as a preferred embodiment, Figure 2 As shown, step S1 includes:

[0088] Step S11, obtaining the system type of the partition to be upgraded of the guest operating system, and determining for each partition whether the system type is a file system type:

[0089] If yes, go to step S12;

[0090] If not, go to step S14;

[0091] Step S12, determining whether the file system type is a fourth-generation extended file system:

[0092] If yes, obtain a source version and a target version corresponding to the partition, and generate corresponding differential files and upgrade script files according to the differences between the files of the source version and the target version;

[0093] If not, go to step S13;

[0094] Step S13, determine whether the file system type can be recognized and mounted by the host operating system:

[0095] If yes, then the files are differentiated according to the source version and the target version to obtain the corresponding differential files and the file attributes of each file are recorded in the upgrade script file;

[0096] If not, go to step S14;

[0097] Step S14, obtaining the available memory of the host operating system, processing the required memory for the upgrade according to the source version and the target version of the partition, and performing a differential operation on the required memory for the upgrade and the available memory to obtain a corresponding differential file and an upgrade script file;

[0098] Step S15, generating a differential upgrade package of the guest operating system according to the differential files of all partitions to be upgraded of the guest operating system and the upgrade script file.

[0099] Specifically, in this embodiment, when making a differential upgrade package, the size of the differential upgrade package, the upgrade time, and the available memory of the host operating system are comprehensively considered to achieve a balance between a smaller upgrade package, a faster upgrade speed, and smaller memory consumption. More specifically, each guest operating system usually includes multiple partitions, and during an upgrade, only one or several of the partitions may need to be upgraded. For the partition that needs to be upgraded, its system type is obtained in advance, and the system type includes a file system type and a non-file system type, wherein the file system type is subdivided into a fourth-generation extended file system (ext4), a file system type that is not a fourth-generation extended file system but can be recognized and mounted normally by the host operating system, and other file system types except the above two types. The present technical solution adopts different differential package production methods for the above four system types.

[0100] Among them, for the fourth-generation extended file system, corresponding differential files and upgrade script files are generated according to the differences between each file between the source version and the target version. As a preference, if the release versions of the above-mentioned source version and target version are sparse type ext4 images, they need to be converted into raw type ext4 images first, and then the source version and the target version are parsed to obtain the storage path, file name and storage position of each file in the partition in the source version and the target version in the ext4 image in units of 4k, and then generate corresponding differential files and upgrade script files based on the differences between each file between the source version and the target version.

[0101] In this embodiment, the fourth-generation extended file system is further subdivided into a file data area and a non-file data area. In step S12, when the file system type is the fourth-generation extended file system, the generation process of the differential file and the upgrade script file includes:

[0102] For the file data area in the fourth-generation extended file system, compare the files in the source version and the target version corresponding to the file data area, and generate corresponding differential files and upgrade script files according to the differences in the file content and storage location of each file between the source version and the target version;

[0103] For the non-file data area in the fourth-generation extended file system, the non-data files in the non-file data area are read from the target version, and the non-data files are stored in a full-package manner as differential files. The storage location of the non-data files in the target version is recorded in the upgrade script file, and a full-package write command is configured in the upgrade script file as an upgrade processing command for the file.

[0104] The non-file data area includes but is not limited to the metadata area including the super block, GPT (GUID partition table, GUID is a globally unique identifier), inode table (index table), bmap (bitmap), data required to be stored by the dm-verity (file system verification) function, and other data merged into the ext4 image to realize certain special functions.

[0105] In this embodiment, the differences in the above file contents and storage locations include:

[0106] If the file is in the source version but not in the target version, then in step S12, the storage location of the file in the source version is recorded in the upgrade script file, and a delete command is configured in the upgrade script file as an upgrade processing command for the file; or

[0107] If the file is not in the source version but in the target version, then in step S12, the file is taken as a differential file, the storage location of the file in the target version is recorded in the upgrade script file, and an insert command is configured in the upgrade script file as an upgrade processing command for the file; or

[0108] If the file is stored in different locations in the source version and the target version and the file content remains unchanged, then in step S12, the storage location of the file in the target version is recorded in the upgrade script file, and a move command is configured in the upgrade script file as an upgrade processing command for the file; or

[0109] If a file exists in both the source version and the target version and the file content has changed, a differential operation is performed on the file in the source version and the target version to obtain a differential file, the storage location of the file in the target version is recorded in the upgrade script file, and a restore command is configured in the upgrade script file as the upgrade processing command for the file.

[0110] Specifically, in this embodiment, for files that exist in the source version but not in the target version, there is no need to generate a differential file. It is only necessary to record the storage location of the file in the source version in the upgrade script file and configure a delete command, so that when the subsequent upgrade is performed, the host operating system deletes the file in the source version according to the storage location recorded in the upgrade script file, and completes the differential upgrade of the file. For files that exist in the target version but do not exist in the source version, that is, the file is a new file in the target version, at this time, the file is used as a differential file, and its storage location in the target version is recorded in the upgrade script file and an insert command is configured, so that when the subsequent upgrade is performed, the host operating system executes the insert command in the upgrade script file, inserts the above differential file into the recorded storage location, and completes the differential upgrade of the file. For files that exist in both the source version and the target version and whose file content has not changed but whose storage location has changed, there is no need to generate a differential file. It is only necessary to record its storage location in the target version in the upgrade script and configure a move command, so that when the subsequent upgrade is performed, the host operating system moves the file in the source version to the storage location according to the storage location recorded in the upgrade script file, and completes the differential upgrade of the file. For files that exist in both the source version and the target version and whose file content has changed, a differential file is generated regardless of whether its storage location has changed. Its storage location in the target version is recorded in the upgrade script file and a restore command is configured so that during subsequent upgrades, the host operating system executes the restore command to perform an inverse differential operation to complete the differential upgrade of the file.

[0111] Preferably, the file names of the files in the source version and the target version can be compared to determine whether the corresponding file exists in the source version or the target version, and the source version and the target version can be accessed through the above storage path to determine whether the file content of the corresponding file has changed.

[0112] In a preferred embodiment of the present invention, Figure 3 As shown, step S14 includes:

[0113] Step S141, obtain the available memory of the host operating system, obtain the memory required for the upgrade according to the source version and the target version of the partition, and determine whether the memory required for the upgrade is less than the available memory:

[0114] If yes, perform a differential operation on the source version and the target version corresponding to the partition to obtain a differential file, and then go to step S15;

[0115] If not, the source version and the target version are divided into multiple data blocks, and the memory required for upgrading each data block is less than the available memory, and then the process goes to step S142;

[0116] Step S142, performing differential operations on each data block in sequence according to the block order to obtain a differential file.

[0117] In a preferred embodiment of the present invention, before executing step S15, the method further includes recording the hash values ​​of the source version and the target version of each partition to be upgraded in the upgrade script file for verification before subsequent upgrades.

[0118] In a preferred embodiment of the present invention, Figure 4 As shown, step S2 includes:

[0119] Step S21, the host operating system obtains the differential upgrade package and performs a validity check on the differential upgrade package to determine whether the check is successful:

[0120] If not, it will prompt that the upgrade failed and exit;

[0121] If yes, go to step S22;

[0122] Step S22, the host operating system reads the partition data of each partition that needs differential upgrade in all guest operating systems to be upgraded, calculates the hash value of the partition data, and determines whether the hash value is consistent with the hash value of the source version recorded in the differential upgrade package:

[0123] If yes, the host operating system parses the differential upgrade package to obtain a differential file and an upgrade script file, and then turns to step S3;

[0124] If not, it will prompt that the upgrade failed and exit.

[0125] Specifically, in this embodiment, the host operating system reads the partition data of each partition that needs to be differentially upgraded in all guest operating systems to be upgraded, and performs hash value verification. This verification method is preferably applied to scenarios where there are multiple guest operating systems at the same time, such as two guest operating systems, and there is a certain correlation between the two guest operating systems. For example, the two guest operating systems need to have a preset version difference to ensure the normal operation of a certain function of the multi-operating system device. Even if the hash value verification of one of the guest operating systems is successful, the upgrade will not be performed, so as to avoid the normal operation of the multi-operating system device being affected by the upgrade of a single guest operating system.

[0126] As a preferred implementation, the above-mentioned hash value verification method can also be applied to scenarios where multiple guest operating systems are completely independent. In theory, when all partitions of a single guest operating system that require differential upgrades pass hash verification, the single guest operating system can be upgraded independently. However, the upgraded version of the guest operating system may differ from the source version stored in the remote server, causing inconvenience in the production of subsequent differential upgrade packages.

[0127] In a preferred embodiment of the present invention, in step S3, after the partition data of the partition is modified according to the corresponding differential file and the upgrade script file, it also includes:

[0128] Calculate the hash value of the modified partition data and determine whether the hash value is consistent with the hash value of the target version recorded in the differential upgrade package:

[0129] If yes, go to step S4;

[0130] If not, exit with an error.

[0131] Specifically, in this embodiment, according to the upgrade processing command recorded in the upgrade script file, the above modification may be deletion, insertion, movement and restoration.

[0132] In a preferred embodiment of the present invention, in step S3, after writing the target version back to the partition, the method further includes:

[0133] Calculate the hash value of the partition data written back to the partition, and determine whether the hash value is consistent with the hash value of the target version:

[0134] If yes, go to step S4;

[0135] If not, exit with an error.

[0136] In a preferred embodiment of the present invention, when the hash value of the partition data written back to the partition is inconsistent with the hash value of the target version, a process of repeatedly performing the write-back action is also included, such as Figure 5 As shown, including:

[0137] Step A1, the host operating system repeatedly executes the write-back action of writing the target version back to the partition, and after executing the write-back action, determines whether the hash value of the partition data is consistent with the hash value of the target version:

[0138] If yes, go to step S4;

[0139] If not, go to step A2;

[0140] Step A2: The host operating system counts the number of repetitions of the write-back action and determines whether the number of repetitions is less than a preset number:

[0141] If yes, return to step A1;

[0142] If not, exit with an error.

[0143] Specifically, in this embodiment, the above-mentioned preset number of times can be three times. When the hash value verification is inconsistent, by repeating the write-back action, it can avoid upgrade failures due to unstable operation of multiple operating system devices and the like, thereby improving the upgrade success rate. At the same time, the number of repeated executions is limited to avoid upgrade failures due to other reasons and repeated write-backs taking up too long an upgrade time.

[0144] The above description is only a preferred embodiment of the present invention, and does not limit the implementation mode and protection scope of the present invention. For those skilled in the art, it should be aware that all solutions obtained by equivalent substitutions and obvious changes made using the contents of this specification and illustrations should be included in the protection scope of the present invention.

Claims

1. A differential upgrade method for a multi-operating system device, characterized in that: The multi-operating system device includes a host operating system and multiple guest operating systems, each of the guest operating systems includes at least one partition, and the host operating system has the partition read and write permissions of each guest operating system; The differential upgrade method comprises: Step S1, for each guest operating system to be upgraded, a differential upgrade package is prepared and released according to the system type of the partition to be upgraded in the guest operating system and the available memory of the host operating system; The differential upgrade package includes a differential file and a corresponding upgrade script file; Step S2, the host operating system obtains the differential upgrade package and performs verification to determine whether the verification is successful: If not, it will prompt that the upgrade failed and exit; If yes, the host operating system parses the differential upgrade package to obtain the differential file and the upgrade script file, and then turns to step S3; Step S3: for each partition to be upgraded of each guest operating system, the host operating system determines whether the system type of the partition is a fourth-generation extended file system: If yes, modify the partition data of the partition according to the corresponding differential file and the upgrade script file, and then go to step S4; If not, a restoration operation is performed based on the obtained source version of the partition and the differential file to obtain a target version, and the target version is written back to the partition, and then the process goes to step S4; Step S4, repeating step S3 until all the partitions to be upgraded of all the guest operating systems are upgraded.

2. The differential upgrade method according to claim 1, characterized in that: The step S1 comprises: Step S11, obtaining the system type of the partition to be upgraded of the guest operating system, and determining for each partition whether the system type is a file system type: If yes, go to step S12; If not, go to step S14; Step S12, determining whether the file system type is a fourth-generation extended file system: If yes, a source version and a target version corresponding to the partition are obtained, and the corresponding differential file and the upgrade script file are generated according to the difference of each file between the source version and the target version; If not, go to step S13; Step S13, determining whether the file system type can be recognized and mounted by the host operating system: If yes, then performing a differential operation on each of the files according to the source version and the target version to obtain the corresponding differential file and recording the file attributes of each of the files in the upgrade script file; If not, go to step S14; Step S14, obtaining the available memory of the host operating system, obtaining the memory required for the upgrade according to the source version and the target version of the partition, and performing a differential operation on the memory required for the upgrade and the available memory to obtain the corresponding differential file and the upgrade script file; Step S15: generating the differential upgrade package of the guest operating system according to the differential files of all the partitions to be upgraded of the guest operating system and the upgrade script file.

3. The differential upgrade method according to claim 2, characterized in that: In step S12, when the file system type is the fourth-generation extended file system, the generation process of the differential file and the upgrade script file includes: For the file data area in the fourth-generation extended file system, compare the source version and each file in the target version corresponding to the file data area, and generate the corresponding differential file and the upgrade script file according to the differences in the file content and storage location of each file between the source version and the target version; For the non-file data area in the fourth-generation extended file system, the non-data files in the non-file data area are read from the target version, and the non-data files are stored in a full-package manner as the differential file. The storage location of the non-data files in the target version is recorded in the upgrade script file, and a full-package write command is configured in the upgrade script file as an upgrade processing command for the file.

4. The differential upgrade method according to claim 3, characterized in that: The differences in the file contents and the storage locations include: If the file is in the source version but not in the target version, then in step S12, the storage location of the file in the source version is recorded in the upgrade script file, and a delete command is configured in the upgrade script file as an upgrade processing command for the file; or If the file is not in the source version but in the target version, then in step S12, the file is used as a differential file, the storage location of the file in the target version is recorded in the upgrade script file, and an insert command is configured in the upgrade script file as an upgrade processing command for the file; or If the file is stored in different locations in the source version and the target version respectively and the file content of the file remains unchanged, then in step S12, the storage location of the file in the target version is recorded in the upgrade script file, and a move command is configured in the upgrade script file as an upgrade processing command for the file; or If the file is in both the source version and the target version and the content of the file has changed, a differential operation is performed on the file in the source version and the target version to obtain the differential file, the storage location of the file in the target version is recorded in the upgrade script file, and a restore command is configured in the upgrade script file as an upgrade processing command for the file.

5. The differential upgrade method according to claim 2, characterized in that: The step S14 comprises: Step S141, obtaining the available memory of the host operating system, obtaining the memory required for upgrading according to the source version and the target version of the partition, and determining whether the memory required for upgrading is less than the available memory: If yes, perform a differential operation on the source version and the target version corresponding to the partition to obtain the differential file, and then go to step S15; If not, the source version and the target version are divided into multiple data blocks, and the memory required for the upgrade of each data block is smaller than the available memory, and then the process goes to step S142; Step S142, performing differential operation on each of the data blocks in sequence according to the block order to obtain the differential file.

6. The differential upgrade method according to claim 2, characterized in that: Before executing the step S15, the method further includes recording the hash values ​​of the source version and the target version of each partition to be upgraded in the upgrade script file.

7. The differential upgrade method according to claim 6, characterized in that: The step S2 comprises: Step S21, the host operating system obtains the differential upgrade package and performs a validity check on the differential upgrade package to determine whether the check is successful: If not, it will prompt that the upgrade failed and exit; If yes, go to step S22; Step S22, the host operating system reads the partition data of each partition that needs differential upgrade in all the guest operating systems to be upgraded, calculates the hash value of the partition data, and determines whether the hash value is consistent with the hash value of the source version recorded in the differential upgrade package: If yes, the host operating system parses the differential upgrade package to obtain the differential file and the upgrade script file, and then turns to step S3; If not, it will prompt that the upgrade failed and exit.

8. The differential upgrade method according to claim 6, characterized in that: In the step S3, after the partition data of the partition is modified according to the corresponding differential file and the upgrade script file, the method further includes: Calculate the hash value of the modified partition data, and determine whether the hash value is consistent with the hash value of the target version recorded in the differential upgrade package: If yes, go to step S4; If not, exit with an error.

9. The differential upgrade method according to claim 6, characterized in that: In the step S3, after writing the target version back to the partition, the step further includes: Calculate the hash value of the partition data written back to the partition, and determine whether the hash value is consistent with the hash value of the target version: If yes, go to step S4; If not, exit with an error.

10. The differential upgrade method according to claim 9, characterized in that: When the hash value of the partition data written back to the partition is inconsistent with the hash value of the target version, a process of repeatedly performing the write-back action is also included, including: Step A1, the host operating system repeatedly executes a write-back action of writing the target version back to the partition, and after executing the write-back action, determines whether the hash value of the partition data is consistent with the hash value of the target version: If yes, go to step S4; If not, go to step A2; Step A2, the host operating system counts the number of repeated executions of the write-back action, and determines whether the number of repeated executions is less than a preset number: If yes, return to step A1; If not, exit with an error.

Images