Installation method of multi-architecture operating system, computer equipment, medium and product

Abstract

The invention discloses an installation method of a multi-architecture operating system, computer equipment, a medium and a product, and the method comprises the steps: loading a unified proxy EFI file as a unique boot entry of all architectures through a cross-architecture boot loader; loading and starting a native EFI boot file embedded in the unified proxy EFI file according to the device architecture of the current computer device; selecting and loading a mirror image file of the multi-architecture operating system in the mirror image file installation medium by utilizing the started native EFI boot file; and completing the operation system installation on the current computer equipment through the unified installation service in the mirror image file and deleting the unified installation service. The invention aims at solving the problems of framework diversification, installation complexity and guide file decentralization in the prior art, realizing EFI guide unified installation, realizing rapid automatic installation of various hardware frameworks such as x86, ARM, Loongson, RISC-V and the like, and improving the universality and efficiency of system deployment.

Description

Technical Field

[0001] This invention relates to the field of operating system installation and booting technology, and specifically to an installation method, computer equipment, media, and products for a multi-architecture operating system. Background Technology

[0002] With the rapid development of information technology, computer system architectures are becoming increasingly diversified, with the mainstream x86 architecture coexisting alongside the increasingly popular ARM, Loongson, and RISC-V architectures. Different architectures often require different boot EFI files, driver support, and system configurations during operating system installation, leading to complex and inconsistent installation processes. This is especially true for embedded devices, personal computers (PCs), domestically developed platforms (such as Phytium, Zhaoxin, and Loongson), and emerging RISC-V architecture devices, where the deployment and booting methods of operating systems like Linux differ significantly, lacking a universal boot and installation method.

[0003] Currently, PC platforms mostly use UEFI boot with a graphical installation process, while embedded devices often rely on serial port programming, dedicated programming tools, or SD card image writing. Loongson platforms require specific firmware support and customized images, while RISC-V devices are mostly under development, and installation methods are not yet standardized. This fragmented installation ecosystem leads to: low deployment efficiency (different platforms require different programming tools, boot methods, and configuration processes); high maintenance costs (IT support personnel need to prepare multiple sets of installation media and scripts for different devices); poor user experience (developers and end users find it difficult to get started quickly, especially facing significant obstacles when migrating across platforms); and low automation (existing solutions are mostly manual operations, unable to meet the needs of batch deployment and unattended scenarios).

[0004] While automated installation technologies such as PXE network booting, Kickstart, and AutoYaST exist, these solutions are typically limited to specific architectures or enterprise-level environments, and their deployment is complex, reliant on network services, and unsuitable for rapid deployment in heterogeneous environments. Furthermore, most installation processes rely on graphical interfaces, which are time-consuming and fail to meet the demands of rapid deployment. Some solutions cannot recognize eMMC hard drives or small-capacity storage devices and do not support general image burning tools like Ventoy, further limiting cross-scenario application. Crucially, different architectures correspond to independent boot files (e.g., bootx64.efi for x86_64, bootaa64.efi for ARM64, grubloongarch64.efi for Loongson, and grubriscv64.efi for RISC-V), requiring installers to adapt to different boot entry points for different architectures, thus preventing truly unified deployment.

[0005] Currently, operating system installation methods are mainly divided into manual and automatic installation. Manual installation requires users to select the boot device, configure the bootloader, partition, install the system and drivers according to the specific architecture, which is a complex and error-prone process that requires high technical skills from users. Automatic installation, such as PXE boot and vendor-customized tools, is usually only applicable to specific architectures or devices, lacks universality, and is complex to deploy and configure, making troubleshooting difficult. In addition, different architecture devices have different boot methods (such as UEFI, Legacy, device tree, etc.), storage media (such as SATA, NVMe, eMMC, SD card, etc.), and driver support, making it difficult to unify existing installation methods. The core problem is that the EFI boot files for different architectures are independent of each other. The operating system needs to deploy corresponding EFI files for x86, ARM64, Loongson, RISC-V, etc., making it impossible to achieve a unified installation boot. Most installation tools do not support cross-architecture compatibility, and the installation process is mostly graphical interface, which is time-consuming and cannot meet the needs of rapid, batch deployment. Some installation tools on the market do not support emerging architectures (such as RISC-V and Loongson) well, and image burning tools have poor compatibility, which further increases the difficulty and complexity of system installation. Summary of the Invention

[0006] The technical problem to be solved by this invention is to provide a method for installing a multi-architecture operating system, computer equipment, media, and products, addressing the aforementioned problems in the prior art. This invention aims to solve the problems of diversified architectures, complex installation, and scattered boot files in the prior art, to achieve unified EFI boot installation, and to enable rapid and automatic installation of various hardware architectures such as x86, ARM, Loongson, and RISC-V, thereby improving the versatility and efficiency of system deployment.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for installing a multi-architecture operating system includes the following steps: S101, The UEFI firmware of the current computer device loads and starts the unified agent EFI file; S102, the unified agent EFI file executes the built-in cross-architecture bootloader, which loads and starts the native EFI boot file embedded in the unified agent EFI file according to the current computer device's device architecture. The unified agent EFI file embeds native EFI boot files for all architectures supported by multi-architecture operating systems. S103 uses the native EFI boot file to select the installation media and load the image file from the installation media; S104 automatically installs the operating system on the current computer device using the unified installation service in the image file, and then deletes the unified installation service after installation.

[0008] Optionally, the unified agent EFI file consists of a file header, a native image file, and an architecture index table. The file header is used as a file type identifier and to indicate the location of the native image file and the architecture index table. The native image file includes native EFI boot files for all architectures supported by the multi-architecture operating system. Each entry in the architecture index table includes the architecture name, the file size of the native EFI boot file, and its base address in the native image file.

[0009] Optionally, the generation of the unified agent EFI file includes: S201, obtain the native EFI boot files for all architectures supported by the multi-architecture operating system, and obtain the file size of the native EFI boot files for each architecture; S202 merges the native EFI boot files of all architectures supported by the multi-architecture operating system to generate a native image file, and records the base address of the native EFI boot files of each architecture in the native image file; S203, Generate an architecture index table based on the native EFI boot files of all architectures supported by the multi-architecture operating system. Each entry in the architecture index table includes the architecture name, the file size of the native EFI boot file, and its base address in the native image file. S204, Generate the header of the unified agent EFI file. The header is used as a file type identifier and to indicate the location of the native image file and the architecture index table. The header, native image file and architecture index table of the unified agent EFI file are packaged together to obtain the unified agent EFI file.

[0010] Optionally, in step S102, loading and starting the native EFI boot file embedded in the unified agent EFI file according to the device architecture of the current computer device via a cross-architecture bootloader includes: S301 reads the header of the unified agent EFI file and locates the native image file and architecture index table in the unified agent EFI file based on the information in the header. S302, call the UEFI application programming interface API to detect the current computer device architecture; S303, retrieve the architecture name from each entry in the architecture index table of the current computer device's architecture to obtain the file size of the corresponding native EFI boot file in the matching entry and its base address in the native image file; S304: Based on the file size of the native EFI boot file and its base address in the native image file, load the corresponding native image file in the unified agent EFI file into memory and jump to execute the native image file.

[0011] Optionally, before step S101, the UEFI firmware may be recompiled to adapt to the current computer device: the source code of the UEFI firmware of the current computer device is modified according to the UEFI firmware development framework, the source code of the boot device selection module and related libraries of the boot device selection module in the source code of the UEFI firmware is modified, and the code that loads the native EFI boot file is modified to load a unified proxy EFI file to achieve a single unified proxy EFI file to adapt to all architectures; then the source code of the UEFI firmware is compiled to generate UEFI firmware and written to the current computer device.

[0012] Optionally, when the unified installation service in the image file automatically starts and completes the installation of the operating system on the current computer device in step S104, it also includes using the installer to detect whether there is a user-customized script and installation configuration file. If there is a user-customized script and installation configuration file, the user-customized script and installation configuration file are used to achieve automatic response during the installation process or automatic configuration after installation, thereby achieving one-click automatic installation of the operating system without user interaction.

[0013] Optionally, the unified agent EFI file may embed native EFI boot files for all architectures supported by multi-architecture operating systems, including native EFI boot files for some or all of the x86_64, arm64, LoongArch64, and RISC-V64 architectures.

[0014] The present invention also provides a computer device including a microprocessor and a memory interconnected thereto, the microprocessor being programmed or configured to execute the installation method of the multi-architecture operating system.

[0015] The present invention also provides a computer-readable storage medium storing a computer program or instructions that are programmed or configured to execute the installation method of the multi-architecture operating system by a processor.

[0016] The present invention also provides a computer program product, including a computer program or instructions that are programmed or configured to execute the installation method of the multi-architecture operating system via a processor.

[0017] Compared with existing technologies, the present invention mainly achieves the following beneficial effects: The multi-architecture operating system installation method of the present invention focuses on unified adaptation across all architectures and unified EFI booting. Based on the traditional operating system installation steps, it adds a unified proxy EFI file and automatic architecture identification and adaptation logic, while retaining the ability for rapid automatic installation. In particular, the introduction of a unified proxy EFI file serves as the sole boot entry point for all architectures, replacing the traditionally scattered boot files for various architectures such as bootx64.efi, bootaa64.efi, and grubloongarch64.efi. This invention provides a multi-architecture operating system installation method that loads a unified proxy EFI file through a cross-architecture bootloader and automatically identifies the current device architecture. Then, it loads the corresponding native boot file for the architecture, enabling a single EFI file to adapt to all architectures. This achieves unified EFI boot installation, enabling rapid and automatic installation of various hardware architectures such as x86, ARM, Loongson, and RISC-V. This improves the versatility and efficiency of system deployment, thereby solving the problems of inconsistent operating system installation methods across different hardware architectures, complex installation processes, low automation, poor compatibility, and scattered boot files (requiring adaptation to multiple EFI files) in existing technologies. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the basic process of the method in an embodiment of the present invention.

[0019] Figure 2 This is a schematic diagram of the structure of the unified proxy EFI file in an embodiment of the present invention.

[0020] Figure 3 This is a schematic diagram of the workflow of the cross-architecture bootloader in an embodiment of the present invention.

[0021] Figure 4 This is a schematic diagram of the operating system structure in the image file of an embodiment of the present invention.

[0022] Figure 5 This is a schematic diagram illustrating the complete installation process of the operating system in an embodiment of the present invention.

[0023] Figure 6 This is a schematic diagram of the workflow of the unified installation service in an embodiment of the present invention. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions of the present invention, the technical solutions of the present invention will be further described in detail below with reference to the accompanying drawings in the embodiments of the present invention.

[0025] like Figure 1 As shown, the installation method of the multi-architecture operating system in this embodiment includes the following steps: S101, the UEFI firmware of the current computer device loads and starts the unified agent EFI file. As an optional implementation, in this embodiment, the unified agent EFI file is named boot-unified.efi; S102, the unified agent EFI file executes the built-in cross-architecture bootloader, which loads and starts the native EFI boot file embedded in the unified agent EFI file according to the current computer device's device architecture. The unified agent EFI file embeds native EFI boot files for all architectures supported by multi-architecture operating systems. S103 uses the native EFI boot file to select the installation media and load the image file from the installation media; S104 automatically installs the operating system on the current computer device using the unified installation service in the image file, and then deletes the unified installation service after installation.

[0026] like Figure 2 As shown, the unified proxy EFI file (boot-unified.efi file) in this embodiment consists of a file header, a native image file, and an architecture index table. The file header serves as a file type identifier and indicates the location of the native image file and the architecture index table. The native image file includes native EFI boot files for all architectures supported by the multi-architecture operating system. Each entry in the architecture index table includes the architecture name, the file size of the native EFI boot file, and its base address within the native image file. Figure 2 As shown, the unified agent EFI file embeds native EFI boot files for all architectures supported by multiple operating systems, including some or all of the x86_64, arm64, LoongArch64, and RISC-V64 architectures. Figure 2 The native image file includes native EFI boot files for all architectures supported by the multi-architecture operating system, represented as: x86_64 image file, arm64 image file, LoongArch64 image file, and RISC-V64 image file; the architecture index table has four corresponding entries, represented as: x86_64 + offset + size, arm64 + offset + size, LoongArch64 + offset + size, and RISC-V64 + offset + size.

[0027] In this embodiment, the generation of the unified proxy EFI file includes: S201, obtain the native EFI boot files for all architectures supported by the multi-architecture operating system, and obtain the file size of the native EFI boot files for each architecture; S202 merges the native EFI boot files of all architectures supported by the multi-architecture operating system to generate a native image file, and records the base address of the native EFI boot files of each architecture in the native image file; S203, Generate an architecture index table based on the native EFI boot files of all architectures supported by the multi-architecture operating system. Each entry in the architecture index table includes the architecture name, the file size of the native EFI boot file, and its base address in the native image file. S204, Generate the header of the unified agent EFI file. The header is used as a file type identifier and to indicate the location of the native image file and the architecture index table. The header, native image file and architecture index table of the unified agent EFI file are packaged together to obtain the unified agent EFI file.

[0028] Specifically, this embodiment constructs a tool called `create_fat_binary` to synthesize a unified proxy EFI file (boot-unified.efi). This tool merges native boot EFI files (such as `bootx64.efi`) from x86_64, arm64, LoongArch64, and RISC-V64 architectures into a single `boot-unified.efi` file, consisting of a file header, a native image file, and an architecture index table. Architecture matching is achieved through metadata. The `create_fat_binary` tool is implemented in Python, and its function format is as follows: The core logic of the boot-unified.efi file synthesis tool includes: defining the header structure, the entry structure of the architecture index table, and the native architecture EFI file, through... create_fat_binary(output_path, efi_files); Where output_path is the output path, and efi_files is a list of native boot EFI files for x86_64, arm64, LoongArch64, and RISC-V64. The EFI files of multiple architectures are merged into a unified proxy EFI file and output to the specified output path output_path.

[0029] like Figure 3 As shown, in step S102 of this embodiment, the native EFI boot file embedded in the unified agent EFI file is loaded and started by the cross-architecture bootloader according to the device architecture of the current computer device, including: S301 reads the header of the unified agent EFI file and locates the native image file and architecture index table in the unified agent EFI file based on the information in the header. S302, call the UEFI application programming interface API to detect the current computer device architecture; S303, retrieve the architecture name from each entry in the architecture index table of the current computer device's architecture to obtain the file size of the corresponding native EFI boot file in the matching entry and its base address in the native image file; S304: Based on the file size of the native EFI boot file and its base address in the native image file, load the corresponding native image file in the unified agent EFI file into memory and jump to execute the native image file.

[0030] The cross-architecture bootloader in this embodiment is written based on EBC (EFI bytecode). Its main structures include a Header and an index table structure FAT_HEADER, and an architecture type and offset size structure FAT_ENTRY. The main function of the cross-architecture bootloader, EbcLoaderMain, is defined as follows: ; Here, `EFI_STATUS` represents the returned status, `EFI_HANDLE ImageHandle` defines a unique handle to the currently running `boot-unified.efi` file in the UEFI system, and `EFI_SYSTEM_TABLE *SystemTable` defines a pointer to the UEFI system table (SystemTable), which is the "main entry point" for UEFI programs to access all core services. The core functions of the cross-architecture bootloader include functions for obtaining the base address and size of the EFI file itself and functions for reading the architecture index table. The format of the function `gBS->GetImageInfo` for obtaining the base address and size of the EFI file is as follows: ; Where ImageHandle is the unique handle of the currently running boot-unified.efi file in the UEFI system, &FileSize is the file size of the native EFI boot file, and &FatBinaryBase is the base address of the native EFI boot file in the native image file; the format for reading the corresponding native image file in the unified agent EFI file is: ; Here, Entries is a pointer defined by (FAT_ENTRY*), (UINT8*)FatBinaryBase is a forced conversion of FatBinaryBase to UINT8 format, and FatHeader.IndexTableOffset is a value obtained from the FatHeader structure with an offset of IndexTableOffset. FatBinaryBase is the base address of the native image file, and IndexTableOffset is the size of the native image file. When the firmware loads boot-unified.efi, it first executes a built-in small bootloader; the bootloader reads the Header and architecture index table to detect the current hardware architecture; it locates the EFI image segment corresponding to the architecture, loads it into memory, and jumps to execute it.

[0031] In this embodiment, before step S101, the UEFI firmware is recompiled to adapt to the current computer device: The source code of the UEFI firmware of the current computer device is modified according to the UEFI firmware development framework. This involves modifying the source code of the boot device selection module and its related libraries, changing the code that loads the native EFI boot file to load a unified proxy EFI file to achieve single unified proxy EFI file adaptation for all architectures. Then, the UEFI firmware source code is compiled to generate UEFI firmware and written to the current computer device. Specifically, in this embodiment, based on the UEFI firmware development framework EDK II logic, the loading process of boot files such as bootx64.efi, bootaa64.efi, and grubloongarch64.efi mainly focuses on the BDS (Boot Device Selection) module and related libraries. Adaptation to a unified architecture is achieved by modifying the paths of different architecture EFI files in MdePkg / Include / Library / BdsLib.h.

[0032] Taking the x86 architecture as an example, the macro definitions need to be:

[0033] Adjusted to: .

[0034] By recompiling and adapting the UEFI firmware for devices with different architectures using the methods described above, compatibility with the unified proxy EFI file can be achieved.

[0035] In this embodiment, the unified installation service (the service form of the system installer) is integrated into the image. It achieves automatic startup, automatic identification of architecture and hardware, loading of corresponding drivers and configurations, and automatic system installation through the form of a service. Figure 4 This is a schematic diagram of the operating system structure in the image file of this embodiment. The operating system in the image file includes installation media detection, installation program, architecture detection, system installation script, installation service, unified agent EFI file, keyboard access detection program, installation configuration file (optional), custom script (optional) and other programs.

[0036] In this embodiment, the image file construction includes: building a unified installation service (os-install.service) to enable the installer to start automatically; writing an architecture identification script (arch-detect) to automatically detect device architecture (x86 / ARM / RISC-V / Loongson, etc.) and storage type; designing a unified installation script (install) to support multi-architecture partitioning, bootloader installation, root file system copying, system configuration, etc.; and providing a user-defined configuration interface (install.cfg) and extended scripts (custom.sh) to meet personalized needs. The user's customized script and installation configuration file are obtained. The installation process is output in a character-based interface, displaying the installation progress in real time. After installation, the installation environment is automatically cleaned up to prevent duplicate installations. Furthermore, this embodiment supports multiple image burning tools such as Ventoy, Rufus, and UltraISO, and only requires integrating the unified installer into system images of different architectures to meet the requirements for automatic installation across all architectures. The design and implementation of the unified installation service in this embodiment includes: 1) creating a full-architecture installation service os-install.service, setting the service type Type to oneshot to ensure that the service runs only once during installation. The main function of this service is to launch the installation program. In the case of batch deployment of devices, it supports reading the unified configuration through the network, without the need for individual configuration of each device; 2) Create the system installation program. The installation program consists of four parts: the installation media judgment script media-check, the architecture detection script arch-detect, the system installation script install, and the keyboard access judgment program keyboard-judge. The installation media judgment script is mainly used to determine the installation boot media and the hard drive type of the device to be installed. The default setting for the installation media is USB, but PXE installation and optical drive installation are also supported. You can use "df -T | grep nfs" to determine whether it is a PXE boot installation, and use "ls / sys / block / | grep sr*.[0-9]" to determine whether it is an optical drive installation. In addition, this script can be used to detect the type of hard drive to be installed. By traversing the device blocks under the / sys / block / directory, it identifies the hard drive type (such as SATA, NVMe or eMMC) and filters out the installation media itself to prevent the installation media from being mistakenly identified as the hard drive to be installed. If the hard drive to be installed is not detected, the message "Installation hard drive does not exist" will be output on the screen. After successful detection, the script will invoke the system installation script. The architecture detection script is primarily used to identify the device architecture and match the corresponding driver and configuration. It determines the architecture type of the device to be installed by reading / proc / cpuinfo and / sys / devices / system / cpu / cpu0 / arch.

[0037] like Figure 5As shown, in this embodiment, when the unified installation service in the image file automatically starts and completes the installation of the operating system on the current computer device in step S104, it also includes using the installer to detect whether there is a user's customized script and installation configuration file. If there is a user's customized script and installation configuration file, the user's customized script and installation configuration file are used to realize automatic response during the installation process or automatic configuration after installation, thereby realizing one-click automatic installation of the operating system without user interaction.

[0038] like Figure 6As shown, the unified installation service in this embodiment is mainly used for the actual actions of image installation, which is consistent with the conventional Linux system installation method. The difference is the addition of logic related to "automatic configuration" and "execution of customized scripts". ① Configurations such as partitions, time zones, languages, users, and hostnames have default values ​​in the installation script, and can also be customized through the file install.cfg, which is read by the installation script to meet personalized configuration needs. When custom installation configuration is required, install.cfg can be integrated into the root directory of the image. This method makes it easy to modify the configuration directly on a writable boot disk without repeatedly creating and burning images. ② When some customization requirements cannot be integrated into the image by default, additional customization can be achieved through the customization script custom.sh. The customization script is integrated into the root directory of the image. The image root directory is mounted to the rootfs using "mount --bind / cdrom $rootfsdir / cdrom", and then chrooted to the rootfs to execute the customization script. If the customization script does not exist, it will not be executed, increasing the extensibility of image installation. The keyboard access detection program is mainly used to determine whether a keyboard is plugged in. It can be determined by "lsusb |grep -i keyboard". After installation, type "Y" to restart the device. The system installation service, installer, installation configuration (optional), and custom scripts (optional) are integrated into the image filesystem.squashfs, and the unified installation service os-install.service is set to enable by default to start automatically at boot, ensuring that the system boots into the installation program by default and automatically completes the system installation. This method is a live installation boot, supporting various methods such as Ventoy, Rufus, and UltraISO for burning bootable disks. The unified agent EFI file is integrated into the image file; boot-unified.efi is located in the image file's directory structure as: EFI / BOOT / boot-unified.efi. Furthermore, this embodiment includes adding the installation boot parameter console=ttyAMA0, and the installer uses "echo -e>> / dev / tty0" to ensure that the entire installation process information is output to the screen as characters. After installation, a prompt will appear to connect a keyboard and remove the installation media; then, type a specific character to restart the device.

[0039] In summary, the key points of the multi-architecture operating system installation method in this embodiment are: 1. Introducing a unified proxy EFI file (unified-boot.efi) to achieve a single boot entry point for multiple hardware architectures such as x86, ARM, Loongson, and RISC-V, replacing the traditional scattered EFI files; 2. Achieving unified automatic installation across multiple architectures; simply integrating the unified installer into system images of different architectures is sufficient to meet the requirements for automatic installation across all architectures; 3. Enabling rapid and automatic installation of the operating system, reducing installation time and improving installation efficiency; 4. Simple installation configuration, supporting custom installation configurations and content, satisfying the needs of all architectures. 5. Simple installation display with character output to the screen, allowing real-time monitoring of the installation process; 6. Supports Linux operating system installation on various types of small-capacity hard drives; 7. Supports multiple image burning tools for creating image bootloaders, eliminating the need to adjust burning parameters for different architectures; 8. Automatically identifies device architecture and installation boot method, adapting to different hardware environments, and the unified proxy EFI has architecture adaptive loading capabilities; 9. Universal and easily expandable design, suitable for various device types such as embedded systems, PCs, and servers. When adding a new architecture, only the corresponding version of the proxy EFI and native boot files need to be added, without modifying the installer's core logic. This embodiment's multi-architecture operating system installation method has broad versatility and practicality, applicable to various architecture devices such as x86, ARM, RISC-V, and Loongson. The core advantage lies in solving the pain point of scattered boot files in traditional solutions through the "unified proxy EFI boot layer," achieving "installation adaptation to multiple architectures, one EFI for full adaptation." By integrating the unified installation service, architecture identification script, installer, unified proxy EFI, and native boot files for each architecture into a single image, the installer is unified. The installation process uses a character-based interface, making it simple, efficient, and quick, significantly improving system deployment efficiency. By simply integrating the unified installer into system images of different architectures, full architecture compatibility can be achieved, reducing image creation and maintenance costs. Users can flexibly adjust the installation content through configuration files or custom scripts to meet personalized needs in different scenarios. This embodiment's multi-architecture operating system installation method supports various burning tools and storage media, facilitating creation and use, and is particularly suitable for scenarios such as batch deployment of multi-architecture devices, rapid system recovery, educational experiments, and the promotion of domestic platforms. This embodiment's multi-architecture operating system installation method has advantages such as fast installation, strong versatility, simple operation, and easy expansion. It particularly solves the core problem of complex boot file adaptation in cross-architecture installation, which is of great value to users unfamiliar with multi-architecture system installation and to enterprises and organizations that wish to achieve unified system deployment.

[0040] Furthermore, this embodiment also provides a computer device including a microprocessor and a memory interconnected, the microprocessor being programmed or configured to execute the installation method of the multi-architecture operating system. This embodiment also provides a computer-readable storage medium storing a computer program or instructions programmed or configured to execute the installation method of the multi-architecture operating system via a processor. This embodiment also provides a computer program product including a computer program or instructions programmed or configured to execute the installation method of the multi-architecture operating system via a processor.

[0041] Those skilled in the art will understand that the technical solutions provided by this invention may take the form of a method, system, or computer program product. Therefore, this invention may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this invention may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce an implementation of the flowchart... Figure 1 One or more processes and / or boxes Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0042] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A method for installing a multi-architecture operating system, characterized in that, Includes the following steps: S101, The UEFI firmware of the current computer device loads and starts the unified agent EFI file; S102, the unified agent EFI file executes the built-in cross-architecture bootloader, which loads and starts the native EFI boot file embedded in the unified agent EFI file according to the current computer device's device architecture. The unified agent EFI file embeds native EFI boot files for all architectures supported by multi-architecture operating systems. S103 uses the native EFI boot file to select the installation media and load the image file from the installation media; S104 automatically installs the operating system on the current computer device using the unified installation service in the image file, and then deletes the unified installation service after installation.

2. The installation method for a multi-architecture operating system according to claim 1, characterized in that, The unified agent EFI file consists of a file header, a native image file, and an architecture index table. The file header is used as a file type identifier and to indicate the location of the native image file and the architecture index table. The native image file includes native EFI boot files for all architectures supported by the multi-architecture operating system. Each entry in the architecture index table includes the architecture name, the file size of the native EFI boot file, and its base address in the native image file.

3. The installation method for a multi-architecture operating system according to claim 2, characterized in that, The generation of the unified agent EFI file includes: S201, obtain the native EFI boot files for all architectures supported by the multi-architecture operating system, and obtain the file size of the native EFI boot files for each architecture; S202 merges the native EFI boot files of all architectures supported by the multi-architecture operating system to generate a native image file, and records the base address of the native EFI boot files of each architecture in the native image file; S203, Generate an architecture index table based on the native EFI boot files of all architectures supported by the multi-architecture operating system. Each entry in the architecture index table includes the architecture name, the file size of the native EFI boot file, and its base address in the native image file. S204, Generate the header of the unified agent EFI file. The header is used as a file type identifier and to indicate the location of the native image file and the architecture index table. The header, native image file and architecture index table of the unified agent EFI file are packaged together to obtain the unified agent EFI file.

4. The method for installing a multi-architecture operating system according to claim 2, characterized in that, In step S102, the native EFI boot file embedded in the unified agent EFI file is loaded and started by the cross-architecture bootloader according to the current computer device's device architecture. This includes: S301 reads the header of the unified agent EFI file and locates the native image file and architecture index table in the unified agent EFI file based on the information in the header. S302, call the UEFI application programming interface API to detect the current computer device architecture; S303, retrieve the architecture name from each entry in the architecture index table of the current computer device's architecture to obtain the file size of the corresponding native EFI boot file in the matching entry and its base address in the native image file; S304: Based on the file size of the native EFI boot file and its base address in the native image file, load the corresponding native image file in the unified agent EFI file into memory and jump to execute the native image file.

5. The method for installing a multi-architecture operating system according to claim 1, characterized in that, Before step S101, the UEFI firmware is recompiled to adapt to the current computer device: the source code of the UEFI firmware of the current computer device is modified according to the UEFI firmware development framework, the source code of the boot device selection module and the related libraries of the boot device selection module in the UEFI firmware source code is modified, and the code that loads the native EFI boot file is modified to load the unified proxy EFI file so as to achieve a single unified proxy EFI file to adapt to all architectures. Then, the UEFI firmware source code is compiled to generate UEFI firmware and written to the current computer device.

6. The method for installing a multi-architecture operating system according to claim 1, characterized in that, In step S104, when the unified installation service in the image file is automatically started to complete the installation of the operating system on the current computer device, the installation program is also used to detect whether there is a user-customized script and installation configuration file. If there is a user-customized script and installation configuration file, the user-customized script and installation configuration file are used to realize automatic response during the installation process or automatic configuration after installation, thereby realizing one-click automatic installation of the operating system without user interaction.

7. The method for installing a multi-architecture operating system according to claim 2, characterized in that, The unified agent EFI file embeds native EFI boot files for all architectures supported by multi-architecture operating systems, including some or all of the native EFI boot files for x86_64, arm64, LoongArch64, and RISC-V64 architectures.

8. A computer device comprising a microprocessor and a memory interconnected, characterized in that, The microprocessor is programmed or configured to execute the installation method of the multi-architecture operating system according to any one of claims 1 to 7.

9. A computer-readable storage medium storing a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute, via a processor, the method for installing the multi-architecture operating system as described in any one of claims 1 to 7.

10. A computer program product, comprising a computer program or instructions, characterized in that, The computer program or instructions are programmed or configured to execute, via a processor, the method for installing the multi-architecture operating system as described in any one of claims 1 to 7.

Images