OSTree-based system upgrade method

Abstract

The application relates to the technical field of OSTree, and specifically provides a system upgrading method based on OSTree, which comprises the following steps: compiling a Linux system version VersionB; after the compiling is completed, pushing rootfs and kernel files of the VersionB into an OSTree remote warehouse through a commit and push instruction of the OSTree, taking the VersionB as a version identifier; pulling a system version VersionA and the system version VersionB in the OSTree remote warehouse to an OSTree local warehouse; and making an OSTree upgrading file for upgrading from the VersionA to the VersionB in the OSTree local warehouse. Through the above scheme, the distribution problem existing in the OSTree updating is solved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of OSTree, and particularly provides a system upgrading method based on OSTree. BACKGROUND

[0002] In the field of industrial control and robot control, the use of Linux embedded operating system is increasing. However, after the Linux system is deployed to the terminal device, the update and upgrade of the system image usually need to be physically deployed again, which cannot ensure the best operation experience and system uptime. In order to improve the upgrade experience of the Linux system, safe remote OTA upgrade becomes an urgent demand.

[0003] The Linux upgrade system based on the OSTree modification has a very small amount of data transmission in the upgrade process, and has a wide application value. The principle of OSTree is a content-addressed storage mechanism, which uniquely identifies all files, directories and commits in the root file system through SHA-256 hash values, and objects with the same content have the same hash value, thereby avoiding repeated storage. The Linux upgrade system based on OSTree constructs a file system through three core object types of file objects (storing file content and permission / ownership metadata), directory objects (containing hash references and metadata of subdirectories / files) and metadata commit objects (pointing to root directory hash, containing timestamp and parent commit information), forming a complete versioned file system structure.

[0004] The update process of OSTree is divided into four steps: first, the target commit hash value is obtained through the specified remote reference, then the corresponding commit object is downloaded from the remote repository, and the root directory hash value is parsed; then all the hash values of the subdirectories and files under the root directory are recursively traversed, and finally the comparison check of the local object repository is performed, only the missing objects are downloaded to complete the incremental synchronization, and the local branch is updated to point to the new commit.

[0005] However, this update mechanism has two main defects: ① OSTree pull itself does not directly handle the transmission protocol, and completely depends on the underlying transmission library (such as libcurl) to realize the protocol support of HTTP / HTTPS / file, which limits the optimization of the protocol layer; ② Many companies already have upgrade background management systems, which are mostly for the management of upgrade files, and to support OSTree update, a lot of management construction for OSTree repository needs to be done, which has a large compatibility task, is not convenient for the promotion of the Linux upgrade system based on OSTree, and the current update mechanism needs to manage the synchronization of the remote OSTree repository and the medium OSTree repository, and the synchronization of the medium OSTree repository and the device OSTree repository, which is very cumbersome and prone to errors. Summary of the Invention

[0006] This invention addresses the distribution issues that exist during OSTree updates by making full use of other existing upgrade backend management systems, reducing OSTree updates' reliance on uncontrollable underlying libraries, enhancing optimization for network transmission, and ensuring compatibility with offline media such as USB and SD cards, thereby increasing the convenience of OSTree updates in offline scenarios.

[0007] This invention proposes a system upgrade method based on OSTree, comprising the following steps:

[0008] Compile Linux version Version B that can run on device D1 with Linux version Version A installed;

[0009] After compilation, the rootfs and kernel files of Linux system version Version B are pushed to the OSTree remote repository containing Linux system version Version A using OSTree commit and push commands, with Version B as the version identifier.

[0010] Pull Linux system versions Version A and Version B from the OSTree remote repository to the OSTree local repository;

[0011] Create an OSTree upgrade file in the local OSTree repository to upgrade the Linux system version from Version A to Version B. The OSTree upgrade file uses Linux system version A as the source version and Linux system version B as the target version.

[0012] Furthermore, the step of pulling Linux system version Version A and Linux system version Version B from the OSTree remote repository to the OSTree local repository includes:

[0013] Create a working directory and allocate the corresponding operating space on the working machine S3 used to create the OSTree upgrade file;

[0014] Enter the working directory, use the OSTree initialization command to create the OSTree local repository directory, and bind the OSTree remote repository address;

[0015] The OSTree pull command will pull all relevant object files from the OSTree remote repository, with version identifiers VersionA and VersionB as reference parameters, to the OSTree local repository.

[0016] Further, the OSTree upgrade file from the Linux system version Version A to the Linux system version Version B in the OSTree local repository is made, comprising:

[0017] Opening the OSTree local repository;

[0018] Creating a source version object hash table, a target version object hash table, an added attribute metadata hash table, an added ordinary file hash table, an added symbolic link hash table, a content modification table hash table and an optimized content modification table hash table;

[0019] According to the Linux system version Version A and the Linux system version Version B, the corresponding objects are stored in the source version object hash table, the target version object hash table, the added attribute metadata hash table, the added ordinary file hash table, the added symbolic link hash table and the content modification table hash table, and the optimized content modification table hash table is obtained based on the content modification table hash table;

[0020] Defining logical slice types and operation codes, generating atomic operation sequences and rollback instruction sets;

[0021] Building slice data blocks and Merkle trees, and associating indexes to obtain complete slice index blocks;

[0022] Creating a file header descriptor;

[0023] Writing the file header descriptor, all slice data blocks, slice index blocks and rollback instruction sets in sequence to generate the OSTree upgrade file.

[0024] Further, the OSTree upgrade file from the Linux system version Version A to the Linux system version Version B in the OSTree local repository is made, comprising:

[0025] If the source version exists, the metadata of the source version is loaded, and the hash values of all objects contained by the source version are stored in the source version object hash table, and the metadata of the target version is loaded, and the hash values of all objects contained by the target version are stored in the target version object hash table;

[0026] Traverse the target version object hash table, for the object file not appearing in the source version object hash table, write the object file not appearing in the source version object hash table into the corresponding new attribute metadata hash table, new ordinary file hash table or new symbolic link hash table according to the type of the object file, for the object file appearing in the source version object hash table but different hash values, record the source version hash value and the target version hash value of the object file as an entry into the content modification table hash table;

[0027] Introduce a content-aware difference engine to optimize the content in the content modification hash table, and generate a difference result and store it in the optimized content modification hash table.

[0028] Further, the definition logic slice type and operation code, generate atomic operation sequence and rollback instruction set, including:

[0029] According to the source of the change content and the difference result, define the operation code, which is used to guide the operation of the device end when upgrading the application, and introduce a new operation code with transaction control capability;

[0030] Traverse the new attribute metadata hash table, the new ordinary file hash table, the new symbolic link hash table and the optimized content modification hash table, and convert each change item into one or more atomic operation instructions using the operation code. All atomic operation instructions are organized into an atomic operation sequence.

[0031] For the database and structured file modification in content-aware difference, the corresponding rollback instruction set is generated synchronously.

[0032] Further, the construction of slice data block and Merkle tree, and the association index get the complete slice index block, including:

[0033] Traverse the new ordinary file hash table, the new symbolic link hash table, the new attribute metadata hash table and the optimized content modification hash table, and compress the data content of each entry in them and add a data block header to form a slice data block.

[0034] The hash values of all generated slice data blocks are used as leaf nodes of the Merkle tree. By pairing adjacent hash values two by two and hashing again, the tree is constructed layer by layer upwards until a unique tree root hash value is generated. The tree root hash value is used as the unique integrity credential of the entire data slice area and is written into the file header.

[0035] Traverse the atomic operation sequence, and for each instruction in the sequence that needs data, associate the corresponding slice data block information to get the complete slice index block. The slice data block information includes the physical offset of the data block in the file, the length of the data block in the file and the location information of the data block in the Merkle tree.

[0036] Further, the creating the file header descriptor comprises:

[0037] According to the size of all data block areas, index block areas, and rollback instruction set areas to be written, the respective starting offsets are calculated.

[0038] The file header descriptor is constructed, and the file header descriptor contains core meta-information describing the entire OSTree upgrade file.

[0039] Further, the OSTree upgrade file is further encrypted by using a preset key file to generate an OSTree encrypted upgrade file, and the OSTree encrypted upgrade file is further transmitted.

[0040] Further, the transmitting the OSTree encrypted upgrade file comprises:

[0041] The OSTree encrypted upgrade file is uploaded to the background through the original upgrade management background, and an upgrade task is configured in the background, the OSTree encrypted upgrade file is pushed to the device D1, the upgrade task is obtained from the upgrade background in a cycle, the OSTree encrypted upgrade file is downloaded to the device D1 according to the upgrade task configuration, and is placed in a specified directory; or

[0042] The OSTree encrypted upgrade file is stored in a specified directory of the device D1 through a USB disk or an SD card; or

[0043] The OSTree encrypted upgrade file is obtained through a network command or through a browser from a specified network address on the device D1, and is placed in a specified directory of the device D1.

[0044] Further, the OSTree encrypted upgrade file is further encrypted by using a preset key file to generate an OSTree upgrade file, and the OSTree upgrade file is applied.

[0045] Working principle and beneficial effects of the present application:

[0046] The version difference data is encapsulated together with the atomized operation log and the state rollback instruction, which fundamentally guarantees the transaction and atomicity of the device end upgrade process. A Merkle tree is constructed to provide strong integrity proof for all data fragments. The operation sequence, security check, transaction control, and emergency plan are encapsulated into the upgrade file, so that the upgrade file not only contains version differences, but also embeds complete transaction control capability and end-to-end trust chain. DETAILED DESCRIPTION

[0047] Some embodiments of the present application will be described below. Those skilled in the art should understand that these embodiments are only used to explain the technical principles of the present application, and are not intended to limit the protection scope of the present application.

[0048] The application provides an OSTree-based system upgrading method. The core of the method is that a complete upgrading flow, including operation sequence, security check, transaction control and emergency plan, is encapsulated into an upgrading file by an innovative file format design, so that the upgrading file not only contains version difference, but also embeds complete transaction control capability and end-to-end trust chain. The specific implementation includes:

[0049] In the production stage, the version difference data is encapsulated together with the atomized operation log and the state rollback instruction, so as to fundamentally ensure the transaction and atomicity of the device end upgrading process.

[0050] A Merkle tree is constructed to provide strong integrity proof for all data fragments, and a double signature is introduced to build and distribute, so as to establish a trust chain from the development source to the deployment terminal, effectively resist tampering and illegal distribution.

[0051] In the application stage, the device strictly executes the update according to the embedded operation log, and performs health check after deployment. If the check fails, the rollback instruction can be automatically triggered to restore the system to the state before upgrading, so as to realize system self-healing in unattended scenario.

[0052] In order to achieve the purpose of the application, the following specific embodiments are combined to explain how to make, authorize and apply an OSTree static upgrading file containing complete upgrading logic through a preset implementation environment, including a remote repository server S1, a construction server S2, a work machine S3 and a target device D1, so as to solve the core problems of compatibility, reliability and offline update existing in the prior art.

[0053] In the embodiment of the application, the following device construction implementation environment is needed:

[0054] A server S1 for storing an OSTree remote repository, which contains a Linux system version Version A;

[0055] A server S2 for constructing a new Linux system version Version B;

[0056] A work machine S3 for making an OSTree upgrading file;

[0057] A device D1 which has installed a Linux system version Version A;

[0058] A group of keys including an offline key pair with high security level managed by the construction system, and an online key pair managed by the upgrading management platform.

[0059] This embodiment of the system upgrade method based on OSTree mainly revolves around creating and applying OSTree upgrade files. The process consists of three stages:

[0060] Example 1: Creating OSTree Upgrade Files

[0061] By traversing the associated objects in the OSTree repository corresponding to the old and new versions of the Linux system, newly added metadata, modified files and symbolic links are identified. Compression technology is used to extract and compress only the changed content between versions, generating incremental data blocks with high compression ratio. Metadata, fragment index, compressed data and other data are encapsulated into descriptor files and merged with incremental data fragment data to store them into OSTree upgrade files.

[0062] 1.1 Preparing Resources

[0063] The system reads user-input parameters, including the source version (Linux system version Version A in this embodiment), the target version (Linux system version Version B in this embodiment), and the OSTree upgrade file storage path. On the constructed server S2, a new Linux system version, Version B, is compiled that can run on device D1. After compilation, the rootfs, kernel, and other core files of Linux system version Version B are pushed to the OSTree remote repository on server S1 using OSTree commit and push commands, with Version B as the version identifier. At this point, the OSTree remote repository already contains the new Linux system version Version B.

[0064] 1.2 Preparing the environment for creating OSTree upgrade files

[0065] On the workstation S3, execute the OSTree upgrade file creation program to create an OSTree upgrade file from Linux system version A to Linux system version B. The OSTree upgrade file creation program first needs to pull the relevant version data of Linux system version A and Linux system version B from the OSTree remote repository on server S1 to the local environment of workstation S3 (i.e., the OSTree local repository).

[0066] 1.2.1 Create a working directory on the working machine S3, ensuring sufficient space for file operations.

[0067] 1.2.2 Enter the working directory, use the OSTree initialization command to create the OSTree local repository directory, and bind it to the OSTree remote repository address of server S1.

[0068] 1.2.3 Pull all related object files referenced by VersionA, VersionB in the OSTree remote repository in server S1 to the OSTree local repository in worker S3 by the OSTree pull instruction, so that all related object files referenced by VersionA and VersionB exist in the OSTree local repository.

[0069] 1.3, Making an OSTree upgrade file

[0070] 1.3.1 Open the OSTree local repository containing the source version and the target version on the worker S3.

[0071] 1.3.2 Initialize object tracking and create a series of hash tables for classified storage of difference information, including a source version object hash table, a target version object hash table, a new attribute metadata hash table, a new ordinary file hash table, a new symbolic link hash table, a content modification table hash table, and an optimized content modification table hash table.

[0072] 1.3.3 Load commit version information: if the source version exists, load the metadata of the source version VersionA and traverse and store the hash values of all objects (file objects, attribute metadata objects, symbolic link objects, etc.) contained in it into the source version object hash table. Similarly, load the metadata of the target version VersionB and traverse and store the hash values of all objects into the target version object hash table.

[0073] 1.3.4 Difference identification: traverse the target version object hash table and check whether each object file in it exists in the source version object hash table.

[0074] If the object file does not exist, it is determined to be a new object. According to its type (attribute metadata, ordinary file, symbolic link), its hash value is stored in the corresponding new attribute metadata hash table, new ordinary file hash table, or new symbolic link hash table.

[0075] If the object file exists but the hash values are different, it is determined to be a content modified file. The source version hash value and the target version hash value of the object file are recorded as an entry in the content modification table hash table.

[0076] 1.3.5 Content-aware intelligent difference and optimization processing: introduce a content-aware difference engine, which aims to select the optimal difference strategy according to the file type, so as to generate smaller and more reliable upgrade patches.

[0077] The content modification table hash table generated in step 1.3.4 is iterated, and for each modification file to be processed, the content-aware difference engine performs the following operations: first, through the preset rule library, the specific content type of the file is identified based on the file extension (such as.db.sqlite.json.xml.tar.zip) or the magic number in the file header. Then, according to the identified file type, the difference engine will call the optimal difference strategy. For example:

[0078] Case one: for SQLite database files (such as.db.sqlite) do not perform binary comparison. Instead, call the special database comparison module, connect the new and old versions of the database file, and compare the internal schema and data rows to generate a set of SQL statements (including UPDATE, INSERT, DELETE, ALTER TABLE, etc.) that can migrate the old database to the new database state. This set of SQL text is the "difference content" of the file.

[0079] Case two: for structured text files (such as JSON, XML, YAML), use structured comparison algorithms to parse the new and old files into data trees in memory. By comparing the node differences of the two trees, a compact patch (for example, a set of JSON Patch format instructions) is generated to describe the addition, deletion, and modification of nodes. This patch is the "difference content".

[0080] Case three: for archive files (such as TAR, ZIP), do not directly perform binary difference on the entire archive file. Instead, decompress the new and old archive files into temporary directories, and then recursively compare the contents of the two directories. The final "difference content" is a set of instructions or scripts that describe how to reconstruct the new archive file by adding, deleting, or replacing some member files based on the old archive. The newly added or modified member files are also packaged.

[0081] Case four: for general binary files, for any other files that cannot be identified or do not apply to the above special strategies (such as executable programs, library files), fall back to binary difference based on the Rollsum algorithm, and generate a binary patch as the "difference content".

[0082] Finally, the "difference content" generated by the above various strategies and their corresponding difference strategy types are stored in the optimized content modification hash table.

[0083] 1.3.6 Build OSTree upgrade file slice data and corresponding slice index:

[0084] The core of ensuring the atomicity and safe rollback capability of the device-side upgrade process. Based on the analysis results of steps 1.3.4 and 1.3.5, a series of precise and executable instructions are generated.

[0085] ① Define the type of logical fragmentation and operation code

[0086] According to the source of the change content and the result of intelligent difference, define more rich operation code, used to guide the operation of the device side when upgrading the application: ADD_FILE, ADD_SYMLINK, ADD_METADATA (used to add content), APPLY_BINARY_DIFF (used to apply general binary patch), APPLY_SQL_PATCH (used to execute SQL scripts for database migration), APPLY_STRUCTURAL_PATCH (used to apply structural patch of JSON / XML and other files), RECONSTRUCT_ARCHIVE (used to reconstruct the archive file according to the instruction set and new member file). In addition, introduce new operation codes with transaction control capability to form a complete execution logic. Including:

[0087] BEGIN_TRANSACTION: Mark the beginning of the upgrade transaction, and the device side starts to prepare the execution environment.

[0088] VERIFY_INTEGRITY: instruct the device side to use the Merkle tree root hash in the file header to verify the integrity of all subsequent data fragments.

[0089] PREPARE_ROLLBACK: instruct the device side to backup the specified file (such as database, key configuration) to the safe area, prepare for possible rollback.

[0090] COMMIT_TRANSACTION: After all operations are successfully applied, commit the OSTree changes and clean up the rollback backup.

[0091] VERIFY_PATCH_RESULT: used to execute verification logic to confirm whether the change is successful after applying key patches (such as SQL scripts).

[0092] ABORT_TRANSACTION: Trigger the rollback process when any error occurs during the upgrade process.

[0093] ② Generate atomic operation sequence

[0094] Traverse the new attribute metadata hash table, the new regular file hash table, the new symbolic link hash table, and the optimized content modification hash table, and convert each change into one or more atomic operation instructions using the above operation codes. These instructions are organized into an ordered list (i.e., transaction log) that precisely describes each step from verification, preparation, application to submission. For example, an update to a database file can be broken down into: PREPARE_ROLLBACK -> APPLY_SQL_PATCH -> VERIFY_PATCH_RESULT.

[0095] ③Generate stateful rollback instruction set

[0096] For key operations in content-aware differential (especially database and structured file modification), the corresponding "reverse operation" instructions are generated synchronously. For example, for APPLY_SQL_PATCH, its rollback instruction can be to restore a database backup or execute a reverse SQL migration script. These rollback instructions will be collected and stored in a separate area of the upgrade file for ABORT_TRANSACTION operation invocation.

[0097] 1.3.7 Build fragmented data blocks and Merkle tree and associate index

[0098] Build fragmented data blocks: Traverse all entries in the new regular file hash table, the new symbolic link hash table, the new attribute metadata hash table, and the optimized content modification hash table. Compress the data content of each entry (whether it is a complete file, a symbolic link target, a SQL script, or a binary patch), and add a data block header (containing the decompressed length, checksum, etc.) to form a fragmented data block.

[0099] Build Merkle tree: Take the hash values of all fragmented data blocks generated in the previous step as the leaf nodes of the Merkle tree. By pairing adjacent hash values two by two and hashing again, build the tree layer by layer upwards until a unique tree root hash value is generated. This tree root hash value will serve as the unique integrity credential for the entire data fragmentation area, written into the file header.

[0100] Perfect atomic operation sequence (build index block): Traverse the atomic operation sequence generated in step 1.3.6. For each instruction in the sequence that requires data (such as ADD_FILE, APPLY_SQL_PATCH, etc.), associate the corresponding fragmented data block information created in the previous step, including the physical offset of the data block in the file, the length, and its location information in the Merkle tree. Finally, this atomic operation sequence filled with data block physical location information constitutes a complete fragmented index block.

[0101] 1.3.8 Create file header descriptor:

[0102] First, according to the size of all the areas to be written (data block area, index block area, rollback instruction set area), the respective starting offsets are calculated. Then, the file header descriptor is constructed, which contains the core meta information describing the entire OSTree upgrade file:

[0103] ① File format identification (magic number) and version information.

[0104] ② Identifiers (Commit ID) of the source version and the target version.

[0105] ③ Merkle Root, used for one-key verification of the integrity of all data.

[0106] ④ Starting offset and total size of the atomic operation sequence (index block).

[0107] ⑤ Starting offset and total size of the rollback instruction set.

[0108] ⑥ Total number of slices contained in the file and other global flags.

[0109] 1.3.9 Encapsulating the upgrade file:

[0110] Write all the built contents in the following strictly defined order to the target file to ensure that the device side can parse and execute:

[0111] First, write the file header descriptor built in 1.3.8.

[0112] Next, write all the slice data blocks generated in step 1.3.7 to the data block area after the file header.

[0113] Then, write the slice index block built in step 1.3.7 to the data block area, which is also the atomic operation sequence defined in step 1.3.6.

[0114] Finally, write the independent rollback instruction set area generated in step 1.3.6 at the end of the file.

[0115] Through the above steps, the generated OSTree upgrade file not only contains data differences, but also encapsulates complete upgrade logic with transaction control and strong integrity verification.

[0116] Embodiment 2 Authorization and delivery of the OSTree upgrade file

[0117] A set of pre-made keys is used to establish an end-to-end trust chain from construction to distribution to ensure the authenticity of its source, the integrity of its content, and the authorization of its deployment.

[0118] The first rebuild signature is a digital signature of the hash value of the final generated unsigned upgrade file containing transaction instructions and Merkle tree in "Embodiment 1" using the offline private key of the build system in a trusted offline build environment. This signature is stored together with the file hash to prove that the content of the upgrade package is built by a trusted source and has not been tampered with since its generation.

[0119] The second redistribution signature uploads the file package with the first layer build signature as a whole to the online upgrade management platform. When the platform is ready to distribute this upgrade file to the target device, it uses its online private key to perform a second digital signature of the hash value of the entire file package (including the original data and the build signature). This signature represents the deployment authorization of the distribution platform for the upgrade package, confirming that it has been audited and allowed to be deployed to the specified device group.

[0120] Finally, the original upgrade file, the build signature, and the distribution signature are packaged into the final distribution package. This security-hardened upgrade file can be transmitted to the target device through offline media such as USB, SD card, or online distribution such as secure network push, background download, etc. through the upgrade management platform.

[0121] Embodiment 3: Verification and application of OSTree upgrade file

[0122] 3.1, Prepare the OSTree upgrade file application environment

[0123] 3.1.1 Start the upgrade installation service, which runs in the background and continuously monitors the specified directory. Once an upgrade file is found, it triggers the upgrade process.

[0124] 3.1.2 Check the storage space to ensure that device D1 has enough remaining storage space to complete the deployment of the new version; and perform memory checks, power checks, etc.

[0125] 3.1.3 Check and confirm that the device is pre-installed with the tools or libraries required for applying all types of patches (e.g., SQLite command-line interface, JSON patch application library, etc.).

[0126] 3.1.4 Check and confirm that the device's built-in distribution public key verification file and build public key verification build signature file already exist.

[0127] 3.2, Apply the OSTree upgrade file

[0128] The upgrade installation service creates an asynchronous execution task to perform the upgrade process to ensure that the upgrade operation is performed in the background and does not block the core business currently running on the device, ensuring service continuity during the upgrade period. The detailed steps of the task are as follows:

[0129] 3.2.1 Security verification and compatibility pre-check

[0130] Open the OSTree upgrade file, read and parse the file header descriptor, and perform the following pre-checks:

[0131] First, verify the distribution signature of the file package using the device's built-in distribution public key to ensure that the upgrade task is issued by an authorized platform. After verification, use the built-in build public key to verify the build signature to ensure that the upgrade content comes from a trusted build environment and has not been tampered with. If either signature verification fails, the upgrade process is immediately aborted and an error is reported.

[0132] Next, read the Merkle tree root hash in the file header, which is the only proof of the integrity of all subsequent data shards.

[0133] Finally, perform a series of pre-checks, such as: check if the target version commit timestamp in the file header is later than the current system deployment version to prevent version rollback; check if the target version is suitable for the current system architecture; traverse all existing deployments of the OSTree local repository, if the target commit hash already exists, skip duplicate updates.

[0134] 3.2.2 Execute transactional applications

[0135] After verification, the upgrade service will strictly follow the logic embedded in the upgrade file to perform the update.

[0136] ① Start OSTree transaction: Start the transaction of the OSTree local repository to ensure that all subsequent file system-level write operations have atomicity.

[0137] ② Load and execute atomic operation sequence: Load and parse the index block area in the file, which serves as the predefined atomic operation sequence (Transaction Log). The service will strictly follow the order of instructions in this sequence, rather than simply traversing the shards.

[0138] ③ Apply shard data: For each instruction in the operation sequence, perform the following steps:

[0139] First, perform shard integrity check: Before reading the data shard, first check its integrity according to its proof path in the Merkle tree and the root hash loaded in the previous step. Failure to check means the file is damaged and the transaction should be aborted immediately.

[0140] After verification, then, according to the operation code in the instruction to decide what kind of application logic to execute. For each shard, first check if the object exists in the local repository according to its object hash, if it exists, skip it. If not, then:

[0141] If opcode is ADD_FILE, ADD_SYMLINK or ADD_METADATA: Read the data block content, decompress and create a new file, symlink or metadata object in the OSTree transaction directly.

[0142] If opcode is APPLY_BINARY_DIFF: Read the corresponding old file object in the local repository, read the binary patch in the data block, invoke the binary patch application tool, generate the new file content and write it as a new object in the OSTree repository.

[0143] If opcode is APPLY_SQL_PATCH: Locate the SQLite database file on the device that needs to be updated. Execute the SQL script content in the data block on a copy of the target database file via the SQLite execution interface on the device. After successful execution, write the updated database file as a new object in the OSTree repository.

[0144] If opcode is APPLY_STRUCTURAL_PATCH: Read the old JSON or XML file object, apply the structural patch in the data block to the file content, generate the new file content and write it as a new object in the OSTree repository.

[0145] If opcode is RECONSTRUCT_ARCHIVE: Read the old archive file object and perform delete, add, replace operations in a temporary directory according to the instruction set in the data block and the accompanying new member files, finally generate a new, complete archive file. Write this new archive file as a new object in the OSTree repository.

[0146] 3.2.3 Commit version and create deployment

[0147] After all instructions in the atomic operation sequence are successfully executed, perform the following steps:

[0148] 3.2.3.1 Commit OSTree transaction: Perform the commit operation of OSTree, organize all new objects written in this transaction in step 3.2.2, create a new commit object pointing to the target version root directory tree, and commit the transaction to complete the atomic creation of the version.

[0149] 3.2.3.2 Create new deployment: Based on the newly committed target version, create a new deployment item in OSTree, at this time the deployment item is in the pending activation state.

[0150] 3.2.4 Update bootloader

[0151] Modify the configuration of the bootloader, and set the newly created deployment item in 3.2.3.2 as the default option for the next system startup. After the configuration is saved, trigger a system restart to boot into the new version.

[0152] 3.2.5 Post-deployment health check and self-healing rollback

[0153] After the system restarts and successfully boots into the newly deployed version, perform the final verification and self-healing process: first, perform an execution health check: immediately after the upgrade service is activated, a set of preset "health check" scripts are executed. This check is used to verify whether the core functions of the new version are normal, for example, whether the key system services are running, whether the hardware drivers are loaded, whether the application can communicate normally, etc.

[0154] Next, confirm the upgrade or trigger a rollback. If the health check is successful: the upgrade service reports to the management platform that the upgrade is successful, and cleans up temporary files. At this point, the upgrade process is officially completed.

[0155] If the health check fails: the system will automatically trigger the self-healing rollback mechanism. It will call the rollback instruction set preset in the upgrade file to undo the key state changes (such as database migration), and then automatically modify the bootloader configuration to point the startup target back to the old version deployment before the upgrade, and restart the system again. This process does not require human intervention and can ensure that the device can automatically recover to the last stable state after the upgrade fails.

[0156] The OSTree static upgrade file constructed by the application can achieve the following technical effects:

[0157] 1. The Linux system integrated with the OSTree upgrade can be easily integrated into many existing upgrade management systems of companies, which enables the OSTree upgrade package to be distributed and managed together with other software resources, facilitates the construction of a unified upgrade pipeline across device forms, simplifies the deployment process, and significantly reduces the operation and maintenance complexity.

[0158] 2. By generating a single upgrade file, the offline upgrade process based on USB, SD card and other media is simplified, breaking through the network stability limitations of industrial devices and edge nodes, and increasing the convenience of OSTree updates in offline scenarios.

[0159] 3. The application introduces transactional operation instructions and an automatic rollback mechanism. It ensures the atomicity of the upgrade process, so that even if unexpected situations occur during the upgrade process, the system can automatically recover to the stable state before the upgrade after restarting.

[0160] 4. By double signature and Merkel tree verification, the full-link trust chain from construction to device and data integrity protection are established. This mechanism can effectively prevent security threats caused by server compromise or transmission tampering, and meets the industrial security standard.

[0161] 5. The generation method of the upgrade file combines the OSTree content addressing and content-aware differential technology, extracts only the minimum change content and performs efficient compression, maximally reduces the upgrade package size under the premise of safety and reliability, and optimizes the distribution efficiency.

[0162] Finally, through the enhancement of reliability, safety, ease of use and compatibility, the extensibility and scene adaptability of the OSTree technology are further improved, the application threshold of the OSTree technology is reduced, and the OSTree technology is better in overall extensibility, and the concept of immutable system is accelerated in the large-scale landing in key fields such as industrial Internet of Things.

[0163] In the present application, the following terms are defined and explained as follows:

[0164] OSTree: It is an upgrade system of Linux-based operating system, which can perform atomic upgrade on complete file system tree. The purpose of OSTree is to supplement the package system, and the main model is to write packages on the server, and then copy the written packages to the client. The core layer of OSTree is a version control file system, and the object types of the object include commit object, content object and attribute object.

[0165] Rollsum algorithm: It is an algorithm for detecting repeated data or changed data in data stream, which is usually used in data synchronization, deduplication and verification scenes.

[0166] Merkel tree: It is a tree-shaped data structure for verifying data integrity by hashing data blocks layer by layer to generate a unique "root hash". It is usually used for efficient and secure integrity verification of large-scale data sets, and is commonly used in distributed storage and secure software distribution scenes.

[0167] Although the present application has been described by the above preferred embodiments, it is not intended to limit the protection scope of the present application, and any person skilled in the art can make various changes and modifications to the above embodiments without departing from the spirit and scope of the present application, which are still within the scope of protection of the present application. Therefore, the protection scope of the present application is defined by the claims.

Claims

1. A method for system upgrade based on OSTree, characterized in that, The method comprises the following steps: Compiling a Linux system version Version B that can run on a device D1 installed with a Linux system version Version A; After the compiling, pushing the rootfs and kernel files of the Linux system version Version B into an OSTree remote repository containing the Linux system version Version A by commit and push instructions of the OSTree, with Version B as the version identifier; Pulling the Linux system version Version A and the Linux system version Version B in the OSTree remote repository into an OSTree local repository; Making an OSTree upgrade file for upgrading from the Linux system version Version A to the Linux system version Version B in the OSTree local repository, with the Linux system version Version A as the source version and the Linux system version Version B as the target version; The making of the OSTree upgrade file for upgrading from the Linux system version Version A to the Linux system version Version B in the OSTree local repository comprises: Opening the OSTree local repository; Creating a source version object hash table, a target version object hash table, an added attribute metadata hash table, an added normal file hash table, an added symbolic link hash table, a content modification table hash table and an optimized content modification table hash table; According to the Linux system version Version A and the Linux system version Version B, storing corresponding objects into the source version object hash table, the target version object hash table, the added attribute metadata hash table, the added normal file hash table, the added symbolic link hash table and the content modification table hash table, and obtaining the optimized content modification table hash table based on the content modification table hash table; Defining logical fragment types and operation codes, generating an atomic operation sequence and a rollback instruction set; Building fragment data blocks and a Merkle tree, and associating indexes to obtain a complete fragment index block; Creating a file header descriptor; Writing the file header descriptor, all fragment data blocks, the fragment index block and the rollback instruction set in sequence to generate the OSTree upgrade file; Iterating the content modification table hash table, and for each modification file to be processed, introducing a content-aware differential engine to perform the following operations: Based on the file extension or the magic number of the file header, identifying the specific content type of the file through a preset rule base; According to the identified file type, the content-aware differential engine calls the optimal differential strategy, and stores the differential content generated by the differential strategy and the corresponding differential strategy type into the optimized content modification hash table; The differential strategy comprises: For SQLite database files, no binary comparison is performed, and a special database comparison module is called to connect the source and target version database files, compare their internal table structures and data rows, and generate a set of SQL statements that can migrate the old database to the new database state; For structured text files, a structured comparison algorithm is used to parse the source and target version database files into data trees in memory, compare the node differences between the two trees, and generate a compact patch that describes the node additions, deletions, and modifications; For archive files, the source and target version archive files are decompressed to temporary directories, respectively, and then the contents of the two temporary directories are recursively compared to generate a set of instructions or scripts that describe how to reconstruct the target version archive file by adding, deleting, or replacing some member files based on the source version archive file; For general binary files, fall back to binary difference based on the Rollsum algorithm to generate a binary patch.

2. The OSTree-based system upgrade method of claim 1, wherein, The pulling of the Linux system version Version A and the Linux system version Version B in the OSTree remote warehouse to the OSTree local warehouse includes: Creating a working directory on a working machine S3 used for making an OSTree upgrade file, and allocating a corresponding operation space; Entering the working directory, creating an OSTree local warehouse directory with an initialization instruction of the OSTree, and binding an OSTree remote warehouse address; Pulling all related object files in the OSTree remote warehouse referenced by the version identifiers Version A and Version B to the OSTree local warehouse through an OSTree pull instruction.

3. The OSTree-based system upgrade method of claim 1, wherein, According to the Linux system version Version A and the Linux system version Version B, corresponding objects are stored in a source version object hash table, a target version object hash table, an added attribute metadata hash table, an added ordinary file hash table, an added symbolic link hash table, and a content modification table hash table, including: If the source version exists, loading the metadata of the source version, storing the hash values of all objects contained in the source version into the source version object hash table, loading the metadata of the target version, and storing the hash values of all objects contained in the target version into the target version object hash table; Traversing the target version object hash table, for an object file that does not appear in the source version object hash table, writing the object file that does not appear in the source version object hash table into the corresponding added attribute metadata hash table, added ordinary file hash table, or added symbolic link hash table according to the type of the object file, and for an object file that appears in the source version object hash table but has different hash values, recording the source version hash value and the target version hash value of the object file as an entry in the content modification table hash table; Introducing a content-aware difference engine to optimize the content in the content modification hash table, generating a difference result and storing it in the optimized content modification hash table.

4. The OSTree-based system upgrade method of claim 3, wherein, The definition of a logical fragmentation type and an operation code, the generation of an atomic operation sequence and a rollback instruction set, include: According to the source and difference result of the change content, define an operation code for guiding the operation of the device end when upgrading the application, and introduce a new operation code with transaction control capability; Traverse the added attribute metadata hash table, the added ordinary file hash table, the added symbolic link hash table, and the optimized content modification hash table, and convert each change item into one or more atomic operation instructions using the operation code. All atomic operation instructions are organized into an atomic operation sequence; For database and structured file modifications in content-aware differential, the corresponding rollback instruction set is generated synchronously.

5. The OSTree-based system upgrade method of claim 4, wherein, The shard data block and the Merkle tree are constructed, and the index is associated to obtain a complete shard index block, including: Traverse the added attribute metadata hash table, the added ordinary file hash table, the added symbolic link hash table, and the optimized content modification hash table, and compress the data content of each entry therein and add a data block header to form a shard data block; The hash values of all generated shard data blocks are taken as leaf nodes of the Merkle tree, the adjacent hash values are paired two by two and hashed again, and the tree is constructed layer by layer upwards until a unique tree root hash value is generated. The tree root hash value is taken as a unique integrity credential of the entire data shard region and is written into a file header; Traverse the atomic operation sequence, and for each instruction in the sequence that requires data, associate the corresponding shard data block information to obtain a complete shard index block. The shard data block information includes the physical offset of the data block in the file, the length of the data block in the file, and the location information of the data block in the Merkle tree.

6. The OSTree-based system upgrade method of claim 1, wherein, The file header descriptor is created, including: According to the sizes of all data block regions, index block regions, and rollback instruction set regions to be written, the starting offsets are calculated; The file header descriptor is constructed, which contains core meta information describing the entire OSTree upgrade file.

7. The OSTree-based system upgrade method of claim 1, wherein, The OSTree upgrade file is also encrypted with a preset key file to generate an OSTree encrypted upgrade file, and the OSTree encrypted upgrade file is delivered.

8. The OSTree-based system upgrade method of claim 7, wherein, The delivery of the OSTree encrypted upgrade file includes: The OSTree encrypted upgrade file is uploaded to the background through the original upgrade management background, and the upgrade task is configured in the background. The OSTree encrypted upgrade file is pushed to the device D1, the upgrade task is obtained from the upgrade background periodically, and the OSTree encrypted upgrade file is downloaded to the device D1 according to the upgrade task configuration and placed in the specified directory; or The OSTree encrypted upgrade file is stored in the specified directory of the device D1 through a USB disk or an SD card; or The OSTree encrypted upgrade file is obtained from a specified network address through a network command or a browser on the device D1 and placed in the specified directory of the device D1.

9. The OSTree-based system upgrade method of claim 7, wherein, The OSTree encrypted upgrade file is also encrypted with a preset key file to generate an OSTree upgrade file, and the OSTree upgrade file is applied.