Deployment method and device for supporting multi-architecture operating system, electronic equipment and medium

Abstract

This invention discloses a deployment method, apparatus, electronic device, and medium that supports multiple operating system architectures. The method includes: automatically detecting the physical architecture and matching the boot file; matching the physical architecture and calling the corresponding architecture boot component based on the matching result; starting and mounting the memory file system installation environment and performing disk partitioning; performing file system installation and deployment; and performing subsequent configuration after system deployment, thereby completing the installation and entering the normal system. This invention can solve the technical problems in related technologies, such as the inability of traditional system installation methods to support multiple architectures, slow installation, complex configuration, and poor hardware support.

Description

Technical Field

[0001] This invention relates to the field of operating system technology, and in particular to a method, apparatus, electronic device, and medium for deploying multi-architecture operating systems. Background Technology

[0002] For industry users of Linux systems, the various application systems are generally relatively fixed. However, due to differences in the underlying hardware architecture (currently the mainstream being x86_64 and arm64), it is necessary to install operating system images of different architectures for deployment before deploying the application systems. Because the requirements for the operating system are relatively fixed and highly homogeneous, such as installation methods, partitioning methods, account information, package lists, and system environment configurations, the main requirements for operating system deployment are: ease of operation, rapid installation and deployment, and quick configuration. Currently, operating system vendors generally use the following solutions to create operating system images and deploy the operating system to meet these requirements:

[0003] 1. First, package all software packages (including customized components, etc.) into the ISO image creation directory according to the package list.

[0004] 2. Add automated installation recipe files. Generally, based on ISO images customized for Red Hat or CentOS systems, the Kickstart recipe method is used. Based on ISO images customized for Debian or Ubuntu systems, the Preseed recipe method is used. The core mechanism of both methods is to pre-set some parts that need to be selected or filled in during the installation process to achieve the purpose of automated installation, such as user account information, partition information, package group list, etc. This invention mainly focuses on the Debian system.

[0005] 3. Then, use relevant tools to package the ISO image directory into an ISO image file, and provide ISO images for different architecture processors.

[0006] 4. Use a creation tool to create a USB bootable disk (CD, etc.) from the ISO image, or directly use the PXE network installation method.

[0007] 5. Perform system installation, following the prompts step by step to complete the system installation.

[0008] First, if the above solution involves machines with processors of various architectures, multiple ISO images need to be created for installation. In such cases, the ISO images of different operating systems provided by default are generally built in a "same source, different architecture" manner. That is to say, regardless of whether it is an x86 or arm64 file system and kernel, they generally use the same source code. The software package versions, environment configuration paths, and usage methods of such same source, different architecture operating systems are basically the same, and the operation and configuration methods can be reused. If the same ISO image supports the installation of systems on different processor architectures, it can reduce a lot of time and effort, avoid resource waste caused by architecture issues, and simplify the operation.

[0009] Secondly, system partitioning is also a very important part of the system deployment process. Currently, most operating system distributions only support fixed-size automatic partitioning, and their support for automatic percentage partitioning is not perfect. Moreover, if LVM partitioning mode is not used, the maintenance cost in the later stage is relatively high.

[0010] Finally, when installing the system, the installation package (deb / rpm) method is used. Generally, installing a complete operating system requires obtaining thousands of packages from the installation media. If the installation media is interrupted or there is a problem accessing it, the installation will fail and the machine will need to be restarted. In addition, the installation process requires the installation and configuration of thousands of packages, which generally takes tens of minutes or even longer. If it is an old machine or hard drive that is being reused (with lower performance), the time cost will be even longer.

[0011] Therefore, there is currently a lack of a complete method for industry users to deploy and configure operating systems more quickly and conveniently. Summary of the Invention

[0012] The purpose of this invention is to overcome the above-mentioned technical deficiencies and provide a deployment method, device, electronic device and medium that supports multiple operating system architectures, so as to solve the technical problems in the related technologies, such as the inability of traditional system installation methods to support multiple architectures, slow installation, complex configuration and poor hardware support.

[0013] To achieve the above-mentioned technical objectives, the present invention adopts the following technical solution:

[0014] According to one aspect of the present invention, a deployment method supporting multiple operating system architectures is provided, comprising:

[0015] Automatically detects the physical architecture and matches the boot files;

[0016] Physical architecture matching; based on the matching result, the corresponding architecture boot file is invoked.

[0017] Start and mount the memory file system installation environment, and perform disk partitioning;

[0018] Perform file system installation and deployment;

[0019] After the system deployment is complete, subsequent configurations are performed, and the installation is complete, allowing you to enter the normal system.

[0020] Optionally, the automatic detection of physical architecture and matching of boot files requires that the provided efi.img file supports multiple architectures. Therefore, this step also includes a method for creating an efi.img file that supports multiple architectures, specifically including:

[0021] Build EFI boot files separately for each architecture;

[0022] Create an EFI boot file (efi.img) that supports multiple architectures;

[0023] Combine the efi.img file into the ISO image.

[0024] Optionally, the physical architecture matching, based on the matching result, involves calling the corresponding architecture boot file, including:

[0025] Obtain the processor architecture and model of the current hardware environment; for example, this can be obtained through cpuuid.

[0026] During the boot phase (such as grub2), a compatibility check is performed, and the corresponding architecture boot file is called; for x86_64 architecture, it is grub-x64.cfg, and for arm64 architecture, it is grub-aa64.cfg.

[0027] Optionally, starting and mounting the memory file system installation environment and performing disk partitioning includes:

[0028] Load the kernel and the initial root filesystem (initrd), and initialize them;

[0029] Determine the machine's physical memory size. If the physical memory size is greater than the ISO image size, copy the ISO image content into memory and mount it. If the physical memory size is less than the ISO image size, do nothing and mount it directly.

[0030] According to the recipe document, confirm the partitioning method and perform a partition size validity judgment and analysis; the partitioning method is configured as one or more of the following: automatic percentage partitioning mode, automatic fixed size partitioning mode, manual percentage partitioning mode, and manual fixed size partitioning mode; furthermore, the partitioning mode is divided into logical volume mode and non-logical volume mode, and the validity judgment logic includes at least: the boot partition is greater than 512M, the / boot / efi partition is greater than 200M, and the root partition is greater than 5G.

[0031] The parsed partition recipe is formatted into a partition size that the system can recognize, and the mount point is recorded to form a partition table.

[0032] Optionally, the file system installation and deployment includes:

[0033] Based on the partition table content, the entire disk partition is mounted in a tree structure. By default, the root partition is mounted first, and then the other partitions are mounted sequentially to the tree directory structure where the root partition is located.

[0034] The root file systems of each architecture are directly mounted, and their contents are copied synchronously to the target system. The synchronous copy is performed using the rsync tool to synchronize the data to the target system.

[0035] Optionally, the method for creating the root file system of each architecture includes:

[0036] Build a file system block, format it, and mount it; the file system block can be built using the dd tool.

[0037] Set the package list, which is obtained from the default ISO image installation list; pull packages from the package source to build the root file system; use the directory built and mounted in the previous step (i.e., the step of building the system block) as the root file system directory. In the yum system, use tool parameters such as yum xxx --install root to build the root file system, and in the apt system, use the debootstrap tool to build the root file system. This article uses the apt system.

[0038] Clean up the root file system environment and compress and package the root file system; the mksquashfs tool can be used for compression and packaging.

[0039] Combine the root file system image into the ISO image.

[0040] Furthermore, after the system is deployed, subsequent configuration is performed, specifically including:

[0041] Bind and mount memory file systems, including: proc, dev, sys, efivars, run, etc., and copy the pre-built environment configuration program to the target root system. At the same time, use chroot to switch the working directory to the target root file system.

[0042] Use the environment configuration program to update user account information, and update the target system's fstab file according to the partition table.

[0043] Install the grub2 bootloader, update the grub.cfg boot file, and add a BIOS boot entry using the efibootmgr command, such as: efibootmgr -cwL xxx -d / dev / xxx-pl.

[0044] Once the system deployment is complete, exit the target system and uninstall the relevant file systems to complete the rapid deployment.

[0045] According to another aspect of the present invention, a deployment apparatus supporting multiple operating system architectures is also provided, comprising:

[0046] The boot file matching unit is used to automatically detect the physical architecture and match the boot file.

[0047] The bootstrapping component invocation unit is used for physical architecture matching and invokes the corresponding architecture bootstrapping component based on the matching result;

[0048] A partition unit is used to boot and mount the memory file system installation environment and perform disk partitioning;

[0049] The installation and deployment unit is used for installing and deploying file systems.

[0050] The configuration unit is used to perform subsequent configurations after system deployment, so that the installation is complete and the system can enter normal operation.

[0051] According to another aspect of the present invention, an electronic device is also provided, comprising: a processor and a memory;

[0052] The memory stores a computer-readable program that can be executed by the processor;

[0053] When the processor executes the computer-readable program, it performs the steps of the method described above.

[0054] According to another aspect of the present invention, a computer-readable storage medium is also provided, the computer-readable storage medium storing one or more programs, the one or more programs being executable by one or more processors to implement the steps in the method described above.

[0055] The present invention provides a deployment method, apparatus, electronic device, and medium that supports multiple architecture operating systems. It enables the installation of systems with multiple architecture processors within the same ISO image. The invention also optimizes the copying of installation media files and disk partitioning, and optimizes the implementation method in the final system installation and deployment stage, reducing unnecessary operations. The installation process can be fully automated, ultimately reducing the installation time of a complete system to a shorter time. The overall solution is cross-architecture and can avoid or reduce problems caused by interruptions or access issues of the installation media itself, which could prevent the installation process from continuing. Furthermore, the entire system installation process is clear, concise, and practical, solving the problems of traditional system installation methods such as inability to support multiple architectures, slow installation, complex configuration, and susceptibility to installation interruptions. Attached Figure Description

[0056] Figure 1 This is a flowchart illustrating a deployment method supporting multiple operating system architectures, as provided in an embodiment of the present invention.

[0057] Figure 2 This is an embodiment of the steps and methods for creating an ISO image according to the present invention;

[0058] Figure 3 This is a schematic diagram of a method for creating a multi-architecture boot file (efi.img) according to an embodiment of the present invention;

[0059] Figure 4 This is a schematic diagram illustrating the construction of a root file system according to an embodiment of the present invention;

[0060] Figure 5 This is a schematic diagram of the percentage partitioning logic flow according to an embodiment of the present invention;

[0061] Figure 6 This is a schematic diagram of the overall system installation and deployment process according to an embodiment of the present invention;

[0062] Figure 7 This is a schematic diagram of the structure of a deployment device that supports multiple operating system architectures, as provided in an embodiment of the present invention.

[0063] Figure 8 This is a terminal structure block diagram that implements the deployment method supporting multiple operating system architectures according to embodiments of the present invention. Detailed Implementation

[0064] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0065] To address the aforementioned problems, this invention proposes a deployment method, apparatus, electronic device, and medium that supports multiple operating system architectures, thereby resolving issues such as the inability of related installation methods to support multiple architectures, slow installation, complex configuration, and susceptibility to installation interruptions. A detailed description follows.

[0066] According to embodiments of the present invention, a deployment method supporting multiple operating system architectures is provided, combined with... Figure 1 The method includes:

[0067] Step S101: Automatically detect the physical architecture and match the boot file;

[0068] Step S103: Physical architecture matching; based on the matching result, call the corresponding architecture boot file.

[0069] Step S105: Start and mount the memory file system installation environment, and perform disk partitioning;

[0070] Step S107: Install and deploy the file system;

[0071] Step S109: After the system deployment is completed, perform subsequent configurations to complete the installation and enter the normal system.

[0072] The above steps will now be described in more detail with reference to a more specific embodiment.

[0073] Example 1

[0074] According to an embodiment of the present invention, a deployment method supporting multiple operating system architectures is provided, comprising:

[0075] Figure 2 This demonstrates the creation of an ISO image that supports rapid installation and deployment across multiple architectures. The main processes include building the installation boot environment, constructing the system root file system based on the installation package list, integrating other ISO components, and finally generating an ISO system installation image that supports multiple architectures. Specifically:

[0076] like Figure 3As shown, the method for creating multi-architecture boot files involves first using the Debian-Installer tool to build basic installation boot environment components based on the GRUB environment, including files such as grubx64.efi, vmlinuz, and initrd.gz. Then, based on an arm64 chroot environment or an arm64 Docker container environment, an arm64 architecture installation boot file is built. Next, an efi.img file is created using the dd tool and formatted as vfat. Then, a mount directory called build is created, and efi.img is mounted to the build directory. The built grubx64.efi and grubaa64.efi files are then copied into the build directory. After copying, the build directory is unmounted, completing the creation of the efi.img multi-architecture boot file.

[0077] like Figure 4 As shown, the method for creating the root file system for each architecture is as follows: First, a file system block is constructed using the dd tool, and then formatted and mounted. For example, in this case, the file system block name is ext.img. Then, it is formatted as an ext3 / ext4 file system.

[0078] First, create the mount directory `mount_dir` and execute `mount -t ext3 / ext4 ext.img mount_dir` to mount the file system blocks. Next, set the package list (`package_list`) required for system installation, and use the `debootstrap` tool to pull packages from the package repository and install them into the `mount_dir` directory. The specific commands are as follows:

[0079] qemu-debootstrap --arch=x86_64 or arm64 include="package_list" --no-check-gpg --keyring= / usr / share / keyings / xxx.gpg sources_url.

[0080] After completing the root file system construction, the root file system is then compressed into a directly mountable squashfs format file using the mksquashfs tool. The specific command is: mkdquashfs ext.img root.img-comp xz-b131072.

[0081] The xz compression algorithm is used to improve the file compression rate, and finally the root file system of each architecture is created.

[0082] After completing the above component construction, combining the modified GRUB component and other main components required for the ISO image, the complete ISO image is created using the following command: `xorriso-asmkisofs xxx -e boot / grub / efi.img xxx`. The `efi.img` file is... Figure 2 The example shown is a bootloader that supports multiple architectures.

[0083] One embodiment of the present invention provides a method for rapid deployment of Linux systems supporting multiple architectures, the main process of which is as follows: Figure 6 As shown, the specific steps are as follows:

[0084] In step S1, the ISO image file of the operating system to be deployed on the machine to be installed (x86_64, arm64, etc.) is prepared. The hardware device is powered on and started, and the system installation boot process is entered (by default, arm64 and other architectures only support UEFI). After finding the ISO image file, the x86_64 architecture machine will read grubx64.efi by default, and the arm64 architecture machine will read grubaa64.efi file, and enter the grub initialization boot judgment stage.

[0085] In step S2, hardware architecture matching is automatically performed. By modifying the grub2 component to support multi-architecture boot logic, the CPUID assembly instruction is called through the cpuid() interface to read the processor architecture and model information of the hardware device, and then the current hardware architecture is matched and determined. If the hardware architecture is x86_64, the grub-x64.cfg file is loaded; if the hardware architecture is arm64, the grub-arm64.cfg file is loaded. The grub-x64.cfg and grub-arm64.cfg files will load the corresponding architecture's vmlinuz kernel image and initrd.gz (ram temporary root file system) into memory.

[0086] In step S3, the custom installer first reads the physical memory size through the kernel interface and compares it with the ISO image size. Then, it mounts the ISO image based on the comparison result. For example, in this embodiment, the physical memory is 16G and the ISO multi-architecture image is 4.5G. If the physical memory size is greater than the image size, then proceed to step S4; otherwise, proceed to step S5.

[0087] In step S4, the installer will copy the ISO image into memory using the dd method (which normally takes tens of seconds) and pop up a window prompting that the installation media can be removed. Then, after mounting the ISO image, the installation will continue and proceed to step S6. If mounting fails, the error message will be displayed in step S14.

[0088] In step S5, if the physical memory is smaller than the ISO image size, the installer will directly mount the ISO image and continue the installation, proceeding to step S6. If mounting fails, proceed to step S14.

[0089] Steps S3 to S5 can, to some extent, prevent installation failures caused by accidental disconnection of the installation media or interruption of the installation process. This phenomenon is relatively easy to occur in actual application scenarios. By using this method, the time wasted caused by such errors and installation abnormalities can be effectively reduced.

[0090] In step S6, the installer will perform a series of configuration and driver loading operations to ensure that devices such as disks can be recognized normally. If the disk device can be recognized normally after loading the disk drive, proceed to step S7. If the disk device cannot be recognized, proceed to step S14 with a failure message.

[0091] In step S7, a prompt will appear to perform a disk partitioning operation. First, the partitioning recipe file will be read, and then the process will proceed to step S8.

[0092] In step S8, the installer will perform a validity check on the partition recipe. The validity check rules are as follows:

[0093] 1) There is a root partition and a / boot / efi partition.

[0094] 2) In the partition recipe, the boot partition should be greater than 512M, the / boot / efi partition should be greater than 200M, and the root partition should be greater than 5G.

[0095] 3) The / boot partition and the / boot / efi partition cannot be logical volumes.

[0096] If all the above rules are met, proceed to S9; otherwise, a message indicating that the partition recipe is invalid will pop up and you will be redirected back to step S8 to recheck the validity of the recipe file you filled in.

[0097] In step S9, the partitioning module will format the specific partition table information according to the partition recipe and perform the partition formatting operation. The partition table information includes: partition size (percentage or fixed size), file system type, mount point, etc. In this example, the partition table information format is mainly as follows:

[0098] 30% ext4 /

[0099] 40% ext4 / home ...

[0101] The main logic of partitioning is as follows: Figure 5 .

[0102] The formatting operation performs partitioning and formatting operations according to the partition table information by calling commands such as fdisk. After formatting is completed, step S10 is entered to deploy the root file system. If formatting fails, step S14 with error message is entered.

[0103] In step S10, all preparations for system deployment have been completed, and the system deployment phase begins. During system deployment, a temporary mount directory ` / rootfs` is first created based on the partition table information obtained in step S10. Then, the partition table information is mounted sequentially to the ` / rootfs` directory according to a tree structure. In this example, the partition table information is as follows:

[0104]

[0105]

[0106] First, mount the root partition to the / rootfs directory. Then, create the relevant mount directories in the / rootfs directory and mount the / home, / boot / , and / boot / efi partitions to the root partition's subdirectories.

[0107] Secondly, the dmicode command is invoked to obtain the current architecture, and the root file system in the ISO image is directly mounted (two mounts, one for the squashfs file system and one for the ext.img file). In this embodiment, the root file system is mounted to / mnt. Then, it is compared to determine whether the disk space meets the size requirements of the root file system. If the size does not meet the requirements, the synchronous copy operation is stopped and the process proceeds to step S14. If the size meets the requirements, the contents of / mnt are synchronously copied to the / rootfs directory using the rsync command. After the synchronization is completed, if no copying errors occur, the root file system in the ISO image is unmounted and the process proceeds to step S11. Otherwise, the process proceeds to step S14 with an error message.

[0108] In step S11, the system deployment is complete, and the system configuration phase begins. First, the relevant memory file systems of the installation environment are bound and mounted to the target system's / rootfs, including file systems such as proc, dev, sys, efivars, and run. Then, the chroot command is executed to switch the current running environment to the / rootfs target system environment. Based on the partition table information and partition UUIDs, the target system's fstab file is updated. At the same time, this part can also provide prompts for updating user account information. According to the prompts, the entered or preset account information is updated to the target system. The account information mainly includes home directory creation, shell specification, group, password, and other information updated to the target system.

[0109] After the above configuration is completed, the grub2 bootloader will be installed to the target system, and the grub.cfg boot menu of the target system will be updated. Then, the efibootmgr command will be used to update the BIOS firmware boot entries. The specific command content is as follows:

[0110] efibootmgr-cwL xxx-d / dev / xxx-pl.

[0111] If all the above installations are completed normally, the system deployment will proceed to step S12, the final stage; otherwise, step S14 will be displayed with an error message.

[0112] In step S12, the configuration phase of system deployment has been completed in step S11. In step S12, environment cleanup will be performed, including uninstalling the target system, and then the "Complete System Installation and Deployment" button will be clicked to enter the restart phase. The restart will allow the system to enter the deployed system normally.

[0113] In step S14, the installer will provide prompts based on the specific error type and cause. Clicking "OK" will proceed to step S15 to abort the installation.

[0114] In step S15, the installation program will perform an abort operation;

[0115] The above is a detailed description of the implementation process and steps of an embodiment of the present invention.

[0116] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better 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 storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0117] Example 2

[0118] According to embodiments of the present invention, a rapid deployment apparatus supporting multi-architecture systems is provided, combined with Figure 7 ,include:

[0119] Boot file matching unit 21 is used to automatically detect the physical architecture and match the boot file;

[0120] The boot file calling unit 23 is used for physical architecture matching and calls the corresponding architecture boot component based on the matching result.

[0121] Partition unit 25 is used to boot and mount the memory file system installation environment and perform disk partitioning;

[0122] Installation and deployment unit 27 is used for file system installation and deployment;

[0123] Configuration unit 29 is used to perform subsequent configurations after system deployment is completed, so that the installation is completed and the system can enter normal operation.

[0124] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0125] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should also be noted that the above modules, as part of the device, can run in a corresponding hardware environment, and can be implemented through software or hardware, wherein the hardware environment includes a network environment.

[0126] Figure 8 This is a structural block diagram of a terminal according to an embodiment of this application, such as... Figure 8 As shown, the terminal may include: one or more (only one is shown) processors 101, memory 103, and transmission devices 105, such as... Figure 8 As shown, the terminal may also include input / output devices 107.

[0127] The memory 103 can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in this embodiment. The processor 101 executes various functional applications and data processing by running the software programs and modules stored in the memory 103, thereby implementing the above-described methods. The memory 103 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 103 may further include memory remotely located relative to the processor 101, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0128] The aforementioned transmission device 105 is used to receive or send data via a network, and can also be used for data transfer between the processor and memory. Specific examples of the network described above may include wired networks and wireless networks. In one example, the transmission device 105 includes a Network Interface Controller (NIC), which can be connected to other network devices and routers via a network cable to communicate with the Internet or a local area network. In another example, the transmission device 105 is a radio frequency (RF) module, used for wireless communication with the Internet.

[0129] Specifically, memory 103 is used to store application programs.

[0130] The processor 101 can call the application stored in the memory 103 through the transmission device 105 to perform the following steps: automatically detect the physical architecture and match the boot file; physical architecture matching, and call the corresponding architecture boot file according to the matching result; start and mount the memory file system installation environment, and perform disk partitioning; perform file system installation and deployment; after the system deployment is completed, perform subsequent configuration, thereby completing the installation and entering the normal system.

[0131] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0132] Those skilled in the art will understand that the structure of the terminal described above is merely illustrative, and the terminal can be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile internet device (MID), a PAD, or other terminal devices. Figure 8 This does not limit the structure of the aforementioned electronic device. For example, the terminal may also include components that are more... Figure 8 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 8 The different configurations shown.

[0133] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0134] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to execute program code for the above-described method.

[0135] Optionally, in this embodiment, the storage medium may be located on at least one of the multiple network devices in the network shown in the above embodiment.

[0136] Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: automatically detecting the physical architecture and matching the boot file; physical architecture matching, and calling the corresponding architecture boot file according to the matching result; starting and mounting the memory file system installation environment, and performing disk partitioning; performing file system installation and deployment; after the system deployment is completed, subsequent configuration is performed, thereby completing the installation and entering the normal system.

[0137] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0138] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0139] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0140] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0141] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0142] In the embodiments provided in this application, the described device embodiments are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces, indirect couplings, or communication connections between units or modules, and may be electrical or other forms.

[0143] The units described as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0144] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0145] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A deployment method supporting multiple operating system architectures, characterized in that, include: Automatically detects the physical architecture and matches the boot files; Physical architecture matching; based on the matching result, the corresponding architecture boot file is invoked. Start and mount the memory file system installation environment, and perform disk partitioning; Perform file system installation and deployment; After the system deployment is complete, perform subsequent configurations to complete the installation and enter the normal system. The automatic detection of physical architecture and matching of boot files includes creating efi.img files that support multiple architectures; The process of creating a multi-architecture efi.img file includes: Build EFI boot files separately for each architecture; Create an EFI boot file (efi.img) that supports multiple architectures; Combine the efi.img file into the ISO image.

2. The deployment method supporting multiple operating system architectures according to claim 1, characterized in that, The physical architecture matching involves calling the corresponding architecture boot file based on the matching result, including: Obtain the processor architecture and model of the current hardware environment; During the startup phase, a matching check is performed, and the corresponding architecture's boot file is invoked.

3. The deployment method supporting multiple operating systems according to claim 1, characterized in that, The process of starting and mounting the memory file system installation environment and partitioning the disk includes: Load the kernel and the initial root filesystem, and initialize them; Determine the machine's physical memory size. If the physical memory size is greater than the ISO image size, copy the ISO image content to memory and mount it. If the physical memory size is less than the ISO image size, mount it directly. According to the formula document, confirm the partitioning method and perform a validity judgment and analysis of the partition size; the partitioning method is configured as one or more of the following: automatic percentage partitioning mode, automatic fixed size partitioning mode, manual percentage partitioning mode, and manual fixed size partitioning mode; The parsed partition recipe is formatted into a partition size that the system can recognize, and the mount point is recorded to form a partition table.

4. The deployment method supporting multiple operating system architectures according to claim 3, characterized in that, The process of installing and deploying the file system includes: Based on the partition table content, the entire disk partition is mounted in a tree structure. By default, the root partition is mounted first, and then the other partitions are mounted sequentially to the tree directory structure where the root partition is located. Directly mount the root file system of each architecture and synchronously copy the content to the target system.

5. The deployment method supporting multiple operating systems according to claim 4, characterized in that, The methods for creating the root file systems of each architecture include: Build a file system block, and format and mount the file system block; Set the package list, which is obtained from the default ISO image installation list; pull packages from the package source to build the root file system; Clean up the root file system environment and compress and package the root file system; Combine the root file system image into the ISO image.

6. A deployment device supporting multiple operating system architectures, characterized in that, include: The boot file matching unit is used to automatically detect the physical architecture and match the boot file. The bootstrap component invocation unit is used for physical architecture matching and invokes the corresponding architecture bootstrap file based on the matching result; A partition unit is used to boot and mount the memory file system installation environment and perform disk partitioning; The installation and deployment unit is used for installing and deploying file systems. The configuration unit is used to perform subsequent configurations after system deployment, so that the installation is complete and the system can enter normal operation. The automatic detection of physical architecture and matching of boot files includes creating efi.img files that support multiple architectures; The process of creating a multi-architecture efi.img file includes: Build EFI boot files separately for each architecture; Create an EFI boot file (efi.img) that supports multiple architectures; Combine the efi.img file into the ISO image.

7. An electronic device, characterized in that, include: Processor and memory; The memory stores a computer-readable program that can be executed by the processor; When the processor executes the computer-readable program, it implements the steps of the method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs that can be executed by one or more processors to implement the steps of the method as described in any one of claims 1-5.

Images