An implementation method of a Linux operating system based on OverlayFS technology and a related device

Abstract

This application discloses a method and related apparatus for implementing a Linux operating system based on OverlayFS technology, relating to the field of operating systems. This application starts the GRAND unified bootloader on the second hardware partition through a boot bridge carrier of the first hardware partition, leveraging the read-only attribute of the second hardware partition to ensure the GRAND unified bootloader is not tampered with; the GRAND unified bootloader loads the Linux Live ISO image file within the second hardware partition; the Linux system kernel program is started and the memory file system image is initialized; during the cleanup phase, a custom dracut script mounts the third hardware partition to a temporary system mount point, using the upperdir and workdir directories within the third hardware partition to achieve independent storage of changed data and intermediate state data; the original configuration file directory embedded in the Linux Live ISO image file is then set as the read-only lowerdir layer of OverlayFS to ensure the system core configuration is not tampered with; the lowerdir layer and the upperdir directory are merged to form a unified view, allowing users to operate normally without needing to concern themselves with the layering logic.

Description

Technical Field

[0001] This application relates to the field of operating system technology, and in particular to a method and related apparatus for implementing a Linux operating system based on OverlayFS technology. Background Technology

[0002] Traditional Linux operating system deployment and installation are mainly divided into full hard drive installation and Live CD (LiveCompact Disc) deployment. Full hard drive installation permanently writes the complete Linux operating system file set, such as the kernel, root file system, / etc directory, boot files, etc., to the local hard drive. After installation, the root file system and / etc directory are entirely writable. Configuration changes are directly written to the hard drive partition containing core files (such as the kernel). If a configuration problem occurs in the Linux operating system, the entire Linux operating system must be restored, resulting in extremely low recovery efficiency.

[0003] Live CD deployment is a lightweight deployment method that boots from read-only media and runs the Linux operating system in memory throughout the entire process. During the operation of the Linux operating system, all configuration changes are temporarily stored in memory and are lost after a reboot, which cannot meet the basic requirement of long-term effectiveness of configuration changes.

[0004] Full hard drive installation sacrifices the purity of the system kernel (i.e., configuration changes can be directly written to the hard drive partition where the kernel files are located) in exchange for configuration persistence; Live CD deployment sacrifices configuration persistence (i.e., configuration changes are temporarily stored in memory and are all lost after a restart) in exchange for the purity of the system kernel. Neither of them achieves a fusion design that ensures the kernel files are read-only and tamper-proof while configuration changes are persistent. Summary of the Invention

[0005] In view of the above problems, this application provides a method and related apparatus for implementing a Linux operating system based on OverlayFS technology, so as to achieve a hybrid design that combines read-only, tamper-proof core files with persistent configuration changes. The specific solution is as follows:

[0006] The first aspect of this application provides a method for implementing a Linux operating system based on OverlayFS technology, including:

[0007] The boot bridge carrier stored in the first directory area of ​​the first hardware partition is loaded through the Unified Extensible Firmware Interface (UEFI) firmware, and the boot bridge carrier is used to link to the GRAND Unified Bootloader.

[0008] The GRAND unified bootloader is started in the second directory area of ​​the second hardware partition through the boot bridging carrier; the second hardware partition is a read-only storage carrier.

[0009] The Linux Live ISO image file stored in the third directory area of ​​the second hardware partition is loaded by the GRAND unified bootloader. The Linux Live ISO image file contains the Linux system kernel program and an initialized memory file system image.

[0010] The Linux system kernel program is started and the memory file system image file is executed, the memory file system image file including the dracut custom script;

[0011] During the cleanup phase, the third hardware partition is mounted to the system temporary mount point using the dracut custom script. The third hardware partition includes the upperdir directory and the workdir directory. The upperdir directory is used to store the change data generated by the original configuration file directory during the operation of the Linux operating system. The workdir directory is used to temporarily store the intermediate state data generated by OverlayFS during file read and write operations in the lowerdir and upperdir layers.

[0012] The dracut custom script parses the original configuration file directory built into the Linux Live ISO image file;

[0013] The original configuration file directory is determined to be the lowerdir layer of OverlayFS;

[0014] The lowerdir layer and the upperdir directory are merged using the dracut custom script to obtain a combined view.

[0015] One possible implementation also includes:

[0016] If a configuration restore command is detected, the restore trigger method and restore mode are determined. The restore mode is either a full restore mode or a restore backup configuration mode. The restore trigger method is either triggered by a one-click restore tool or triggered by a restore mode startup item. The restore mode startup item corresponding to the restore mode startup item is deployed on the second hardware partition.

[0017] If the restoration is triggered by the one-click restoration tool, terminate all read and write processes on the third hardware partition and release the upperdir directory and the workdir directory from their occupied states.

[0018] If the restore triggering method is triggered by the restore mode startup item, terminate the association between the third hardware partition and the system temporary mount point;

[0019] If the restore mode is the full restore mode, format the third hardware partition;

[0020] Rebuild the upperdir directory and the workdir directory within the third hardware partition;

[0021] If the restore mode is the recovery backup configuration mode, delete the changed data stored in the upperdir directory of the third hardware partition;

[0022] Load the configuration file stored in the preset path and copy it to the upperdir directory;

[0023] Perform a restart operation.

[0024] In one possible implementation, the method for constructing the first hardware partition includes:

[0025] The boot bridging carrier is obtained, which includes an Extensible Firmware Interface (EFI) bootloader and a boot configuration table. The EFI bootloader is a program used to bridge the UEFI firmware and the GRAND unified bootloader, and the boot configuration table is a configuration file used to record the running path of the GRAND unified bootloader.

[0026] The boot bridge carrier is stored in the first directory area of ​​the first hardware partition.

[0027] In one possible implementation, the method for constructing the second hardware partition includes:

[0028] Obtain system core and boot software resources, including the Linux Live ISO image file, the GRAND unified bootloader, and the GRAND unified bootloader GRUB boot configuration template file; the GRUB boot configuration template file is a configuration file framework for the basic operating parameters and rules of the GRAND unified bootloader.

[0029] The GRAND unified bootloader is stored in the second directory area of ​​the second hardware partition;

[0030] Compress the Linux Live ISO image file into squashfs format;

[0031] The Linux Live ISO image file in squashfs format is stored in the third directory area of ​​the second hardware partition;

[0032] Obtain GRUB customized configuration parameters, which include loopback mount rules, embedded kernel parameters, and restore mode boot items; the embedded kernel parameters include the third directory area of ​​the second hardware partition, the device name of the third hardware partition, and the stacking directory of OverlayFS used for joint mounting;

[0033] The GRUB customized configuration parameters are set in the GRUB boot configuration template file to obtain the GRUB solidified configuration file;

[0034] The GRUB firmware configuration file is stored in the fourth directory area of ​​the second hardware partition;

[0035] Set the second hardware partition to read-only.

[0036] In one possible implementation, the method for constructing the third hardware partition includes:

[0037] This document describes the acquisition of file system and directory management tools, including a formatting tool for the fourth extended file system (ext4), Linux directory creation scripts, permission configuration tools, and storage capacity planning tools. The ext4 file system formatting tool is a native Linux tool for formatting hardware partitions as ext4 file systems. The Linux directory creation script is a standardized execution script that can automatically generate a specified directory structure. The permission configuration tool is a native Linux tool used to modify file or directory access control permissions. The storage capacity planning tool is a tool used to calculate and plan the storage capacity of hardware partitions.

[0038] The third hardware partition is formatted as an ext4 file system using the ext4 file system formatting tool.

[0039] The Linux directory creation script creates an OverlayFS directory in the third hardware partition, the OverlayFS directory including the upperdir directory and the workdir directory;

[0040] Configure preset permission rules for the upperdir directory and the workdir directory using the permission configuration tool;

[0041] The storage capacity planning tool is used to plan and reserve redundant storage space for the third hardware partition.

[0042] One possible implementation also includes:

[0043] Verify whether the UEFI firmware can locate the GRAND unified bootloader stored in the second directory area of ​​the second hardware partition through the boot bridging carrier, so as to obtain the first verification result;

[0044] Verify whether the GRAND unified bootloader can read the GRUB hardened configuration file stored in the fourth directory area of ​​the second hardware partition, whether it can mount the Linux Live ISO image file through the loopback mount rule, and whether the read-only attribute of the second hardware partition is effective, so as to obtain the second verification result. The GRUB hardened configuration file includes the loopback mount rule.

[0045] Verify whether the upperdir directory and the workdir directory in the third hardware partition can be written normally by the root user, and whether the third hardware partition can be mounted, so as to obtain the third verification result.

[0046] If the first verification result, the second verification result, and the third verification result are all yes, generate a software storage deployment log;

[0047] The software storage deployment log is stored in a designated hidden directory of the third hardware partition.

[0048] In one possible implementation, the step of loading the Linux Live ISO image file stored in the third directory area of ​​the second hardware partition via the GRAND unified bootloader includes:

[0049] The GRAND unified bootloader reads the GRUB hardened configuration file stored in the fourth directory area of ​​the second hardware partition. The GRUB hardened configuration file includes loopback mount rules, hardened kernel parameters, and restore mode boot items. The hardened kernel parameters include the third directory area of ​​the second hardware partition, the device name of the third hardware partition, and the stacking directory of OverlayFS used for joint mounting.

[0050] The GRAND unified bootloader uses the loopback mount rules to virtualize the Linux LiveISO image file as a block device.

[0051] Access the block device.

[0052] In one possible implementation, the step of starting the Linux system kernel program and executing the initialization memory file system image file includes:

[0053] Load the Linux system kernel program and the initialized memory file system image from the Linux Live ISO image file;

[0054] Start the Linux system kernel program;

[0055] The initialization of the memory file system image is executed through the Linux system kernel program.

[0056] In one possible implementation, the step of mounting the third hardware partition to the system temporary mount point via the dracut custom script during the cleanup phase includes:

[0057] During the cleanup phase, the dracut custom script is triggered by the Linux system kernel program;

[0058] The third hardware partition is mounted to the system's temporary mount point using the dracut custom script.

[0059] In one possible implementation, after the step of merging the lowerdir layer and the upperdir directory via the dracut custom script to obtain a unioned view, the method further includes:

[0060] If a read operation is detected for the federated view, the changed data stored in the upperdir directory is read by the Linux system kernel program;

[0061] If the changed data has not been changed, read the original configuration file stored in the lowerdir layer. The original configuration file refers to the initial configuration content that has not been modified.

[0062] If a write operation is detected for the federated view, the write operation is redirected to the upperdir directory by the Linux system kernel program.

[0063] A second aspect of this application provides an implementation apparatus for a Linux operating system based on OverlayFS technology, comprising:

[0064] The first loading module is used to load the boot bridge carrier stored in the first directory area of ​​the first hardware partition through the Unified Extensible Firmware Interface (UEFI) firmware, wherein the boot bridge carrier is used to link to the GRAND Unified Bootloader.

[0065] The first boot module is used to start the GRAND unified bootloader stored in the second directory area of ​​the second hardware partition through the boot bridging carrier; the second hardware partition is a read-only storage carrier.

[0066] The second loading module is used to load the Linux Live ISO image file stored in the third directory area of ​​the second hardware partition through the GRAND unified bootloader. The Linux Live ISO image file contains the Linux system kernel program and an initialized memory file system image.

[0067] The second boot module is used to start the Linux system kernel program and execute the initialization memory file system image file, wherein the initialization memory file system image includes a dracut custom script;

[0068] The first mounting module is used to mount the third hardware partition to the system temporary mount point through the dracut custom script during the cleanup phase. The third hardware partition includes the upperdir directory and the workdir directory. The upperdir directory is used to store the change data generated by the original configuration file directory during the operation of the Linux operating system. The workdir directory is used to temporarily store the intermediate state data generated by OverlayFS during the file read and write operations in the lowerdir layer and the upperdir layer.

[0069] The parsing module is used to parse the original configuration file directory built into the Linux Live ISO image file using the dracut custom script;

[0070] The first determining module is used to determine that the original configuration file directory is the lowerdir layer of OverlayFS;

[0071] The first acquisition module is used to merge the lowerdir layer and the upperdir directory through the dracut custom script to obtain a combined view.

[0072] A third aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the Linux operating system based on OverlayFS technology described in the first aspect or any implementation thereof.

[0073] A fourth aspect of this application provides an electronic device, including at least one processor and a memory connected to the processor, wherein:

[0074] The memory is used to store computer programs;

[0075] The processor is used to execute the computer program so that the electronic device can implement the Linux operating system based on OverlayFS technology according to the first aspect or any implementation of the first aspect described above.

[0076] The fifth aspect of this application provides a computer storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement a Linux operating system based on OverlayFS technology as described in the first aspect or any implementation thereof.

[0077] Using the above technical solution, the Linux operating system implementation method based on OverlayFS technology provided in this application loads the boot bridge carrier of the first hardware partition through UEFI firmware; links and boots the GRAND unified bootloader of the second hardware partition through the boot bridge carrier, and ensures that the GRAND unified bootloader is not tampered with or damaged by utilizing the read-only attribute of the second hardware partition, thus solving the problem of easy tampering of core files in traditional full hard drive installation; subsequently, the Linux Live ISO image file in the second hardware partition is loaded through the GRAND unified bootloader. The LiveISO image file contains the Linux system kernel program and an initialized memory file system image. Because the second hardware partition is read-only, the purity of the Linux system kernel program is guaranteed, solving the problem of easily tampered core files in traditional full hard drive installations. Next, the Linux system kernel program is started, and the initialized memory file system image containing the dracut custom script is executed. The dracut custom script automatically completes hardware partition identification and basic environment initialization, replacing the manual configuration of traditional deployments and solving the problem of low deployment efficiency in traditional solutions. During the cleanup phase, the dracut custom script mounts the third hardware partition to the system's temporary mount point. Through the upperdir and workdir directories within this third hardware partition, independent storage of changed data and intermediate state data is achieved, solving the problem of lack of configuration isolation in traditional deployments. Finally, the dracut custom script parses the Linux LiveISO image. The ISO image file contains the original configuration file directory, which is then set as a read-only lowerdir layer in OverlayFS to ensure that the configuration file is not tampered with, meeting the scenario's requirement for the purity of the system core. Finally, a custom script using dracut merges the lowerdir layer and the upperdir directory to form a unified view, allowing users to operate normally without having to worry about the layering logic. This ensures the security of the original configuration file and achieves the persistence of configuration changes, resolving the contradiction between traditional full hard drive installation sacrificing the purity of the system core for configuration persistence and Live CD deployment sacrificing configuration persistence for the purity of the system core.

[0078] Furthermore, because configuration change data and intermediate state data are stored independently, the upperdir directory can be reset when configuration problems occur without restoring the entire Linux operating system, thus avoiding the loss of effective data. It also has the foundation for fast restoration, solving the problems of low efficiency in full installation and recovery from traditional hard drives and the inability of Live CD deployment configurations to remain effective for a long time. Attached Figure Description

[0079] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0080] Figure 1 A schematic diagram of a system architecture is provided for this application;

[0081] Figure 2 A flowchart illustrating an implementation method of a Linux operating system based on OverlayFS technology provided in this application embodiment;

[0082] Figure 3 A schematic diagram of the structure of an implementation device for a Linux operating system based on OverlayFS technology provided in this application embodiment;

[0083] Figure 4 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0084] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0085] The embodiments of this application will now be described with reference to the accompanying drawings. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are equally applicable to similar technical problems.

[0086] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0087] This application can be applied to the field of operating systems. The following will take the Linux operating system as an example to introduce several application scenarios that have been implemented in products.

[0088] First, let's introduce the application scenarios of this application.

[0089] This application can be applied, but is not limited to, to applications that have implementation functions on Linux operating systems based on OverlayFS technology or cloud services provided by cloud-side servers, which will be described in detail below:

[0090] See Figure 1 , Figure 1 A schematic diagram of a system architecture is shown. The system may include a terminal 100 and a server 200. The server 200 can provide the methods provided in the embodiments of this application to one or more terminals.

[0091] The terminal 100 may have applications installed on it that are related to the implementation process of the Linux operating system based on OverlayFS technology. These applications and web pages can provide an interface. The terminal 100 can receive relevant parameters input by the user on the interface and send the parameters to the server 200. The server 200 can obtain the processing result based on the received parameters and return the processing result to the terminal 100.

[0092] It should be understood that in some optional implementations, the terminal 100 can also complete the action of obtaining the processing result based on the received parameters on its own, without the need for the server to cooperate. This application embodiment is not limited to this.

[0093] The following description Figure 1 The product form of the mid-terminal 100;

[0094] The terminal 100 in this application embodiment can be a mobile phone, tablet computer, wearable device, vehicle device, augmented reality (AR) / virtual reality (VR) device, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), etc., and this application embodiment does not impose any restrictions on it.

[0095] Terminal 100 may include a radio frequency unit, memory, input unit, display unit, camera (optional), audio circuitry (optional), speaker (optional), microphone (optional), headphone jack (optional), processor, external interface, power supply, and other components. Those skilled in the art will understand that the above-mentioned components are merely examples and do not constitute a limitation on the terminal or multifunctional device; it may include more or fewer components, or a combination of certain components, or different components.

[0096] The input unit can be used to receive input numeric or character information, and to generate key signal inputs related to user settings and function control of the portable multi-functional device. Specifically, the input unit may include a touchscreen (optional) and / or other input devices. Other input devices may include, but are not limited to, one or more of a physical keyboard, function keys (such as volume control buttons, power buttons, etc.), trackball, mouse, joystick, etc.

[0097] Among them, the input device can receive input data, etc.

[0098] The display unit can be used to display information input by the user or information provided to the user, various menus of the terminal, interactive interfaces, file display, and / or playback of any multimedia file. In the embodiments of this application, the display unit can be used to display interfaces, processing results, etc.

[0099] The memory can be used to store software code related to the implementation method of the Linux operating system based on OverlayFS technology. The processor can execute the steps of the implementation method of the Linux operating system based on OverlayFS technology, and can also schedule other units (such as the above-mentioned input unit and display unit) to achieve the corresponding functions.

[0100] This radio frequency unit (optional) can be used to receive and send signals during information transmission or calls.

[0101] In this embodiment of the application, the radio frequency unit can send data to the server 200 and receive the processing results sent by the server 200.

[0102] It should be understood that this radio frequency unit is optional and can be replaced with other communication interfaces, such as a network port.

[0103] Terminal 100 also includes a power source (such as a battery) for supplying power to the various components.

[0104] Terminal 100 also includes an external interface, which can be a standard Micro USB interface or a multi-pin connector, which can be used to connect terminal 100 to other devices for communication or to connect a charger to charge terminal 100.

[0105] Server 200 includes a bus, a processor, a communication interface, and memory. The processor, memory, and communication interface communicate with each other via the bus.

[0106] The memory can be used to store software code related to the implementation method of the Linux operating system based on OverlayFS technology. The processor can execute the steps of the chip's implementation method of the Linux operating system based on OverlayFS technology, and can also schedule other units to achieve corresponding functions.

[0107] To address the aforementioned problems, this application provides a method for implementing a Linux operating system based on OverlayFS technology. The implementation method of this application's Linux operating system based on OverlayFS technology will be described in detail below with reference to the accompanying drawings.

[0108] Reference Figure 2 , Figure 2 A flowchart illustrating an implementation method of a Linux operating system based on OverlayFS technology provided in this application embodiment is shown below. Figure 2 As shown in the figure, the implementation method of a Linux operating system based on OverlayFS technology provided in this application embodiment may include steps S201 to S208, which are described in detail below.

[0109] Before executing steps S201 to S208, the hard drive in the terminal or server needs to be partitioned to obtain three functionally independent hardware partitions: the first hardware partition (exemplarily, the directory on the hard drive is / dev / sda1), the second hardware partition (exemplarily, the directory on the hard drive is / dev / sda2), and the third hardware partition (exemplarily, the directory on the hard drive is / dev / sda3). The three hardware partitions are described below.

[0110] The first hardware partition follows the UEFI (Unified Extensible Firmware Interface) boot specification, has a capacity of hundreds of megabytes, is adapted for the storage and operation of the boot bridging carrier, and only undertakes the bridging function between UEFI firmware and GRUB (Grand Unified Bootloader).

[0111] Second hardware partition: Adapted for storing Linux Live ISO (International Organization for Standardization) images, GRAND unified bootloader and GRUB hard-coded configuration files. The second hardware partition is set to read-only throughout.

[0112] The third hardware partition is adapted to the ext4 (Fourth Extended Filesystem) file system, with built-in upperdir and workdir directories. It serves as the writable layer storage and temporary cache for OverlayFS (Overlay File System). The third hardware partition is writable and is the sole target of configuration restore operations.

[0113] Understandably, after partitioning the hard drive, each independent hardware partition can be deployed. This can be achieved by sequentially executing a standardized process: boot triggering → image mounting → kernel loading → initialization execution → OverlayFS stacking → read / write redirection, thus enabling dynamic stacking of OverlayFS. Specifically:

[0114] Step S201: Load the boot bridge carrier stored in the first directory area of ​​the first hardware partition through the UEFI firmware. The boot bridge carrier is used to link to the GRAND unified bootloader.

[0115] For example, the boot bridging carrier includes: an EFI (Extensible Firmware Interface) bootloader and a boot configuration table; the EFI bootloader is a program used to bridge the UEFI firmware and the GRAND unified bootloader, and the boot configuration table is a configuration file used to record the running path of the GRAND unified bootloader.

[0116] An EFI bootloader is a program that conforms to the UEFI boot specification, can be recognized and loaded by the UEFI firmware, and is used to bridge the UEFI firmware and the GRAND unified bootloader. A boot configuration table is a configuration file that conforms to the UEFI boot specification, records the runtime path and hardware identification rules of the GRAND unified bootloader, and is the core basis for the UEFI firmware to locate the GRAND unified bootloader.

[0117] For example, the first directory area can be the / EFI / BOOT / standard directory area of ​​the first hardware partition.

[0118] For example, after a terminal or server powers on, the UEFI firmware is started, and the UEFI firmware scans the first directory area of ​​the first hardware partition. The UEFI firmware is embedded on the computer motherboard, located between the computer hardware and the operating system. It is used to complete functions such as hardware initialization, system boot loading, and hardware resource management during power-on, providing a standardized and scalable underlying operating environment for the operating system to start.

[0119] Step S202: Start the GRAND unified bootloader in the second directory area storage of the second hardware partition through the boot bridging carrier; the second hardware partition is a read-only storage carrier.

[0120] For example, a communication link can be established between the UEFI firmware and the GRAND unified bootloader via the EFI bootloader. The GRAND unified bootloader is then started via the communication link through the UEFI firmware.

[0121] For example, the second directory area can be the / boot / grub / directory area of ​​the second hardware partition.

[0122] Step S203: Load the Linux Live ISO image file stored in the third directory area of ​​the second hardware partition through the GRAND unified bootloader. The Linux Live ISO image file contains the Linux system kernel program and an initialized memory file system image.

[0123] For example, step S203 includes steps A1 to A3.

[0124] Step A1: The GRUB hardened configuration file stored in the fourth directory area of ​​the second hardware partition is read by the GRAND unified bootloader. The GRUB hardened configuration file includes loopback mount rules, hardened kernel parameters, and restore mode boot items. The hardened kernel parameters include the third directory area of ​​the second hardware partition, the device name of the third hardware partition, and the stacking directory of OverlayFS used for joint mounting.

[0125] Among them, the loopback mount rule refers to the mount rule that enables the GRAND unified bootloader to virtualize the Linux Live ISO image file as a block device, so that the block device can be accessed directly without decompression.

[0126] The parameters for the solidified kernel include, but are not limited to: the storage path of the Linux Live ISO image file on the second hardware partition, the device name of the third hardware partition (such as / dev / sda3), and the stacked directories used by OverlayFS for union mounting (such as / etc).

[0127] OverlayFS stacked directory refers to a unified directory structure formed by mounting multiple independent directories in a hierarchical manner through OverlayFS (overlay file system). This structure can logically merge the lower-level read-only directory with the upper-level writable directory, presenting a single, coherent file directory view to the outside world, thereby realizing hierarchical read and write and isolated data storage of the file system.

[0128] The system restore mode boot option refers to a dedicated boot option that provides a boot entry point for manually triggering system restore.

[0129] For example, the fourth directory area of ​​the second hardware partition can be the second hardware partition / boot / grub / grub.cfg.

[0130] Understandably, the GRAND unified bootloader can read the solidified kernel parameters from the GRUB solidified configuration file, thereby specifying the boot target and the configuration rules for the OverlayFS stack directory.

[0131] Step A2: The Linux Live ISO image file is virtualized as a block device using the loopback mount rules through the GRAND unified bootloader.

[0132] After virtualizing the Linux Live ISO image file as a block device, the GRAND unified bootloader can directly mount and access the Linux Live ISO image file without decompression.

[0133] For example, a Linux Live ISO image file refers to a Linux system image file that can be booted directly from a read-only medium, i.e., a second hardware partition; a Linux Live ISO image file is a system core file carrier with a kernel version ≥3.18, native support for OverlayFS technology, and no need for additional compilation of kernel modules; a Linux Live ISO image file contains a built-in Linux system kernel program (such as vmlinuz) and an initramfs (Initial RAM File System) image (such as initrd.img), and the root file system of the Linux Live ISO image file is in squashfs format.

[0134] The Linux kernel is the core system program that manages computer hardware resources, schedules processes, manages memory, provides file system and network support, and drives hardware devices. It provides a unified abstract interface between upper-layer applications and lower-layer hardware, and is the core and scheduling center of the entire Linux operating system.

[0135] The initial RAM file system image (initramfs) is a temporary file system image loaded into memory during the Linux system startup phase and before the root file system is mounted. It contains necessary hardware drivers, initialization scripts, and utility programs to complete pre-boot operations such as hardware initialization, driver loading, root file system lookup and mounting, ensuring that the Linux system kernel program can successfully boot and switch to the actual root file system for operation.

[0136] SquashFS is a block-based compressed read-only file system format. It is inherently read-only and has a high compression ratio, which can protect Linux Live ISO image files from tampering to the greatest extent and is suitable for the read-only storage needs of a second hardware partition.

[0137] The GRAND unified bootloader is used to load the Linux system kernel program from the Linux Live ISO image file and initialize the memory file system image.

[0138] Step A3: Access the block device.

[0139] Step S204: Start the Linux system kernel program and execute the initialized memory file system image file, the initialized memory file system image including the dracut custom script.

[0140] For example, step S204 includes steps B1 to B3.

[0141] Step B1: Load the Linux system kernel program and the initialized memory file system image from the Linux Live ISO image file.

[0142] Step B2: Start the Linux system kernel program.

[0143] After the Linux kernel program starts, it can perform the initialization and configuration of the system's underlying hardware. Following this initialization, the kernel can then initialize the memory file system image.

[0144] Step B3: Execute the initialization memory file system image through the Linux system kernel program.

[0145] During the initialization of the memory file system image, pre-processing operations such as hardware device identification, driver loading, and tool initialization can be performed according to a preset sequence until the cleanup phase is entered.

[0146] Step S205: During the cleanup phase, the third hardware partition is mounted to the system temporary mount point using the dracut custom script. The third hardware partition includes the upperdir directory and the workdir directory. The upperdir directory is used to store the change data generated by the original configuration file directory during the operation of the Linux operating system. The workdir directory is used to temporarily store the intermediate state data generated by OverlayFS during file read and write operations in the lowerdir and upperdir layers.

[0147] For example, the original configuration file directory refers to the directory used to store the configuration parameters and rule information required for the operation of the operating system and related services. The initialization and parameter settings of the system operating environment are realized by reading the configuration files in this directory, such as the / etc directory.

[0148] The upperdir directory is the core directory of the writable layer of OverlayFS, while the workdir directory is a temporary cache directory that stores intermediate state data of file reading and writing during the OverlayFS stacking process.

[0149] For example, step S205 includes steps C1 to C2.

[0150] Step C1: During the cleanup phase, the dracut custom script is triggered by the Linux system kernel program.

[0151] The Cleanup phase refers to the critical initialization stage before the third hardware partition is officially mounted, and it is a dedicated execution stage that triggers the construction of the OverlayFS stack.

[0152] The dracut custom script refers to the initialization script specifically written to implement dynamic stacking of OverlayFS, which integrates core logic such as partition mounting, directory verification, file system parsing, and joint mounting of OverlayFS.

[0153] Step C2: Mount the third hardware partition to the system temporary mount point using the dracut custom script.

[0154] The dracut custom script mounts the third hardware partition to the system temporary mount point according to the device name of the third hardware partition specified by the hardened kernel parameters.

[0155] A system temporary mount point is a dedicated directory created during the startup or operation of the operating system to temporarily mount storage devices, file systems, or partitions. It is only valid within the current operating cycle and is used to temporarily associate external storage resources with the system directory tree, facilitating the system to read, write, parse, and interact with the target storage resources. The mount point can be unmounted at any time after the relevant operations are completed.

[0156] For example, after the third hardware partition is mounted, the dracut custom script scans and verifies the integrity of the directory structure of the upperdir and workdir directories of the third hardware partition; if the directory is damaged or missing, the dracut custom script automatically rebuilds the directory to avoid subsequent OverlayFS stack build failure.

[0157] Step S206: Parse the original configuration file directory built into the Linux Live ISO image file using the dracut custom script.

[0158] Step S207: Determine that the original configuration file directory is the lowerdir layer of OverlayFS.

[0159] The original configuration file directory is built into the Linux Live ISO image file, which is stored on the second hardware partition. Therefore, the original configuration file directory has read-only attributes, and thus the lowerdir layer of OverlayFS also has read-only attributes.

[0160] Step S208: Merge the lowerdir layer and the upperdir directory using the dracut custom script to obtain a combined view.

[0161] The dracut custom script executes the OverlayFS union mount command, merging the lowerdir layer with the upperdir directory in the third hardware partition to build a union view.

[0162] The combined view is the result of overlaying the lowerdir layer and the upperdir directory, realizing an integrated display of read-only basic configuration and writable change configuration.

[0163] Understandably, once the union view is obtained, the OverlayFS stack is built, the system officially mounts the root file system of the Linux Live ISO image file and enters normal operation.

[0164] After completing the OverlayFS stack construction, a stack success signal is returned to the Linux system kernel program. After receiving the stack success signal, the Linux system kernel program completes the formal mounting of the root file system of the Linux Live ISO image file, ends the initialization process of the memory file system image, and the system enters normal operation.

[0165] This application provides a method for implementing a Linux operating system based on OverlayFS technology. It loads a boot bridge carrier from a first hardware partition via UEFI firmware; links and boots a GRAND unified bootloader from a second hardware partition through the boot bridge carrier. Utilizing the read-only attribute of the second hardware partition, it ensures the GRAND unified bootloader is not tampered with or corrupted, solving the problem of easily tampered core files in traditional full hard drive installations; subsequently, the GRAND unified bootloader loads a Linux Live ISO image file from the second hardware partition. The ISO image file contains the Linux system kernel program and an initialized memory file system image. Because the second hardware partition is read-only, the purity of the Linux system kernel program is guaranteed, solving the problem of easily tampered core files in traditional full hard drive installations. Next, the Linux system kernel program is started, and the initialized memory file system image containing the dracut custom script is executed. The dracut custom script automatically completes hardware partition identification and basic environment initialization, replacing the manual configuration of traditional deployments and solving the problem of low deployment efficiency in traditional solutions. During the cleanup phase, the dracut custom script mounts the third hardware partition to a temporary system mount point. Through the upperdir and workdir directories within this third hardware partition, independent storage of changed data and intermediate state data is achieved, solving the problem of lack of configuration isolation in traditional deployments. Finally, the dracut custom script parses the Linux Live... The ISO image file contains the original configuration file directory, which is then set as a read-only lowerdir layer in OverlayFS to ensure that the configuration file is not tampered with, meeting the scenario's requirement for the purity of the system core. Finally, a custom script using dracut merges the lowerdir layer and the upperdir directory to form a unified view, allowing users to operate normally without having to worry about the layering logic. This ensures the security of the original configuration file and achieves the persistence of configuration changes, resolving the contradiction between traditional full hard drive installation sacrificing the purity of the system core for configuration persistence and Live CD deployment sacrificing configuration persistence for the purity of the system core.

[0166] Furthermore, because configuration change data and intermediate state data are stored independently, the upperdir directory can be reset when configuration problems occur without restoring the entire Linux operating system, thus avoiding the loss of effective data. It also has the foundation for fast restoration, solving the problems of low efficiency in full installation and recovery from traditional hard drives and the inability of Live CD deployment configurations to remain effective for a long time.

[0167] Understandably, after dividing the hard drive into multiple independent hardware partitions, it is necessary to create the first hardware partition, the second hardware partition, and the third hardware partition. The creation process is explained below.

[0168] The process of constructing the first hardware partition is described below, which includes the following steps D1 to D2.

[0169] Step D1: Obtain the boot bridging carrier, which includes an EFI bootloader and a boot configuration table; the EFI bootloader is a program used to bridge the UEFI firmware and the GRAND unified bootloader, and the boot configuration table is a configuration file used to record the running path of the GRAND unified bootloader.

[0170] Step D2: Store the boot bridge carrier in the first directory area of ​​the first hardware partition.

[0171] In an optional implementation, before executing step D2, the following operations may also be performed: the boot bridging carrier is verified based on a preset UEFI official verification algorithm; if the verification passes, step D2 is executed.

[0172] The default UEFI official verification algorithm refers to the dedicated verification algorithm specified by the UEFI firmware. This algorithm verifies the integrity and operational validity of the boot bridging carrier files and eliminates damaged or incompatible software files.

[0173] The process of constructing the second hardware partition is described below, which includes the following steps E1 to E8.

[0174] Step E1: Obtain system core and boot software resources, including the Linux Live ISO image file, the GRAND unified bootloader, and the GRUB boot configuration template file; the GRUB boot configuration template file is a configuration file framework for the basic operating parameters and rules of the GRAND unified bootloader.

[0175] The basic parameters and rules for the operation of the GRAND unified bootloader refer to the preset configuration parameters, boot logic, partition mounting rules, and boot control instructions to ensure the normal loading, execution, and booting of the GRAND unified bootloader and the operating system. The basic parameters and rules for the operation of the GRAND unified bootloader include, but are not limited to: boot timeout parameters, default boot item parameters, kernel loading path, initialization image path, file system identification rules, boot permission control, and boot process constraints.

[0176] Step E2: Store the GRAND unified bootloader in the second directory area of ​​the second hardware partition.

[0177] For example, before executing step E2, the GRAND unified bootloader can be verified, and if the verification passes, step E2 can be executed.

[0178] The method for verifying the GRAND unified bootloader includes: verifying the GRAND unified bootloader based on preset compatibility verification rules.

[0179] The default compatibility verification rule refers to the verification rule that matches the Linux kernel environment with the ability to recognize squashfs format files. This rule is used to verify whether the GRAND unified bootloader can recognize and mount the squashfs format Linux Live ISO image file.

[0180] Step E3: Compress the Linux Live ISO image file into squashfs format.

[0181] Before executing step E3, the Linux Live ISO image file needs to be verified. If the verification passes, step E3 is then executed. For example, the method for verifying the Linux Live ISO image file includes: verifying the Linux Live ISO image file based on a preset hash verification algorithm. The preset hash verification algorithm refers to an algorithm that converts file data of arbitrary length into a fixed-length hash value, i.e., a verification hash value. By comparing the original hash value of the Linux Live ISO image file with the verification hash value, the integrity and tamper-proof nature of the Linux Live ISO image file are verified.

[0182] Step E4: Store the Linux Live ISO image file in squashfs format to the third directory area of ​​the second hardware partition.

[0183] For example, the third directory area can be the root directory / core storage area of ​​the second hardware partition.

[0184] Step E5: Obtain GRUB customized configuration parameters, which include loopback mount rules, solidified kernel parameters, and restore mode boot items; the solidified kernel parameters include the third directory area of ​​the second hardware partition, the device name of the third hardware partition, and the stacking directory of OverlayFS used for joint mounting.

[0185] Step E6: Set the GRUB customized configuration parameters in the GRUB boot configuration template file to obtain the GRUB solidified configuration file.

[0186] Step E7: Store the GRUB firmware configuration file in the fourth directory area of ​​the second hardware partition.

[0187] For example, before executing step E7, a verification operation on the GRUB firmware configuration file can also be performed. If the verification passes, then step E7 is executed.

[0188] For example, the method for verifying the GRUB hardened configuration file can be: verifying the GRUB hardened configuration file through preset parameter verification rules to ensure that there are no missing parameters, no conflicting rules, and that it can be read normally by the GRAND unified bootloader.

[0189] Step E8: Set the second hardware partition to read-only.

[0190] For example, the Linux partition attribute setting tool can be used to mark the second hardware partition as read-only. The read-only attribute is a hardware permission attribute that prohibits any user from performing write operations on the second hardware partition. At the same time, the partition table in the second hardware partition is locked. The partition table is a hardware configuration table that records information such as hard disk partition number, capacity, and permission attributes. After being locked, even the root user cannot modify the file content in the second hardware partition.

[0191] In an alternative implementation, after executing step E8, it can be further verified whether the read-only attribute of the second hardware partition is valid. For example, a method for verifying the validity of the read-only attribute of the second hardware partition includes: performing a simulated write operation on the second hardware partition; if the write operation is rejected, the read-only attribute configuration is determined to be successful; if the write operation is executable, step E8 is re-executed.

[0192] The process of building a third hardware partition is described below, which includes the following steps F1 to F5.

[0193] Step F1: Obtain file system and directory management tools, including ext4 file system formatting tools, Linux directory creation scripts, permission configuration tools, and storage capacity planning tools. The ext4 file system formatting tool is a native Linux tool that formats hardware partitions as ext4 file systems. The Linux directory creation script is a standardized execution script that can automatically generate a specified directory structure. The permission configuration tool is a native Linux tool used to modify file or directory access control permissions. The storage capacity planning tool is a tool used to calculate and plan the storage capacity of hardware partitions.

[0194] Step F2: Format the third hardware partition as an ext4 file system using the ext4 file system formatting tool.

[0195] Step F3: Create an OverlayFS directory in the third hardware partition using the Linux directory creation script. The OverlayFS directory includes the upperdir directory and the workdir directory.

[0196] For example, the upperdir and workdir directories can be automatically created in the root directory of the third hardware partition.

[0197] Step F4: Configure preset permission rules for the upperdir directory and the workdir directory using the permission configuration tool.

[0198] For example, the default permission rule is a rule that only the root user has write and modify permissions, while ordinary users only have read-only permissions.

[0199] For example, the preset permission rules configured for the upperdir and workdir directories can also be verified. For example, simulated write operations are performed on the upperdir and workdir directories by the root user and a regular user, respectively. If the root user can write normally and the regular user's write operation is rejected, the preset permission rules are determined to be configured successfully. If the preset effect is not achieved, the process is backtracked to step F4 to reconfigure the preset permission rules.

[0200] Step F5: Use the storage capacity planning tool to plan and reserve redundant storage space for the third hardware partition.

[0201] Redundant storage space refers to the unallocated hardware storage area reserved in the third hardware partition to meet the growing needs of temporary cache data storage and configuration file growth. For example, the redundant capacity can be calculated as twice the estimated capacity of the original configuration file directory, and this redundant capacity can be dedicated to specific areas.

[0202] In an optional implementation, after constructing the first, second, and third hardware partitions, it is necessary to mount the first, second, and third hardware partitions in a preset timing sequence, as shown in steps S201 to S208, and verify the software storage and hardware compatibility of each partition. For example, the preset timing sequence is: first hardware partition → second hardware partition → third hardware partition.

[0203] The following describes the process of verifying the software storage and hardware compatibility of each partition, which includes the following steps G1 to G5.

[0204] Step G1: Verify whether the UEFI firmware can locate the GRAND unified bootloader stored in the second directory area of ​​the second hardware partition through the boot bridging carrier, so as to obtain the first verification result.

[0205] Step G2: Verify whether the GRAND unified bootloader can read the GRUB hardened configuration file stored in the fourth directory area of ​​the second hardware partition, whether it can mount the LinuxLive ISO image file through the loopback mount rule, and whether the read-only attribute of the second hardware partition is effective, so as to obtain the second verification result. The GRUB hardened configuration file includes the loopback mount rule.

[0206] Step G3: Verify whether the upperdir directory and the workdir directory in the third hardware partition can be written normally by the root user, and whether the third hardware partition can be mounted, to obtain the third verification result.

[0207] Step G4: If the first verification result, the second verification result, and the third verification result are all yes, generate a software storage deployment log.

[0208] Software storage deployment logs are text files that record the execution time of each step in this application, the operation content of each step, the number of each hardware partition, the software storage path, configuration parameters, and verification results.

[0209] If at least one of the first verification result, the second verification result, and the third verification result is negative, then the corresponding step is re-executed.

[0210] Step G5: Store the software storage deployment log to a designated hidden directory of the third hardware partition.

[0211] For example, the software storage deployment log is stored in a designated hidden directory on the third hardware partition to ensure that the software storage deployment can be queried but cannot be modified by ordinary users, providing a basis for subsequent system maintenance and troubleshooting.

[0212] In an alternative implementation, after step S208, steps H1 to H3 may also be included.

[0213] Step H1: If a read operation is detected for the federated view, the change data stored in the upperdir directory is read by the Linux system kernel program.

[0214] Transparent read / write redirection of federated views is achieved through the OverlayFS kernel module in the Linux system kernel program, without the user or application being aware of it at all.

[0215] Step H2: If the changed data has not been changed, read the original configuration file stored in the lowerdir layer. The original configuration file refers to the initial configuration content that has not been modified.

[0216] Step H3: If a write operation is detected for the federated view, the write operation is redirected to the upperdir directory by the Linux system kernel program.

[0217] It is understandable that after completing the aforementioned storage deployment process (such as building the first, second, and third hardware partitions) and the stacking process (i.e., steps S201-S208), and after the Linux operating system is in a stable running state, there is still a need to reset the system state and restore the purity of the system kernel. The system state reset method in this application relies on the aforementioned deployed hardware partitions and software runtime environment, providing reset triggering methods for multiple scenarios, which are described in detail below. This process includes the following steps J1 to J8.

[0218] Step J1: If a configuration restore command is detected, determine the restore trigger method and restore mode. The restore mode is either a full restore mode or a restore backup configuration mode. The restore trigger method is either triggered by a one-click restore tool or triggered by a restore mode startup item. The restore mode startup item corresponding to the restore mode startup item is deployed on the second hardware partition.

[0219] This application deploys two restore triggering methods based on different system operating states, specifically:

[0220] One-click restore tool trigger: Deploy the restore-defaults tool in the user interface of the Linux operating system. The restore-defaults tool is a standardized program that can be executed by system commands to trigger system restore operations. The restore-defaults tool integrates operation confirmation and restore mode selection functions.

[0221] Restore mode boot entry triggering, also known as GRUB restore mode triggering: Based on the restore mode boot entry, a restore mode boot entry trigger entry is deployed in the GRUB boot selection interface after UEFI firmware booting, which is suitable for abnormal scenarios where the Linux operating system cannot be entered normally.

[0222] For example, after detecting a configuration restore command, the current running state of the Linux operating system can be identified. The running state can be either normal or abnormal. The restore trigger method should match the running state to avoid invalid triggers. For instance, if the running state is normal, the restore trigger method should be triggered by a one-click restore tool; if the running state is abnormal, the restore trigger method should be triggered by GRUB restore mode.

[0223] For example, if the restore is triggered by a one-click restore tool such as restore-defaults, the restore-defaults tool will display a restore mode selection prompt in the user interface to avoid user misoperation; if the restore is triggered by a restore mode boot option, the restore mode confirmation option can be displayed in the GRUB boot selection interface.

[0224] Full restore mode refers to the restoration method that restores the Linux operating system to the original state of the Linux Live ISO image file, while restore backup configuration mode refers to the restoration method that restores the Linux operating system to the configuration state that the user has backed up in advance.

[0225] Step J2: If the restoration is triggered by the one-click restore tool, terminate all read and write processes on the third hardware partition and release the upperdir directory and the workdir directory from their occupied states.

[0226] The purpose of releasing the upperdir directory from the workdir directory is to free up the files occupied by the upperdir directory and the workdir directory, ensuring that no process locks the third hardware partition.

[0227] Step J3: If the restore triggering method is the restore mode startup item trigger, terminate the association between the third hardware partition and the system temporary mount point.

[0228] If the restore is triggered by the restore mode startup item, the OverlayFS stacking process is skipped, and the core execution program of the restore operation is loaded directly, that is, the association between the third hardware partition and the system temporary mount point is terminated.

[0229] Terminating the association between the third hardware partition and the system temporary mount point ensures that the upperdir and workdir directories are not occupied by any read or write operations, thus avoiding file corruption and abnormal data writing during the restore process.

[0230] Step J4: If the restore mode is the full restore mode, format the third hardware partition.

[0231] Formatting the third hardware partition refers to a full format of the third hardware partition. For details, please refer to the section on reformatting the third hardware partition to an ext4 file system mentioned during the creation process. This process clears all changed data, temporary cache data, and other files within the third hardware partition, restoring it to its initial storage state.

[0232] Step J5: Rebuild the upperdir directory and the workdir directory within the third hardware partition.

[0233] For example, step J5 can refer to the process of creating the upperdir and workdir directories in the steps of building the third hardware partition.

[0234] Step J6: If the restore mode is the recovery backup configuration mode, delete the changed data stored in the upperdir directory of the third hardware partition.

[0235] For example, delete the changed data stored in the upperdir directory of the third hardware partition to ensure that there are no conflicts between old changed data and the backup configuration file, while retaining the temporary cache function of the workdir directory without needing to clean it up.

[0236] Step J7: Load the configuration file stored in the preset path and copy it to the upperdir directory.

[0237] For example, a pre-backed-up configuration file can be scanned according to a preset path, which may include a hidden directory in a third hardware partition or an external storage medium.

[0238] For example, the integrity and validity of the configuration file can also be verified.

[0239] Step J8: Perform a restart operation.

[0240] If triggered by a one-click restore tool, a restart prompt will pop up in the user interface to inform the user that the restore operation is complete and the system needs to be restarted for the restore effect to take effect; if triggered by a restore mode startup item, no manual intervention from the user is required, and the automatic restart operation will be performed directly to enter the system startup process after restoration.

[0241] Understandably, after system reboot, the OverlayFS stack can be rebuilt following steps 201 to S208 of the boot process. If the restore mode is a full restore, the upperdir directory will be empty after reboot, and the union view will only display the original configuration files of the lowerdir layer, restoring the system to the original clean state of the Linux Live ISO image file. If the restore mode is a restore backup configuration mode, the upperdir directory will contain configuration files after reboot, and the union view will prioritize displaying the configuration files, restoring the system to the configuration state pre-backed up by the user. Throughout the entire process, core files such as the LinuxLive ISO image file and the GRAND unified bootloader on the second hardware partition remain unchanged, achieving a lossless system reset.

[0242] In one optional implementation, after the restoration operation is completed, a restoration effect verification operation can be automatically performed. The core verification content includes, but is not limited to:

[0243] Verify the purity of the system core: Check whether the read-only attribute of the second hardware partition remains effective, and whether the lowerdir layer of the Linux LiveISO image text has not been modified.

[0244] Verify the compatibility of the restore target: If the restore mode is full restore mode, confirm whether there are no user configuration changes in the original configuration file directory, i.e., whether it has been restored to its original state; if the restore mode is restore backup configuration mode, confirm whether the configuration content of the original configuration file directory is completely consistent with the pre-backed-up configuration file.

[0245] Verify system operational validity: Check if read and write operations on the original configuration file directory can be successfully redirected to the upperdir directory of the third hardware partition; if all verification items pass, the restore operation is considered successful; if the verification fails, the system will re-trigger the restore operation.

[0246] The above describes an implementation method of a Linux operating system based on OverlayFS technology provided by the embodiments of this application. The following will describe the apparatus for implementing the above-described implementation method of a Linux operating system based on OverlayFS technology.

[0247] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of a Linux operating system implementation device based on OverlayFS technology, provided as an embodiment of this application. Figure 3 As shown, the implementation device of the Linux operating system based on OverlayFS technology includes:

[0248] The first loading module 301 is used to load the boot bridge carrier stored in the first directory area of ​​the first hardware partition through the Unified Extensible Firmware Interface (UEFI) firmware, wherein the boot bridge carrier is used to link to the GRAND Unified Bootloader.

[0249] The first boot module 302 is used to start the GRAND unified bootloader stored in the second directory area of ​​the second hardware partition through the boot bridging carrier; the second hardware partition is a read-only storage carrier.

[0250] The second loading module 303 is used to load the Linux Live ISO image file stored in the third directory area of ​​the second hardware partition through the GRAND unified boot loader. The Linux Live ISO image file contains the Linux system kernel program and the initialized memory file system image.

[0251] The second boot module 304 is used to start the Linux system kernel program and execute the initialization memory file system image file, wherein the initialization memory file system image includes a dracut custom script;

[0252] The first mounting module 305 is used to mount the third hardware partition to the system temporary mount point through the dracut custom script during the cleanup phase. The third hardware partition includes the upperdir directory and the workdir directory. The upperdir directory is used to store the change data generated by the original configuration file directory during the operation of the Linux operating system. The workdir directory is used to temporarily store the intermediate state data generated by OverlayFS during the file read and write operations in the lowerdir layer and the upperdir layer.

[0253] Parsing module 306 is used to parse the original configuration file directory built into the Linux Live ISO image file using the dracut custom script;

[0254] The first determining module 307 is used to determine that the original configuration file directory is the lowerdir layer of OverlayFS;

[0255] The first acquisition module 308 is used to merge the lowerdir layer and the upperdir directory through the dracut custom script to obtain a combined view.

[0256] In one alternative implementation, it also includes:

[0257] The second determining module is used to determine the restoration triggering method and restoration mode if a configuration restore command is detected. The restoration mode is a full restore mode or a restore backup configuration mode. The restoration triggering method is triggered by a one-click restore tool or a restore mode startup item. The restore mode startup item corresponding to the restore mode startup item is deployed in the second hardware partition.

[0258] The termination module is used to terminate all read and write processes on the third hardware partition and release the occupancy status of the upperdir directory and the workdir directory if the restoration triggering method is triggered by the one-click restoration tool.

[0259] The termination association module is used to terminate the association between the third hardware partition and the system temporary mount point if the restoration triggering method is the restoration mode startup item trigger.

[0260] The first formatting module is used to format the third hardware partition if the restore mode is the full restore mode.

[0261] The rebuild module is used to rebuild the upperdir directory and the workdir directory within the third hardware partition;

[0262] The deletion module is used to delete the changed data stored in the upperdir directory of the third hardware partition if the restoration mode is the recovery backup configuration mode;

[0263] The third loading module is used to load the configuration file stored in the preset path and copy it to the upperdir directory;

[0264] The execution module is used to perform the restart operation.

[0265] In one alternative implementation, it also includes:

[0266] The second acquisition module is used to acquire the boot bridging carrier, which includes an Extensible Firmware Interface (EFI) bootloader and a boot configuration table. The EFI bootloader is a program used to bridge the UEFI firmware and the GRAND unified bootloader, and the boot configuration table is a configuration file used to record the running path of the GRAND unified bootloader.

[0267] The first storage module is used to store the boot bridge carrier in the first directory area of ​​the first hardware partition.

[0268] In one alternative implementation, it also includes:

[0269] The third acquisition module is used to acquire system core and boot software resources, including the Linux Live ISO image file, the GRAND unified bootloader, and the GRUB boot configuration template file; the GRUB boot configuration template file is a configuration file framework for the basic operating parameters and rules of the GRAND unified bootloader.

[0270] The second storage module is used to store the GRAND unified bootloader in the second directory area of ​​the second hardware partition;

[0271] A compression module is used to compress the Linux Live ISO image file into squashfs format;

[0272] The third storage module is used to store the Linux Live ISO image file in squashfs format to the third directory area of ​​the second hardware partition;

[0273] The fourth acquisition module is used to acquire GRUB customized configuration parameters, which include loopback mount rules, solidified kernel parameters, and restore mode boot items; the solidified kernel parameters include the third directory area of ​​the second hardware partition, the device name of the third hardware partition, and the stacking directory of OverlayFS used for joint mounting.

[0274] The first setting module is used to set the GRUB customized configuration parameters in the GRUB boot configuration template file to obtain the GRUB solidified configuration file;

[0275] The fourth storage module is used to store the GRUB hardened configuration file to the fourth directory area of ​​the second hardware partition;

[0276] The second settings module is used to set the second hardware partition to read-only.

[0277] In one alternative implementation, it also includes:

[0278] The fifth acquisition module is used to acquire file system and directory management tools, including the fourth extended file system ext4 file system formatting tool, Linux directory creation script, permission configuration tool, and storage capacity planning tool; the ext4 file system formatting tool refers to a native Linux tool that formats hardware partitions into an ext4 file system; the Linux directory creation script refers to a standardized execution script that can automatically generate a specified directory structure; the permission configuration tool refers to a native Linux tool used to modify file or directory access control permissions; and the storage capacity planning tool refers to a tool used to calculate and plan the storage capacity of hardware partitions.

[0279] The second formatting module is used to format the third hardware partition as an ext4 file system using the ext4 file system formatting tool.

[0280] A module is created to create an OverlayFS directory in the third hardware partition via the Linux directory creation script. The OverlayFS directory includes the upperdir directory and the workdir directory.

[0281] The configuration rules module is used to configure preset permission rules for the upperdir directory and the workdir directory through the permission configuration tool;

[0282] The planning and reservation space module is used to plan and reserve redundant storage space for the third hardware partition through the storage capacity planning tool.

[0283] In one alternative implementation, it also includes:

[0284] The first verification module is used to verify whether the UEFI firmware can locate the GRAND unified bootloader stored in the second directory area of ​​the second hardware partition through the boot bridging carrier, so as to obtain the first verification result;

[0285] The second verification module is used to verify whether the GRAND unified bootloader can read the GRUB hardened configuration file stored in the fourth directory area of ​​the second hardware partition, whether it can mount the Linux Live ISO image file through the loopback mount rule, and whether the read-only attribute of the second hardware partition is effective, so as to obtain the second verification result. The GRUB hardened configuration file includes the loopback mount rule.

[0286] The third verification module is used to verify whether the upperdir directory and the workdir directory in the third hardware partition can be written normally by the root user, and whether the third hardware partition can be mounted, so as to obtain the third verification result.

[0287] The generation module is used to generate a software storage deployment log if the first verification result, the second verification result, and the third verification result are all yes.

[0288] The fifth storage module is used to store the software storage deployment logs to a designated hidden directory of the third hardware partition.

[0289] In one alternative implementation, the second loading module includes:

[0290] The reading unit is used to read the GRUB hardened configuration file stored in the fourth directory area of ​​the second hardware partition through the GRAND unified bootloader. The GRUB hardened configuration file includes loopback mount rules, hardened kernel parameters, and restore mode boot items. The hardened kernel parameters include the third directory area of ​​the second hardware partition, the device name of the third hardware partition, and the stacked directory of OverlayFS used for joint mounting.

[0291] The virtual processing unit is used to virtualize the Linux Live ISO image file as a block device using the loopback mount rules through the GRAND unified bootloader;

[0292] An access unit is used to access the block device.

[0293] In one alternative implementation, the second startup module includes:

[0294] A loading unit is used to load the Linux system kernel program and the initialized memory file system image from the Linux Live ISO image file;

[0295] A startup unit is used to start the Linux system kernel program;

[0296] An execution unit is used to execute the initialization memory file system image through the Linux system kernel program.

[0297] In one alternative implementation, the first mounting module includes:

[0298] A triggering unit is used to trigger the dracut custom script through the Linux system kernel program during the cleanup phase;

[0299] The mounting unit is used to mount the third hardware partition to the system temporary mount point through the dracut custom script.

[0300] In one alternative implementation, it also includes:

[0301] The first reading module is used to read the changed data stored in the upperdir directory through the Linux system kernel program if a read operation for the federated view is detected.

[0302] The second reading module is used to read the original configuration file stored in the lowerdir layer if the changed data has not been changed. The original configuration file refers to the initial configuration content that has not been modified.

[0303] A redirection module is used to redirect a write operation to the upperdir directory via the Linux system kernel program if a write operation is detected for the federated view.

[0304] This application also provides an electronic device in its embodiments. (See reference...) Figure 4 The diagram illustrates a structural schematic suitable for implementing the electronic device in the embodiments of this application. The electronic device in the embodiments of this application may include, but is not limited to, fixed terminals such as mobile phones, laptops, PDAs (personal digital assistants), PADs (tablet computers), desktop computers, etc. Figure 4 The electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0305] like Figure 4 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 401, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 402 or a program loaded from a storage device 408 into a random access memory (RAM) 403. When the electronic device is powered on, the RAM 403 also stores various programs and data required for the operation of the electronic device. The processing unit 401, ROM 402, and RAM 403 are interconnected via a bus 404. An input / output (I / O) interface 405 is also connected to the bus 404.

[0306] Typically, the following devices can be connected to I / O interface 405: input devices 406 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 407 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 408 including, for example, memory cards, hard drives, etc.; and communication devices 409. Communication device 409 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0307] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the Linux operating system implementation methods based on OverlayFS technology provided in this application.

[0308] This application also provides a computer-readable storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the Linux operating system implementation methods based on OverlayFS technology provided in this application.

[0309] It should also be noted that the device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. In addition, in the device embodiment drawings provided in this application, the connection relationship between modules indicates that they have a communication connection, which can be implemented as one or more communication buses or signal lines.

[0310] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can also be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0311] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0312] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for implementing a Linux operating system based on OverlayFS technology, characterized in that, include: The boot bridge carrier stored in the first directory area of ​​the first hardware partition is loaded through the Unified Extensible Firmware Interface (UEFI) firmware, and the boot bridge carrier is used to link to the GRAND Unified Bootloader. The GRAND unified bootloader is started in the second directory area of ​​the second hardware partition through the boot bridging carrier; the second hardware partition is a read-only storage carrier. The Linux Live ISO image file stored in the third directory area of ​​the second hardware partition is loaded by the GRAND unified bootloader. The Linux Live ISO image file contains the Linux system kernel program and an initialized memory file system image. The Linux system kernel program is started and the memory file system image file is executed, the memory file system image file including the dracut custom script; During the cleanup phase, the third hardware partition is mounted to the system temporary mount point using the dracut custom script. The third hardware partition includes the upperdir directory and the workdir directory. The upperdir directory is used to store the change data generated by the original configuration file directory during the operation of the Linux operating system. The workdir directory is used to temporarily store the intermediate state data generated by OverlayFS during file read and write operations in the lowerdir and upperdir layers. The dracut custom script parses the original configuration file directory built into the Linux Live ISO image file; The original configuration file directory is determined to be the lowerdir layer of OverlayFS; The lowerdir layer and the upperdir directory are merged using the dracut custom script to obtain a combined view.

2. The implementation method of the Linux operating system based on OverlayFS technology according to claim 1, characterized in that, Also includes: If a configuration restore command is detected, the restore trigger method and restore mode are determined. The restore mode is either a full restore mode or a restore backup configuration mode. The restore trigger method is either triggered by a one-click restore tool or triggered by a restore mode startup item. The restore mode startup item corresponding to the restore mode startup item is deployed on the second hardware partition. If the restoration is triggered by the one-click restoration tool, terminate all read and write processes on the third hardware partition and release the upperdir directory and the workdir directory from their occupied states. If the restore triggering method is triggered by the restore mode startup item, terminate the association between the third hardware partition and the system temporary mount point; If the restore mode is the full restore mode, format the third hardware partition; Rebuild the upperdir directory and the workdir directory within the third hardware partition; If the restore mode is the recovery backup configuration mode, delete the changed data stored in the upperdir directory of the third hardware partition; Load the configuration file stored in the preset path and copy it to the upperdir directory; Perform a restart operation.

3. The implementation method of the Linux operating system based on OverlayFS technology according to claim 1, characterized in that, The method for constructing the first hardware partition includes: The boot bridging carrier is obtained, which includes an Extensible Firmware Interface (EFI) bootloader and a boot configuration table. The EFI bootloader is a program used to bridge the UEFI firmware and the GRAND unified bootloader, and the boot configuration table is a configuration file used to record the running path of the GRAND unified bootloader. The boot bridge carrier is stored in the first directory area of ​​the first hardware partition.

4. The implementation method of the Linux operating system based on OverlayFS technology according to claim 1, characterized in that, The method for constructing the second hardware partition includes: Obtain system core and boot software resources, including the LinuxLive ISO image file, the GRAND unified bootloader, and the GRAND unified bootloader GRUB boot configuration template file; the GRUB boot configuration template file is a configuration file framework for the basic operating parameters and rules of the GRAND unified bootloader. The GRAND unified bootloader is stored in the second directory area of ​​the second hardware partition; Compress the Linux Live ISO image file into squashfs format; The Linux Live ISO image file in squashfs format is stored in the third directory area of ​​the second hardware partition; Obtain GRUB customized configuration parameters, which include loopback mount rules, embedded kernel parameters, and restore mode boot items; the embedded kernel parameters include the third directory area of ​​the second hardware partition, the device name of the third hardware partition, and the stacking directory of OverlayFS used for joint mounting; The GRUB customized configuration parameters are set in the GRUB boot configuration template file to obtain the GRUB solidified configuration file; The GRUB firmware configuration file is stored in the fourth directory area of ​​the second hardware partition; Set the second hardware partition to read-only.

5. The implementation method of the Linux operating system based on OverlayFS technology according to claim 1, characterized in that, The method for constructing the third hardware partition includes: This document describes the acquisition of file system and directory management tools, including a formatting tool for the fourth extended file system (ext4), Linux directory creation scripts, permission configuration tools, and storage capacity planning tools. The ext4 file system formatting tool is a native Linux tool for formatting hardware partitions as ext4 file systems. The Linux directory creation script is a standardized execution script that can automatically generate a specified directory structure. The permission configuration tool is a native Linux tool used to modify file or directory access control permissions. The storage capacity planning tool is a tool used to calculate and plan the storage capacity of hardware partitions. The third hardware partition is formatted as an ext4 file system using the ext4 file system formatting tool. The Linux directory creation script creates an OverlayFS directory in the third hardware partition, the OverlayFS directory including the upperdir directory and the workdir directory; Configure preset permission rules for the upperdir directory and the workdir directory using the permission configuration tool; The storage capacity planning tool is used to plan and reserve redundant storage space for the third hardware partition.

6. The implementation method of the Linux operating system based on OverlayFS technology according to any one of claims 1 to 5, characterized in that, Also includes: Verify whether the UEFI firmware can locate the GRAND unified bootloader stored in the second directory area of ​​the second hardware partition through the boot bridging carrier, so as to obtain the first verification result; Verify whether the GRAND unified bootloader can read the GRUB hardened configuration file stored in the fourth directory area of ​​the second hardware partition, whether it can mount the Linux Live ISO image file through the loopback mount rule, and whether the read-only attribute of the second hardware partition is effective, so as to obtain the second verification result. The GRUB hardened configuration file includes the loopback mount rule. Verify whether the upperdir directory and the workdir directory in the third hardware partition can be written normally by the root user, and whether the third hardware partition can be mounted, so as to obtain the third verification result. If the first verification result, the second verification result, and the third verification result are all yes, generate a software storage deployment log; The software storage deployment log is stored in a designated hidden directory of the third hardware partition.

7. The implementation method of the Linux operating system based on OverlayFS technology according to claim 1, characterized in that, The step of loading the Linux Live ISO image file stored in the third directory area of ​​the second hardware partition through the GRAND unified bootloader includes: The GRAND unified bootloader reads the GRUB hardened configuration file stored in the fourth directory area of ​​the second hardware partition. The GRUB hardened configuration file includes loopback mount rules, hardened kernel parameters, and restore mode boot items. The hardened kernel parameters include the third directory area of ​​the second hardware partition, the device name of the third hardware partition, and the stacking directory of OverlayFS used for joint mounting. The GRAND unified bootloader uses the loopback mount rules to virtualize the Linux Live ISO image file as a block device. Access the block device.

8. The implementation method of the Linux operating system based on OverlayFS technology according to claim 1, characterized in that, The steps of starting the Linux system kernel program and executing the initialization memory file system image file include: Load the Linux system kernel program and the initialized memory file system image from the Linux Live ISO image file; Start the Linux system kernel program; The initialization of the memory file system image is executed through the Linux system kernel program.

9. The implementation method of the Linux operating system based on OverlayFS technology according to claim 1, characterized in that, The step of mounting the third hardware partition to the system temporary mount point using the dracut custom script during the cleanup phase includes: During the cleanup phase, the dracut custom script is triggered by the Linux system kernel program; The third hardware partition is mounted to the system's temporary mount point using the dracut custom script.

10. The implementation method of the Linux operating system based on OverlayFS technology according to claim 1, characterized in that, After the step of merging the lowerdir layer and the upperdir directory using the dracut custom script to obtain a unioned view, the method further includes: If a read operation is detected for the federated view, the changed data stored in the upperdir directory is read by the Linux system kernel program; If the changed data has not been changed, read the original configuration file stored in the lowerdir layer. The original configuration file refers to the initial configuration content that has not been modified. If a write operation is detected for the federated view, the write operation is redirected to the upperdir directory by the Linux system kernel program.

11. An implementation device for a Linux operating system based on OverlayFS technology, characterized in that, include: The first loading module is used to load the boot bridge carrier stored in the first directory area of ​​the first hardware partition through the Unified Extensible Firmware Interface (UEFI) firmware, and the boot bridge carrier is used to link to the GRAND Unified Bootloader. The first boot module is used to start the GRAND unified bootloader stored in the second directory area of ​​the second hardware partition through the boot bridging carrier; The second hardware partition is a read-only storage medium; The second loading module is used to load the Linux Live ISO image file stored in the third directory area of ​​the second hardware partition through the GRAND unified bootloader. The Linux Live ISO image file contains the Linux system kernel program and an initialized memory file system image. The second boot module is used to start the Linux system kernel program and execute the initialization memory file system image file, wherein the initialization memory file system image includes a dracut custom script; The first mounting module is used to mount the third hardware partition to the system temporary mount point through the dracut custom script during the cleanup phase. The third hardware partition includes the upperdir directory and the workdir directory. The upperdir directory is used to store the change data generated by the original configuration file directory during the operation of the Linux operating system. The workdir directory is used to temporarily store the intermediate state data generated by OverlayFS during the file read and write operations in the lowerdir layer and the upperdir layer. The parsing module is used to parse the original configuration file directory built into the Linux Live ISO image file using the dracut custom script; The first determining module is used to determine that the original configuration file directory is the lowerdir layer of OverlayFS; The first acquisition module is used to merge the lowerdir layer and the upperdir directory through the dracut custom script to obtain a combined view.

12. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, cause the electronic device to implement the Linux operating system implementation method based on OverlayFS technology as described in any one of claims 1 to 10.

13. An electronic device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the electronic device to implement the Linux operating system based on OverlayFS technology as described in any one of claims 1 to 10.

14. A computer storage medium, characterized in that, The storage medium carries one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the Linux operating system based on OverlayFS technology as described in any one of claims 1 to 10.

Images