A mounting method based on immutable operating system data isolation architecture

Abstract

The application relates to the technical field of computers, and particularly provides a mounting method based on an immutable operating system data isolation architecture, which comprises the following steps: S1, deploying a basic system layer, an installed data layer, a data snapshot layer, a temporary maintenance layer and a directory display layer in a system installation stage, and creating directories for the layers of the system; S2, reading a configuration file state bit of a maintenance mode through a script in an initramfs stage of system startup, and determining a corresponding data layer according to the configuration file state bit; S3, when a user triggers mode switching, a background process responds to the switching request, updates the configuration file state bit of the maintenance mode, completes data migration, and prompts the user to restart the system to complete the switching, and after restarting, returning to step S2. Through the above scheme, the technical problems of insufficient configuration protection and complex management of data modification of an existing operating system are solved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and specifically provides a mounting method based on an immutable operating system data isolation architecture. Background Technology

[0002] With the accelerating pace of digitalization in society, enterprises are placing increasingly higher demands on operating systems in terms of data security and system stability. The application scenarios for domestically developed operating systems are also becoming more widespread. However, current mainstream operating systems generally suffer from the problem of user data and core system data being stored together. If a user accidentally modifies critical system files, it can easily trigger a system crash, posing a significant risk.

[0003] To address the aforementioned risks and enhance system stability and security, the immutable system based on OSTree technology employs a strict access control mechanism: core system directories (including / usr and its linked directories such as / lib, / bin, and / sbin) are uniformly set to read-only. This mechanism effectively prevents users or applications from writing to, deleting from, or creating links to these core directories during system runtime. The main purpose of this access control mechanism is to: prevent critical files from being tampered with, avoiding modification of core system files due to accidental operations or malicious attacks; ensure upgrade / rollback consistency, guaranteeing that system upgrades and rollbacks are based on a deterministic and unchanging fundamental state; and improve the overall system security level by limiting write permissions, thereby reducing the attack surface.

[0004] However, the strict read-only restriction of the core directory also brings significant challenges. Traditional software installation methods fail, and any software that relies on writing files to the aforementioned core directory cannot be installed, severely weakening the system's availability and flexibility.

[0005] Furthermore, existing technologies (taking open-source Fedora as an example) have the following significant drawbacks.

[0006] 1. Insufficient protection of core configurations and mixed data:

[0007] Although access control (such as setting the / usr directory to read-only) protects some core data, critical directories such as / etc remain writable. User modifications to the core system configurations under / etc are directly written to the underlying system.

[0008] This design leads to a lack of effective isolation between core system data and user-modified data, resulting in a chaotic hierarchy. Furthermore, accidental or malicious modifications to core configurations by users can cause system crashes, and there is a lack of effective mechanisms to roll back to the stable state before the modifications.

[0009] 2. Developer mode introduces complexity in deployment point management and data synchronization obstacles:

[0010] To modify the contents of the protected / usr directory, Developer Mode must be enabled. This mode creates a new, independent Deployment Point, allowing users to modify the / usr directory within this new deployment point.

[0011] 1) Disorganized deployment point management: Deployment points generated by system upgrades coexist with those created in developer mode and are difficult to distinguish. User modifications and system installation data are mixed together, increasing the complexity of user management. In addition, it also makes the factory reset function more simplistic (it needs to save the original factory data, and restore data through data copying or other means during restoration).

[0012] 2) Lack of data synchronization mechanism: The developer mode deployment point is isolated from the user's current running deployment point, lacking an effective data synchronization channel. Modifications made by the user in the developer deployment point cannot be directly updated or applied to the currently running deployment point, resulting in inefficient and fragmented data management. Summary of the Invention

[0013] To overcome the above-mentioned shortcomings, this invention is proposed to solve the technical problems of insufficient configuration protection and complex management of data modification in existing operating systems.

[0014] This invention provides a mounting method based on an immutable operating system data isolation architecture, comprising the following steps:

[0015] S1: During the system installation phase, deploy a data layer including the basic system layer, installation data layer, data snapshot layer, temporary maintenance layer, and directory display layer, and create directories for each layer of the system. The basic system layer is used to store read-only data distributed by the storage client or system image disk. The installation data layer is used to store persistent data written during the system installation phase. The data snapshot layer is used to record changed data during system operation. The temporary maintenance layer is used to record temporary changed data in maintenance mode. The basic system layer, installation data layer, data snapshot layer, and temporary maintenance layer are finally presented in a unified manner in the directory display layer through the overlay mechanism.

[0016] S2: During the initramfs phase of system startup, the configuration file status bits of the maintenance mode are read by a script, and the corresponding data layer is determined to be mounted based on the configuration file status bits.

[0017] S3: When the user triggers the mode switch, the background process responds to the switch request and updates the status bits of the maintenance mode configuration file, completes the data migration, and prompts the user to restart the system to complete the switch. After restarting, it returns to step S2.

[0018] further,

[0019] The basic system layer includes the / usr, / etc, and / var / lib directories;

[0020] The installation data layer includes the etc-lower, usr-lower, and var-lower / lib directories;

[0021] The data snapshot layer includes the etc-upper, usr-upper, and var-upper / lib directories;

[0022] The temporary maintenance layer includes the etc-tmpupper, usr-tmpupper, and var-tmpupper / lib directories.

[0023] Furthermore, S1 also includes mounting an installation data layer, which saves the user settings and installation configurations during the system installation phase in the installation data layer, and restarts the device after the installation process is completed.

[0024] Furthermore, when the configuration file status is set to "Maintenance Mode Enabled," the basic system layer, installation data layer, data snapshot layer, and temporary maintenance layer need to be mounted. When the configuration file status is set to "Maintenance Mode Disabled," the basic system layer, installation data layer, and data snapshot layer also need to be mounted.

[0025] Furthermore, when the configuration file status is set to enabled maintenance mode, the following directories are mounted to Lower Dir: / usr, / etc, / var / lib in the basic system layer, etc-lower, usr-lower, var-lower / lib in the installation data layer, and etc-upper, usr-upper, var-upper / lib in the data snapshot layer. The following directories are mounted to Upper Dir: etc-tmpupper, usr-tmpupper, var-tmpupper / lib in the temporary maintenance layer.

[0026] Furthermore, when the configuration file status is in the off maintenance mode, the / usr, / etc, and / var / lib directories of the basic system layer, the etc-lower, usr-lower, and var-lower / lib directories of the installation data layer, and the usr-upper of the data snapshot layer are mounted to Lower Dir, and the etc-upper and var-upper / lib directories of the data snapshot layer are mounted to UpperDir.

[0027] Furthermore, S3 includes:

[0028] S311: The user enables maintenance mode through the maintenance mode component in the control panel;

[0029] S312: Background DBus process responds to mode switching instructions, determines whether maintenance mode is currently enabled, and updates the configuration file status bits;

[0030] S313: The UI prompts the user to restart in order to complete the mode switch.

[0031] Furthermore, S3 includes:

[0032] S321: Normal user operation of the system involves modification of data in the core directories / usr, / etc, and / var / lib;

[0033] S322: Users can set "Save changes made in this maintenance mode" through the maintenance mode component in the control panel;

[0034] S323: The user disables maintenance mode via the maintenance mode component in the control panel;

[0035] S324: The background DBus process responds to the mode switching command and determines whether to save the changes of this maintenance mode. If yes, the temporary operation and maintenance layer data needs to be migrated to the data snapshot layer, and then the configuration file status bit is updated; if not, the configuration file status bit is updated directly.

[0036] S325: The UI prompts the user to restart to complete the mode switch.

[0037] Furthermore, the factory reset process includes the following steps:

[0038] When a user clicks "Restore Factory Settings" through the graphical interface, a request to restore factory settings is initiated, and the system captures this operation command.

[0039] After the background service responds to the factory reset request command, it renames the current data snapshot layer and the temporary operation and maintenance layer, creates an empty directory with the same name as the new data layer carrier, and triggers the system to restart and enter the recovery state.

[0040] Multi-level verification is performed during system startup;

[0041] If the system starts normally within the set time and all critical services are ready, the old data layer directory is asynchronously cleared; if a system startup timeout or critical service failure is detected, an error code and failure reason are pushed to the user, and an automatic rollback is performed in the initramfs stage.

[0042] Furthermore, during the rollback, the newly generated data layer directory is deleted, and the backup directory is restored to the standard naming of the data snapshot layer or temporary operation and maintenance layer. The system is then restarted a second time to return to its original stable state.

[0043] The working principle and beneficial effects of this invention:

[0044] In implementing the technical solution of this invention, dynamic permission control and scene switching are achieved without increasing deployment points. Through dynamic mounting strategies, strong write protection of the core directory in user mode and complete software installation and configuration update compatibility in maintenance mode are achieved. Furthermore, atomic rollback and rapid recovery are supported. The five-layer architecture of the system ensures the purity of the underlying system, and can be quickly recovered through the basic system in the event of a crash. Factory reset efficiency is greatly improved, and rapid factory recovery can be achieved by only deleting data and modifying snapshot layer and temporary maintenance layer data. Attached Figure Description

[0045] The disclosure of this invention will become more readily understood with reference to the accompanying drawings. It will be readily understood by those skilled in the art that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of this invention. Furthermore, similar numbers in the drawings are used to denote similar components, wherein:

[0046] Figure 1 This is a schematic diagram of the data isolation architecture with maintenance mode enabled in this invention;

[0047] Figure 2 This is a schematic diagram of the data isolation architecture with maintenance mode disabled in this invention;

[0048] Figure 3 This is a flowchart illustrating the process of enabling maintenance mode in this invention;

[0049] Figure 4 This is a flowchart illustrating the process of closing the maintenance mode in this invention;

[0050] Figure 5 This is a system startup flowchart in Embodiment 2 of the present invention;

[0051] Figure 6 This is a flowchart illustrating the execution of scripts at each stage in initramfs in Embodiment 2 of the present invention;

[0052] Figure 7 This is a schematic diagram of the process for restoring factory settings in Embodiment 3 of the present invention. Detailed Implementation

[0053] Some embodiments of the present invention will now be described with reference to the accompanying drawings. Those skilled in the art should understand that these embodiments are merely illustrative of the technical principles of the present invention and are not intended to limit the scope of protection of the present invention.

[0054] Here we will first explain some of the terms involved in this invention.

[0055] ostree: A very popular and powerful underlying technology for implementing immutable operating system models. It perfectly meets the requirements of immutable systems for atomicity, efficiency, reliability, and version management.

[0056] Overlay: A file system technique for union mounting. It transparently merges the contents of multiple directories (called "layers") into a unified view. Users see the result of all layers being overlaid, but the underlying files themselves are not modified or copied.

[0057] Lower Dir(s): These are typically one or more read-only directories. They form the underlying content of an overlay.

[0058] Upper Directory: This is typically a read-write directory. It is used to store modifications (additions, deletions, and changes) made to the lower-level directories.

[0059] Work Dir: A required empty directory for internal use by OverlayFS to ensure the atomicity of file operations (such as temporary operations during file renaming).

[0060] Merged Dir: The final rendering view, which is the result of merging the Lower Dir(s) and Upper Dir. Users or applications work within this directory.

[0061] Example 1

[0062] This embodiment proposes a mounting method based on an immutable operating system data isolation architecture. Based on the determination of the maintenance mode state at startup, a file system mounting strategy is dynamically constructed, specifically including the following steps S1-S3.

[0063] S1: During the system installation phase, deploy the basic system layer, installation data layer, data snapshot layer, temporary maintenance layer, and directory display layer (including core directories such as / usr, / etc, and / var), and create directories for each layer of the system; mount the installation data layer to save user settings and installation configurations during the system installation phase, and restart the device after completing the subsequent installation process.

[0064] Figure 1 This is a schematic diagram of the data isolation architecture with maintenance mode enabled in this invention. Figure 2 This is a schematic diagram of the data isolation architecture with maintenance mode disabled in this invention. Figure 1-2 The red portion indicates read-only, and the green portion indicates read-write. For example... Figure 1-2As shown, the logical separation of the basic system layer, installation data layer, data modification layer, temporary maintenance layer, and directory display layer is achieved through OverlayFS technology, where:

[0065] The basic system layer is used to store read-only data distributed by the storage client or system image disk, and it includes the / usr, / etc, and / var / lib directories;

[0066] The installation data layer is used to store persistent data written during the system installation phase, including the etc-lower, usr-lower, and var-lower / lib directories;

[0067] The data snapshot layer is used to record changes in system data during operation, including the etc-upper, usr-upper, and var-upper / lib directories;

[0068] The temporary maintenance layer is used to record temporary change data in maintenance mode, including the etc-tmpupper, usr-tmpupper, and var-tmpupper / lib directories;

[0069] The basic system layer, installation data layer, data snapshot layer, and temporary maintenance layer are ultimately presented uniformly in this directory display layer through the overlay mechanism.

[0070] In one implementation, / var primarily contains logs, application status, cache, and temporary files. The logs and cache are temporary or regenerable data, typically requiring no migration or cross-deployment point storage. Therefore, to improve data processing efficiency, in this embodiment, only application status data (i.e., the / var / lib directory) is used as the core data under the / var directory. To avoid altering the structure of the system's root directory (" / "), the / etc, / usr, and / var / lib directories store data from the basic system layer and also serve as the directory presentation layer after the various directories are stacked. The relationship between these directories and each layer is as follows:

[0071] -lower directories (etc-lower, usr-lower, var-lower / lib): Store data from the installation data layer;

[0072] -upper directories (etc-upper, usr-upper, var-upper / lib): Store data from the data snapshot layer;

[0073] -tmpupper directories (etc-tmpupper, usr-tmpupper, var-tmpupper / lib): Store data for the temporary maintenance layer;

[0074] -work directories (etc-work, usr-work, var-work / lib): These directories do not correspond to any layer in the data isolation architecture; they are created solely for overlay mounting technology.

[0075] S2: During the initramfs phase of system startup, the configuration file status bits of the maintenance mode are read by a script, and the corresponding data layer is determined to be mounted based on the configuration file status bits.

[0076] like Figure 1 As shown, when the configuration file status is enabled for maintenance mode, the basic system layer, installation data layer, data snapshot layer, and temporary maintenance layer need to be mounted. Specifically, the mounting status of each directory when maintenance mode is enabled is shown in Table 1.

[0077] Table 1: Mounting status when maintenance mode is enabled

[0078]

[0079] Figure 1 The actual mounting logic when enabling maintenance mode is shown in the table above. To ensure that all data generated by maintenance mode is stored in the temporary maintenance layer and separated from the data in other layers, it is necessary to separate the basic system layer ( / etc, / usr, / var / lib directories), the installation data layer ( -lower directory), data snapshot layer ( The upper directory is mounted to the Lower Dir, while the temporary maintenance layer ( The -tmpupper directory is then mounted to Upper Dir.

[0080] WorkDir is the working directory used internally by the overlay. -work is an empty directory and does not correspond to any layer of the data isolation architecture.

[0081] Merge Dir is a unified file system view that overlays Lower Dir and Upper Dir, allowing users or applications to directly access this directory. The directory presentation layer is mounted on Merge Dir.

[0082] Therefore, when the operation and maintenance mode is enabled, the directory display layer data is the result of the basic system layer, installation data layer, data snapshot layer and temporary maintenance layer being superimposed through overlay technology. Updates to core data ( / etc, / usr, / var / lib) by users or applications are stored in the temporary maintenance layer.

[0083] like Figure 2As shown, when the configuration file status is in the off maintenance mode, only the basic system layer, installation data layer, and data snapshot layer need to be mounted. Specifically, the mounting status of each directory when the maintenance mode is off is shown in Table 2.

[0084] Table 2: Mounting status when maintenance mode is off

[0085]

[0086] Figure 2 The actual mounting logic when the maintenance mode is closed is shown in the table above. Due to the characteristics of OverlayFS, LowerDir is read-only. In order to ensure that users cannot modify the data of each directory related to usr when the maintenance mode is closed, in addition to the basic system layer and the installation data layer, the data snapshot layer of usr (usr-upper directory) also needs to be mounted on LowerDir.

[0087] Because of the OverlayFS characteristics, UpperDir is read-write, and user file operations will be stored here. Therefore, the data snapshot layer directories for / etc and / var / lib should be mounted to UpperDir. Since the usr directory does not allow writing data when maintenance mode is off, the UpperDir for / usr does not need to be mounted. However, to ensure the integrity of the directory presentation layer after overlay merging, the data snapshot layer for / usr (i.e., the usr-upper directory) should be mounted to LowerDir.

[0088] WorkDir is the working directory used internally by the overlay. -work is an empty directory and does not correspond to any layer of the data isolation architecture.

[0089] Merge Dir is a unified file system view that overlays Lower Dir and Upper Dir, allowing users or applications to directly access this directory. The directory presentation layer is mounted on Merge Dir.

[0090] Therefore, when the operation and maintenance mode is closed, the directory presentation layer data is the result of the basic system layer, installation data layer and data snapshot layer being superimposed through overlay technology. Modifications made by users or applications to the / etc and / var / lib directories are saved in the data snapshot layer, and users do not have permission to modify or update the data in the / usr directory.

[0091] S3: Users can trigger mode switching through the control panel. The background process responds to the switching request and updates the status bits of the maintenance mode configuration file. After completing the data migration, the user is prompted to restart the system to complete the switch. After restarting, the process returns to step S2.

[0092] In one implementation, Figure 3 This is a flowchart illustrating the process of activating maintenance mode in this invention, as shown below. Figure 3 As shown, when a user switches from off maintenance mode to on maintenance mode via the control panel, the following steps S311-S313 are included.

[0093] S311: The user enables maintenance mode through the maintenance mode component in the control panel;

[0094] S312: Background DBus process responds to mode switching instructions, determines whether maintenance mode is currently enabled, and updates the configuration file status bits;

[0095] S313: The UI prompts the user to restart in order to complete the mode switch.

[0096] In one implementation, Figure 4 This is a flowchart illustrating the process of disabling maintenance mode in this invention, as shown below. Figure 4 As shown, when a user switches from maintenance mode to maintenance mode off via the control panel, the following steps S321-S325 are included.

[0097] S321: Normal user use of the system involves modifications to data in core directories such as / usr, / etc, and / var / lib;

[0098] S322: Users can set "Save changes made in this maintenance mode" through the maintenance mode component in the control panel;

[0099] S323: The user disables maintenance mode via the maintenance mode component in the control panel;

[0100] S324: The background DBus process responds to the mode switching command and determines whether to save the changes of this maintenance mode. If yes, the temporary operation and maintenance layer data needs to be migrated to the data snapshot layer, and then the configuration file status bit is updated; if not, the configuration file status bit is updated directly.

[0101] S325: The UI prompts the user to restart to complete the mode switch.

[0102] In this embodiment, the daemon process in maintenance mode will clear the temporary maintenance layer data when it detects a shutdown signal, so that the temporary maintenance data layer data will contain all the data generated by the current maintenance modification when entering maintenance mode again.

[0103] Based on the above steps S1-S3, the following technical effects can be achieved:

[0104] 1. Without increasing deployment points, achieve dynamic permission control and scenario switching, and realize strong write protection of the core directory in user mode and complete software installation and configuration update compatibility in maintenance mode through dynamic mounting strategy;

[0105] 2. Supports temporary debugging and permanent storage of maintenance data, providing users with a portable entry point for system debugging;

[0106] 3. Supports atomic rollback and fast recovery; the system's five-layer architecture ensures the purity of the underlying system, allowing for rapid recovery through the basic system in case of a crash; factory reset efficiency is greatly improved, and a fast factory reset can be achieved by simply deleting data and modifying snapshot layer and temporary maintenance layer data;

[0107] 4. Greatly improves system data security; based on the hierarchical structure, it enables fine-grained access control and supports effective tracking of modified data.

[0108] It should be noted that although the steps in the above embodiments are described in a specific order, those skilled in the art will understand that in order to achieve the effects of the present invention, different steps do not necessarily have to be executed in such an order. They can be executed simultaneously (in parallel) or in other orders, and these variations are all within the scope of protection of the present invention.

[0109] Example 2

[0110] Based on the mounting method for an immutable operating system data isolation architecture proposed in Embodiment 1, this embodiment presents the specific mounting process of this method in practical applications. Figure 5 This is a system startup flowchart in Embodiment 2 of the present invention, as follows: Figure 5 As shown, in practical applications, the following process is included:

[0111] A: Boot from BIOS;

[0112] B: Boot loads the GRUB program, kernel, and initramfs;

[0113] C: Kernel boots, decompresses and mounts initramfs as a temporary root file system;

[0114] D: Execute the scripts for each stage in initramfs;

[0115] E: Switch root file system;

[0116] F: System initialization complete.

[0117] further, Figure 6 This is a flowchart illustrating the execution of scripts at each stage in initramfs in Embodiment 2 of the present invention, as shown below. Figure 6 As shown, the execution of each stage script in initramfs specifically includes the following steps D1-D7.

[0118] D1. During the initramfs stage of the system startup process, this invention will check whether there are fields in the / proc / cmdline file used to identify factory reset, backup restore, etc.

[0119] D2. If the flag described in D1 is present, it indicates that this is a normal system startup process. In this case, check whether the mode value in the osree-ovl.conf configuration file and the lock file both indicate that the configuration file is enabled / disabled. The configuration file is used to identify the mount mode, and the lock file is used for double verification during mode determination to avoid the system startup state being inconsistent with the user's expectations due to user error or abnormal maintenance mode switching.

[0120] D3. If the switch states represented in D2 are consistent, then the corresponding data layer can be directly mounted.

[0121] In maintenance mode, the basic system layer, installation data layer, data snapshot layer, temporary maintenance layer, and directory display layer are mounted via an overlay. The basic system layer, installation data layer, and data snapshot layer correspond to the lower layers of the overlay, ensuring that user modifications to the directory cannot directly affect these layers, thus protecting data security. The temporary maintenance layer corresponds to the upper layer of the overlay; all modifications made in maintenance mode are stored in this layer, and subsequent retention of these modifications can be dynamically determined based on user selection. These layers are then overlaid using the overlay and ultimately displayed to the user through the directory display layer.

[0122] In user mode (i.e., maintenance mode disabled), the overlay mounts the basic system layer, installation data layer, data snapshot layer, and directory display layer. The basic system layer and installation data layer correspond to the lower layer of the overlay (to ensure the data security of the user's core data usr directory in this mode, the usr directory in the data snapshot layer also needs to be mounted to the lower layer), thus preventing users from directly modifying the above layers and ensuring data security. The data snapshot layer corresponds to the upper layer of the overlay, so that user-modified data can be directly saved to the directory corresponding to the data snapshot layer.

[0123] The directories mounted in the above mode can be dynamically adjusted through the configuration file. To ensure system security and consistency, the configuration file is uniformly distributed and updated by the server and can only be modified by users with administrator privileges.

[0124] D4. If the maintenance switch status represented in D2 is inconsistent, it indicates that the previous mode switch was abnormal. The user needs to be asked via Plymouth whether to continue starting the system with maintenance mode enabled.

[0125] D5. Based on the user's input, continue mounting the corresponding data layer according to the logic in D3;

[0126] D6. After mounting is complete, update the configuration file and lock file status;

[0127] D7. Once the system's layered mounting is complete, continue with the original system startup process.

[0128] Example 3

[0129] Based on the mounting method for an immutable operating system data isolation architecture proposed in Embodiment 1, this embodiment presents a specific procedure for restoring factory settings in practical applications of this mounting method. Figure 7 This is a schematic diagram of the factory reset process in Embodiment 3 of the present invention, as shown below. Figure 7 As shown:

[0130] ① The user initiates a factory reset request by clicking "Restore Factory Settings" through the graphical user interface (GUI), and the system captures this operation command.

[0131] ② After the background service responds to the factory reset request command, it performs atomic operations: renames the current data snapshot layer and the temporary operation and maintenance layer (retains the original data layer as a rollback backup), creates an empty directory with the same name as the new data layer carrier, and triggers the system to restart and enter the recovery state;

[0132] ③ The system performs multi-level verification during startup, including the status of core services such as systemd and lightdm;

[0133] ④ If the system starts normally within the set time and all critical services are ready, the old data layer directory is cleared asynchronously; if a system startup timeout or critical service abnormality is detected, an error code and failure reason are pushed to the user, and an automatic rollback is performed in the initramfs stage.

[0134] During the rollback, delete the new data layer directory generated during the abnormal startup, restore the backup directory to the standard naming of the data snapshot layer / temporary operation and maintenance layer, and restart the system a second time to the original stable state.

[0135] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after such changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A mounting method based on an immutable operating system data isolation architecture, characterized in that, Includes the following steps: S1: During the system installation phase, deploy a data layer including the basic system layer, installation data layer, data snapshot layer, temporary maintenance layer, and directory display layer, and create directories for each layer of the system. The basic system layer is used to store read-only data distributed by the storage client or system image disk. The installation data layer is used to store persistent data written during the system installation phase. The data snapshot layer is used to record changed data during system operation. The temporary maintenance layer is used to record temporary changed data in maintenance mode. The basic system layer, installation data layer, data snapshot layer, and temporary maintenance layer are finally presented in a unified manner in the directory display layer through the overlay mechanism. S2: During the initramfs phase of system startup, the configuration file status bits of the maintenance mode are read by a script, and the corresponding data layer is determined to be mounted based on the configuration file status bits. S3: When the user triggers a mode switch, the background process responds to the switch request and updates the status bits of the maintenance mode configuration file, completes the data migration, and prompts the user to restart the system to complete the switch. After restarting, it returns to step S2. The creation of directories for each layer of the system includes: -lower directory: Stores data from the installation data layer; -upper directory: Stores data from the data snapshot layer; -tmpupper directory: Stores data for the temporary maintenance layer; -work directory: The working directory used internally by the overlay. It does not correspond to any layer in the data isolation architecture and is only created for the needs of the overlay mounting technology. The basic system layer includes the / usr, / etc, and / var / lib directories; The installation data layer includes the etc-lower, usr-lower, and var-lower / lib directories; The data snapshot layer includes the etc-upper, usr-upper, and var-upper / lib directories; The temporary maintenance layer includes the etc-tmpupper, usr-tmpupper, and var-tmpupper / lib directories; When the configuration file status is set to "Maintenance Mode Enabled", the basic system layer, installation data layer, data snapshot layer, and temporary maintenance layer need to be mounted. When the configuration file status is set to "Maintenance Mode Disabled", the basic system layer, installation data layer, and data snapshot layer need to be mounted. When the configuration file status is set to enabled maintenance mode, the following directories are mounted to Lower Dir: / usr, / etc, / var / lib in the basic system layer, etc-lower, usr-lower, var-lower / lib in the installation data layer, and etc-upper, usr-upper, var-upper / lib in the data snapshot layer. The following directories are mounted to Upper Dir: etc-tmpupper, usr-tmpupper, var-tmpupper / lib in the temporary maintenance layer. When the configuration file status is in the off maintenance mode, mount the / usr, / etc, and / var / lib directories of the basic system layer, the etc-lower, usr-lower, and var-lower / lib directories of the installation data layer, and the usr-upper of the data snapshot layer to the Lower Dir, and mount the etc-upper and var-upper / lib directories of the data snapshot layer to the Upper Dir. Work Dir is the working directory used internally by the overlay to ensure the atomicity of file operations. S3 includes: S321: Normal user operation of the system involves modification of data in the core directories / usr, / etc, and / var / lib; S322: Users can set "Save changes made in this maintenance mode" through the maintenance mode component settings in the control panel; S323: The user disables maintenance mode via the maintenance mode component in the control panel; S324: The background DBus process responds to the mode switching command and determines whether to save the changes of this maintenance mode. If yes, the temporary operation and maintenance layer data needs to be migrated to the data snapshot layer, and then the configuration file status bit is updated; if not, the configuration file status bit is updated directly. S325: The UI prompts the user to restart to complete the mode switch; When restoring factory settings, the user initiates a factory reset request by clicking "Restore Factory Settings" through the graphical interface, and the system captures this operation command; After the background service responds to the factory reset request command, it renames the current data snapshot layer and the temporary operation and maintenance layer, creates an empty directory with the same name as the new data layer carrier, and triggers the system to restart and enter the recovery state.

2. The mounting method based on an immutable operating system data isolation architecture according to claim 1, characterized in that, S1 also includes mounting an installation data layer, which saves the user settings and installation configurations during the system installation phase in the installation data layer, and restarts the device after the installation process is completed.

3. The mounting method based on an immutable operating system data isolation architecture according to claim 1, characterized in that, S3 includes: S311: The user enables maintenance mode through the maintenance mode component in the control panel; S312: Background DBus process responds to mode switching instructions, determines whether maintenance mode is currently enabled, and updates the configuration file status bits; S313: The UI prompts the user to restart in order to complete the mode switch.

4. The mounting method based on an immutable operating system data isolation architecture according to claim 1, characterized in that, The factory reset process also includes the following steps: Multi-level verification is performed during system startup; If the system starts normally within the set time and all critical services are ready, the old data layer directory is asynchronously cleared; if a system startup timeout or critical service failure is detected, an error code and failure reason are pushed to the user, and an automatic rollback is performed in the initramfs stage.

5. The mounting method based on an immutable operating system data isolation architecture according to claim 4, characterized in that, During the rollback, delete the new data layer directory generated during the abnormal startup, restore the backup directory to the standard naming of the data snapshot layer or temporary operation and maintenance layer, and restart the system a second time to the original stable state.

Images