System upgrading method based on OSTree

Abstract

The invention relates to the technical field of OSTree, and particularly provides an OSTree-based system upgrading method, which comprises the following steps of: compiling a version VersionB of a Linux system; after compiling is completed, rootfs and kernel files of the VersionB are pushed to an OSTree remote warehouse by taking the VersionB as a version identifier through a submitting and pushing instruction of the OSTree; a system version VersionA and a system version VersionB in the OSTree remote warehouse are pulled to an OSTree local warehouse, and the system version VersionA and the system version VersionB in the OSTree remote warehouse are pulled to the OSTree local warehouse; and making an OSTree upgrading file which is upgraded from the VersionA to the VersionB in an OSTree local warehouse. By means of the scheme, the distribution problem existing when the OSTree is updated is solved.

Description

Technical Field

[0001] The present invention relates to the field of OSTree technology, and specifically provides an OSTree-based system upgrade method. Background Art

[0002] The use of Linux embedded operating systems is increasing in the industrial and robotics control fields. However, after Linux systems are deployed on end devices, updates and upgrades to the system image often require physical redeployment, which fails to ensure optimal user experience and system uptime. To improve the Linux system upgrade experience, secure remote OTA updates are becoming an urgent need.

[0003] The Linux upgrade system, based on OSTree, transmits very little data during the upgrade process, making it highly valuable for widespread application. OSTree operates on a content-addressed storage mechanism that uniquely identifies all files, directories, and commits in the root file system using SHA-256 hash values. Objects with identical content have identical hash values, thus preventing duplicate storage. The OSTree-based Linux upgrade system constructs the file system using three core object types: file objects (which store file content and permissions / ownership metadata), directory objects (which contain hash references and metadata for subdirectories and files), and metadata commit objects (which point to the root directory hash and contain timestamps and parent commit information), forming a complete versioned file system structure.

[0004] OSTree's update process is divided into four steps: first, obtain the target commit hash value through the specified remote reference, then connect to the remote repository to download the corresponding commit object and parse its root directory hash value; then recursively traverse the hash values ​​of all subdirectories and files under the root directory, and finally, through a comparison check of the local object repository, only download missing objects to complete incremental synchronization and update the local branch to point to the new commit.

[0005] However, this update mechanism has two major flaws: ① OSTree pull itself does not directly handle the transmission protocol and relies entirely on the underlying transmission library (such as libcurl) to implement HTTP / HTTPS / file and other protocol support, which leads to very limited optimization of the protocol layer; ② Many companies already have upgrade backend management systems, most of which are for managing upgrade files. To support OSTree updates, a lot of management and construction of OSTree repositories is required, which has a large compatibility task and is not conducive to the promotion of OSTree-based Linux upgrade systems. In addition, the current update mechanism is designed for offline support and requires managing the synchronization of remote OSTree repositories with media OSTree repositories, and the synchronization of media OSTree repositories with device OSTree repositories, which is very cumbersome and prone to errors. Summary of the Invention

[0006] The present invention solves the distribution problem existing during OSTree updates, makes use of other existing upgrade background management systems as much as possible, reduces the reliance on uncontrollable underlying libraries during OSTree updates, enhances the optimization for network transmission, is compatible with offline media transmission such as USB and SD cards, and increases the convenience of OSTree updates in offline scenarios.

[0007] The present invention proposes a system upgrade method based on OSTree, comprising the following steps: Compile Linux system version B that can run on device D1 installed with Linux system version A; After the compilation is complete, the rootfs and kernel files of Linux system version B are pushed to the OSTree remote repository containing Linux system version A using OSTree commit and push instructions, with Version B as the version identifier. Pull Linux system version VersionA and Linux system version VersionB from the OSTree remote warehouse to the OSTree local warehouse; An OSTree upgrade file for upgrading from Linux system version Version A to Linux system version Version B is created in the OSTree local warehouse. The OSTree upgrade file uses Linux system version Version A as a source version and Linux system version Version B as a target version.

[0008] Furthermore, the process of pulling the Linux system version Version A and the Linux system version Version B from the OSTree remote repository to the OSTree local repository includes: Create a working directory on the S3 workstation used to create the OSTree upgrade file and allocate the corresponding operating space. Enter the working directory, use OSTree initialization instructions to create the OSTree local warehouse directory, and bind the OSTree remote warehouse address; Through the OSTree pull command, all relevant object files with version identifiers VersionA and VersionB as reference parameters in the OSTree remote warehouse are pulled into the OSTree local warehouse.

[0009] Furthermore, the OSTree upgrade file for upgrading from Linux system version Version A to Linux system version Version B is generated in the OSTree local warehouse, including: Open the OSTree local repository; Create source version object hash table, target version object hash table, new attribute metadata hash table, new common file hash table, new symbolic link hash table, content modification table hash table and optimized content modification table hash table; According to Linux system version Version A and Linux system version Version B, corresponding objects are stored in the source version object hash table, the target version object hash table, the newly added attribute metadata hash table, the newly added ordinary file hash table, the newly added symbolic link hash table, and the content modification table hash table, and an optimized content modification table hash table is obtained based on the content modification table hash table; Define logical shard types and operation codes, generate atomic operation sequences and rollback instruction sets; Build shard data blocks and Merkle trees, and associate indexes to obtain complete shard index blocks; Create a file header descriptor; Write the file header descriptor, all shard data blocks, shard index blocks, and rollback instruction sets in sequence to generate the OSTree upgrade file.

[0010] Furthermore, 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 newly added attribute metadata hash table, the newly added ordinary file hash table, the newly added symbolic link hash table, and the content modification table hash table, including: If the source version exists, the metadata of the source version is loaded, and the hash values ​​of all objects contained in the source version are stored in the source version object hash table. At the same time, the metadata of the target version is loaded, and the hash values ​​of all objects contained in the target version are stored in the target version object hash table. Traverse the target version object hash table. For object files that do not appear in the source version object hash table, write the object files that do not appear in the source version object hash table into the corresponding newly added attribute metadata hash table, newly added common file hash table, or newly added symbolic link hash table according to the type of the object file. For object files that appear in the source version object hash table but have different hash values, record the source version hash value and the target version hash value of the object file as one entry in the content modification table hash table. A content-aware difference engine is introduced to optimize the content in the content modification hash table, generate difference results and store them in the optimized content modification hash table.

[0011] Furthermore, the definition of logical sharding types and operation codes, and the generation of atomic operation sequences and rollback instruction sets include: Based on the source of the changes and the difference results, operation codes are defined to guide device-side operations when upgrading applications. New operation codes with transaction control capabilities are also introduced. Traversing the newly added attribute metadata hash table, the newly added common file hash table, the newly added symbolic link hash table, and the optimized content modification hash table, converting each change item into one or more atomic operation instructions using the opcode, and organizing all atomic operation instructions into an atomic operation sequence; For database and structured file modifications in content-aware differencing, corresponding rollback instruction sets are generated synchronously.

[0012] Furthermore, the construction of the shard data block and the Merkle tree, and the associated index to obtain a complete shard index block, includes: Traverse the newly added common file hash table, the newly added symbolic link hash table, the newly added attribute metadata hash table, and the optimized content modification hash table, compress the data content of each entry, and add a data block header to form a fragmented data block; The hash values ​​of all generated sharded data blocks are used as leaf nodes of the Merkle tree. The adjacent hash values ​​are paired and hashed again, and the tree is constructed layer by layer until a unique root hash value is generated. The root hash value is used as the unique integrity certificate of the entire data shard area and is written into the file header. Traverse the atomic operation sequence, and for each instruction in the sequence that requires data, associate the corresponding shard data block information with it 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 position information of the data block in the Merkle tree.

[0013] Furthermore, the creation of the file header descriptor includes: Calculate the starting offset of each area based on the size of all data blocks, index blocks, and rollback instruction set areas to be written. Construct a file header descriptor, which contains the core meta information describing the entire OSTree upgrade file.

[0014] Furthermore, the method further includes encrypting the OSTree upgrade file with a preset key file to generate an OSTree encrypted upgrade file, and then transmitting the OSTree encrypted upgrade file.

[0015] Furthermore, the OSTree encrypted upgrade file is delivered, including: Upload the OSTree encrypted upgrade file to the existing upgrade management backend, configure the upgrade task in the backend, push the OSTree encrypted upgrade file to device D1, periodically obtain the upgrade task from the upgrade backend, download the OSTree encrypted upgrade file to device D1 according to the upgrade task configuration, and place it in the specified directory; or Store the OSTree encrypted upgrade file in the specified directory of device D1 via a USB disk or SD card; or The data is obtained from the specified network address on the device D1 through a network command or a browser, and is placed in the specified directory of the device D1.

[0016] Furthermore, the method further includes encrypting the OSTree encrypted upgrade file with a preset key file to generate an OSTree upgrade file, and then applying the OSTree upgrade file.

[0017] Working principle and beneficial effects of the present invention: Encapsulating version difference data with atomic operation logs and stateful rollback instructions fundamentally ensures the transactional and atomic nature of the device-side upgrade process. A Merkle tree is constructed to provide strong integrity proof for all data shards. By encapsulating operation sequence, security checks, transaction control, and emergency response plans into upgrade files, these files not only contain version differences but also embed complete transaction control capabilities and an end-to-end trust chain. DETAILED DESCRIPTION

[0018] Some embodiments of the present invention are described below. It should be understood by those skilled in the art that these embodiments are only used to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0019] This paper proposes an OSTree-based system upgrade method. The core of this method is to encapsulate the complete upgrade process—including operation sequence, security verification, transaction control, and emergency response plan—into an upgrade file through an innovative file format design. This upgrade file not only contains version differences but also embeds complete transaction control capabilities and an end-to-end trust chain. Specific implementations include: During the production phase, version difference data is encapsulated together with atomic operation logs and stateful rollback instructions, fundamentally ensuring the transactionality and atomicity of the device-side upgrade process.

[0020] By constructing a Merkle tree, strong integrity proof is provided for all data shards; and by introducing dual signatures for construction and distribution, a trust chain is established from the development source to the deployment terminal, effectively resisting tampering and illegal distribution.

[0021] During the application phase, the device strictly follows the embedded operation log to execute the update and performs a health check after deployment. If the check fails, the system will automatically trigger a rollback command to restore the system to its pre-upgrade state, achieving system self-healing in unattended scenarios.

[0022] To achieve the purpose of the present invention, the following, in combination with specific embodiments, elaborates in detail how to create, authorize and apply an OSTree static upgrade file containing complete upgrade logic through a preset implementation environment - including a remote warehouse server S1, a build server S2, a working machine S3 and a target device D1, thereby solving the core problems of compatibility, reliability and offline updates in the existing mechanism.

[0023] In this embodiment of the present invention, the following equipment is required to build an implementation environment: A server S1 is used to store the OSTree remote repository, which contains the Linux system version VersionA; A server S2 used to build a new Linux system version VersionB; A worker machine S3 for creating OSTree upgrade files; A device D1 with Linux version A installed; A set of keys includes a high-security offline key pair managed by the build system and an online key pair managed by the upgrade management platform.

[0024] The OSTree-based system upgrade method in this embodiment mainly focuses on creating and applying OSTree upgrade files. The process is divided into three stages: Example 1: Creating an OSTree Upgrade File By traversing the associated objects in the OSTree warehouse corresponding to the new and old version identifiers of the Linux system, newly added metadata, modified files and symbolic links are identified, and compression technology is used to extract and compress only the changed content between versions to generate highly compressed incremental data blocks; metadata, shard indexes, compressed data, etc. are encapsulated into descriptor files, and merged with incremental data shard data to store them as OSTree upgrade files.

[0025] 1.1. Prepare resources The system reads the parameters entered by the user, including the source version (Linux system version A in this example), the target version (Linux system version B in this example), and the OSTree upgrade file storage path. A new Linux system version B, which can run on device D1, is compiled on the constructed server S2. After compilation is complete, the rootfs, kernel, and other core files of Linux system version B are pushed to the OSTree remote repository on server S1 using OSTree's commit and push instructions, using Version B as the version identifier. At this point, the new Linux system version B is already in the OSTree remote repository.

[0026] 1.2. Prepare the production environment for OSTree upgrade files On worker machine S3, execute the OSTree upgrade file creation program to create the OSTree upgrade file from Linux system version A to Linux system version B. The OSTree upgrade file creation program first pulls the relevant version data for Linux system version A and Linux system version B from the OSTree remote repository on server S1 to the local environment of worker machine S3 (i.e., the OSTree local repository).

[0027] 1.2.1 Create a working directory on the S3 server and ensure that there is sufficient space for file operations.

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

[0029] 1.2.3 Through the OSTree pull instruction, all relevant object files with the version identifier VersionA of the Linux system version VersionA and the version identifier VersionB of the Linux system version VersionB as reference parameters in the OSTree remote warehouse of server S1 are pulled to the OSTree local warehouse of the working machine S3. In this way, all relevant object files with the version identifiers VersionA and VersionB as reference parameters exist in the OSTree local warehouse.

[0030] 1.3. Create OSTree upgrade file 1.3.1 Open the OSTree local repository on the worker machine's S3 repository that contains the source and target versions.

[0031] 1.3.2 Initialize object tracking and create a series of hash tables for categorized storage of difference information, including the source version object hash table, the target version object hash table, the newly added attribute metadata hash table, the newly added ordinary file hash table, the newly added symbolic link hash table, the content modification table hash table, and the optimized content modification table hash table.

[0032] 1.3.3 Loading Submitted Version Information: If a source version exists, load the metadata for source version VersionA and traverse the hash values ​​of all objects it contains (file objects, attribute metadata objects, symbolic link objects, etc.) and store them in the source version object hash table. Similarly, load the metadata for target version VersionB and traverse the hash values ​​of all objects in it and store them in the target version object hash table.

[0033] 1.3.4 Difference identification: Traverse the target version object hash table, and for each object file in it, check whether it exists in the source version object hash table.

[0034] If the object file does not exist, it is considered a newly added object. Based on its type (attribute metadata, regular file, symbolic link), its hash value is stored in the corresponding newly added attribute metadata hash table, newly added regular file hash table, or newly added symbolic link hash table.

[0035] If the object file exists but the hash value is different, it is determined to be a 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.

[0036] 1.3.5 Content-Aware Intelligent Differencing and Optimized Processing: A content-aware differencing engine is introduced to select the optimal differencing strategy based on file type, thereby generating smaller and more reliable upgrade patches.

[0037] The content-aware differencing engine iterates over the content modification table hash table generated in step 1.3.4. For each modified file to be processed, it performs the following operations: First, it uses a preset rule library to identify the specific content type of the file based on the file extension (such as .db .sqlite .json .xml .tar .zip) or the magic number in the file header. Then, based on the identified file type, the differencing engine will invoke the optimal differencing strategy. For example: Case 1: For SQLite database files (e.g., with the .db.sqlite extension), no binary comparison is performed. Instead, a dedicated database comparison module is invoked to connect the old and new versions of the database files. By comparing the internal table structures (schemas) and data rows, a set of SQL statements (including UPDATE, INSERT, DELETE, ALTER TABLE, etc.) is generated to migrate the old database to the new state. This set of SQL statements is the "difference content" of the file.

[0038] Case 2: For structured text files (such as JSON, XML, and YAML), a structured comparison algorithm is used to parse the old and new files into an in-memory data tree. By comparing the node differences between the two trees, a compact patch describing the addition, deletion, and modification of the nodes is generated (for example, a set of instructions in the JSON Patch format). This patch is the "difference content."

[0039] Case 3: For archive files (such as TAR and ZIP), binary diffing is not performed directly on the entire archive. Instead, the new and old archives are decompressed separately into temporary directories, and the contents of the two directories are recursively compared. The resulting "difference" is a set of instructions or a script describing how to reconstruct the new archive by adding, deleting, or replacing some member files from the old archive. The newly added or modified member files are also packaged.

[0040] Case 4: For general binary files, for any other files whose types cannot be identified or for which the above special strategies do not apply (such as executable programs and library files), the system falls back to binary differencing based on the Rollsum algorithm and generates a binary patch as the "difference content".

[0041] Finally, the “difference content” generated by the above strategies and their corresponding differential strategy types are stored in the optimized content modification hash table.

[0042] 1.3.6 Build the shard data and corresponding shard index of the OSTree upgrade file: The core of ensuring the atomicity and safe rollback capabilities 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.

[0043] ①Define logical sharding type and operation code Based on the source of the changed content and the results of intelligent differencing, a richer set of opcodes are defined to precisely guide device-side operations when upgrading applications: ADD_FILE, ADD_SYMLINK, ADD_METADATA (for adding new content), APPLY_BINARY_DIFF (for applying universal binary patches), APPLY_SQL_PATCH (for executing SQL scripts for database migration), APPLY_STRUCTURAL_PATCH (for applying structured patches for files such as JSON / XML), and RECONSTRUCT_ARCHIVE (for reconstructing archive files based on instruction sets and new member files). In addition, new opcodes with transaction control capabilities are introduced to form a complete execution logic. This includes: BEGIN_TRANSACTION: Marks the start of the upgrade transaction, and the device begins to prepare the execution environment.

[0044] VERIFY_INTEGRITY: Instructs the device to use the Merkle root hash in the file header to verify the integrity of all subsequent data shards.

[0045] PREPARE_ROLLBACK: Instructs the device to back up specified files (such as databases and key configurations) to a safe area in preparation for a possible rollback.

[0046] COMMIT_TRANSACTION: Commit OSTree changes after all operations are successfully applied and clean up the rollback backup.

[0047] VERIFY_PATCH_RESULT: Used to execute verification logic after applying a critical patch (such as a SQL script) to confirm whether the change was successful.

[0048] ABORT_TRANSACTION: Triggers the rollback process if any error occurs during the upgrade process.

[0049] ②Generate atomic operation sequence 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 are traversed, converting each change item into one or more atomic operation instructions using the aforementioned opcodes. These instructions are organized into an ordered list (the transaction log), precisely describing each step from verify, prepare, apply, to commit. For example, an update to a database file might be decomposed into: PREPARE_ROLLBACK -> APPLY_SQL_PATCH -> VERIFY_PATCH_RESULT.

[0050] ③Generate a stateful rollback instruction set For key operations in content-aware differencing (particularly database and structured file modifications), corresponding "inverse operation" instructions are generated synchronously. For example, for APPLY_SQL_PATCH, the rollback instructions might involve restoring a database backup or executing a reverse SQL migration script. These rollback instructions are collected and stored in a separate area of ​​the upgrade file, ready for invocation by the ABORT_TRANSACTION operation.

[0051] 1.3.7 Building Shard Data Blocks and Merkle Trees and Associating Indexes Constructing shard data blocks: Traverse all entries in the newly added regular file hash table, newly added symbolic link hash table, newly added attribute metadata hash table, and the optimized content modification hash table. Compress the data content of each entry (whether it is a complete file, symbolic link target, SQL script, or binary patch) and add a data block header (including the decompressed length and checksum) to form a shard data block.

[0052] Build a Merkle tree: Use the hash values ​​of all sharded data blocks generated in the previous step as leaf nodes of the Merkle tree. By pairing adjacent hash values ​​and hashing them again, the tree is constructed layer by layer until a unique root hash value is generated. This root hash value serves as the unique integrity certificate for the entire data shard area and is written into the file header.

[0053] Complete the atomic operation sequence (build the 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 and APPLY_SQL_PATCH), associate it with the corresponding shard data block information created in the previous step, including the data block's physical offset and length within the file, as well as its location in the Merkle tree. Ultimately, this atomic operation sequence, filled with the data block's physical location information, forms a complete shard index block.

[0054] 1.3.8 Create a file header descriptor: First, based on the sizes of all areas to be written (data block area, index block area, rollback instruction set area), the starting offsets of each area are calculated. Then, a file header descriptor is constructed, which contains the core metadata describing the entire OSTree upgrade file: ① File format identifier (magic number) and version information.

[0055] ② Identifiers of the source and target versions (Commit ID).

[0056] ③ Merkle Root, used to verify the integrity of all data with one click.

[0057] ④ The starting offset and total size of the atomic operation sequence (index block).

[0058] ⑤ The starting offset and total size of the rollback instruction set.

[0059] ⑥ The total number of shards contained in the file and other global flags.

[0060] 1.3.9 Package upgrade file: Write all built content to the target file in the following strictly defined order to ensure that the device can parse and execute it: First, write the file header descriptor of the completed 1.3.8 build.

[0061] Next, all the fragmented data blocks generated in step 1.3.7 are written sequentially into the data block area after the file header.

[0062] Then, immediately following the data block area, write the shard index block built in step 1.3.7 (this block is also the atomic operation sequence defined in step 1.3.6).

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

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

[0065] Example 2 Authorization and Delivery of OSTree Upgrade Files A pre-made set of keys is used to establish an end-to-end trust chain from build to distribution to ensure the authenticity of its source, the integrity of its content, and the authorization of its deployment.

[0066] The first rebuild signature uses the build system's offline private key in a trusted offline build environment to digitally sign the hash value of the unsigned upgrade file generated in Example 1, which contains the transaction instructions and Merkle tree. This signature is stored along with the file hash to prove that the upgrade package's contents were built from a trusted source and have not been tampered with since generation.

[0067] The second distribution signature uploads the entire file package, along with the first-level build signature, to the online upgrade management platform. When the platform prepares to distribute the upgrade file to target devices, it uses its online private key to digitally sign the hash value of the entire file package (including the original data and the build signature) a second time. This signature represents the distribution platform's deployment authorization for the upgrade package, confirming that it has been reviewed and approved for deployment to the specified device group.

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

[0069] Example 3 Verification and Application of OSTree Upgrade Files 3.1. Prepare the OSTree upgrade file application environment 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, the upgrade process is triggered.

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

[0071] 3.1.3 Verify that the device has pre-installed tools or libraries required to apply all types of patches (for example, the SQLite command-line interface, the JSON patch application library, etc.).

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

[0073] 3.2. Apply OSTree upgrade file The upgrade installation service creates an asynchronous execution task to execute the upgrade process, ensuring that the upgrade operation is performed in the background without blocking the core services currently running on the device, thus ensuring service continuity during the upgrade. The detailed steps of the task are as follows: 3.2.1 Security Verification and Compatibility Pre-check Open the OSTree upgrade file, read and parse the file header descriptor, and perform the following pre-checks: First, the device uses the built-in distribution public key to verify the distribution signature of the file package, ensuring that the upgrade task was issued by the authorized platform. Once verified, the built-in build public key is used to verify the build signature, ensuring that the upgrade content originates from a trusted build environment and has not been tampered with. If any signature verification fails, the upgrade process is immediately aborted and an error is reported.

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

[0075] Finally, a series of pre-checks are performed, such as: checking whether the target version commit timestamp in the file header is later than the current system deployment version to prevent version rollback; checking whether the target version is applicable to the current system architecture; traversing all existing deployments in the OSTree local repository, and skipping duplicate updates if the target commit hash already exists.

[0076] 3.2.2 Executing Transactional Applications After verification, the upgrade service will strictly execute the update according to the logic embedded in the upgrade file.

[0077] ① Start OSTree transaction: Start the transaction of OSTree local warehouse to ensure that all subsequent file system-level write operations are atomic.

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

[0079] ③ Apply the fragmented data: For each instruction in the operation sequence, perform the following steps: First, perform a shard integrity check: Before reading a data shard, verify the integrity of the data shard based on its Proof Path in the Merkle tree and the root hash loaded in the previous step. Failure to verify the integrity indicates file corruption and the transaction should be aborted immediately.

[0080] After the verification is passed, the application logic to be executed is determined based on the opcode in the instruction. For each shard, first check whether the object already exists in the local warehouse based on its object hash. If it does, skip it. If not, then: If the opcode is ADD_FILE, ADD_SYMLINK, or ADD_METADATA: read the data block contents, decompress them, and create a new file, symbolic link, or metadata object directly in the OSTree transaction.

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

[0082] If the opcode is APPLY_SQL_PATCH: The SQLite database file to be updated is located on the device. The SQL script content in the sharded data block is executed on the copy of the target database file through the SQLite execution interface on the device. After successful execution, the updated database file is written to the OSTree repository as a new object.

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

[0084] If the opcode is RECONSTRUCT_ARCHIVE: Read the old archive file object and perform delete, add, and replace operations in the temporary directory according to the instructions set in the shard data block and the accompanying new member files, ultimately generating a new, complete archive file. This new archive file is written to the OSTree repository as a new object.

[0085] 3.2.3 Submit version and create deployment After all instructions in the atomic operation sequence have been successfully executed, the following steps are performed: 3.2.3.1 Commit the OSTree transaction: Execute the OSTree commit operation, organize all new objects written in this transaction in step 3.2.2, create a new commit object pointing to the target version root tree, and commit the transaction to complete the atomic creation of the version.

[0086] 3.2.3.2 Create a new deployment: Based on the newly submitted target version, a new deployment item is created in OSTree. At this time, the deployment item is in the pending activation state.

[0087] 3.2.4 Updating the boot loader Modify the boot loader configuration to set the newly created deployment item in 3.2.3.2 as the default option the next time the system boots. After saving the configuration, trigger a system reboot to boot into the new version.

[0088] 3.2.5 Post-deployment health check and self-healing rollback After the system restarts and successfully boots into the newly deployed version, the final verification and self-healing process begins. First, a health check is performed: After the upgrade service is activated, a pre-defined "health check" script is immediately executed. This check verifies that the core functionality of the new version is functioning properly, such as whether key system services are running, hardware drivers are loaded, and applications can communicate normally.

[0089] Next, confirm the upgrade or trigger a rollback. If the health check succeeds, the upgrade service reports the upgrade success to the management platform and cleans up temporary files. The upgrade process is now officially complete.

[0090] If a health check fails, the system automatically triggers a self-healing rollback mechanism. This mechanism invokes rollback instructions pre-configured in the upgrade file to undo critical state changes (such as database migrations). It then automatically modifies the bootloader configuration, reverting the boot target to the previous version deployed before the upgrade, and reboots the system. This process requires no manual intervention and ensures that the device automatically returns to its previous stable state after an upgrade failure.

[0091] The OSTree static upgrade file constructed by the present invention can achieve the following technical effects: 1. Linux systems that integrate OSTree upgrades can be easily integrated into many companies' existing upgrade management systems. This allows OSTree upgrade packages to be distributed and managed collaboratively with other software resources, facilitating the construction of a unified upgrade pipeline across devices, thereby simplifying the deployment process and significantly reducing operation and maintenance complexity.

[0092] 2. By generating a single upgrade file, the offline upgrade process based on media such as USB and SD cards is simplified, breaking through the scenario limitations of network stability on industrial equipment and edge nodes, and increasing the convenience of OSTree updates in offline scenarios.

[0093] 3. This invention introduces transactional operation instructions and an automatic rollback mechanism to ensure the atomicity of the upgrade process. Even if an unexpected situation occurs during the upgrade, the system can automatically recover to the stable state before the upgrade after restart.

[0094] 4. Through dual signatures and Merkle tree verification, a full chain of trust and data integrity protection is established from build to device. This mechanism effectively defends against security threats caused by server compromise or transmission tampering, meeting industrial-grade security standards.

[0095] 5. The upgrade file generation method of the present invention combines OSTree content addressing and content-aware differential technology to extract only the minimized changed content and perform efficient compression. While ensuring safety and reliability, it minimizes the upgrade package size and optimizes distribution efficiency.

[0096] Ultimately, by enhancing reliability, security, usability, and compatibility, this invention further improves the scalability and scenario adaptability of OSTree technology, lowers the application threshold of OSTree technology, makes OSTree technology more scalable overall, and accelerates the large-scale implementation of the immutable system concept in key areas such as the Industrial Internet of Things.

[0097] In this invention, the following terms are used and explained as follows: OSTree: An upgrade system for Linux-based operating systems, OSTree performs atomic upgrades of the entire file system tree. OSTree aims to complement package management systems. Its primary model involves authoring packages on the server and replicating them to the client. At its core, OSTree is a version-controlled file system, with object types such as commit objects, content objects, and attribute objects.

[0098] Rollsum algorithm: is an algorithm used to detect duplicate or changed data in a data stream. It is commonly used in scenarios such as data synchronization, deduplication, and verification.

[0099] A Merkle tree is a tree-like data structure that verifies data integrity by hashing data blocks layer by layer, ultimately generating a unique "root hash." It's commonly used for efficient and secure integrity verification of large datasets, and is commonly found in scenarios like distributed storage and secure software distribution.

[0100] Although the present invention has been described using the above preferred embodiments, they are not intended to limit the scope of protection of the present invention. Any person skilled in the art may make various changes and modifications to the above embodiments without departing from the spirit and scope of the present invention. These changes and modifications are still within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be based on the definition of the claims.

Claims

1. A system upgrade method based on OSTree, characterized in that: The following steps are involved: Compile Linux system version B that can run on device D1 installed with Linux system version A; After the compilation is complete, the rootfs and kernel files of Linux system version B are pushed to the OSTree remote repository containing Linux system version A using OSTree commit and push instructions, with Version B as the version identifier. Pull Linux system version VersionA and Linux system version VersionB from the OSTree remote warehouse to the OSTree local warehouse; An OSTree upgrade file for upgrading from Linux system version Version A to Linux system version Version B is created in the OSTree local warehouse. The OSTree upgrade file uses Linux system version Version A as a source version and Linux system version Version B as a target version.

2. The OSTree-based system upgrade method according to claim 1, characterized in that: Pulling Linux system version Version A and Linux system version Version B from the OSTree remote warehouse to the OSTree local warehouse includes: Create a working directory on the S3 workstation used to create the OSTree upgrade file and allocate the corresponding operating space. Enter the working directory, use OSTree initialization instructions to create the OSTree local warehouse directory, and bind the OSTree remote warehouse address; Through the OSTree pull command, all relevant object files with version identifiers VersionA and VersionB as reference parameters in the OSTree remote warehouse are pulled into the OSTree local warehouse.

3. The OSTree-based system upgrade method according to claim 1, characterized in that: The OSTree upgrade file for upgrading from Linux system version A to Linux system version B is generated in the OSTree local warehouse, including: Open the OSTree local repository; Create source version object hash table, target version object hash table, new attribute metadata hash table, new common file hash table, new symbolic link hash table, content modification table hash table and optimized content modification table hash table; According to Linux system version Version A and Linux system version Version B, corresponding objects are stored in the source version object hash table, the target version object hash table, the newly added attribute metadata hash table, the newly added ordinary file hash table, the newly added symbolic link hash table, and the content modification table hash table, and an optimized content modification table hash table is obtained based on the content modification table hash table; Define logical shard types and operation codes, generate atomic operation sequences and rollback instruction sets; Build shard data blocks and Merkle trees, and associate indexes to obtain complete shard index blocks; Create a file header descriptor; Write the file header descriptor, all shard data blocks, shard index blocks, and rollback instruction sets in sequence to generate the OSTree upgrade file.

4. The OSTree-based system upgrade method according to claim 3, characterized in that: 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 newly added attribute metadata hash table, the newly added common file hash table, the newly added symbolic link hash table, and the content modification table hash table, including: If the source version exists, the metadata of the source version is loaded, and the hash values ​​of all objects contained in the source version are stored in the source version object hash table. At the same time, the metadata of the target version is loaded, and the hash values ​​of all objects contained in the target version are stored in the target version object hash table. Traverse the target version object hash table. For object files that do not appear in the source version object hash table, write the object files that do not appear in the source version object hash table into the corresponding newly added attribute metadata hash table, newly added common file hash table, or newly added symbolic link hash table according to the type of the object file. For object files that appear in the source version object hash table but have different hash values, record the source version hash value and the target version hash value of the object file as one entry in the content modification table hash table. A content-aware difference engine is introduced to optimize the content in the content modification hash table, generate difference results and store them in the optimized content modification hash table.

5. The OSTree-based system upgrade method according to claim 4, characterized in that: Defining the logical shard type and operation code, generating the atomic operation sequence and rollback instruction set, includes: Based on the source of the changes and the difference results, operation codes are defined to guide device-side operations when upgrading applications. New operation codes with transaction control capabilities are also introduced. Traversing the newly added attribute metadata hash table, the newly added common file hash table, the newly added symbolic link hash table, and the optimized content modification hash table, converting each change item into one or more atomic operation instructions using the opcode, and organizing all atomic operation instructions into an atomic operation sequence; For database and structured file modifications in content-aware differencing, corresponding rollback instruction sets are generated synchronously.

6. The OSTree-based system upgrade method according to claim 5, characterized in that: The construction of the shard data block and the Merkle tree, and the associated index to obtain a complete shard index block, includes: Traverse the newly added common file hash table, the newly added symbolic link hash table, the newly added attribute metadata hash table, and the optimized content modification hash table, compress the data content of each entry, and add a data block header to form a fragmented data block; The hash values ​​of all generated sharded data blocks are used as leaf nodes of the Merkle tree. The adjacent hash values ​​are paired and hashed again, and the tree is constructed layer by layer until a unique root hash value is generated. The root hash value is used as the unique integrity certificate of the entire data shard area and is written into the file header. Traverse the atomic operation sequence, and for each instruction in the sequence that requires data, associate the corresponding shard data block information with it 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 position information of the data block in the Merkle tree.

7. The OSTree-based system upgrade method according to claim 3, characterized in that: The step of creating a file header descriptor includes: Calculate the starting offset of each area based on the size of all data blocks, index blocks, and rollback instruction set areas to be written. Construct a file header descriptor, which contains the core meta information describing the entire OSTree upgrade file.

8. The OSTree-based system upgrade method according to claim 1, characterized in that: The method also includes encrypting the OSTree upgrade file with a preset key file, generating the OSTree encrypted upgrade file, and then transmitting the OSTree encrypted upgrade file.

9. The OSTree-based system upgrade method according to claim 8, characterized in that: The OSTree encrypted upgrade file is delivered, including: Upload the OSTree encrypted upgrade file to the existing upgrade management backend, configure the upgrade task in the backend, push the OSTree encrypted upgrade file to device D1, periodically obtain the upgrade task from the upgrade backend, download the OSTree encrypted upgrade file to device D1 according to the upgrade task configuration, and place it in the specified directory; or Store the OSTree encrypted upgrade file in the specified directory of device D1 via a USB disk or SD card; or The data is obtained from the specified network address on the device D1 through a network command or a browser, and is placed in the specified directory of the device D1.

10. The OSTree-based system upgrade method according to claim 8, characterized in that: The method also includes encrypting the OSTree encryption upgrade file with a preset key file, generating an OSTree upgrade file, and then applying the OSTree upgrade file.