CN118939325A

CN118939325A - A method, device and computing device for starting an operating system

Info

Publication number: CN118939325A
Application number: CN202410944142.7A
Authority: CN
Inventors: 曹中委
Original assignee: XFusion Digital Technologies Co Ltd
Current assignee: XFusion Digital Technologies Co Ltd
Priority date: 2024-07-12
Filing date: 2024-07-12
Publication date: 2024-11-12

Abstract

The application provides a method and a device for starting an operating system and computing equipment, and relates to the technical field of computers. The method comprises the steps of acquiring equipment information of in-place hardware equipment in the computing equipment in a starting stage of the computing equipment; determining a target operating system corresponding to the equipment information based on a preset mapping relation; the method comprises the steps that a preset mapping relation in the computing equipment indicates a mapping relation between at least one operating system and equipment information, and the at least one operating system comprises a target operating system; and starting the target operating system. Therefore, the operating system compatible with the in-place hardware equipment can be selected to be started in the starting stage of the computing equipment, maintainability and stability of the system are improved, and the problem that the default starting operating system preset by the system is incompatible with the in-place hardware equipment in the starting stage due to improper manual selection of the user in the starting stage of the operating system is solved.

Description

Method and device for starting operating system and computing equipment

Technical Field

The present invention relates to the field of computer technologies, and in particular, to a method, an apparatus, and a computing device for starting an operating system.

Background

During the computing device boot phase, a user is typically faced with selecting an operating system from a plurality of operating systems to boot. These operating systems may include different system types or different versions of the same system. The computing device may be configured to automatically expose these operating system options at boot-up. The user may select the operating system in the boot interface that he wishes to boot on his own or without any selection. If the user does not select within the preset time, the system automatically guides the operating system to the default configuration for starting.

However, a variety of hardware devices installed in computing devices, such as PCIe and PCI peripherals, are typically produced by different manufacturers, and these devices may be optimized for a particular operating system, providing specialized drivers and support. Thus, they can provide better performance and stability on these operating systems. In addition, the support capability of the operating system to the peripheral hardware is different, and some systems may have built-in drive support to specific manufacturer devices, which may exhibit better compatibility. While for other systems, additional drivers may need to be installed or specifically configured to achieve full compatibility with these hardware devices.

Disclosure of Invention

The embodiment of the application provides a method, a device, computing equipment, a computer storage medium and a computer program product for starting an operating system, which can realize the starting of the operating system with selective adaptation.

In a first aspect, an embodiment of the present application provides a method for booting an operating system, where the method includes: in a starting stage of the computing equipment, acquiring equipment information of in-place hardware equipment in the computing equipment; determining a target operating system corresponding to the equipment information based on a preset mapping relation; the preset mapping relation indicates the mapping relation between at least one operating system and equipment information, and the at least one operating system comprises a target operating system; and starting the target operating system.

In the above examples, in the electronic device, for example, the server. In the startup phase of the server, if a plurality of operating systems are installed on the server, one operating system startup is selected from the plurality of operating systems when a server startup event occurs. At the time of the boot event, typically one of the operating systems may match the hardware device at the boot time. The hardware devices of the server connection are, for example, devices connected to the server system bus and/or devices directly connected to the server motherboard. The operation system matched with the hardware equipment is selected for starting, the operation system can be matched with the hardware equipment better to work, and the starting efficiency, stability and reliability of the system are improved. The adaptive operating system can fully exert the performance of the hardware equipment, thereby obtaining better system performance and response speed. The adaptive operating system can reduce compatibility problems and conflicts and improve maintainability and stability of the system.

In one possible example, the computing device boot phase is a BIOS boot phase.

In one possible example, the mapping relationship between at least one operating system and the device information has a sequence, each item in the mapping relationship is matched with the device information in sequence according to the sequence, and the operating system which is matched with the device information first is selected as a target operating system; each entry in the mapping relationship indicates a correspondence of device information of the operating system and the hardware device.

In the above example, by acquiring the device information of the hardware device and matching the mapping relationship according to the preset sequence, the most suitable target operating system can be quickly determined. The method reduces the time of manually selecting the operating system, reduces the waiting time in the starting process, quickly starts the system and improves the starting efficiency of the equipment. Through an automatic mapping and matching process, the system can intelligently select an operating system which is most suitable for the current hardware configuration, so that the possibility of human intervention and errors is reduced, and the user experience is improved. The automated matching process also reduces the need for users to manually select operating systems, reducing the risk of human operator error, particularly in environments where different operating systems need to be frequently started. An administrator can adjust the sequence of the mapping relation according to the needs so as to adapt to different hardware environments or priority strategies.

In one possible example, the mapping relationship between at least one operating system and device information supports dynamic updating to accommodate hardware changes or newly added operating system conditions.

In the above example, the mapping relationship may be preset and updated as required, so as to adapt to different hardware configurations and operating system versions. The method has high flexibility and expandability and can be applied to various computing devices and operating system environments. By dynamically updating the mapping relationship, the system can be compatible with more new hardware devices, and the starting problem caused by hardware device updating is reduced. With the continuous addition of the equipment information and the expansion of the mapping relation, the system can gradually establish an equipment information knowledge base, and more reliable data support is provided for subsequent hardware equipment identification and operating system matching.

In one possible example, when a target operating system corresponding to device information is not found based on a preset mapping relationship, the device information is added to the mapping relationship, and a corresponding operating system is provided.

In the above example, the system can learn and update the mapping relationship by itself, and as the device information of the new hardware device is introduced, the system can automatically expand the mapping relationship, so as to improve the adaptability and the intelligence level. After the device information of the new hardware device is identified and added to the mapping relation, the user does not need to manually configure or select the operating system again when starting next time, and convenience of user experience is improved.

In one possible example, obtaining device information for a hardware device includes: sending a device information acquisition request to a Baseboard Management Controller (BMC); and receiving and analyzing the data returned by the BMC to determine the device information of the in-place hardware device.

In the above example, by requesting the BMC for the device information of the incumbent hardware device, it may be ensured that the latest device information of the startup phase is obtained. The BMC is generally used for centrally managing and monitoring server hardware, and device information is acquired through the BMC, so that the existing management and monitoring capability of the BMC can be utilized, and the information acquisition process is simplified. The BMC is used for acquiring the device information, so that complex device scanning at a system level in a starting stage can be avoided, and the starting efficiency is improved.

In one possible example, the acquiring device information of the hardware device in place further includes: extracting at least one attribute of the device information, wherein the attribute comprises one or more of an address identifier bdf of the hardware device, a vendor identifier vendor_id, a hardware device identifier device_id, a sub vendor identifier sub_vendor_id and a sub device identifier sub_device_id; constructing an identifier for representing the hardware device using the at least one extracted attribute; the identifier is used for searching the operating system corresponding to the identifier in the mapping relation.

In the above example, by constructing a unique identifier of the device information, it is ensured that the system can accurately identify the currently installed hardware device. The corresponding operation system can be quickly searched in the mapping relation, the searching and matching time is reduced, and the overall matching efficiency is improved. The specific equipment attribute is used for constructing the identifier, so that mismatching and system conflict caused by equipment information blurring or incompleteness can be reduced, and the reliability of a system starting process is improved.

In one possible example, the request is sent through a smart platform management interface, where the interface uses the smart platform management interface IPMI protocol or REDFISH protocol.

In the above example, the IPMI protocol and REDFISH protocol are industry standard protocols. The standardized interface ensures compatibility with various hardware and software platforms, and improves the universality and reliability of the system. With these standardized protocols of IPMI and REDFISH, it is ensured that device information of hardware devices of different vendors can be extracted.

In one possible example, determining a target operating system corresponding to the device information based on the preset mapping relationship includes: if the target operating system corresponding to the equipment information is not found within the preset time based on the preset mapping relation, outputting an operating system selection interface; in the case where a user operation for the operating system selection interface is received, a target operating system is determined based on the user operation.

In the above example, the preset time limits the latency of the system in selecting the operating system, helping to reduce the latency of the user, especially when the device information matches the preset mapping slower or fails. The user friendliness is improved, and starting interruption caused by automatic matching failure is avoided.

In one possible example, after outputting the operating system selection interface, if no user operation for the operating system selection interface is received within a preset time, the target operating system is determined to be a preset default operating system.

In the above example, when the user does not perform the operation for the operating system selection interface within the preset time, the default operating system is automatically guided to start, so that the system can still operate normally even if the user does not select, and a reliable automatic rollback mechanism is provided.

In one possible example, if the operating system corresponding to the device information does not exist in the preset mapping relationship, determining that the target operating system is a preset default operating system, or outputting an operating system selection interface; upon receiving a user operation for the operating system selection interface, a target operating system is determined based on the user operation.

In the above example, the preset default operating system is started under the condition that the operating system matched with the equipment information of the in-place hardware equipment in the starting stage is not available, or the user is allowed to select the operating system in the starting process, so that the flexibility of the system is improved, and the system is suitable for the requirements and the use scenes of different users.

In one possible example, the device information mapping relationship of at least one operating system and the hardware device is that one operating system forms a one-to-one mapping relationship corresponding to one device information, or that one operating system forms a one-to-many mapping relationship corresponding to a plurality of device information.

In the above example, the one-to-one and one-to-many mapping relationship is supported, so that the system can flexibly adapt to various hardware configurations and operating system environments, and the requirements of different users and application scenes are met.

In one possible example, the mapping relationship includes a plurality of entries, each entry specifying a correspondence of device information of one operating system and one or more hardware devices.

In one possible example, the mapping relationship is stored in a configuration file of the bootloader, defining a correspondence relationship between device information of the hardware device and at least one operating system.

In one possible example, during a computing device startup phase, automatically executing a device discovery command line program to determine a target operating system; the device discovery command sequence includes:

Sending a request to a baseboard management controller BMC to acquire device information of currently in-place hardware devices; receiving equipment information returned by the BMC, and receiving and analyzing data returned by the BMC; determining a target operating system corresponding to the equipment information based on a preset mapping relation; the preset mapping relationship indicates a mapping relationship between at least one operating system and equipment information, and the at least one operating system comprises a target operating system.

In the above example, the acquisition, analysis and operating system matching functions of the device information are integrated into one command line tool or module, so that the management and configuration of the system are simplified, and the complexity of the system is reduced. The integrated solution reduces the amount of management and maintenance effort. As a stand-alone module, it can be easily integrated into existing bootloaders and extended as needed.

In a second aspect, an embodiment of the present application provides an apparatus for booting an operating system, where the apparatus includes: the device information acquisition module is used for acquiring device information of in-place hardware devices in the computing device in a starting stage of the computing device; the operating system determining module is used for determining a target operating system corresponding to the equipment information based on a preset mapping relation; the preset mapping relation indicates the mapping relation between at least one operating system and equipment information, and the at least one operating system comprises a target operating system; and the operating system starting module is used for starting the target operating system.

In a third aspect, embodiments of the present application provide a computing device comprising:

at least one memory for storing a program;

At least one processor for executing the programs stored in the memory;

Wherein the processor is adapted to perform the method as described in the first aspect or any one of the possible implementations of the first aspect, when the program stored by the memory is executed.

In a fourth aspect, embodiments of the present application provide a computer readable storage medium storing a computer program which, when run on a processor, causes the processor to perform the method described in the first aspect or any one of the possible implementations of the first aspect.

In a fifth aspect, embodiments of the application provide a computer program product, characterized in that the computer program product, when run on a processor, causes the processor to perform the method described in the first aspect or any one of the possible implementations of the first aspect.

It will be appreciated that the advantages of the second to fifth aspects may be found in the relevant description of the first aspect, and are not described here again.

Drawings

FIG. 1A is a schematic diagram of a multi-operating system boot;

FIG. 1B is a schematic diagram of a further operating system selection interface;

FIG. 2 is a schematic diagram of a computing device 100 for performing a boot scheme according to an embodiment of the present application;

FIG. 3 is a method for booting an operating system according to an embodiment of the present application;

FIG. 4 is a further method for booting an operating system according to an embodiment of the present application;

FIG. 5 is a schematic diagram of an execution flow of a boot loader using an MBR partition table in a conventional BIOS mode according to an embodiment of the present application;

FIG. 6 is a flowchart illustrating a method for booting an operating system according to an embodiment of the present application;

FIG. 7 is a flowchart of a method for booting an operating system according to an embodiment of the present application;

Fig. 8 is a schematic flow chart of an implementation of a device discovery command module according to an embodiment of the present application;

FIG. 9A is a flowchart of a boot operating system according to an embodiment of the present application;

FIG. 9B is a flowchart of a boot operating system according to an embodiment of the present application;

FIG. 10 is a schematic diagram of a computer network for booting an operating system using PXE according to an embodiment of the present application;

Fig. 11 is a schematic structural diagram of a device for booting an operating system according to an embodiment of the present application.

Detailed Description

The term "and/or" herein is an association relationship describing an associated object, and means that there may be three relationships, for example, a and/or B may mean: a exists alone, A and B exist together, and B exists alone. The symbol "/" herein indicates that the associated object is or is a relationship, e.g., A/B indicates A or B.

The terms "first" and "second" and the like in the description and in the claims are used for distinguishing between different objects and not for describing a particular sequential order of objects. For example, the first response message and the second response message, etc. are used to distinguish between different response messages, and are not used to describe a particular order of response messages.

In the description herein, it should be understood that the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "circumferential", etc. indicate orientations or positional relationships that are based on the orientations or positional relationships shown in the drawings, are merely for purposes of describing the present application and simplifying the description, and do not indicate or imply that the device or element being referred to must have a particular orientation, be configured and operated in a particular orientation.

In embodiments of the application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "e.g." in an embodiment should not be taken as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion. In order to facilitate understanding of the technical solution of the present application, the related terms referred to herein are explained below.

1. Intelligent platform management interface (INTELLIGENT PLATFORM MANAGEMENT INTERFACE, abbreviated as IPMI): is an industry standard, which defines a general standardized abstract interface based on information technology (Information Technology, abbreviated as IT) equipment management, shields the details of the bottom hardware, and enables management software to be used across platforms. Physical health information of each hardware device in the electronic device, such as temperature, voltage, fan working state, power state and the like, can be monitored through IPMI; meanwhile, the work logs of each hardware device in the electronic device can be recorded through IPMI, and the work logs are used for prompting the user and the subsequent positioning problem; the working state data of the hardware equipment is sent to the management equipment in the form of IPMI data, and the management equipment can manage the hardware equipment in the electronic equipment according to the received IPMI data.

2. Basic input/output system (BIOS): the special responsibility for setting various parameters of the system hardware is essentially a set of programs, i.e. a set of codes, which are solidified onto a ROM chip on the motherboard in the computer.

3. A baseboard management controller (Baseboard Management Controller, referred to as BMC) is an embedded microcontroller, typically integrated on the motherboard of a server or other computing device. It is a separate processing unit independent of the main processor and is primarily responsible for monitoring, managing and controlling system hardware, temperature, power, fan speed, etc. BMCs typically have their own storage, processing power, and network interfaces that can remotely monitor and manage computing devices, providing remote diagnostics, fault recovery, and remote control functions.

4. A unified extensible firmware interface (Unified Extensible FIRMWARE INTERFACE, UEFI) is a firmware interface standard for operating system startup and hardware initialization. It replaces the conventional BIOS (basic input/output System) and provides more powerful and flexible startup and management functions for computer systems.

5. Legacy BIOS a traditional BIOS is a traditional computer boot-up scheme that uses a basic input/output system in firmware to boot an operating system.

When a start event is encountered, a computing device with a plurality of operating systems is installed, an option is provided for a user to select at a boot interface, a selection input of the user is received, and one of the operating systems is loaded to start the computing device according to the selection input of the user. If the user does not select within the preset time, the system automatically guides the operating system to the default configuration for starting.

FIG. 1A is a schematic diagram of a multi-OS boot, as shown in FIG. 1, in which a computing device detects a boot event to boot the OS, a boot process generally starts with firmware (BIOS or UEFI), outputs a multi-OS selection interface, receives an OS selection instruction input by a user, and according to the OS selection instruction, directs a boot module to boot a target OS, including loading a boot-related file such as a target OS kernel into memory for execution. The boot starting module comprises a starting code, a boot loader and the like and a program related to the boot of the boot operating system, and the boot loader starts the target operating system by reading a boot loader configuration file.

FIG. 1B is a schematic diagram of a multiple operating system selection interface presented to a user, the interface including presenting multiple operating systems information to the user indicating that there are multiple pre-installed operating systems, the interface listing the multiple operating systems, the user being able to select a target operating system from among the multiple operating systems (operating systems A-D) to launch. The selected system is loaded by selecting any entry. When the boot process begins, the boot loader loads the specified operating system kernel file and then initiates the boot process of the operating system. Or the user does not make a selection operation within the preset time, and the boot loader starts a default operating system. For example, if the default operating system is set as operating system B in the configuration file, operating system B is started after a preset time.

Different operating systems may have different degrees of support for hardware. Some operating systems may already have drivers built into them for some manufacturers or have better compatibility to support these devices better. While for other operating systems, additional drivers are installed or some configuration is made to be fully compatible with certain devices.

For example, some specialized server network cards may provide optimized drivers for a particular operating system to achieve higher performance and more stable network connections. In this case, it may be more appropriate to select an operating system compatible with these network cards. And, the user may select the operating system by himself or herself, and a selection error or a wrong selection may occur.

The embodiment of the application provides a method for starting an operating system, which is used for realizing automatic identification of hardware equipment information by modifying source codes of a boot loader when the operating system is selected in a boot stage, and guiding and loading a target operating system according to matching of the information of the hardware equipment. According to the embodiment of the application, compatibility factors of the hardware equipment are considered, more specialized selection is performed on the starting operation system, and the step of searching a hardware equipment manual by a user to determine the operation system compatible with the hardware equipment is saved.

Fig. 2 is a schematic structural diagram of a computing device 100 for executing a startup scheme according to an embodiment of the present application. In some possible embodiments, computing device 100 may be a physical machine, such as a server. The computing device 100 may be a virtual device, such as a Virtual Machine (VM).

As shown in fig. 2, the computing device 100 includes a processor 110, a baseboard management controller BMC130, a hardware device 140, a memory 170, and a storage 160. Wherein storage 160 includes a storage firmware module (e.g., BIOS/UEFI)

120. Boot up module 150, etc. The boot initiation module 150 includes a boot loader or the like.

The processor 110 is a device having data processing capabilities, the program instructions and data are stored in the storage device 160, and the storage device 160 is a non-volatile memory, such as a storage medium, e.g., a hard disk drive, an optical disk, a USB drive, or a network storage. The processor 110 and the storage 160 are coupled to each other. Processor 110 reads the program instructions in storage 160 to perform the following operations:

After computing device 100 detects a boot event, processor 110 loads firmware module 120 into memory 170 for execution, firmware module 120 invokes boot up module 150, boot up module 150 including, but not limited to, a boot loader or the like. The boot initiation module 150 is used to load the boot loader and other necessary software components into the memory 170. The processor 110 executes the software to complete the booting process of the operating system. Firmware module 120 includes, but is not limited to, BIOS, UEFI, etc. The firmware module 120 stores, for example, a BIOS start code, which is solidified in the BIOS chip. At the start of the computing device 100, BIOS boot code is executed to detect the hardware, initialize the hardware, and make and complete the BIOS settings. For example, the BIOS chip enumerates PCIE/PCI devices connected to the computing device 100, and initializes the PCIE/PCI devices.

The processor 110 may initiate and run a boot loader in the storage 160. The processor 110 may be one or more processors (e.g., one processor, two processors, three processors, etc.). The processor 110 may also be other forms of processors such as a graphics processor (graphics processing unit, GPU for short), an artificial intelligence (ARTIFICIAL INTELLIGENCE, AI for short) chip, and the like. Embodiments of the present application are not limited to a particular implementation of processor 110. It should be appreciated that when the storage 160 is a network storage medium, the storage 160 is connected to the computing device 100 via a network.

The BMC130 is connected to the hardware device 140, and after the computing device 100 is powered on, the BMC synchronously powers on, acquires device information of the hardware device 140, and stores the device information of the hardware device. The hardware 140 according to the embodiment of the present application includes peripheral hardware devices. Peripheral hardware devices are devices that connect to a motherboard or internal bus of a computing device, including but not limited to PCIE and/or PCI devices such as DPU cards, IPU cards, smart network cards, accelerator cards, and the like.

It should be noted that the computing devices 100 of different companies refer to the BMC130 differently, for example, some companies refer to the BMC, some companies refer to fully automated integration (INTEGRATED LIGHTS-out, iLO for short), and another company refers to the integrated dill remote access controller (INTEGRATED DELL remote access controller, iDRAC for short). Either BMC or iLO or iDRAC may be understood as BMC130 in embodiments of the invention.

The boot startup module 150 is configured to obtain device information of the hardware device 140 stored in the BMC130, and parse the device information of the hardware device 140 to obtain device information of the hardware device that is in place at the startup time. An operating system of at least one hardware device adapted to the bit is selected as a target operating system. The kernel of the target operating system and the necessary boot files are loaded into memory 170 to boot the target operating system.

The boot initiation module 150 includes a boot loader, which is a program that boots an operating system, such as grub, clover, syslinux, etc. When firmware module 120 is a UEFI, a bootloader such as grub (GRand Unified Bootloader), grub is a multiple operating system boot manager or boot loader that is used to boot different systems. After the target operating system is determined, the boot loader is responsible for extracting the kernel and necessary boot files of the target operating system from the storage device, loading them into the memory, and configuring boot parameters to enable the operating system to take over execution and complete the remaining boot process, including initializing system services, mounting the file system, etc., until the target operating system is fully started. The boot loader allows a user to select the operating system that he wishes to run during the computer boot phase and may be used to select different kernel files on the operating system partition and also to pass boot parameters to those kernel files. The method comprises the steps of adding a guide menu item in a configuration file of a guide loader, and displaying a page of the guide menu item when a corresponding keyboard input exists by a user. And according to the configuration file grub.cfg of the boot loader, booting the kernel of the Linux system and the like. After the kernel is loaded into memory, the kernel may boot the operating system according to a configuration in a bootloader configuration file, such as grub. For example, the type of operating system may include Linux, UNIX, centOS, ubuntu, debian, gentoo, fedora, etc. Writing preset time, default operating system and system option list displayed to user in configuration file of boot loader, and modifying each configuration of computing device through BIOS menu page including multiple modifiable options. The boot loader is used for providing an operating system option list on a boot interface for a user to select, and starting a default operating system after a preset time when the user does not select.

In grub profiles menuentry is used to define entries in the boot menu that are typically used to boot up different operating systems or different versions of operating systems. For example, menuentry may be named "Ubuntu" if the Ubuntu operating system is to be booted; menuentry may be named "Windows" if it is to boot up the Windows operating system. Modifying the grub. Cfg file and configuring the plurality menuentry means defining a plurality of boot options, each option corresponding to a different kernel or operating system installed in the system. Each menuentry contains a set of instructions specifying the kernel to be loaded, initrd (initialize RAM disk), and other boot parameters. The linux line specifies the path of the kernel file and the initrd line specifies the path of the initrd file. initrd (initial RAM disk) is a temporary root file system that is typically loaded into memory at Linux startup. It contains key files and tools for booting and initializing the operating system, KERNEL is an instruction to specify the KERNEL file that the boot loader loads. squash files typically contain some or all of the file system content of the operating system, and these files may be dynamically loaded into memory. squash files may contain various files required by the operating system, such as program files, library files, configuration files, and the like. Menuentry of the profile grub. Cfg is illustrated as follows:

Menuentry“GPU A100 Diagnosis”{

Linux/tiny/A100/kernel/kernel squash＝/tiny/A100/squash_iso.bin

Initrd/tiny/A100/intird

}

In the Legacy BIOS, legacy mode, the bootloader is Isolinux, for example, writes a bootloader configuration file isolinux. Cfg, specifies the location of files like kernel, initrd, squash by adding a "lable" key to specify the start-up menu item and associated boot parameters. Menuentry of the profile isolinux. Cfg is illustrated as follows:

Label a100{

Menu label^GPU A100 Diagnosis

Linux/tiny/A100/kernel/kernel squash＝/tiny/A100/squash_iso.bin Initrd/tiny/A100/intird

}

It should be understood that the components included in the computing device and the positional relationships among the components are merely illustrative, and the computing device adapted to the technical solution of the embodiment of the present application is not limited to the one shown in fig. 1. The components included in the computing device can be replaced by other types of components with the same functions, and the system with the replaced components is also applicable to the technical scheme provided by the embodiment of the application. The computing device may also contain more or fewer components, as the containing components change, so too does the operating system boot flow.

The above examples introduce computing device 100. Fig. 3 is a method for starting an operating system according to an embodiment of the present application. Next, a booting scheme provided by an embodiment of the present application is described in conjunction with the computing device 100 in fig. 2 and 3.

S310, in a starting stage of the computing device, device information of an in-place hardware device in the computing device is obtained.

In one possible example, the hardware device is a peripheral hardware device connected to the computing device, the peripheral hardware device being a device connected to a motherboard or internal bus of the computing device.

In one possible example, the peripheral hardware devices include PCIE and/or PCI devices.

After the computing device 100 is powered up, the processor 110 loads the boot code in the firmware module 120 into the memory 170 for execution, the boot code performs a hardware Self Test (POST), initializes a hardware device (e.g., a memory, a hard disk, a video card, etc.), establishes an interrupt vector table, etc., and attempts to load a boot loader from the storage 160, i.e., a predefined boot device (e.g., a hard disk, an optical disk, a USB drive, etc.). The processor 110 loads a boot loader into the memory 170 for execution.

In one possible example, a request is sent to the BMC130 to request device information of the hardware device that is in place at the current start time, and after the device information of the hardware device is parsed, device information of the hardware device in a required format is obtained, where the device information includes configuration information and identification information of the hardware device, for example.

In one possible example, the computing device boot phase is a BIOS boot phase.

In one possible example, the computing device startup phase is a UEFI startup phase.

S320, determining a target operating system corresponding to the equipment information based on a preset mapping relation; the preset mapping relationship indicates a mapping relationship between at least one operating system and equipment information, and the at least one operating system comprises a target operating system.

In one possible example, the device information mapping relationship of at least one operating system and the hardware device is that one operating system forms a one-to-one mapping relationship corresponding to one device information, or that one operating system forms a one-to-many mapping relationship corresponding to a plurality of device information. The mapping relation between one-to-one and one-to-many is supported, so that the system can flexibly adapt to various hardware configurations and operating system environments, and the requirements of different users and application scenes are met.

In one possible example, the mapping of device information for at least one operating system and hardware device may be altered, such as adding, deleting, or altering the mapping. The system can learn and update the mapping relation by itself, and the system can automatically expand the mapping relation along with the introduction of the equipment information of the new hardware equipment, so that the adaptability and the intelligent level of the system are improved. After the device information of the new hardware device is identified and added to the mapping relation, the user does not need to manually configure or select the operating system again when starting next time, and convenience of user experience is improved.

S330, starting the target operating system.

In one possible example, booting a target operating system includes reading a kernel file of the operating system to memory.

In one possible example, if the operating system corresponding to the device information does not exist in the preset mapping relationship, determining that the target operating system is a preset default operating system. Or output an operating system selection interface. In the case where a user operation for the operating system selection interface is received, a target operating system is determined based on the user operation.

In one possible example, the target operating system is determined to be a preset default operating system if no user operation for the operating system selection interface is received within a preset time.

In one possible example, based on the preset mapping relationship, the target operating system corresponding to the device information is not found within a preset time, and an operating system selection interface is output; in the case where a user operation for the operating system selection interface is received, a target operating system is determined based on the user operation.

FIG. 4 is a flowchart of a method for booting an operating system according to an embodiment of the present application. As shown in fig. 4, the method includes:

S410, in a starting stage of the computing device, device information of an in-place hardware device in the computing device is obtained.

S420, based on a preset mapping relation with a sequence, sequentially matching each item in the mapping relation with equipment information according to the sequence, and selecting an operating system which is matched with the equipment information first as a target operating system; each entry in the mapping relationship indicates a correspondence of device information of the operating system and the hardware device. The preset mapping relationship indicates a mapping relationship between at least one operating system and device information, the at least one operating system including a target operating system.

The most suitable target operating system can be rapidly determined by acquiring the equipment information of the hardware equipment and matching the mapping relation according to the preset sequence. The method reduces the time of manually selecting the operating system, reduces the waiting time in the starting process and improves the efficiency of equipment starting. Through an automatic mapping and matching process, the system can intelligently select an operating system which is most suitable for the current hardware configuration, so that the possibility of human intervention and errors is reduced, and the user experience is improved. In addition, the automated matching process reduces the risk of human operator error, particularly in environments where frequent starting of different operating systems is required. An administrator can adjust the sequence of the mapping relation according to the needs so as to adapt to different hardware environments or priority strategies.

S430, starting the target operating system.

The execution principle of step S410 and step S430 is similar to that of steps S310 and S330 in the foregoing embodiments, and the specific process can be referred to the foregoing explanation about steps S310 and S330, which is not repeated here.

Fig. 5 is a schematic diagram of an execution flow of a boot loader using an MBR partition table in a conventional BIOS mode according to an embodiment of the present application, and the booting process is further described below with reference to fig. 5. As shown in FIG. 5, the boot code is located in the firmware module 120, and a first instruction executed by the processor 110 after the boot is directed to the boot code, and the processor 110 loads the boot code to a first address (e.g., the first address is 0x7c 00) of the memory 170, thereby completing the boot self-test and the hardware initialization operation. The first storage medium, e.g., disk, stored in the boot sequence is then read according to the preset boot sequence.

The boot record (Master Boot Record, MBR for short) of the disk boot sector is read to the second address of the memory 170. MBRs are typically located in a hard disk 0 track 0 cylinder 0 sector, the MBR typically comprising 512 bytes, with the first 446 bytes storing the boot loader, the next 46 bytes for storing the partition table, describing the partition layout on the disk, including information on the location, size and type of partition, and the last two bytes of the MBR for storing an end flag, identifying that this sector is a valid MBR.

The boot loader is loaded into memory 170 for execution, and the boot loader boots one of a plurality of operating systems. The embodiment of the application determines a target operating system from a plurality of operating systems, wherein the target operating system is one of the operating systems matched with the in-place hardware equipment detected at the starting moment. The hardware environment of the computing device is better adapted than the default operating system selected by the user or specified by the system.

In the embodiment of the present application, it is assumed that a plurality of operating systems are installed in a server, in other words, for example, a disk may be divided into a plurality of independent storage spaces, each corresponding to a partition. And at least part of the storage space is internally provided with different operating systems, such as an operating system A, an operating system B, an operating system C and an operating system D, and when the server is started, one operating system needs to be selectively loaded for operation.

System files of operating system A are stored, for example, in a first partition of the internal storage space, system files of operating system B are stored in a second partition of the internal storage space, system files of operating system C are stored in a third partition of the internal storage space, and system files of operating system D are stored in a fourth partition of the internal storage space. The system files of the operating system include kernel files, initrd files, and other necessary files.

When the boot loader is loaded into the second address in the memory 170 for execution, the boot loader reads the information in the partition table, determines the type and location of each partition according to the information in the partition table, and locates and loads the corresponding operating system. For example, a partial boot loader is located in the MBR.

Before loading the operating system into the third address in the memory 170 for execution, the embodiment of the present application determines the target operating system matching the current hardware device information. And then loads the kernel file of the target operating system into the third address space of the memory 170 for execution to complete the starting of the operating system.

Wherein the hardware device discovery method may be registered as a command module, executed by the bootloader.

Correspondingly, the same is true in the UEFI mode, and the current mainstream server BIOS generally adopts a unified extensible firmware interface. The UEFI mode is selectable by a variety of bootloaders (i.e., the bootloader programs referred to by embodiments of the present application), such as Windows Boot Manager, systemd-boot (also known as gummiboot), and so forth. UEFI systems generally fall into 7 phases from power up to power down: SEC (security verification) - > PEI (EFI pre-initialization) - > DXE (drive execution environment) - > BDS (boot device select) - > TSL (operating system loading pre-period) - > RT (Run Time) - > AL (system disaster recovery period). The embodiment of the application is mainly realized in the BDS stage.

In the UEFI mode, the UEFI uses an EFI system Partition (EFI SYSTEM Partition, ESP for short), which is a special Partition dedicated to storing boot loaders and related files. The boot loader will typically be installed into the ESP. And in the starting stage of the computing equipment, initializing UEFI firmware and performing self-checking. UEFI firmware loads UEFI Boot manager, after which UEFI Boot manager loads the boot loader located in ESP. The boot loader communicates with the BMC to obtain device information of the hardware device in place. And matching the device information of the hardware device with the mapping relation of the operating system, and when a matched entry exists, finding the kernel file address of the operating system from the partition table, and loading the kernel file to a third address of the memory 170.

Fig. 6 is a flowchart of a method for booting an operating system according to an embodiment of the present application, where in a firmware stage, as shown in fig. 6, the method includes the following steps:

In step S610, a request is sent to the baseboard management controller BMC to obtain device information of the on-site hardware device at the starting time of the computing device.

By requesting the BMC for device information of the hardware device in place, it can be ensured that the latest device information in the start-up phase is obtained. The BMC is generally used for centrally managing and monitoring server hardware, and device information is acquired through the BMC, so that the existing management and monitoring capability of the BMC can be utilized, and the information acquisition process is simplified. The BMC is used for acquiring the device information, so that complex device scanning at a system level in a starting stage can be avoided, and the starting efficiency is improved.

Step S620, extracting an attribute of at least one hardware device in the device information, wherein the attribute comprises one or more of an address identifier bdf, a vendor identifier vendor_id, a hardware device identifier device_id, a sub vendor identifier sub_vendor_id and a sub device identifier sub_device_id of the hardware device; constructing an identifier for representing the hardware device using the at least one extracted attribute; the hardware device identifier is used for searching the operating system corresponding to the identifier in the mapping relation.

And acquiring device information of the hardware device with the in-place starting moment from the BMC. The device information of the hardware device comprises configuration information and identification information of the hardware device, and the hardware device comprises peripheral devices connected to the computing device; the configuration information of the hardware equipment at least comprises equipment ID and manufacturer ID of the hardware equipment; the identification information of the hardware device at least comprises an address identifier bdf of the hardware device; the address identifier of the hardware device is used to uniquely identify the device in the peripheral connection bus.

Taking device information acquisition of PCIE devices as an example, description will be given. PCIE belongs to high-speed serial point-to-point dual-channel high-bandwidth transmission, and connected devices allocate exclusive channel bandwidth and do not share bus bandwidth. In complex computer systems, such as servers, PCIE devices are typically configured. Among the common PCIE devices are: network cards, display cards, host Bus Adapters (HBAs) and the like. It should be noted that, the PCIE device is not necessarily a device plugged into the server, but may be a PCIE device that is independent of the server and is powered on separately, and is connected to the server through a high-speed cable.

"Bdf" generally refers to the bus, device, and function numbers of the devices, which is one way to uniquely identify PCIE devices. On the PCIE Bus, each Device has a unique bdf number, which consists of a Bus number (Bus), a Device number (Device), and a Function number (Function), expressed in hexadecimal numbers. Bus Number (Bus Number): and the bus number of the PCIE equipment is indicated. Each PCIE bus may connect multiple devices with a bus number that is incremented from 0. Device Number (Device Number): representing the number of PCIE devices on a particular bus. Each PCIE device has a unique device number, and increases from 0, up to 32 devices. Function Number (Function Number): representing the numbering of the different functions on the PCIE device. For PCIE devices (e.g., PCIE-PCIE bridges) that support multiple functions, each function has a unique function number, and up to 8 functions may be incremented from 0.

For example, bdf format is typically Bus Device Function, indicating the location of the Device on the PCIE Bus. For example 0000:50:00.0 denotes a device with bus number 0, device number 50, and function number 0.

Vendor identifier (Vendor Identifier): in the hardware field, vendor identifiers are typically used to uniquely identify a manufacturer or vendor. For hardware devices such as servers, processors, mainboards, etc., the vendor identifier may help identify the manufacturer of the device. By way of example, NVIDIA is a company that produces graphics cards, whose vendor ID may be 0x10DE (in hexadecimal).

"Sub_vendor_id" refers to a vendor identifier of a device, typically used to identify a particular manufacturer or vendor's sub-company or partner of the device. In the context of a PCI device or USB device, it is used to represent a subsidiaries or partners of the device manufacturer, or to distinguish between different device versions or configurations. The vendor ID (vendor_id) of a device uniquely identifies the primary manufacturer of the device, while the sub-vendor ID (sub-vendor_id) is used to further distinguish between different sub-companies or partners of the device manufacturer.

"Device_id" is typically a combination of numbers or letters that identify a particular PCIE device. For example, a NVIDIA GeForce GTX 1080 graphics card is inserted into the graphics card slot, and then the device ID of the graphics card may be a specific number or combination of letters, such as 103e, for uniquely identifying the graphics card.

In one possible implementation manner, device information of PCIE devices is combined, and PCIE device identification at least includes: bdf information, vendor ID, and device ID. For example, the following data formats are obtained: p_000050000_8090_103e and p_00003b000_8090_106e.

It is understood that PCIE device information may be concatenated bdf with information, vendor ID, sub-vendor ID, device ID, and sub-device ID in any specified combined order. The embodiment of the application does not limit the combination sequence of bdf information, vendor ID, sub-vendor ID, device ID and sub-device ID. And combining bdf the information, the manufacturer ID, the sub-manufacturer ID, the device ID and the sub-device ID to obtain a device information identifier of at least one PCIE device.

The identifier of the hardware device is obtained from the device information of the hardware device, for example, the identifier of the device 01:

p_000050000_8090_103e, device 02: p_00003b000_8090_106e.

P_000050000_8090_103e, 000050000: representing device bdf information, 8090: vendor_id information representing a device, 103e: device_id information representing a device.

P_00003b000_8090_106e, 00003b000: representing device bdf information, 8090: vendor_id information representing a device, 106e: device_id information representing a device.

Hardware device 01, whether device 02 is present in the bit, i.e., whether device 01, device 02 can be detected and identified.

Step S630, determining a target operating system corresponding to the identifier of the hardware equipment based on the preset mapping relation; the preset mapping relationship indicates a mapping relationship between at least one operating system and equipment information, and the at least one operating system comprises a target operating system.

In one possible example, the device information and the operating system mapping relationship of the preset hardware device are written into the configuration file of the boot loader. The mapping relationship between the device information and the operating system of the hardware device is shown in table 1:

table 1 device information and operating system mapping relationship for hardware devices

As shown in table 1, the operating system to which the device information of the device 01 matches is the operating system a, the operating system to which the device information of the device 02 matches with the device information of the device 03 is the operating system B, and the operating system to which the device information of the device 04 matches is the operating system C. The device information of the device 01 is the device information of the first group of devices, the device information of the device 02 and the device 03 is the device information of the second group of devices, and the device information of the device 04 is the device information of the third group of devices.

The mapping relationship between the device information and the operating system of the device 01 and the device 04 is one-to-one. The mapping relationship between the device information of the device 02 and the device 03 and the operating system is many-to-one, in other words, if the device information of the device 02 and the device 03 coexist, it is determined that the matching operating system is the operating system B.

In one possible example, each entry in the mapping relationship indicates a correspondence of device information of the operating system and the hardware device. The mapping relation has a sequence, and each item in the mapping relation is matched with the equipment information in sequence according to the sequence.

In one possible example, each entry in the mapping relationship associates an identifier of the hardware device with the operating system in the form of a variable and a value.

For example, in the mapping relationship between the identifier of the hardware device and the operating system, p_000050000_8090_103e=os1, and the hardware device identifier of the device01 corresponds to the operating system 1. p_00003b000_8090_106e=os2, representing that the hardware device identifier of device02 corresponds to operating system 2.p_000050000_8090_103e and

The combination of p_00003b000_8090_106e represents that the hardware device identifiers of device01 and device02 correspond to operating system 3.

In one possible example, the mapping relationship between the identifier of the hardware device and the operating system may also be identified by way of configuring a json file.

By way of example, { "p_000050000_8090_103e": "OS1" },

{ "P_00003b000_8090_106e": "OS2" }, indicating that the identifier p_000050000_8090_103e of device01 corresponds to operating system 1 and the identifier p_00003b000_8090_106 of device02 corresponds to operating system 2.

Step S640, starting the target operating system.

In one possible example, if the target operating system corresponding to the identifier of the hardware device is not found based on the preset mapping relationship, outputting an operating system selection interface; in the case where a user operation for the operating system selection interface is received, a target operating system is determined based on the user operation.

The method extracts at least one hardware device attribute (including an address identifier bdf, a vendor identifier vendor_id, a hardware device identifier device_id, a sub vendor identifier sub_vendor_id, a sub device identifier sub_device_id) of the device information by sending a request to a baseboard management controller BMC to acquire device information of an in-place hardware device, and constructs an identifier for representing the hardware device by using the at least one extracted attribute. The hardware device identifier is used for searching the operating system corresponding to the identifier in the mapping relation. Based on the identifier of the hardware device, a target operating system corresponding to the identifier is determined and started.

By sending a request to the BMC to acquire accurate device information and extracting detailed hardware device attributes, a hardware device identifier can be quickly constructed, and the accuracy and instantaneity of the hardware device information are ensured. The definition form (such as variable and value or JSON object form) of the mapping relation is flexible, is convenient to add and update, and can adapt to different hardware equipment and operating system configuration requirements.

Fig. 7 is a schematic flow chart of a device discovery method according to an embodiment of the present application. As shown in fig. 7, the method includes the steps of:

step S710, add and register device discovery command line program/module.

During the boot phase, the boot loader needs to load some necessary command modules when executing. Such as a Filesystem module: for the boot loader to identify and load a particular file system; terminal module: for allowing a bootloader to start up during a boot process a command line terminal interface is provided; insmod linux module: the method is used for loading a Linux kernel module and loading a Linux kernel specified in a grub configuration file so as to guide and start a Linux operating system.

The embodiment of the application provides a device discovery command module and registers in a configuration file of a boot loader. The boot loader executes before it starts the operating system to load the operating system that matches the current hardware environment.

The device discovery command line module is used for sending a request to the baseboard management controller BMC to acquire device information of the currently in-place hardware device; receiving and analyzing data returned by the BMC, and determining a target operating system corresponding to the equipment information based on a preset mapping relation; the preset mapping relationship indicates a mapping relationship between at least one operating system and equipment information, and the at least one operating system comprises a target operating system.

The embodiment of the application does not limit the mode of acquiring the PCIE/PCI device information from the BMC.

In one possible implementation, the IPMI/Redfish command is used to communicate with the BMC to obtain device information at the start-up of the BIOS in Legacy mode.

In one possible implementation, when the UEFI mode is enabled, communicating with the BMC to obtain device information typically utilizes related protocols and interfaces provided by UEFI, such as Simple Network Protocol (SNP), EFI SYSTEM MANAGEMENT Protocol (ESMP), and the like. Through these protocols and interfaces, the UEFI firmware may communicate with the BMC to obtain information of PCIe devices, etc. The device discovery command line module may be placed in a particular directory in the ESP, for example

/boot/efi/EFI/grub/。

In one possible implementation, the function name of the PCIE and/or PCI device discovery command module is defined as getdev. In step S720, during the computing device startup phase, the device discovery command line program/module is executed.

Executing the device discovery command line module getdev, determining a target operating system, and starting the target operating system.

According to the embodiment of the application, the device discovery command line module is added and registered in the boot loader, the hardware device information is automatically acquired and analyzed, and the adaptive operating system is matched and started based on the preset mapping relation. The method automatically executes the device discovery command line module in the starting stage of the computing device, and ensures that the system can dynamically identify and adapt to the current hardware environment in the starting process, thereby improving the starting efficiency and the system compatibility. Manual intervention is reduced, and efficiency and accuracy of a starting process are improved. The acquisition, analysis and operation system matching functions of the equipment information are integrated into a command line tool or module, so that the management and configuration of the system are simplified, and the complexity of the system is reduced. The integrated solution reduces the amount of management and maintenance effort. As a stand-alone module, it can be easily integrated into existing bootloaders and extended as needed.

Fig. 8 is a schematic flow chart of a device discovery command module for acquiring hardware device information according to an embodiment of the present application. As shown in fig. 8, the method includes: steps S810 to S860. It may be appreciated that, in the embodiment of the present application, the CPU is used as a core processing unit of the computing device, and is responsible for executing the key program of the startup phase including the BIOS and the boot loader. The flow of information between the BIOS, the boot loader, the BMC, and the PCIE device is shown in FIG. 8.

In step S810, the BMC and the BIOS are powered on and started, and the BIOS performs hardware device initialization and self-checking, and then loads the boot loader to the memory for execution. In the power-on process of the server, the BMC can synchronously power on. When PCIE and/or PCI equipment is deployed on the server, in the starting process of the server, the BIOS chip enumerates all PCIE/PCI equipment connected to the server according to a PCIE/PCI protocol, and initializes the PCIE/PCI equipment.

In step S820, the BMC sends a request for reading device information of at least PCIE and/or PCI devices to PCIE/PCI devices.

In step S830, the PCIE/PCI device returns device information to the BMC, which stores the PCIE/PCI device information.

In step S840, the boot loader sends first information to the BMC, where the first information indicates device information of the PCIE/PCI device that is requested to be stored by the BMC.

In step S850, the BMC returns the data corresponding to the first information.

In one possible implementation, if the BMC returns data, step S860 is entered to parse the first information. If the BMC does not return data or the returned data is incomplete, it will be appreciated that an attempt is made to resend the first information.

In step S860, the boot loader parses the data.

After receiving the response of the BMC, the boot loader analyzes the response and processes the equipment information of the PCIE/PCI equipment in the response, wherein the method comprises the steps of analyzing the format of the response and extracting the needed equipment information to obtain the equipment information of the in-place PCIE/PCI equipment.

For example, at power-up of the server, the BMC boots up to monitor hardware status. Subsequently, the BIOS starts and performs initialization and self-checking of the hardware device, and loads the boot loader into the memory for execution. If the server is deployed with PCIe and/or PCI devices, the BIOS enumerates and initializes the devices according to the corresponding protocols, the BMC sends a request to read and store the device information of at least the PCIe and/or PCI devices, and when the request for the device information is received, the BMC returns the requested device information data. If the BMC successfully returns the data, the boot loader enters an analysis stage; if the data is not returned or incomplete, the request is resent. The boot loader parses the returned data to identify and match the hardware device information with the operating system.

According to the embodiment of the application, through the cooperative work of the BMC and the boot loader, the automatic acquisition and management of the device information of the hardware device are realized, and the manual intervention is reduced. By checking the integrity of the data returned by the BMC and resending the request if necessary, it is ensured that the data used in the boot process is accurate and complete. And the hardware identification process is optimized between the BMC and the boot loader through a standardized information exchange flow.

FIG. 9A is a flowchart of a further boot operating system according to an embodiment of the present application. As shown in fig. 9A, the method includes the following steps S910-S980:

Step S910, an operating system boot menu entry is configured.

By way of example, the operating system directs the menu entry to be preconfigured information. The boot options for each operating system are defined in the configuration file of the boot loader. Typically, these options include information such as the name of the operating system, the location of the kernel file, boot parameters, etc. For example, in grub's profile, menuentry may be used to define boot options for each operating system.

By way of example, one operating system configuration in the boot loader configuration file is as follows:

menuentry"OS1"{

linux/tiny/OS1/kernel squash＝/tiny/OS1/squash_iso.bin

initrd/tiny/OS1/initrd

}

Step S920, configuring an operating system corresponding to the hardware device.

For example, the operating system corresponding to the hardware device is preconfigured information. In the hardware device and operating system mapping relationship, as described above, for example, p_000050000_8090_103e=os1, the identifier indicating device01 corresponds to operating system 1. p_00003b000_8090_106e=os2, and an identifier indicating device02 corresponds to operating system 2.

In one possible example, the hardware device and operating system mappings may be identified by way of a configuration json file.

By way of example, { "p_000050000_8090_103e": "OS1" },

{ "P_00003b000_8090_106e": "OS2" }, indicating that the device identifier of device01 corresponds to p_000050000_8090_103e to operating system OS1 and the identifier of device02 p_00003b000_8090_106 to operating system 02.

It should be noted that, step S910 and step S920 are performed in different order.

In step S930, the computing device starts up a phase, and loads a plurality of command modules.

In the computing device startup phase, a timeout period is typically set during which a plurality of registered command modules are loaded, and if the loading is successful, the startup process is continued. If the loading fails, the process may jump to a specific error recovery step S980 according to the pre-configured error handling policy of the system, and the reloading or other operations of the module are performed to ensure the stability and reliability of the system. Or may jump to step S970, starting the default operating system or outputting the operating system selection interface according to the settings of the bootstrap configuration file; in the case where a user operation for the operating system selection interface is received, a target operating system is determined based on the user operation. The embodiments of the present application are not limited in this regard.

For example, in grub's configuration file, multiple modules may be loaded using insmod commands. For example, multiple insmod commands may be added to the configuration file to load multiple command modules, ensuring that they are properly loaded and executed during the boot load process.

By way of example, the bootloader configuration is illustrated as follows: getdev is a device discovery command provided by an embodiment of the present application.

set timeout＝60

insmod efi_gop

insmod efi_uga

insmod linux

insmod getdev

insmod test

In step S940, the device information is searched for through the device discovery command module.

If the target operating system corresponding to the device information exists in the mapping relationship, the step goes to step S950 to determine the operating system corresponding to the device information in the mapping relationship as the target operating system.

If the target operating system corresponding to the device information does not exist in the mapping relationship, the process goes to step S970. And starting a default preset operating system or outputting an operating system selection interface.

In step S950, the operating system corresponding to the device information in the mapping relationship is determined as the target operating system.

In step S960, the target operating system is started.

Step S970, starting a preset default operating system, or outputting an operating system selection interface; in the case where a user operation for the operating system selection interface is received, a target operating system is determined based on the user operation.

In step S980, a reload or other operation of the module is performed.

According to the embodiment of the application, the intelligent selection and adaptation in the system starting process are realized by automatically acquiring the equipment information of the hardware equipment. The starting problem caused by incompatibility of an operating system which is manually operated or set by default and an on-site hardware device at the operating system guiding interface is effectively avoided, and therefore the starting efficiency and the reliability of the system are remarkably improved.

FIG. 9B is a flowchart of a booting an operating system according to an embodiment of the present application. As shown in fig. 9B, the method includes steps S910-S980, and steps S910-S980 are similar to the steps described in fig. 9A, except that the determination after step S940 is whether the target operating system is found within the preset time.

After step S940, in one possible example, if the device discovery command indicates that the device information of the hardware device in place is found in the mapping relationship, for example, when the first value is returned within the preset time getdev, it is determined that the hardware device in place is found, and it is determined that the operating system corresponding to the device information of the hardware device is the target operating system.

The preset time limits the latency of the system in selecting the operating system, helping to reduce the latency of the user, especially when the device information matches the preset mapping slower or fails. The user friendliness is improved, and starting interruption caused by automatic matching failure is avoided.

In one possible example, if the device discovery command module indicates that no device information is found for the hardware device in place in the mapping relationship, such as when a second value (the second value being a different value than the first value) is returned within a preset time getdev. Outputting an operating system selection interface; in the case where a user operation for the operating system selection interface is received, a target operating system is determined based on the user operation. The embodiment of the application can also be accessed by manually selecting the operating system when the automatic access to the adaptive operating system fails. In one possible example, the target operating system is determined to be a preset default operating system if no user operation for the operating system selection interface is received within a preset time.

In some computer networks, a Pre-boot execution environment (Pre-bootExecution Environment, abbreviated PXE) is used to boot, which refers to a communication device (e.g., computing device) downloading an image from a remote server over the network and booting. FIG. 10 is a schematic diagram of a computer network using PXE to boot an operating system according to an embodiment of the present application. As shown in FIG. 10, the computer network 1100 includes a computing device 1110, the computing device 1110 being adapted to boot using PXE. Computing device 1110 includes processor 1111, memory 1112, bmc1113, storage 1117, hardware device 1115, and network adapter 1116. Where storage 1117 stores firmware modules 1114 and boot-strap modules 1118, each of the boot-strap modules 1118 includes a boot loader or the like.

The computing device 1110 boots from a PXE server 1120. When the computing device 1110 boots, the PXE boot process starts. First, the computing device 1110 transmits a request to be booted to the PXE server 1120, and the PXE server 1120 sends a boot loader.

The network adapter 1116 is connected to the PXE server 1120 as a communication interface, and the boot up work before the PXE boot up is performed by the firmware module 1114. Firmware module 1114 executes boot code that initializes the hardware and performs self-tests. At this stage, firmware module 1114 may also examine the system configuration, determine bootable devices (e.g., hard disk, optical disk, USB drive, etc.) and their boot sequence. If a network boot is employed, the PXE firmware in the network adapter 1116 is used to send a PXE boot request to the PXE server 1120. After receiving the PXE boot request, the PXE server 1120 provides location information for the boot loader and the operating system in response to the request. The boot loader is downloaded according to the location information of the boot loader provided by the PXE server 1120. Such as a boot loader, is stored in storage 1117 after being downloaded, after which the system loads the boot loader into memory 1112 for execution by processor 1111. Memory 1112 is illustratively Random Access Memory (RAM).

The bootloader obtains the in-place hardware device 1115 from the BMC, and determines, based on the device information, that the target operating system bootloader corresponding to the device information bootloads the target operating system. After the boot loader loads the operating system image, the operating system starts up and runs.

It should be noted that, the boot loader of the embodiment of the present application may be started from a hard disk, a px, or an optical disc drive. The difference is the source and loading mode of the boot loader, and when starting from the optical drive, the BIOS or UEFI will first try to load the boot loader from the optical drive.

Based on the method of the above embodiment, the embodiment of the present application provides a device for accessing an operating system. Referring to fig. 11, fig. 11 is a schematic structural diagram of a booting operation system device according to an embodiment of the application. The boot operating system device 1100 includes: a device information acquisition module 1110, an operating system determination module 1120, and an operating system startup module 1130. The device information obtaining module 1110 is configured to obtain device information of an in-place hardware device in the computing device in a starting stage of the computing device; an operating system determining module 1120, configured to determine a target operating system corresponding to the device information based on a preset mapping relationship; the preset mapping relation indicates the mapping relation between at least one operating system and equipment information, and the at least one operating system comprises a target operating system; an operating system startup module 1130 for starting the target operating system.

Based on the method in the above embodiment, the embodiment of the present application provides a computer-readable storage medium storing a computer program, which when executed on a processor, causes the processor to perform the method in the above embodiment.

Based on the method in the above embodiments, an embodiment of the present application provides a computer program product, characterized in that the computer program product, when run on a processor, causes the processor to perform the method in the above embodiments.

It will be appreciated that the steps of the method embodiments described above may be performed by logic circuitry in the form of hardware in a processor or instructions in the form of software.

It should be understood that, the sequence number of each step in the foregoing embodiment does not mean the execution sequence, and the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application. In addition, in some possible implementations, each step in the foregoing embodiments may be selectively performed according to practical situations, and may be partially performed or may be performed entirely, which is not limited herein.

It is to be appreciated that the processor in embodiments of the application may be a central processing unit (central processing unit, CPU), but may also be other general purpose processors, digital signal processors (DIGITAL SIGNAL processors, DSPs), application Specific Integrated Circuits (ASICs), field programmable gate arrays (field programmable GATE ARRAY, FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general purpose processor may be a microprocessor, but in the alternative, it may be any conventional processor.

The method steps in the embodiments of the present application may be implemented by hardware, or may be implemented by executing software instructions by a processor. The software instructions may be comprised of corresponding software modules that may be stored in random access memory (random access memory, RAM), flash memory, read-only memory (ROM), programmable ROM (PROM), erasable programmable ROM (erasable PROM, EPROM), electrically Erasable Programmable ROM (EEPROM), registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC.

In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, produces a flow or function in accordance with embodiments of the present application, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable apparatus. The computer instructions may be stored in or transmitted across a computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)), or wireless (e.g., infrared, wireless, microwave, etc.). The computer readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that contains an integration of one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid State Drive (SSD)), etc.

It will be appreciated that the various numerical numbers referred to in the embodiments of the present application are merely for ease of description and are not intended to limit the scope of the embodiments of the present application.

Claims

1. A method for starting an operating system is characterized in that,

In a computing device starting stage, acquiring device information of in-place hardware devices in the computing device;

determining a target operating system corresponding to the equipment information based on a preset mapping relation; wherein the preset mapping relationship indicates a mapping relationship between at least one operating system and equipment information, and the at least one operating system comprises the target operating system;

And starting the target operating system.

2. The method of claim 1, wherein the computing device boot phase is a BIOS boot phase.

3. The method according to claim 1 or 2, wherein the mapping relationship between the at least one operating system and the device information has a sequence, each entry in the mapping relationship is sequentially matched with the device information according to the sequence, and an operating system first matched with the device information is selected as a target operating system; each entry in the mapping relationship indicates a correspondence of device information of the operating system and the hardware device.

4. The method of claim 1, wherein the obtaining device information for an incumbent hardware device in the computing device comprises:

Sending a device information acquisition request to a Baseboard Management Controller (BMC);

And receiving and analyzing the data returned by the BMC to acquire the device information of the in-place hardware device.

5. The method of claim 4, wherein the obtaining device information for a incumbent hardware device in the computing device further comprises:

Extracting an attribute of at least one hardware device in the device information, wherein the attribute comprises one or more of an address identifier bdf, a vendor identifier vendor_id, a hardware device identifier device_id, a sub vendor identifier sub_vendor_id and a sub device identifier sub_device_id of the hardware device;

Constructing an identifier representing the hardware device using the at least one extracted attribute; the identifier is used for searching the operating system corresponding to the identifier in the mapping relation.

6. The method of claim 4, wherein the request is sent through a smart platform management interface, wherein the interface uses a smart platform management interface IPMI protocol or REDFISH protocol.

7. The method of claim 1, wherein the determining a target operating system corresponding to the device information based on a preset mapping relationship comprises:

If the target operating system corresponding to the equipment information is not found within the preset time based on the preset mapping relation, outputting an operating system selection interface;

Upon receiving a user operation for the operating system selection interface, a target operating system is determined based on the user operation.

8. The method of claim 1, wherein the determining a target operating system corresponding to the device information based on a preset mapping relationship comprises:

and if the operating system corresponding to the equipment information does not exist in the preset mapping relation, determining that the target operating system is a preset default operating system.

9. An apparatus for booting an operating system, the apparatus comprising:

The device information acquisition module is used for acquiring device information of in-place hardware devices in the computing device in a starting stage of the computing device;

the operating system determining module is used for determining a target operating system corresponding to the equipment information based on a preset mapping relation; wherein the preset mapping relationship indicates a mapping relationship between at least one operating system and equipment information, and the at least one operating system comprises the target operating system;

and the operating system starting module is used for starting the target operating system.

10. A computing device, comprising:

at least one memory for storing a program;

At least one processor for executing the programs stored in the memory;

Wherein the processor is adapted to perform the method of any of claims 1-8 when the program stored in the memory is executed.