Operating system (OS) starting method, equipment and medium

Abstract

The embodiment of the invention provides an operating system OS starting method, equipment and a medium, and relates to the technical field of servers. The method comprises the following steps: firstly, starting an OS based on a first boot boot mode of a basic input output system BIOS; secondly, acquiring starting detection information reported by the BIOS, wherein the starting detection information is used for indicating OS starting failure; then, under the condition that starting of the OS fails, on the basis of hardware configuration information of the OS, a starting strategy of the OS is determined, and the starting strategy is used for adjusting a boot starting mode of the OS from a first boot starting mode to a second boot starting mode; and finally, starting the OS based on a second boot boot mode of the BIOS. Therefore, according to the OS starting method provided by the embodiment of the invention, the OS can be restarted without manual fault reason judgment, the efficiency of restarting the OS is improved, and the risk of service interruption caused by the fact that the OS cannot be started is reduced.

Description

Technical Field

[0001] The present application relates to the field of server technology, and in particular to an operating system (OS) startup method, device and medium. Background Art

[0002] With the continuous improvement of informatization, the stable operation of servers has become a key factor in ensuring business continuity and data security. However, servers may encounter various problems in a complex and changeable operating environment, among which the failure to start the operating system (OS) is a common and critical failure. The main reasons for OS startup failure include the failure of the baseboard management controller (BMC) to power on the OS startup device and the failure to load the OS.

[0003] In the related art, when a server encounters an OS startup failure, it mainly relies on manual intervention by operation and maintenance personnel. Operation and maintenance personnel usually need to manually check the server and confirm the server's log information to determine the specific cause of the OS startup failure. Then, based on experience and expertise, the operation and maintenance personnel select appropriate solutions according to the cause of the failure, such as replacing the faulty hardware device, repairing or reinstalling the OS, etc.

[0004] However, manually checking the server and resolving OS startup failures usually takes a long time and relies heavily on the personal experience and professional skills of the operation and maintenance personnel. If the failure causes are complex or the operation and maintenance personnel lack experience, the failure may not be resolved in time. Summary of the invention

[0005] The purpose of the present application is to provide an operating system (OS) startup method, device and medium, which can reduce the risk of business interruption caused by the inability to start the OS.

[0006] In the first aspect, the present application discloses an operating system OS startup method, the method comprising: starting the OS based on a first boot startup mode of a basic input and output system BIOS; obtaining startup detection information reported by the BIOS, the startup detection information is used to indicate that the OS startup fails; in the case of OS startup failure, based on the hardware configuration information of the OS, determining the OS startup strategy, the startup strategy is used to adjust the OS boot startup mode from the first boot startup mode to the second boot startup mode; starting the OS based on the second boot startup mode of the BIOS. Therefore, the OS startup method provided in the embodiment of the present application can restart the OS without manual fault cause judgment, thereby improving the efficiency of restarting the OS and reducing the risk of business interruption caused by the failure of the OS to start.

[0007] In some specific implementations, the startup strategy of the OS is determined based on the hardware configuration information of the OS, including: determining the failure type of the OS based on the startup detection information; when the failure type is OS loading failure, determining the startup strategy of the OS based on the hardware configuration information of the current startup device of the OS and the historical configuration information of the OS, the historical configuration information being the hardware configuration information of the startup device of the OS when the OS is successfully started.

[0008] In some specific implementations, the startup policy of the OS is determined based on the hardware configuration information of the current startup device of the OS and the historical configuration information of the OS, including: if the hardware configuration information of the current startup device of the OS and the historical configuration information of the OS fail to match, then the startup policy of the OS is determined to adjust the boot mode of the OS from the first boot mode to the second boot mode.

[0009] In some specific implementations, the startup policy of the OS is determined based on the hardware configuration information of the current startup device of the OS and the historical configuration information of the OS, including: if the hardware configuration information of the current startup device of the OS and the historical configuration information of the OS match successfully, then the startup policy of the OS is determined to be to adjust the boot startup mode of the OS from the first boot startup mode to the second boot startup mode, the second boot startup mode being the boot startup mode of the startup device of the OS when the OS is loaded successfully.

[0010] In some specific implementations, the method further includes: when the boot mode of the current boot device of the OS is successfully switched to the second boot mode, the OS boots successfully, and then determining that the cause of the OS boot failure is a boot mode error.

[0011] In some specific implementations, the method further includes: when the cause of the fault is a boot mode error, outputting a first boot strategy, the first boot strategy being to switch the boot mode of the current boot device of the OS from the first boot mode to the second boot mode.

[0012] In some specific implementations, the method further includes: saving the second boot mode to a log file, where the log file is used to store the boot mode of the boot device of the OS when the OS is loaded successfully.

[0013] In some specific implementations, the hardware configuration information includes disk information, and the disk information includes one or more of serial number information, model information, capacity information, and interface type information of the hard disk.

[0014] In some specific implementations, the startup detection information includes a power-on self-test code.

[0015] In a second aspect, the present application discloses an electronic device, which includes: a memory and a controller; the memory is used to store computer programs or computer instructions; and a processor is used to execute the computer programs or computer instructions stored in the memory, so that the electronic device executes the method of the first aspect.

[0016] In a third aspect, the present application discloses a computer-readable storage medium, in which a computer program or instruction is stored. When the computer program or instruction is executed, the method of the first aspect is implemented.

[0017] Based on the above technical solution, this application has the following beneficial effects:

[0018] The present application provides an operating system OS startup method, device and medium, firstly, the OS is started based on the first boot startup mode of the basic input and output system BIOS; secondly, the startup detection information reported by the BIOS is obtained, and the startup detection information is used to indicate that the OS startup fails; then, in the case of OS startup failure, the OS startup strategy is determined based on the hardware configuration information of the OS, and the startup strategy is used to adjust the OS boot startup mode from the first boot startup mode to the second boot startup mode; finally, the OS is started based on the second boot startup mode of the BIOS. Therefore, the OS startup method provided in the embodiment of the present application can restart the OS without manual fault cause judgment, thereby improving the efficiency of restarting the OS. At the same time, the OS startup method provided in the present application also provides a strong guarantee for the continuous and stable operation of the business, and reduces the risk of business interruption caused by OS startup failure. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 A schematic diagram of an OS startup failure;

[0020] Figure 2 A flowchart of an OS startup method provided in an embodiment of the present application;

[0021] Figure 3 A schematic diagram of a BMC determining an OS startup strategy provided in an embodiment of the present application;

[0022] Figure 4 A signaling diagram of an OS startup system provided in an embodiment of the present application;

[0023] Figure 5 A schematic diagram of a startup strategy in a power-on failure scenario provided by an embodiment of the present application;

[0024] Figure 6 A schematic diagram of a startup strategy in a scenario where OS loading fails provided in an embodiment of the present application;

[0025] Figure 7A schematic diagram of another startup strategy in a scenario where OS loading fails provided in an embodiment of the present application;

[0026] Figure 8 A schematic diagram of an OS startup device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The terms "first", "second", "third", etc. in the specification, claims and drawings of this application are used to distinguish different objects rather than to limit a specific order.

[0028] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0029] First, the technical terms involved in this application are explained:

[0030] The operating system (OS) is a key component on the server. It is a system software on the server that is responsible for managing and controlling the hardware and software resources of the server so that they can be reasonably allocated and used.

[0031] The Baseboard Management Controller (BMC) is a key component in server hardware. It can perform operations such as powering on the operating system's boot device, determining whether the power-on fails, and diagnosing the cause of the failure when the power-on fails.

[0032] The Basic Input / Output System (BIOS) is one of the core components in the server, responsible for providing the most basic hardware initialization, detection and configuration functions. BIOS is usually a set of programs fixed in the Read-Only Memory (ROM) chip on the server motherboard, including interrupt service programs, system setup programs, power-on self-test programs, and system bootstrap programs.

[0033] A Power-On Self-Test Code (Postcode) is a code used to help diagnose server hardware problems. When you start a server, the server's BIOS performs a process called POST. During this process, the BIOS checks the server's hardware configuration and status to ensure that all hardware devices are working properly. If problems are found during the POST process, the BIOS will report these problems to the user through some methods. One common method is to display the Postcode. These codes are usually displayed on the screen when the server starts, or through the LED lights on the motherboard. Each Postcode corresponds to a specific hardware check step or a specific error type.

[0034] To facilitate understanding of the technical solutions provided by the embodiments of the present application, the background technology involved in the embodiments of the present application will be described below:

[0035] OS startup failure is a common and critical fault. When a server encounters an OS startup failure, it may cause service interruption. Figure 1 , which is a schematic diagram of an OS startup failure. OS startup failure may be caused by a variety of reasons, the most common of which include BMC's failure to power on the OS startup device or OS loading failure.

[0036] The failure of BMC to power on the OS boot device may be caused by various factors:

[0037] In one possibility, the reason why the BMC fails to power on the OS startup device is that there may be a problem with the server's power supply, such as a power module failure, a loose or damaged power line, etc., which may cause the OS startup device to be unable to receive power supply normally, resulting in the BMC failing to power on the OS startup device, and then causing the OS startup failure.

[0038] In another possibility, the reason why the BMC fails to power on the OS boot device is a hardware failure of the boot device, such as a damaged motherboard or a memory module failure, which may cause the BMC to fail to power on the OS boot device, thereby causing the OS boot failure.

[0039] When the BMC fails to power on, in order to let the operation and maintenance personnel know that there is a fault during the power-on process, the BMC will trigger a power-on failure notification and issue a corresponding error alarm. Specifically, in order to confirm whether the unsuccessful power-on is caused by a temporary, non-critical problem (such as a short power supply fluctuation or poor line contact), the BMC will first perform a certain number of power-on retries. If the BMC still cannot successfully power on the OS boot device after a certain number of power-on retries, the BMC will lock the register that records the power error information in the complex programmable logic device (CPLD) of the motherboard. By locking the register that records the power error information, the BMC can ensure that the error information will not be overwritten or lost by subsequent operations, thereby providing a key basis for the subsequent OS startup process. At the same time, the BMC will parse the error information and trigger a power-on failure notification to the operation and maintenance personnel. The power-on failure notification usually includes the error type, occurrence time, and possible error causes, etc., to help the operation and maintenance personnel quickly handle the fault.

[0040] The reasons why OS fails to load are also varied:

[0041] In one possibility, if the boot file of the OS is damaged or misconfigured, the BIOS will not be able to find the correct boot path when starting, which will cause the OS to fail to load and further cause the OS to fail to start.

[0042] In another possibility, hard disk failure is also one of the reasons for OS loading failure. Because the hard disk stores the core files and system data of the OS, once the hard disk has problems, the OS will not be able to read these data, which will also cause the OS loading failure, and then cause the OS startup failure.

[0043] In the third possibility, if the OS is installed in the Basic Input / Output System Unified Extensible Firmware Interface (BIOS UEFI) mode, and the traditional Legacy mode is selected when loading the OS this time, then the OS loading fails due to the mismatch of the boot mode, and then the OS boot fails.

[0044] In the fourth possibility, the mismatch of firmware versions such as CPLD, BIOS and BMC may also cause OS loading failure. These firmwares are important components of server hardware. They are responsible for different functions, but they need to work together. If their versions do not match, it may cause hardware initialization failure, communication errors and other problems, which will also cause OS loading failure, and then OS startup failure.

[0045] When the BMC can be powered on normally but the OS fails to load, the operation and maintenance personnel need to further locate the problem based on the corresponding system information and / or logs provided by the OS, thereby providing key basis for the subsequent OS startup process.

[0046] That is to say, no matter what the reason is for the OS startup failure, it requires manual intervention by the operation and maintenance personnel. The operation and maintenance personnel usually need to manually check the server and confirm the server log information to determine the specific cause of the OS startup failure. Then, based on their experience and expertise, the operation and maintenance personnel select appropriate solutions according to the cause of the failure, such as replacing the faulty hardware device, repairing or reinstalling the OS, etc.

[0047] However, manually checking the server and resolving OS startup failures usually takes a long time and relies heavily on the personal experience and professional skills of the operation and maintenance personnel. If there are complex reasons for the failure or the operation and maintenance personnel lack experience, the failure may not be resolved in time, resulting in business interruption.

[0048] In view of this, the present application provides an OS startup method, firstly, the OS is started based on the first boot startup mode of the basic input and output system BIOS; secondly, the startup detection information reported by the BIOS is obtained, and the startup detection information is used to indicate that the OS startup fails; then, in the case of OS startup failure, the OS startup strategy is determined based on the hardware configuration information of the OS, and the startup strategy is used to adjust the OS boot startup mode from the first boot startup mode to the second boot startup mode; finally, the OS is started based on the second boot startup mode of the BIOS. Therefore, the OS startup method provided in the embodiment of the present application can restart the OS without manual fault cause judgment, thereby improving the efficiency of restarting the OS. At the same time, the OS startup method provided in the present application also provides a strong guarantee for the continuous and stable operation of the business, and reduces the risk of business interruption caused by OS startup failure.

[0049] In order to make the technical solution of this application clearer and easier to understand, Figure 2 , an embodiment of the OS startup method of the present application is introduced:

[0050] See also Figure 2 , which is a flow chart of an OS startup method provided by an embodiment of the present application. The method includes:

[0051] S201: Start the OS in the first boot mode based on BIOS.

[0052] When the OS needs to be started, the BIOS will be loaded first and try to start the OS from a specified startup device (such as a hard disk, a USB drive, a network, etc.) according to the first boot mode (such as legacy mode or BIOS UEFI mode).

[0053] S202: The BMC obtains the startup detection information reported by the BIOS.

[0054] During the boot process, BIOS generates a series of boot detection information including the power-on self-test code Postcode, where Postcode is a series of codes generated by BIOS during the boot process to indicate different states and faults of OS, i.e., boot detection information is used to indicate OS boot failure. Subsequently, BIOS reports the boot detection information to BMC, so that BMC can issue an alarm or perform corresponding management operations in time when it detects OS boot failure.

[0055] S203: When the OS fails to start, the BMC determines the OS startup strategy based on the OS hardware configuration information.

[0056] OS boot failures are usually divided into two categories: The first category is that the BMC fails to power on the OS boot device, resulting in the OS being unable to boot. This may be caused by power failure, physical damage to the boot device (such as a hard disk), or connection problems. The second category is that the OS cannot boot due to OS loading failure, that is, although the boot device is successfully powered on, the OS cannot be loaded correctly. This may be caused by system file damage, configuration errors, software conflicts, or incompatible boot modes.

[0057] In some specific implementations, the BMC may first determine the fault type based on the startup detection information obtained in step S202. If the fault type is that the OS cannot be started due to the failure of OS loading, the OS startup strategy may be determined based on the hardware configuration information of the current startup device of the OS and the historical configuration information of the OS. The historical configuration information of the OS is the hardware configuration information of the startup device of the OS when the OS is successfully started.

[0058] Specifically, see Figure 3 , which is a schematic diagram of a BMC determining an OS startup strategy provided by an embodiment of the present application. The steps of the BMC determining an OS startup strategy may be as follows:

[0059] After the BMC identifies the fault type as OS loading failure, the BMC first uses the startup detection information to determine which boot mode the current BIOS is using to boot the OS boot device (i.e., which boot mode is the first boot mode). Exemplarily, the boot mode may include legacy mode and BIOS UEFI mode. Different boot modes may correspond to different hard disk configurations or startup settings, which are crucial for determining the source of the fault.

[0060] After the BMC determines the mode in which the current BIOS is booting the OS boot device, the BMC will obtain the hardware configuration information of the current OS boot device and the historical configuration information of the OS respectively, and determine whether the two match. In some specific implementations, the method for determining whether they match can be to compare the hardware configuration information of the current OS boot device with the preset fields (such as serial number, model, etc.) in the historical configuration information of the OS to determine whether they are consistent.

[0061] It can be understood that by comparing the hardware configuration information of the current OS boot device with the historical configuration information of the OS, it is possible to determine whether any hardware changes have occurred from the time when the OS successfully booted to the time when the OS failed to boot this time (for example, whether there was a disk plugging and unplugging event).

[0062] If the hardware configuration information of the current boot device of the OS is inconsistent with the historical configuration information of the OS, the match fails, indicating that a hardware change has occurred from the time when the OS successfully booted to the time when the OS failed to boot this time, and there is a disk plug-in and unplug event. In order to cope with this hardware change, the BMC will switch the boot mode of the current boot device of the OS from the first boot mode to the second boot mode. Exemplarily, if the boot mode of the current boot device of the OS is the legacy mode, the boot mode is directly adjusted to the BIOS UEFI mode. This adjustment is based on the assumption that the mismatch of configuration information may be caused by hardware changes.

[0063] If the hardware configuration information of the current boot device of the OS is consistent with the historical configuration information of the OS, the match is successful, indicating that no hardware changes have occurred from the time when the OS successfully booted to the time when the OS failed to boot this time, and there is no disk plug-in and unplug event. Therefore, it can be seen that the reason for the failure to load the OS is not in the hardware, but in other aspects (such as software or configuration). At this time, the BMC will obtain the boot mode of the OS boot device when the OS is successfully loaded as the second boot mode, and switch the boot mode of the current boot device of the OS from the first boot mode to the second boot mode.

[0064] In some specific implementations, the BMC may determine the second boot mode as a pre-stored boot mode when the kernel-based virtual machine (KVM) installs the OS. In other specific implementations, the BMC may also determine the second boot mode as the boot mode of the OS boot device when the OS is successfully loaded from a log file obtained through an interface (such as a web interface, CLI, or API) provided by the BMC. It is understandable that the log file is a collection of boot modes of the OS boot device when the OS is successfully loaded, and can be saved in the BMC's local storage or a remote server.

[0065] It should be noted that the hardware component of the current boot device of the OS may be a hard disk, a central processing unit, etc. In this embodiment, the hardware component of the current boot device of the OS is a hard disk, and the hardware configuration information of the OS may be disk information, and the disk information includes one or more of the serial number information, model information, capacity information, and interface type information of the hard disk.

[0066] S204: Start the OS in the second boot mode based on the BIOS.

[0067] When the boot mode of the current boot device of the OS is successfully switched to the second boot mode, the BIOS will try to restart the OS in the second boot mode. If the OS boots successfully at this time, it means that the original boot mode (the first boot mode) is the cause of the OS boot failure. At this time, the BMC determines that the cause of the OS boot failure is a boot mode error.

[0068] In some specific implementations, when the cause of the fault is determined to be a boot mode error, the BMC can output the first boot strategy to the user in a variety of ways (such as log files, emails, or text messages, etc.): switching the boot mode of the current boot device of the OS from the first boot mode to the second boot mode. Thus, the BMC can simplify the troubleshooting process and reduce the need for in-depth technical knowledge to solve the problem by suggesting that the user or administrator permanently change the boot mode of the current boot device of the OS from the first boot mode to the second boot mode.

[0069] Furthermore, when the BMC confirms that the OS can be successfully loaded using the second boot mode, the BMC will save the second boot mode to the log file. The log file records that the second boot mode can successfully start the OS under the current hardware and software environment, which is very important for future system maintenance, troubleshooting, and configuration recovery. When a similar problem of being unable to start the OS occurs again, the relevant technicians can refer to the log file to understand how similar problems were solved before, thereby accelerating the fault location and OS startup process.

[0070] In summary, the present application provides an OS startup method. The OS startup method provided in the embodiment of the present application can restart the OS without manual fault cause determination, thereby improving the efficiency of restarting the OS. At the same time, the OS startup method provided in the present application also provides a strong guarantee for the continuous and stable operation of the business, reducing the risk of business interruption caused by OS startup failure.

[0071] Next, combine the attached Figure 4 , an embodiment of the OS startup system of the present application is introduced:

[0072] See also Figure 4 , which is a signaling diagram of an OS boot system provided in an embodiment of the present application. The OS boot system 40 includes a BMC 41 and a BIOS 42 .

[0073] S401: The BMC powers on the OS startup device.

[0074] During the server startup phase, the BMC 41 is responsible for controlling and monitoring the power-on process of the OS startup device, which enables the hardware components of the OS startup device (such as the CPU, memory, hard disk, etc.) to receive power and start initialization operations.

[0075] S402: The BMC determines whether powering on the OS startup device fails. If yes, execute S403; if no, execute S407.

[0076] When BMC41 powers on the OS boot device, BMC41 can continuously monitor the status of the hardware components of the OS boot device to check whether the hardware components can be properly initialized and respond to system commands. If BMC detects that any hardware component fails to initialize or respond to system commands correctly, BMC41 will determine that the power-on fails accordingly.

[0077] It should be noted that the specific method for determining whether power-on fails may vary depending on the hardware configuration of the server, the setting of BIOS 42 and the implementation of BMC 41, and this application does not limit this.

[0078] Once BMC41 determines that the OS boot device fails to power on, BMC41 will execute step S403, that is, use the alarm information and / or other possible power-on failure reasons to perform failure diagnosis. If BMC41 determines that the power-on is successful, BMC will execute step S407, that is, send a power-on success message to BIOS42.

[0079] S403: The BMC performs failure diagnosis using the alarm information and / or other possible power-on failure causes.

[0080] Failure diagnosis refers to diagnosis of the cause of failure of the BMC 41 to power on the boot device of the OS.

[0081] In a specific implementation, the BMC 41 may perform failure diagnosis through alarm information, wherein the alarm information refers to information indicating abnormal conditions received from the OS boot device during the process of the BMC 41 powering on the OS boot device.

[0082] Specifically, the alarm information may include an error code and / or a warning message. Among them, the error code refers to a specific combination of numbers or letters, which is used to uniquely identify a specific cause of failure. See Table 1, which is a schematic table of error codes provided in an embodiment of the present application. The existence of the error code enables BMC41 to quickly identify the cause of the power-on failure, thereby executing the corresponding startup strategy.

[0083] Table 1

[0084] Error Code Cause 0001 Power module failure 0002 Loose power line

[0085] Warning messages are text description messages used to explain error codes or provide additional context information. Warning messages can help maintenance personnel or BMC41 understand more clearly what specific faults have occurred and the specific causes of the faults, so that BMC41 can execute more accurate startup strategies.

[0086] Therefore, BMC41 can determine the cause of failure of BMC41 to power on the OS startup device by analyzing these alarm information, such as power supply problem, hardware failure problem or configuration error problem, and then obtain the startup strategy corresponding to the failure cause.

[0087] In another specific implementation, BMC41 can also perform failure diagnosis through other possible power-on failure reasons. Exemplarily, other possible power-on failure reasons may include: CPLD, BIOS or BMC firmware version mismatch, incorrect hardware configuration of OS boot device, abnormal network connection, etc. This application does not limit this.

[0088] S404: The BMC determines whether the failure diagnosis is successful. If so, execute S405; if not, execute S406.

[0089] In step S403, BMC41 has performed failure diagnosis using the alarm information and / or other possible power-on failure causes. At this time, BMC41 needs to evaluate the result of this failure diagnosis, that is, to determine whether the failure cause obtained in step S403 is correct. Specifically, successful failure diagnosis means that BMC41 has learned the cause of the failure through failure diagnosis, and the cause of the failure has a corresponding startup strategy. Otherwise, it is determined that the failure diagnosis failed.

[0090] Exemplarily, if in step S403 BMC41 has determined that the cause of the power-on failure is: the firmware version of the CPLD, BIOS or BMC41 does not match, and the startup strategy corresponding to the cause of the failure is: remotely obtain the correct firmware version of the mismatched CPLD, BIOS or BMC41, and then upgrade the corresponding firmware version. Then, it can be determined that the failure diagnosis is successful, and step S405 is executed. It should be noted that the above-mentioned "correct firmware version" refers to the firmware version that enables the OS to power on successfully, that is, the firmware version that is suitable for the current OS configuration and will not cause other compatibility or stability issues.

[0091] S405: The BMC outputs a startup strategy corresponding to the fault cause.

[0092] See also Figure 5 , which is a schematic diagram of a startup strategy in a power-on failure scenario provided by an embodiment of the present application. If BMC41 detects in step S403 that the cause of the OS power-on failure is that the firmware version of CPLD, BIOS or BMC41 does not match, and BMC41 determines in step S404 that the failure diagnosis is successful, then BMC41 outputs the startup strategy corresponding to the cause of the failure: after remotely obtaining the correct firmware version, upgrade the firmware version of CPLD, BIOS or BMC41.

[0093] S406: The BMC records a fault log.

[0094] When failure diagnosis fails, the BMC41 records a fault log. These fault logs usually contain detailed information about the power-on failure, alarm information, and any attempted repair measures. The purpose of recording the fault log is for subsequent analysis and troubleshooting, helping operation and maintenance personnel understand the history and context of the fault.

[0095] It should be noted that when recording fault logs, attention should also be paid to ensuring the security and accessibility of the fault logs. For example, the fault logs should be stored in a reliable and easily accessible location of the BMC41 so that they can be quickly retrieved and analyzed when needed. At the same time, the fault logs should take appropriate encryption and permission management measures to protect the fault log data from unauthorized access or tampering.

[0096] S407: The BMC sends a power-on success message to the BIOS.

[0097] If the BMC 41 successfully powers on the current boot device of the OS, the BMC 41 sends a power-on success message to the BIOS 42 .

[0098] S408: The BIOS starts, and starts the OS based on the first boot mode.

[0099] First, BIOS42 starts automatically after receiving the power-on success message sent by BMC41. It should be noted that BMC41 may not send the power-on success message to BIOS42, but after BIOS42 determines that BMC41 has successfully powered on the current boot device of the OS, BIOS42 directly starts and starts the OS based on the first boot mode. This application does not limit this.

[0100] Subsequently, BIOS 42 starts the OS based on the first boot mode. One of the main tasks of BIOS 42 is to load the OS after the current boot device of the OS is powered on successfully. Specifically, BIOS 42 will load and start the OS from the current boot device (such as a hard disk, etc.) based on the first boot mode after performing a series of hardware initialization and self-test processes.

[0101] S409: BIOS determines whether OS loading fails. If so, execute S410.

[0102] If BIOS 42 cannot successfully load OS from the current boot device, it means OS loading failure. OS loading failure may be caused by many reasons, such as damage to the current boot device, damage to the boot sector (the area storing the boot code), configuration error or hardware failure.

[0103] In some examples, BIOS 42 can check the physical connection and status of the current boot device. If the current boot device is correctly connected and in a working state, BIOS 42 determines that the OS is loaded successfully; otherwise, if the current boot device does not respond or is not connected correctly, BIOS 42 determines that the OS fails to load and triggers the subsequent OS boot process.

[0104] In other examples, BIOS42 can also check other key steps in the boot process, such as loading a boot loader (such as GRUB or Windows Boot Loader). Loading a boot loader is one of the key steps in the boot process. The boot loader is a small program that is responsible for loading the core part of the OS. BIOS42 will try to read the boot loader from the boot device and load it into memory. If BIOS42 can successfully load the boot loader and the boot loader can run normally, the BIOS determines that the OS has been loaded successfully; conversely, if an error occurs in the process of loading the boot loader in BIOS42, the BIOS determines that the OS has failed to load and triggers the subsequent OS startup process.

[0105] It should be noted that the method by which BIOS 42 determines whether OS loading fails may vary depending on the BIOS version and OS configuration. This application does not limit the specific method for determining whether OS loading fails.

[0106] If the OS fails to load, step S410 is executed; if the OS is loaded successfully, the OS can continue to start and run without executing the OS startup process disclosed in the embodiment of the present application.

[0107] S410: BIOS records the startup detection information, the hardware configuration information of the current startup device, and the log information.

[0108] Once the OS fails to load, BIOS42 will record the startup detection information, the hardware configuration information of the current startup device, and the log information. Among them, the startup detection information includes the power-on self-test code Postcode, which is used to indicate that the OS failed to start. The hardware configuration information of the current startup device includes disk information, and the disk information includes one or more of the serial number information, model information, capacity information, and interface type information of the hard disk. The log information refers to the log that records the successful power-on and the failed boot, which helps to determine whether the problem occurs after BMC41 powers on the current startup device of the OS.

[0109] When BIOS42 records the startup detection information, the hardware configuration information and log information of the current startup device, and saves the startup detection information, the hardware configuration information and log information of the current startup device in the non-volatile memory of BIOS42, BIOS42 will also report the above information to BMC41.

[0110] S411: When the BMC identifies that the OS loading fails, the BMC determines whether the cause of the OS loading failure can be determined based on the hardware configuration information of the current OS boot device and the historical configuration information of the OS. If so, S412 is executed; if not, S414 is executed.

[0111] When the number of times that BMC41 obtains the startup detection information from BIOS42 is higher than the preset number threshold, the execution of step S411 is triggered. It should be noted that the reason for setting the number threshold is to ensure that BMC41 performs failure diagnosis after receiving enough startup detection information, thereby improving the accuracy of determining the cause of the failure of OS loading failure.

[0112] Specifically, the method for determining the cause of the failure of OS loading is as follows: First, BMC41 determines the boot mode (such as legacy mode or BIOS UEFI mode) of the current boot device of the current OS based on the boot detection information. Secondly, BMC41 compares the hardware configuration information of the current boot device of the OS with the historical configuration information of the OS (usually the hardware configuration information of the boot device when the OS is successfully booted). If the configuration information is inconsistent, it means that there is a hardware change (such as hard disk plugging and unplugging), and BMC41 will try to switch the boot mode of the current boot device of the OS from the first boot mode to the second boot mode (such as switching from legacy mode to BIOS UEFI mode) to deal with possible hardware compatibility issues. If the configuration information is consistent, it means that the hardware has not changed, and the problem may be in the software or configuration. At this time, the BMC will try to switch the boot mode of the current boot device of the OS from the first boot mode to the boot mode when the OS is successfully loaded to restore the OS.

[0113] It should be noted that when the OS boot device still fails to start normally after the boot mode is switched, or when the boot mode is confirmed to be correct but the boot device still fails to start, BMC41 needs to take further troubleshooting measures.

[0114] In one possible implementation, if the boot mode of the current boot device of the OS is successfully switched to the second boot mode and BMC41 restarts the server, but the boot device of the OS still fails to start normally, it indicates that the cause of the failure to load the OS is still unknown at this time, and step S414 needs to be executed.

[0115] In another possible implementation, if the boot mode of the current boot device of the OS and the boot mode of the boot device of the OS when the OS is loaded successfully match, the matching result indicates that the boot mode of the current boot device of the OS is correct (that is, the first boot mode is the boot mode when the OS is loaded successfully), but the boot device of the OS still fails to start normally, then it indicates that the cause of the failure is not related to the boot mode error. At this time, the cause of the failure of the OS loading failure is still unknown, and step S414 also needs to be executed.

[0116] S412: The BMC determines a startup strategy according to the fault cause.

[0117] See also Figure 6 , which is a schematic diagram of a startup strategy in a scenario where OS loading fails provided by an embodiment of the present application. In some specific implementations, if the hardware configuration information of the current startup device of the OS fails to match the historical configuration information of the OS, and the cause of the failure is a boot mode error, the startup strategy determined by the BMC41 is: switching the boot mode of the current startup device of the OS from the first boot mode to the second boot mode.

[0118] See also Figure 7 , which is a schematic diagram of another startup strategy in the OS loading failure scenario provided by an embodiment of the present application. In some other specific implementations, if the hardware configuration information of the current startup device of the OS matches the historical configuration information of the OS successfully, and the boot startup mode of the current startup device of the OS (i.e., the first boot startup mode) is inconsistent with the boot startup mode of the startup device of the OS when the OS is successfully loaded, and the cause of the failure is a boot startup mode error, then the startup strategy determined by BMC41 is: switch the boot startup mode of the current startup device of the OS (i.e., the first boot startup mode) to the boot startup mode of the startup device of the OS when the OS is successfully loaded (i.e., the second boot startup mode).

[0119] S413: The BMC outputs a startup strategy corresponding to the fault cause.

[0120] When the cause of the fault is determined to be a boot mode error, BMC41 can output the first boot strategy to the user in a variety of ways (such as log files, emails, or text messages, etc.): switch the boot mode of the current boot device of the OS from the first boot mode to the second boot mode. Thus, BMC41 can simplify the troubleshooting process and reduce the need for in-depth technical knowledge to solve the problem by suggesting that the user or administrator permanently change the boot mode of the current boot device of the OS from the first boot mode to the second boot mode.

[0121] S414: The BMC records a fault log.

[0122] If the OS fails to start successfully, BMC41 will record the relevant fault log, including the specific details of the OS startup failure, the attempted startup mode, the current disk information, etc. After recording the fault log, BMC41 may try other recovery strategies or prompt the operation and maintenance personnel to perform further intervention.

[0123] In summary, the embodiment of the present application discloses an OS startup system. The OS startup system disclosed in the embodiment of the present application can restart the OS without manual fault cause judgment, thereby reducing the risk of misoperation that may occur during the OS startup process, and can also improve the efficiency and accuracy of OS startup. At the same time, the OS startup system provided by the present application also provides a strong guarantee for the continuous and stable operation of the business, reducing the risk of business interruption caused by OS startup failure. In addition, when the OS failure cannot be resolved, the BMC can record detailed fault logs, including details of the startup failure, the attempted startup mode, and the current disk information, etc. These fault logs are crucial for subsequent fault analysis and diagnosis, and provide strong support for operation and maintenance personnel.

[0124] See also Figure 8 , which is a schematic diagram of an OS startup device provided by an embodiment of the present application. The OS startup device 80 comprises: a first startup module 801 , an information acquisition module 802 , a policy determination module 803 and a second startup module 804 .

[0125] The first startup module 801 is used to start the OS based on the first boot startup mode of the basic input and output system BIOS.

[0126] The information acquisition module 802 is used to acquire the startup detection information reported by the BIOS, where the startup detection information is used to indicate that the OS startup fails.

[0127] The policy determination module 803 is used to determine the OS startup policy based on the OS hardware configuration information when the OS startup fails, and the startup policy is used to adjust the OS boot mode from the first boot mode to the second boot mode.

[0128] The second startup module 804 is used to start the OS based on the second boot startup mode of the BIOS.

[0129] In summary, the present application provides an OS startup device, which can restart the OS without manual fault cause determination, thereby improving the efficiency of restarting the OS. At the same time, the OS startup device provided by the present application also provides a strong guarantee for the continuous and stable operation of the business, reducing the risk of business interruption caused by OS startup failure.

[0130] The embodiments of the present application also provide corresponding electronic devices and computer storage media for implementing the OS startup method provided in the embodiments of the present application.

[0131] Among them, the electronic device includes a memory and a processor, the memory is used to store instructions or codes, and the processor is used to execute instructions or codes so that the device executes an OS startup method of any embodiment of the present application.

[0132] The computer storage medium stores codes, and when the codes are executed, the device executing the codes implements the OS startup method described in any embodiment of the present application.

[0133] It should be understood that in the present application, "at least one (item)" means one or more, and "plurality" means two or more. "And / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the objects associated before and after are in an "or" relationship. "At least one of the following" or similar expressions refers to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0134] It should also be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0135] The steps of the method or algorithm described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), a memory, a read-only memory (ROM), an electrically programmable ROM, an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0136] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for starting an operating system OS, characterized in that: The method comprises: Starting the OS in a first boot mode based on a basic input and output system BIOS; Obtaining startup detection information reported by the BIOS, where the startup detection information is used to indicate that the OS startup fails; In the case that the OS fails to start, determining a startup strategy of the OS based on the hardware configuration information of the OS, wherein the startup strategy is used to adjust the boot mode of the OS from the first boot mode to a second boot mode; The OS is started based on the second boot mode of the BIOS.

2. The method according to claim 1, characterized in that: The step of determining the startup strategy of the OS based on the hardware configuration information of the OS includes: Determining a fault type of the OS based on the startup detection information; When the fault type is the failure of OS loading, the startup strategy of the OS is determined according to the hardware configuration information of the current startup device of the OS and the historical configuration information of the OS, wherein the historical configuration information is the hardware configuration information of the startup device of the OS when the OS is successfully started.

3. The method according to claim 2, characterized in that The step of determining the startup strategy of the OS according to the hardware configuration information of the current startup device of the OS and the historical configuration information of the OS comprises: If the hardware configuration information of the current boot device of the OS fails to match the historical configuration information of the OS, the boot policy of the OS is determined to adjust the boot mode of the OS from the first boot mode to the second boot mode.

4. The method according to claim 2, characterized in that: The step of determining the startup strategy of the OS according to the hardware configuration information of the current startup device of the OS and the historical configuration information of the OS comprises: If the hardware configuration information of the current boot device of the OS matches the historical configuration information of the OS successfully, the boot policy of the OS is determined to be to adjust the boot mode of the OS from the first boot mode to the second boot mode, where the second boot mode is the boot mode of the boot device of the OS when the OS is loaded successfully.

5. The method according to claim 3 or 4, characterized in that: The method further comprises: When the boot mode of the current boot device of the OS is successfully switched to the second boot mode, the OS is successfully booted, and it is determined that the cause of the failure to boot the OS is a boot mode error.

6. The method according to claim 5, characterized in that The method further comprises: When the fault cause is a boot mode error, a first boot strategy is output, where the first boot strategy is to switch the boot mode of the current boot device of the OS from the first boot mode to the second boot mode.

7. The method according to claim 6, characterized in that The method further comprises: The second boot mode is saved to a log file, where the log file is used to store the boot mode of the boot device of the OS when the OS is loaded successfully.

8. The method according to claim 1, characterized in that The hardware configuration information includes disk information, and the disk information includes one or more of serial number information, model information, capacity information, and interface type information of the hard disk.

9. The method according to claim 1, characterized in that: The startup detection information includes a power-on self-test code.

10. An electronic device, characterized in that: The electronic device comprises: Memory for storing computer programs or computer instructions; A processor, configured to execute a computer program or computer instruction stored in the memory, so that the electronic device executes the method according to any one of claims 1 to 9.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program or instruction, and when the computer program or instruction is executed, the method according to any one of claims 1 to 9 is implemented.

Images