Loading method, system, host and storage medium of operating system

Abstract

The embodiment of the application relates to the computer or network technology application field, and discloses a loading method, system, host and storage medium of an operating system, the loading method of the operating system uses the mode of a pre-boot execution environment to load a system image file into a host memory, then loads the system image file to a read-only file system of a virtual file system, and hangs a storage device of the host to a writable file system of the virtual file system, so that the writable file system is automatically loaded when next power-on starting, thereby solving the problem that the mode of the pre-boot execution environment cannot save system data, and improving the loading flexibility of the operating system.

Description

Technical Field

[0001] This application relates to the field of computer or network technology applications, and in particular to a method for loading an operating system, a system, a host, and a storage medium. Background Technology

[0002] Preboot Execution Environment (PXE) is a network boot technology that allows operating systems to be installed without the need for installation media such as CDs or USB drives. PXE allows a computer to download the operating system image over a network during startup, enabling system installation or recovery. PXE is widely used in enterprise environments to facilitate large-scale operating system deployment. PXE loads the network card driver during the BIOS stage, then performs network configuration via HTTP protocol (depending on Legacy or UEFI), and connects to a remote server via TFTP to transfer the kernel, image, and configuration files, thus achieving automatic system installation.

[0003] Currently, PXE technology is mainly used for system installation. Therefore, it is necessary to ensure that the system has an installation hard drive. At the same time, the installation needs to overwrite the original system. The PXE method is a read-only file system and cannot save system data. Summary of the Invention

[0004] This application provides an operating system loading method, system, host, and storage medium to solve the problem that the pre-boot execution environment cannot save system data, thereby improving the loading flexibility of the operating system.

[0005] The embodiments of this application provide the following technical solutions:

[0006] In a first aspect, embodiments of this application provide an operating system loading method, applied to a host, the host being communicatively connected to a server, the host including a storage device and memory space, the method comprising:

[0007] Receive the system image file sent by the server and load the system image file into the memory space. The system image file corresponds to a virtual file system.

[0008] Load the virtual file system, which includes a read-only file system and a writable file system;

[0009] Load the system image file into a read-only file system, and mount the storage device into a writable file system;

[0010] The operating system is loaded remotely based on the system image file.

[0011] In some embodiments,

[0012] A read-only file system corresponds to a read-only directory in a virtual file system, while a writable file system corresponds to a read-write directory in a virtual file system.

[0013] Loading the system image file onto a read-only file system, and mounting the storage device onto a writable file system, include:

[0014] Mount the system image file to a read-only directory, and mount the storage device to a read-write directory.

[0015] In some embodiments,

[0016] After loading the operating system, the method also includes:

[0017] Load the storage driver to identify the storage device, which includes the host's built-in storage and / or external storage devices;

[0018] Mount the identified storage device to a writable directory.

[0019] In some embodiments,

[0020] Based on the system image file, load the operating system, including:

[0021] Extract the system image file to obtain the operating system kernel and temporary root file system;

[0022] Load the operating system kernel, and load a temporary root file system to load the operating system.

[0023] In some embodiments,

[0024] Before receiving the system image file sent by the server, the method also includes:

[0025] Customize the host's current operating system, including:

[0026] Customize the operating system kernel to support virtual file systems; and,

[0027] Customize the operating system to support loading system image files into a read-only file system, and mounting storage devices into a writable file system;

[0028] Customize the startup script to load the system image file into memory after receiving the system image file sent by the server.

[0029] In some embodiments,

[0030] The method also includes:

[0031] Mount the host's original system hard drive to the hard drive directory of the current root file system so that data on the original system hard drive can be read and written through the hard drive directory.

[0032] In some embodiments,

[0033] Storage devices are used to store files corresponding to the current operating system;

[0034] The host corresponds to at least two original operating systems, and the method also includes:

[0035] Receive operation instructions, which are used to perform read and write operations;

[0036] According to the operation instructions, read and write operations are performed on the system hard drive where the current operating system is located;

[0037] After reading and writing to the system hard drive, a shutdown command is received. This shutdown command is used to disable the function of remotely loading the operating system.

[0038] The original operating system will be booted according to the shutdown command.

[0039] In some embodiments,

[0040] The method also includes:

[0041] Receive system storage instructions;

[0042] According to the system storage instructions, the system image file is stored on the storage device.

[0043] In some embodiments,

[0044] The operating system includes Linux.

[0045] Virtual file systems include the OverlayFS system.

[0046] Secondly, embodiments of this application provide a host, including:

[0047] The processor and memory, wherein the processor is used to execute executable program code in memory, and when the executable program code is executed, the processor executes instructions of the operating system loading method as described in any of the first aspects.

[0048] Thirdly, embodiments of this application provide an operating system loading system, comprising:

[0049] Such as the host in the second aspect;

[0050] Server, connecting to host.

[0051] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed, implements an operating system loading method as described in any of the first aspects.

[0052] The beneficial effects of this application embodiment are as follows: Unlike the prior art, this application embodiment provides an operating system loading method applied to a host, which is communicatively connected to a server. The host includes a storage device and memory space. The method includes: receiving a system image file sent by the server and loading the system image file into the memory space, wherein the system image file corresponds to a virtual file system; loading the virtual file system, wherein the virtual file system includes a read-only file system and a writable file system; loading the system image file into the read-only file system and mounting the storage device into the writable file system; and remotely loading the operating system based on the system image file.

[0053] By using a pre-boot execution environment to load the system image file into the host memory, and then loading the system image file into a read-only file system of the virtual file system, and mounting the host's storage devices into a writable file system of the virtual file system, the writable file system is automatically loaded on the next power-on boot. This solves the problem that the pre-boot execution environment method cannot save system data and improves the loading flexibility of the operating system. Attached Figure Description

[0054] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0055] Figure 1 This is a schematic diagram of the hardware structure of a host provided in an embodiment of this application;

[0056] Figure 2 This is a schematic diagram of a PXE installation process provided in an embodiment of this application;

[0057] Figure 3 This is a schematic diagram of the structure of an operating system loading system provided in an embodiment of this application;

[0058] Figure 4 This is a flowchart illustrating an operating system loading method provided in an embodiment of this application;

[0059] Figure 5 This is a schematic diagram illustrating a customized operating system provided in an embodiment of this application;

[0060] Figure 6 yes Figure 4 A detailed flowchart of step S403 in the process;

[0061] Figure 7 This is a schematic diagram of an OverlayFS system provided in an embodiment of this application;

[0062] Figure 8 yes Figure 4 A detailed flowchart of step S404 in the process;

[0063] Figure 9 This is a schematic diagram of the overall process of starting a system via a PXE network, provided in an embodiment of this application.

[0064] Figure 10 This is a schematic diagram of a process for starting a raw operating system provided in an embodiment of this application;

[0065] Figure 11 This is a timing diagram of the interaction between a server and a host provided in an embodiment of this application;

[0066] Figure 12 This is a schematic diagram of the structure of a host provided in an embodiment of this application.

[0067] Explanation of icon numbers:

[0068] label name label name 300 Operating system loading system 100 host 101 storage devices 102 memory space 200 server 110 processor 120 memory Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0070] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than the module division in the device or the order in the flowchart. Moreover, the terms "first," "second," and "third" used in this application do not limit the data or execution order, but only distinguish identical or similar items with essentially the same function and effect.

[0071] Please see Figure 1 , Figure 1 This is a schematic diagram of the hardware structure of a host provided in an embodiment of this application.

[0072] like Figure 1 As shown, the hardware structure of this host includes:

[0073] A System-on-Chip (SoC) is an integrated circuit (IC) design designed to integrate an entire computer system or functional module onto a single chip. An SoC typically includes a processor core, memory, input / output interfaces, and other necessary components that work together to perform a specific task.

[0074] In this embodiment of the application, the system-on-a-chip includes:

[0075] A processor (Central Processing Unit, CPU) is responsible for executing instructions, processing data, and controlling other hardware components.

[0076] A PXE network interface card (NIC) is a type of network interface card that enables the booting of an operating system over a network. A Preboot Execution Environment (PXE) allows a computer to download and execute an operating system image from a network server at startup, without requiring the operating system to be pre-installed on local storage devices such as hard drives, optical discs, or USB drives.

[0077] Non-volatile memory is widely used to store data such as firmware and program code. This non-volatile memory includes flash memory, which includes NAND flash memory or NOR flash memory. NOR flash memory uses a logic gate structure (NOR gate).

[0078] A hard disk drive (HDD) is a widely used storage device for storing and retrieving digital information.

[0079] A solid-state drive (SSD) is a device used for data storage that uses NAND flash memory to store data.

[0080] The Universal Serial Bus (USB) interface is a widely used interface standard for connecting computers and other electronic devices for data transmission and power supply.

[0081] Double Data Rate (DDR) memory is a type of computer memory widely used in personal computers, servers, and mobile devices.

[0082] Understandably, the pre-boot execution environment needs to communicate with the server to download the operating system image over the network during operating system installation, thereby performing system installation.

[0083] Please refer to the following: Figure 2 , Figure 2 This is a schematic diagram of a PXE installation process provided in an embodiment of this application.

[0084] like Figure 2 As shown, the host interacts with the server to complete the PXE installation, that is, to load the operating system via PXE. It can be understood that the host acts as the client and the server as the service provider.

[0085] The PXE installation process includes the following steps:

[0086] (1) Configure the host's BIOS to support PXE boot.

[0087] Specifically, by entering the BIOS settings, enabling network boot, and setting network boot as the first option in the boot order, PXE boot can be supported.

[0088] (2) Configure the expansion ROM to store the PXE network card driver.

[0089] The PXE network card driver includes a PXE-related boot program responsible for pre-boot loading. By entering the BIOS settings and enabling the Expansion ROM, the PXE network card driver can be configured to be stored in the extended read-only memory.

[0090] (3) Upon receiving a request for Dynamic Host Configuration Protocol (DHCP), the DHCP server in the server assigns an IP address to the host and provides information on the boot file and configuration file.

[0091] (4) The host downloads the boot files and configuration files from the server's TFTP server via the Trivial File Transfer Protocol (TFTP), and transfers the kernel and root file system.

[0092] (5) After downloading the bootloader, the host obtains the automatic installation script from the installation source (NFS or FTP server) and downloads the required installation source files from the installation source (NFS or FTP server).

[0093] As can be seen, the Preboot Execution Environment (PXE) is a boot method for installing an operating system that allows it to boot over the network without the need for installation media such as CDs or USB drives. PXE loads the network card driver during the BIOS stage, then performs network configuration via HTTP protocol depending on whether it's Legacy or UEFI, and connects to a remote server via TFTP to transfer the kernel, image, and configuration files, thereby enabling automatic system installation.

[0094] However, current PXE technology is mainly used for system installation. Therefore, it is necessary to ensure that the system has an installation hard drive. At the same time, the installation needs to overwrite the original system. The PXE method is a read-only file system that cannot save system data, resulting in insufficient flexibility in loading the operating system.

[0095] In view of this, embodiments of this application provide an operating system loading method, system, host, and storage medium. By utilizing a pre-boot execution environment to load the system image file into the host memory, and then loading the system image file into a read-only file system of a virtual file system, and mounting the host's storage device into a writable file system of the virtual file system, the writable file system is automatically loaded upon the next power-on startup. This solves the problem that the pre-boot execution environment method cannot save system data and improves the loading flexibility of the operating system.

[0096] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of an operating system loading system provided in an embodiment of this application.

[0097] like Figure 3 As shown, the loading system 300 of the operating system includes a host 100 and a server 200. The host 100 is connected to the server 200, and the server 200 communicates with the host 100 via wired or wireless means to realize data interaction.

[0098] The host 100 includes: storage device 101 and memory space 102.

[0099] Specifically, storage device 101 may include:

[0100] The extended read-only storage space, i.e., the Expansion ROM space, is used to store firmware or drivers. Specifically, it is used to store boot code, device drivers, or other necessary software to support the functions of storage device 101.

[0101] The flash memory space is composed of flash memory media, which is connected to the controller. The flash memory media, also known as flash memory, NAND Flash, Flash memory, or Flash chip, is a type of storage device and a non-volatile memory that can retain data for a long time without a current supply. Its storage characteristics are similar to those of a hard disk, making flash memory the basis for the storage media of various portable digital devices.

[0102] In some embodiments, the controller includes a processor, memory, flash memory controller, and interface.

[0103] The processor is connected to the memory, flash memory controller, and interface, respectively. The processor, memory, flash memory controller, and interface can be connected via a bus or other means. The processor is used to run non-volatile software programs, instructions, and modules stored in the memory, thereby implementing any of the method embodiments of this application. Furthermore, through firmware development, it is also used to handle the core processing of the flash translation layer (FTL).

[0104] The memory is mainly used to cache read / write commands sent by the host, as well as to cache read or write data obtained from the flash memory medium according to the read / write commands sent by the host.

[0105] The flash memory controller, connected to the flash memory medium, processor, and memory, is used to access the back-end flash memory medium and manage various parameters and data I / O of the flash memory medium.

[0106] The interface connects the host, processor, and memory, and is used to receive data sent by the host or to receive data sent by the processor, thereby enabling data transfer between the host and the processor. The interface can be a SATA-2 interface, a SATA-3 interface, a SAS interface, an MSATA interface, a PCI-E interface, an NGFF interface, a CFast interface, an SFF-8639 interface, or an M.2 NVME / SATA protocol.

[0107] Specifically, memory space 102 is used to store data or instructions from host 100.

[0108] In this embodiment, memory space 102 is used to store system image files obtained by host 100 from the server. This memory space 102 includes a cache space, i.e., a cache, which is a fast storage area in host 100 used to store data and instructions. The cache space is used to improve the data access speed of host 100 and reduce data access latency.

[0109] In some embodiments, the cache space is implemented using different storage media, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Flash Memory, and high-performance cache memory. Preferably, the cache space includes Static Random Access Memory (SRAM).

[0110] It is understandable that memory space 102 refers to the memory area in the computer system of host 100 used to store data and instructions. Memory space 102 is a key component for the computer to run programs, process data and perform tasks.

[0111] Please see Figure 4 , Figure 4 This is a flowchart illustrating an operating system loading method provided in an embodiment of this application.

[0112] The operating system loading method described herein applies to a host computer that communicates with a server. The host computer includes storage devices and memory space. Specifically, the execution entity for this operating system loading method is one or at least two processors of the host computer.

[0113] like Figure 4 As shown, the loading method of this operating system includes the following steps S401-S404:

[0114] Step S401: Receive the system image file sent by the server and load the system image file into the memory space. The system image file corresponds to a virtual file system.

[0115] Specifically, the host communicates with the server. After the host boots in BIOS, it boots via PXE to obtain the system image file sent by the server and loads the system image file into memory. In other words, the system image file sent by the server is saved to the host's memory.

[0116] Understandably, a system image file is a file that stores the complete file system and is typically used to back up or distribute operating system and application installation packages.

[0117] The system image file corresponds to a virtual file system, which enables the operating system to access and manage different types of file systems. Understandably, this virtual file system allows users and applications to operate between different file systems without needing to concern themselves with the specific implementation details of the underlying file systems.

[0118] In this embodiment of the application, the operating system includes a Linux system, and the virtual file system includes an OverlayFS system.

[0119] In this embodiment of the application, before receiving the system image file sent by the server, the method further includes:

[0120] Customize the host's current operating system, including:

[0121] Customize the operating system kernel to support virtual file systems; and,

[0122] Customize the operating system to support loading system image files into a read-only file system, and mounting storage devices into a writable file system;

[0123] Customize the startup script to load the system image file into memory after receiving the system image file sent by the server.

[0124] Please see Figure 5 , Figure 5 This is a schematic diagram of a customized operating system provided in an embodiment of this application.

[0125] like Figure 5 As shown, the customization of this operating system includes: system customization, kernel customization, and startup script customization.

[0126] System customization includes: customizing a readable file system, customizing drivers for built-in and external storage devices, and configuring readable and writable partitions.

[0127] Specifically, customizing a readable file system includes: selecting the file system type, setting up file system mounting, optimizing the storage structure, and tuning the file system. Selecting the file system includes choosing a suitable file system (such as ext4, FAT32, NTFS, XFS, etc.) based on the use case. It's understood that each file system has different characteristics, such as performance, compatibility, security, and data integrity. Setting up the file system mount includes: customizing file system mount options, such as read-only or read-write permissions, user and group access control, and buffer settings. Optimizing the storage structure includes: customizing partition size and block size according to data storage needs to improve storage efficiency and access speed. Tuning the file system includes: adjusting file system parameters (such as journaling mode, caching strategy, etc.) to optimize performance and security.

[0128] Specifically, customizing drivers for internal and external storage devices includes: driver selection and compilation, driver configuration, plugins and extensions, and error handling mechanisms within the customized drivers. Driver selection and compilation includes: selecting appropriate drivers and compiling drivers for internal and external storage devices (such as SATA, SAS, USB storage devices, etc.). Driver configuration includes: customizing driver parameters based on hardware characteristics (such as read / write speed, buffer size, timing control, etc.) to ensure compatibility and performance optimization with storage devices. Plugins and extensions include: adding specific functions and plugins for specific hardware devices (such as SSDs, RAID controllers, etc.) to support advanced features (such as TRIM, snapshots, backups, etc.). Error handling mechanisms within the customized drivers include: automatic retries, backoff algorithms, and resource cleanup and release. Automatic retries include: implementing a retry mechanism to attempt to re-execute the operation when a recoverable error is encountered. Backoff algorithms include: using backoff algorithms (such as exponential backoff) to increase the retry interval for frequently failing operations. This includes cleaning up and releasing resources, such as ensuring that allocated resources (e.g., memory, file handles) are properly released when errors occur, to prevent memory leaks or resource exhaustion.

[0129] Specifically, read / write partition configuration includes: partition planning, file system selection, mount point configuration, permission management, data security, scalability, and performance optimization. Partition planning involves determining the number of partitions, the size of each partition, and the partition type. Proper partition configuration can improve system performance, data security, and user experience, ensuring efficient and stable system operation.

[0130] Kernel customization includes customizing the operating system kernel to support virtual file systems.

[0131] Specifically, customizing the operating system kernel includes kernel configuration, interface design, data structures, file system driver development, permission management, error handling, performance optimization, documentation, and testing. Kernel configuration involves enabling options related to the Virtual File System (VFS) during the kernel configuration phase, such as VFS support and support for required file systems (e.g., ext4, NFS, FAT). Interface design involves defining a unified interface for the virtual operating system, including operations on files, directories, and devices, so that different file systems can operate through these interfaces. Furthermore, this is implemented through system calls to ensure that file-related system calls (such as open, read, write, close, mkdir, etc.) are correctly forwarded to the corresponding underlying file system.

[0132] The startup script customization includes configuring a virtual file system. Specifically, it configures the startup script to support a virtual file system.

[0133] Specifically, configuring the startup script to support the virtual file system includes several aspects: configuring the startup script location, mounting the virtual file system, setting up the virtual file system environment, configuring permissions and attributes, starting services, error handling, logging, and testing the startup script. Configuring the startup script location includes determining the script path. Mounting the virtual file system includes adding mount commands to the startup script to ensure the required virtual file system is correctly mounted to the specified mount point during startup. Setting up the virtual file system environment includes configuring and mounting a temporary file system in the startup script. Configuring permissions and attributes includes setting appropriate permissions and owners after mounting to ensure users can access the file system. Starting services includes ensuring any services that depend on the file system, such as database services and web services, are started in the startup script before the virtual file system and the file system are mounted. Error handling includes checking error status after mounting and other operations to ensure appropriate handling when errors occur, such as logging or sending alerts. Logging includes adding log entries to the startup script to track the mount and unmount status of the file system. The test startup script includes: after the configuration is completed, testing the startup script to ensure that the virtual file system and file system can work properly during the startup process.

[0134] In this embodiment of the application, through reasonable configuration and testing, it can be ensured that the operating system can successfully load and manage the virtual file system and its related file systems at startup.

[0135] In this embodiment of the application, by customizing the operating system, the stability and reliability of the system can be improved.

[0136] Step S402: Load the virtual file system, wherein the virtual file system includes a read-only file system and a writable file system.

[0137] Specifically, the virtual file system includes a union mount file system, which allows two or more file systems to be overlaid together to provide a unified view. This union mount file system includes: UnionFS, MergerFS, and overlayFS. Preferably, the virtual file system in this embodiment is an overlayFS system.

[0138] As is understandable, OverlayFS (Overlay File System) is a file system overlay technology provided by the Linux kernel. As a lightweight union mount file system, OverlayFS is commonly used in container technologies such as Docker. OverlayFS allows multiple file systems to be stacked together to form a virtual file system view. For example, OverlayFS supports stacking a read-only layer (LOWER layer) and a writable layer (UPPER layer) together to provide a consistent file view.

[0139] The file system layer includes a read-only file system and a writable file system. The read-only file system is called "LOWER", and the writable file system is called "UPPER".

[0140] Step S403: Load the system image file into the read-only file system and mount the storage device into the writable file system.

[0141] Specifically, the system image file received from the server will be loaded into a read-only file system as a read-only layer of the virtual file system; and the storage device will be mounted onto a writable file system as a writable layer of the virtual file system.

[0142] Please see Figure 6 , Figure 6 yes Figure 4 A detailed flowchart of step S403 in the process.

[0143] like Figure 6 As shown, step S403 includes the following step S4031:

[0144] Step S4031: Mount the system image file to a read-only directory, and mount the storage device to a read-write directory.

[0145] As can be understood, mounting refers to connecting a storage device (such as a hard drive, USB flash drive, optical disc, etc.) or an image file (such as an ISO file) to a file system so that the operating system can access its contents.

[0146] In the embodiments of this application, the read-only file system corresponds to the read-only directory of the virtual file system, and the writable file system corresponds to the read-write directory of the virtual file system.

[0147] Mounting the system image file to a read-only directory prevents the operating system from making any modifications to the contents of that directory. In other words, the operating system can only view and read the system image file, but cannot add, delete, or modify it. This prevents accidental modifications when inspecting file contents or extracting files from the image, thus ensuring the integrity of the system image file.

[0148] The storage device can be a hard drive partition, USB flash drive, SD card, etc., and contains files and data that can be accessed and modified. Mounting the storage device to a read-write directory is equivalent to setting the storage device's space to read-write mode. At this time, users can read and modify the contents of the storage device's space, that is, allow users to create, delete, and edit files on the storage device.

[0149] Please refer to the following: Figure 7 , Figure 7 This is a schematic diagram of an OverlayFS system provided in an embodiment of this application.

[0150] like Figure 7 As shown, the OverlayFS system includes a root file system (Virtual RootFS), which is a merged layer. This root file system is composed of all directories for users to read and write. That is, it merges the upper and lower layers into a single view, and users can access files from this merged layer.

[0151] In this OverlayFS system, the upper layer (UPPER) is writable, and the lower layer (LOWER) is read-only. The upper layer includes a read-write directory to which storage devices are mounted. These storage devices can include internal and external storage devices. Internal storage devices can include disk storage devices, flash memory devices, and hybrid storage devices, while external storage devices can include external disk storage devices, external flash memory devices, external hybrid storage devices, and network attached storage (NAS). The lower layer includes a read-only directory to which the system image file is mounted.

[0152] In this embodiment, before the host loads the OverlayFS system, a writable layer directory (UPPER directory) and a read-only layer directory (LOWER directory) are pre-defined, enabling the system to switch from the temporary root file system (initrd) to the final OverlayFS system during startup. This achieves PXE network-based startup of the OverlayFS system and improves the loading flexibility of the operating system.

[0153] Step S404: Load the operating system remotely based on the system image file.

[0154] As is understandable, a system image file refers to a complete file containing the operating system and all its configurations, applications, and files. This system image file also includes a temporary root file system.

[0155] For details, please refer to [link / reference]. Figure 8 , Figure 8 yes Figure 4 A detailed flowchart of step S404 in the process.

[0156] like Figure 8 As shown, step S404 includes the following steps S4041-S4042:

[0157] Step S4041: Decompress the system image file to obtain the operating system kernel and the temporary root file system.

[0158] As is understandable, the operating system kernel is the core of a computer's operating system, responsible for managing hardware resources and providing basic services. The main functions of the operating system kernel include: process management, memory management, device driver management, system call management, and file system management. Process management includes scheduling and managing the creation, execution, and termination of processes. Memory management includes allocating and managing system memory, including the mapping between virtual and physical memory. Device driver management includes communicating with hardware devices and providing access interfaces to them. System call management includes providing an interface for interaction between user programs and the kernel. File system management includes managing data storage and access, such as file creation, deletion, and reading / writing.

[0159] As is understandable, the temporary root filesystem is an initial filesystem loaded by the kernel during system startup. The primary purpose of the temporary root filesystem is to provide the most basic environment required for booting, enabling the kernel to mount the actual root filesystem. The temporary root filesystem typically contains the following: basic commands and tools, drivers, configuration files, and startup scripts. The basic commands and tools are essential command-line tools for initializing and mounting the root filesystem, providing basic functionality. Drivers are for accessing storage devices and other hardware, ensuring the kernel can find and mount the root filesystem. Configuration files define the location of the root filesystem and other boot options. Startup scripts initialize the system, typically handling device identification and mounting of the root filesystem.

[0160] Specifically, unzipping the system image file includes the following steps:

[0161] (1) Mount the image file. For example, use the mount command to mount the image file to a temporary directory to access its contents.

[0162] (2) Extract the operating system kernel and temporary root file system. For example, use tools to extract the kernel image and temporary root file system content, and use specific commands to decompress the compressed kernel image and temporary root file system and extract them to the current directory. Furthermore, after decompression is completed, check the extracted content to confirm that all necessary components of the operating system kernel and temporary root file system exist.

[0163] Step S4042: Load the operating system kernel and load the temporary root file system to load the operating system.

[0164] Specifically, loading the operating system kernel includes the following steps (1)-(5):

[0165] (1) Bootloader, for example: when the host starts, the BIOS / UEFI performs a self-test and looks for boot devices (such as hard disk, USB drive, etc.), and the bootloader is loaded into memory.

[0166] (2) Selecting the kernel: For example, if there are multiple versions of the operating system kernel, the bootloader can provide a menu that allows the user to select the kernel version to load.

[0167] (3) Loading the kernel image: For example, the bootloader loads the kernel image (e.g., vmlinuz) from the storage device into memory. During the loading process, if the operating system kernel is compressed, it will be decompressed.

[0168] (4) Set kernel parameters. For example, the bootloader can pass boot parameters to the kernel. These parameters may include the kernel boot mode, the location of the root file system, memory parameters, etc.

[0169] (5) Jump to the kernel. For example, after the bootloader finishes loading the kernel, it will transfer control to the kernel and start executing the kernel code.

[0170] Understandably, the temporary root filesystem (initrd) is typically loaded after the kernel loads, providing the necessary environment for the kernel to mount the real root filesystem.

[0171] Specifically, loading the temporary root file system includes the following steps (1)-(5):

[0172] (1) Initialize the kernel, for example: the kernel starts initialization, setting up core functions such as system calls, scheduler, and memory management.

[0173] (2) Loading the temporary root file system: For example, the kernel will look for the path of the temporary root file system specified in the boot parameters and load the temporary root file system. The temporary root file system is usually embedded in the kernel image as a compressed archive (such as CPIO format) or stored as a separate file on the boot device.

[0174] (3) Decompress the temporary root file system. For example, the kernel decompresses the temporary root file system and mounts it as the root file system. This process loads the contents of the temporary root file system into memory, which typically includes basic command-line tools, drivers, and initialization scripts.

[0175] (4) Run the initialization program, for example: the initialization program in the temporary root file system is executed. This program is responsible for detecting hardware, loading necessary modules, mounting the actual root file system, and completing system initialization.

[0176] (5) Mount the actual root file system. For example, the init program will identify the system's root file system (which may be from a hard drive, network, or other device) and attempt to mount it. After successful mounting, the system will transfer control to the actual root file system and execute / sbin / init or other initialization programs.

[0177] In this embodiment, after the operating system kernel and temporary root file system are successfully loaded, the system will further initialize and eventually enter user space to load the operating system, including the following steps (1)-(3):

[0178] (1) Initialize user space, for example: the process that loads user space, usually init or similar processes (such as systemd, upstart, etc.), is responsible for starting other system services and user programs.

[0179] (2) Start services, for example: according to the configuration file (such as the service definition of systemd), start various system services and daemons (such as network services, graphical interface services, etc.).

[0180] (3) Enter the login interface, allowing users to enter credentials to access the operating system's desktop or command-line environment.

[0181] In this embodiment of the application, by remotely obtaining the system image file and decompressing the system image file to load the operating system, the operating system can be started more efficiently.

[0182] Please refer to the following: Figure 9 , Figure 9 This is a schematic diagram of the overall process of starting a system via a PXE network, provided in an embodiment of this application.

[0183] like Figure 9As shown, the overall process of starting the system via PXE network includes the following steps S901-S9010:

[0184] Step S901: Power on the host.

[0185] Specifically, the host computer is powered on, and the system begins initialization.

[0186] Step S902: BIOS startup.

[0187] Specifically, the Basic Input Output System (BIOS) is loaded, and the BIOS is used for hardware initialization and power-on self-test (POST).

[0188] Hardware initialization includes initializing various hardware components in the system, including devices such as CPU, memory, hard disk, graphics card, keyboard, and mouse, and allocating necessary resources (such as memory addresses and I / O ports) to prepare for the subsequent loading of the operating system.

[0189] The self-test (POST) includes a series of tests performed by the host on hardware components during startup to ensure all critical hardware functions correctly. This includes memory testing, device detection, and error reporting. Memory testing checks the random access memory (RAM) to ensure it can correctly read and write data. Device detection identifies and detects connected hardware devices such as hard drives, optical drives, and graphics cards, ensuring they are operational. Error reporting indicates that if an error is detected during the POST, the BIOS will alert the user with a beep or display an error message and abort the startup process to allow the user to troubleshoot.

[0190] Step S903: Select PXE boot.

[0191] Specifically, the operating system is selected to boot via PXE network, meaning that the host obtains the boot program and operating system image from the server via the network when it boots up.

[0192] Step S904: System file transfer.

[0193] Specifically, the server sends a system image file to the host.

[0194] Step S905: Load the kernel and initrd.

[0195] Specifically, it loads the operating system kernel and a temporary root file system.

[0196] Step S906: Configure the OverlayFS system.

[0197] Specifically, configuring the OverlayFS system, i.e., creating the OverlayFS file system, includes the following steps:

[0198] (1) Create a working directory. Specifically, the working directory includes a read-only directory, a read-write directory, and a merge directory. The read-only directory is used for the lower-level file system, the read-write directory is used for the upper-level file system, and the merge directory is used for the merge result.

[0199] (2) Mount the system image file to a read-only directory.

[0200] (3) Mount the storage device to a writable directory.

[0201] (4) Access merged directories. Specifically, access files in read-only directories and read-write directories through merged directories.

[0202] Step S907: Switch to the PXE root file system.

[0203] Specifically, after configuring the OverlayFS system, switch to the root file system corresponding to the system image file to load the storage driver.

[0204] Step S908: Load the storage driver.

[0205] Specifically, obtain the storage driver and run the storage driver to load the storage driver.

[0206] Step S909: Mount the storage device to a writable directory.

[0207] Specifically, the storage device includes an internal storage device and / or an external storage device. The internal storage device and / or the external storage device are mounted to a read-write directory, so that the files in the internal storage device and / or the external storage device can be read and written.

[0208] Step S9010: The PXE read / write system has been loaded.

[0209] In this embodiment of the application, by combining the PXE network boot method with the OverlayFS system, the operating system can mount different storage devices to different directories after booting, thereby enabling better loading of the operating system.

[0210] Understandably, the original operating system is stored on the host's hard drive. After the PXE read / write system loads the system, the host mounts the original operating system partition to the corresponding directory of the file system upon power-up, thus creating separate partitions. Furthermore, since PXE is loaded directly into the host's memory, it needs to be reloaded if the host loses power.

[0211] Furthermore, in order to read and write the original system hard disk, this embodiment of the application will also utilize the current root file system to achieve reading and writing of the original system hard disk.

[0212] Specifically, the host's original system hard drive is mounted to the hard drive directory of the current root file system, so that the data of the original system hard drive can be read and written through the hard drive directory. For example, before mounting, the device name of the original system hard drive is determined, and a directory is selected or created in the read-write directory as the mount point of the original system hard drive, so that the original system hard drive is mounted to the hard drive directory of the current root file system, thereby enabling the data of the original system hard drive to be read and written through the hard drive directory.

[0213] Understandably, since the system image file loaded via PXE network boot is different from the host's original operating system, it is necessary to operate on the original system hard drive, back up and restore data, so that the original hard drive system can still be booted after the PXE function is turned off, thereby enabling the same host to boot multiple operating systems.

[0214] For details, please refer to [link / reference]. Figure 10 , Figure 10 This is a schematic diagram of a process for starting a raw operating system, provided in an embodiment of this application.

[0215] like Figure 10 As shown, the process of booting the original operating system includes the following steps S1001-S1004:

[0216] Step S1001: Receive operation instructions, wherein the operation instructions are used to perform read and write operations.

[0217] Specifically, this operation command is used to perform read and write operations on the system hard drive.

[0218] Step S1002: Perform read and write operations on the system hard disk where the current operating system is located according to the operation instructions.

[0219] Specifically, based on the operation instructions, in the operating system environment running under the current PXE network mode, read and write operations are performed on the system hard drive, such as read operations, write operations, hard drive management operations, and other related operations.

[0220] The read operation includes:

[0221] (1) Loading operating system files. For example, in a PXE environment, the system will download the core files of the operating system (such as the kernel and initialization system) to memory via the network. At this time, it is necessary to read the relevant files on the hard disk.

[0222] (2) Reading configuration files: The operating system may need to read configuration files (such as system settings, user settings, etc.), which are usually stored in a specific directory on the hard drive.

[0223] (3) Reading the driver: Some device drivers may need to be read from the hard drive when the system starts up to support the operation of the hardware.

[0224] The write operation includes:

[0225] (1) Write to system logs. For example, the operating system generates log files during operation. These logs are usually written to the hard disk for subsequent system analysis and troubleshooting.

[0226] (2) Update configuration files. For example, during system operation, some configurations may be modified by user operations, and these changes need to be written to the relevant configuration files on the hard drive.

[0227] (3) Save user files, such as files (such as documents, pictures, etc.) created or modified by users in the operating system will be written to the hard drive.

[0228] (4) Installing and updating software, for example: in the operating system environment, software packages can be installed or existing software can be updated via the network. These operations involve reading and writing hard disks.

[0229] (5) System snapshots and backups, for example: some systems may create snapshots or backup files of the current state and save them on the hard drive so that they can be restored to the previous state.

[0230] The hard disk management operations include:

[0231] (1) Partition management, for example: In some cases, users may need to perform partitioning operations on the hard drive, including creating, deleting or resizing partitions. These hard drive management operations all involve reading and writing.

[0232] (2) Formatting, for example: when installing a new operating system or cleaning up the hard drive, it may be necessary to format the hard drive.

[0233] (3) Disk checks and repairs, for example: the operating system may check the hard drive at startup or during operation to repair potential file system errors, which requires reading and writing hard drive data.

[0234] Other related operations include:

[0235] (1) Network configuration, for example: During the PXE boot process, network configuration (such as IP address, DNS, etc.) may be written to the hard disk for use in subsequent operations.

[0236] (2) Security and permission settings, such as: certain security policies and user permission settings may be modified and written to the hard disk during system operation.

[0237] Step S1003: After performing read and write operations on the system hard disk, a shutdown command is received, wherein the shutdown command is used to disable the function of remotely loading the operating system.

[0238] Specifically, after performing read / write operations on the system hard drive, when it's necessary to disable the remote operating system loading function, the host receives a shutdown command from the user to disable the remote operating system loading function, for example:

[0239] (1) In the PXE (Preboot Execution Environment) environment, stop network services, such as: canceling network connection: close the network connection with the PXE server to ensure that no more data or commands are received from the network. Releasing IP address: if a dynamic IP address is obtained using DHCP, a release request needs to be sent to the DHCP server to release the IP address assigned to the device.

[0240] (2) Close processes, such as terminating running applications to safely terminate all user and system processes and ensure that no applications are running in the background. Alternatively, stop services, such as shutting down web services, database services, etc.

[0241] Step S1004: Start the original operating system according to the shutdown command.

[0242] Specifically, if the host corresponds to only one original operating system, then after receiving the shutdown command, the original operating system will be started according to the shutdown command.

[0243] If the host corresponds to at least two original operating systems, after receiving the shutdown command, it further receives a selection command. According to the selection command, it selects one of the at least two original operating systems and uses that original operating system as the current operating system to be started, so as to start that operating system.

[0244] Understandably, before a customer needs to upgrade the host system, they can remotely boot the operating system via PXE network to preload and experience it, then evaluate the results before choosing to update the system. If it is determined that an operating system update is needed, the operating system is saved from memory to a storage device. Specifically, by receiving a system storage command, the system image file is stored on the storage device according to the system storage command, allowing the user to install the operating system corresponding to the system image file to achieve a system upgrade.

[0245] By preloading the system and storing the system image file on the host's storage device, this application enables more flexible system upgrades, which is beneficial to improving the user experience.

[0246] It's important to note that, generally, the host computer can select boot options during the BIOS phase, such as booting from PXE or the hard drive. For example, if you need to boot the original operating system, simply select the corresponding system hard drive; PXE does not affect the original system hard drive data. Furthermore, after the host computer is powered off, the data in the lower layer is lost, but the upper layer will be automatically loaded when booting via PXE on the next power-on. This solves the drawback of PXE boot files needing to be saved, improving the flexibility and reliability of PXE loading of the operating system.

[0247] Please refer to the following: Figure 11 , Figure 11 This is a timing diagram of the interaction between a server and a host provided in an embodiment of this application.

[0248] like Figure 11 As shown, the interaction between the server and the host includes the following steps S1101-S1106:

[0249] Step S1101: The server sends the system image file to the host.

[0250] Specifically, the host sends a DHCP (Dynamic Host Configuration Protocol) request over the network, querying a DHCP server (usually a PXE server) to obtain an IP address and other network configuration parameters. The DHCP server then returns the address of the TFTP server and the name of the bootloader to the host, enabling the host to determine the address to obtain the bootloader.

[0251] After obtaining the IP address and TFTP server information, the host will send a TFTP (Trivial File Transfer Protocol) request to download the bootloader, or boot file, from the PXE server. The host downloads and executes the bootloader, which is typically a boot loader used to determine the operating system image to be loaded subsequently based on the configuration file.

[0252] The bootloader then typically downloads the operating system image (usually the Linux kernel and initrd file) from the PXE server. For example, the bootloader may use the TFTP protocol to download the operating system image.

[0253] Step S1102: The host receives the system image file sent by the server.

[0254] Step S1103: The host loads the system image file into memory.

[0255] Specifically, the host receives the system image file sent by the server, and after the system image file is successfully downloaded, it loads the system image file into memory.

[0256] Step S1104: The host loads the virtual file system.

[0257] Specifically, virtual file systems include read-only file systems and writable file systems.

[0258] Step S1105: The host mounts the system image file and storage device to the virtual file system.

[0259] Specifically, the host loads the system image file into a read-only file system and mounts the storage device into a writable file system.

[0260] Step S1106: The host remotely loads the operating system based on the system image file.

[0261] Specifically, the host decompresses the system image file to obtain the operating system kernel and temporary root file system, loads the operating system kernel, and loads the temporary root file system to load the operating system.

[0262] In this embodiment of the application, an operating system loading method is provided, applied to a host, which is communicatively connected to a server. The host includes a storage device and memory space. The method includes: receiving a system image file sent by the server and loading the system image file into the memory space, wherein the system image file corresponds to a virtual file system; loading the virtual file system, wherein the virtual file system includes a read-only file system and a writable file system; loading the system image file into the read-only file system and mounting the storage device into the writable file system; and remotely loading the operating system according to the system image file.

[0263] By using the Preboot Execution Environment (PXE) to load the system image file into the host memory, and then loading the system image file into the read-only file system of the virtual file system, and mounting the host's storage devices into the writable file system of the virtual file system, the writable file system is automatically loaded on the next power-on boot. This solves the problem that the Preboot Execution Environment method cannot save system data and improves the loading flexibility of the operating system.

[0264] Please refer to the following: Figure 12 , Figure 12 This is a schematic diagram of the structure of a host provided in an embodiment of this application.

[0265] like Figure 12As shown, the host 100 includes one or more processors 110 and a memory 120. Wherein, Figure 12 Take a processor 110 as an example.

[0266] Processor 110 and memory 120 can be connected via a bus or other means. Figure 12 Taking the example of a connection between China and Israel via a bus.

[0267] Processor 110 provides computing and control capabilities to control host 100 to perform corresponding tasks, such as controlling host 100 to execute the operating system loading method in any of the above method embodiments. This method is applied to a host, which is communicatively connected to a server. The host includes storage devices and memory space. The method includes: receiving a system image file sent by the server and loading the system image file into the memory space, wherein the system image file corresponds to a virtual file system; loading the virtual file system, wherein the virtual file system includes a read-only file system and a writable file system; loading the system image file into the read-only file system; and mounting the storage device into the writable file system; and remotely loading the operating system based on the system image file.

[0268] By using a pre-boot execution environment to load the system image file into the host memory, and then loading the system image file into a read-only file system of the virtual file system, and mounting the host's storage devices into a writable file system of the virtual file system, the writable file system is automatically loaded on the next power-on boot. This solves the problem that the pre-boot execution environment method cannot save system data and improves the loading flexibility of the operating system.

[0269] Processor 110 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), a hardware chip, or any combination thereof; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD can be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0270] Memory 120, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as program instructions / modules corresponding to the operating system loading method in the embodiments of this application. Processor 110 can implement the operating system loading method in any of the following method embodiments by running the non-transitory software programs, instructions, and modules stored in memory 120. Specifically, memory 120 may include volatile memory (VM), such as random access memory (RAM); memory 120 may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, hard disk drive (HDD), solid-state drive (SSD), or other non-transitory solid-state storage devices; memory 120 may also include combinations of the above types of memory.

[0271] Memory 120 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 120 may optionally include memory remotely located relative to processor 110, which can be connected to processor 110 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0272] One or more modules are stored in memory 120. When executed by one or more processors 110, they execute the operating system loading method in any of the above method embodiments, for example, executing the method described above. Figure 4 The steps shown.

[0273] In this embodiment, the host 100 may also have wired or wireless network interfaces, keyboards, and input / output interfaces for input and output. The host 100 may also include other components for implementing device functions, which will not be described in detail here.

[0274] This application also provides a non-volatile computer-readable storage medium, such as a memory including program code, which can be executed by a processor to complete the operating system loading method in the above embodiments. For example, the non-volatile computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CDROM), magnetic tape, floppy disk, and optical data storage device, etc.

[0275] This application also provides a computer program product comprising one or more lines of program code stored in a non-volatile computer-readable storage medium. A host processor reads the program code from the non-volatile computer-readable storage medium and executes the program code to complete the method steps of the operating system loading method provided in the above embodiments.

[0276] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program or program code related to hardware. The program can be stored in a non-volatile computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0277] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0278] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations as described above in different aspects of this application, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method for loading an operating system, characterized in that, Applied to a host computer that communicates with a server, the host computer includes storage devices and memory space, the method includes: The system receives a system image file sent by the server and loads the system image file into the memory space, wherein the system image file corresponds to a virtual file system; Load the virtual file system, wherein the virtual file system includes a read-only file system and a writable file system; Load the system image file into the read-only file system, and mount the storage device into the writable file system; The operating system is remotely loaded based on the system image file.

2. The method according to claim 1, characterized in that, The read-only file system corresponds to the read-only directory of the virtual file system, and the writable file system corresponds to the read-write directory of the virtual file system; Loading the system image file into the read-only file system and mounting the storage device into the writable file system includes: The system image file is mounted to the read-only directory, and the storage device is mounted to the read-write directory.

3. The method according to claim 2, characterized in that, After loading the operating system, the method further includes: Load the storage driver to identify the storage device, wherein the storage device includes the host's built-in storage device and / or external storage device; The identified storage device is mounted to the read / write directory.

4. The method according to claim 1, characterized in that, The step of loading the operating system based on the system image file includes: Decompress the system image file to obtain the operating system kernel and a temporary root file system; The operating system kernel is loaded, and the temporary root file system is loaded to load the operating system.

5. The method according to claim 4, characterized in that, Before receiving the system image file sent by the server, the method further includes: Customizing the host's current operating system includes: Customize the operating system kernel to support the virtual file system; and, A customized operating system is provided to support loading the system image file into the read-only file system and mounting the storage device into the writable file system. A custom startup script is used to load the system image file into the memory space after receiving the system image file sent by the server.

6. The method according to claim 1, characterized in that, The method further includes: The host's original system hard drive is mounted to the hard drive directory of the current root file system, so that the data of the original system hard drive can be read and written through the hard drive directory.

7. The method according to claim 1, characterized in that, The storage device is used to store files corresponding to the current operating system; The host corresponds to at least two original operating systems, and the method further includes: Receive operation instructions, wherein the operation instructions are used to perform read and write operations; According to the operation instructions, read and write operations are performed on the system hard disk where the current operating system is located; After performing read and write operations on the system hard disk, a shutdown command is received, wherein the shutdown command is used to disable the function of remotely loading the operating system; The original operating system is started according to the shutdown command.

8. The method according to claim 1, characterized in that, The method further includes: Receive system storage instructions; According to the system storage instruction, the system image file is stored in the storage device.

9. The method according to any one of claims 1-8, characterized in that, The operating system includes Linux. The virtual file system includes the OverlayFS system.

10. A host computer, characterized in that, include: A processor and a memory, the processor being configured to execute executable program code in the memory, wherein, when the executable program code is executed, the processor executes instructions of a loading method for an operating system as described in any one of claims 1 to 9.

11. A loading system for an operating system, characterized in that, include: The host computer as described in claim 10; The server connects to the host.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed, implements the method for loading an operating system as described in any one of claims 1 to 9.

Images