A computing device startup method, device, medium and product

Abstract

The present invention discloses a computing device startup method, device, medium, and product, relating to the field of computer technology. When detecting that a computing device has failed to boot multiple times in a row, this solution detects the failure type, reducing the user's understanding of the cause of the failure. Based on the failure type, corresponding visual operation suggestion information is output, visually indicating the user's next operation, eliminating the need for the user to repeatedly try different hotkeys or enter the firmware settings interface for troubleshooting, shortening the user's operation process and reducing operational difficulty. Finally, the key event function triggered by the user based on the visual operation suggestion information is executed, and the device is ultimately restarted, greatly improving the flexibility of booting and increasing the efficiency of device maintenance and management.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a computing device startup method, device, medium and product. Background Art

[0002] During the server boot process, the Basic Input / Output System (BIOS) is the first software loaded, responsible for hardware initialization, self-testing, and booting the operating system. Boot devices include hard disk drives (HDDs), preboot execution environments (PXE), and compact disk read-only memories (CDROMs). Due to production testing requirements, PXE booting has become a common method on production lines and in customer rooms, allowing for rapid loading of the boot program and installation of the operating system.

[0003] However, PXE booting presents risks and limitations, such as transmission interruptions caused by network dependencies, high latency that impacts boot speeds, and hardware and software compatibility issues. Currently, there's a lack of visual troubleshooting when PXE booting fails, forcing users to rely on text-based hotkey prompts and physical keystrokes, resulting in lengthy troubleshooting. These issues can lead to customer complaints or production issues, including business interruptions, data loss, and resource waste.

[0004] In view of the above, how to solve the current lack of visual fault analysis when PXE boot fails, which leads to a lengthy troubleshooting process, is an urgent problem that needs to be solved by technical personnel in this field. Summary of the Invention

[0005] The present invention provides a computing device startup method, device, medium and product to at least solve the problem of lack of visual fault analysis when PXE boot fails, resulting in a lengthy troubleshooting process.

[0006] The present invention provides a method for starting a computing device, comprising:

[0007] When a preset number of consecutive startup failures are detected, the failure type of the startup failure is detected;

[0008] Output corresponding visual operation suggestion information according to the fault type; wherein the visual operation suggestion information at least includes the fault code, operation suggestion and corresponding hot key selection prompt;

[0009] Get the key events triggered by the user based on the visual operation suggestion information;

[0010] Trigger the corresponding function according to the key event and execute the device restart.

[0011] The present invention also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any one of the above-mentioned computing device startup methods when executing the computer program.

[0012] The present invention also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned computing device startup methods are implemented.

[0013] The present invention also provides a computer program product, comprising a computer program, which implements the steps of any of the above-mentioned computing device startup methods when executed by a processor.

[0014] The beneficial effect of the present invention is that when it is detected that the computing device has failed to start up for multiple consecutive times, the failure type of the startup failure is detected, thereby reducing the user's cost of understanding the cause of the failure; corresponding visual operation suggestion information is output according to the failure type, that is, the user is instructed to perform the next operation in a visual manner, so that the user does not need to repeatedly try different hot keys or enter the firmware setting interface for troubleshooting, shortening the user's operation process and reducing the difficulty of operation; finally, the key event function triggered by the user according to the visual operation suggestion information is executed, and the device is finally restarted, which greatly improves the flexibility of booting and startup, and improves the efficiency of device maintenance and management.

[0015] In addition, the present invention also provides a computing device startup device, medium and product, with the same effects as above. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Figure 1 A flowchart of a method for starting a computing device provided by an embodiment of the present invention;

[0018] Figure 2 A schematic diagram of a hotkey prompt and PXE polling times implementation scenario provided by an embodiment of the present invention;

[0019] Figure 3 A schematic diagram of a computing device startup device provided by the present invention. DETAILED DESCRIPTION

[0020] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0021] It should be noted that, in the description of the present invention, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. The terms "first," "second," etc., in the present invention are used to distinguish similar objects, and are not used to describe a particular order or precedence.

[0022] In order to enable those skilled in the art to better understand the solutions of the present invention, the present invention is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0023] During the server startup process, due to production testing requirements, PXE booting has become a common method in production lines and customer rooms. It can quickly load the boot program and install the operating system. However, PXE booting has some risks and limitations. First, it relies on a network connection to transmit the operating system image. Network failure or congestion may cause transmission interruptions, resulting in service interruptions and data loss. Second, downloading the image from a remote location will cause high network latency, affecting the server's rapid startup and response time. In addition, PXE booting requires hardware and software compatibility. Older devices or specific hardware models may have compatibility issues, and incompatible or conflicting software versions can also cause boot failures.

[0024] Currently, when a PXE boot fails, users can only rely on textual hotkey prompts and physical keystrokes for troubleshooting. This lack of visual troubleshooting makes the troubleshooting process lengthy and can lead to customer complaints or production issues such as business interruption, data loss, and resource waste. To address these issues, the present invention provides a method for booting a computing device.

[0025] It should be noted that the method provided in this solution is applied to computing devices. The computing device includes basic components such as a central processing unit (CPU), memory, and a motherboard, and has BIOS support and network card support, and a Dynamic Host Configuration Protocol (DHCP) server is required in the network. The DHCP server is used to assign an Internet Protocol (IP) address to the computing device and specify the location of the boot file. At the same time, the computing device needs to provide the download of the system kernel and boot image through the Trivial File Transfer Protocol (TFTP) service. In this embodiment, there is no restriction on the specific type of computing device, for example, it can be a server, a personal computer, or a laptop. The following is a detailed description of the computing device startup method in conjunction with specific embodiments:

[0026] Figure 1 This is a flowchart of a method for starting a computing device provided by an embodiment of the present invention. Figure 1 As shown, the method includes:

[0027] S10: When a preset number of consecutive startup failures are detected, the failure type of the startup failure is detected.

[0028] Specifically, when it is detected that the computing device has failed to boot for a preset number of consecutive times, the failure type of the boot failure is detected. It should be noted that the preset number of times is the number of PXE polling or the number of boot item retries. Among them, PXE polling refers to the number of times the computing device attempts to connect and obtain boot information by broadcasting a DHCP discovery message through the network during the PXE boot process, so as to ensure that the boot information can be successfully obtained in the case of network instability or server response delay. Boot item retry means that when the system cannot load the operating system from the specified boot device, the system automatically retries to boot within a set number of times to solve temporary hardware failures, connection problems or boot configuration errors. Both are intended to improve the reliability and success rate of PXE booting. In this embodiment, there is no limit on the size of the preset number of times.

[0029] At the same time, the failure type of the startup failure is detected, and the cause of the startup failure is specifically analyzed, such as PXE network timeout, or HDD sector error, etc. The specific process of detecting the failure type of the startup failure in this embodiment is not limited and depends on the specific implementation situation.

[0030] S11: Output corresponding visual operation suggestion information according to the fault type.

[0031] The visual operation suggestion information at least includes a fault code, an operation suggestion, and a corresponding hot key selection prompt.

[0032] Furthermore, in this embodiment, corresponding visual operation suggestion information is pre-configured for different fault types; when the fault type is determined, the corresponding visual operation suggestion information can be output according to the fault type.

[0033] It should be noted that visual action suggestion information includes at least the fault code, action suggestion, and corresponding hotkey selection prompt. For example, in a PXE timeout scenario, the fault type "DHCP server unresponsive" and its fault code can be displayed visually, with hotkeys for "Check network cable" and "Replace PXE server" provided, significantly reducing user comprehension effort.

[0034] In this embodiment, there is no limitation on the specific process of outputting corresponding visual operation suggestion information according to the fault type, which depends on the specific implementation situation.

[0035] S12: Acquire a key event triggered by the user according to the visual operation suggestion information.

[0036] S13: triggering a corresponding function according to the key event and executing a device restart.

[0037] Then, it waits for the user to trigger the corresponding hotkey according to the visual operation suggestion information, captures the key events (such as the DEL key, the F11 key, or the F12 key) triggered by the user according to the visual operation suggestion information through the firmware (Basic Input / Output System, BIOS) keyboard driver, and parses the corresponding scan code (for example, DEL=0x04, F11=0x3A, F12=0x3B).

[0038] Finally, the corresponding function is triggered based on the key event, and the device reboots. For example, pressing the DEL key enters the BIOS Setup interface, allowing the user to modify the boot option configuration; pressing the F11 key brings up the Boot menu, displaying all available boot options for the user to select; and pressing the F12 key immediately triggers a PXE boot, skipping the remaining countdown. After the corresponding key function is executed, the device reboots.

[0039] It should be noted that the countdown is a preset period that is activated when a computing device fails to boot. During the countdown, the user is required to perform key operations. If the user does not perform any operation after the countdown ends, the normal power-on self-test (Post) process information will be displayed on the visual page: Press <del>to Setup or F11 to Boot Menu or <f12>to PXE Boot.

[0040] In this embodiment, when it is detected that the computing device has failed to start up for multiple consecutive times, the failure type of the startup failure is detected, thereby reducing the user's cost of understanding the cause of the failure; corresponding visual operation suggestion information is output according to the failure type, that is, the user is instructed to perform the next operation in a visual manner, so that the user does not need to repeatedly try different hot keys or enter the firmware setting interface for troubleshooting, shortening the user's operation process and reducing the difficulty of operation; finally, the key event function triggered by the user according to the visual operation suggestion information is executed, and the device is finally restarted, which greatly improves the flexibility of booting and startup, and improves the efficiency of device maintenance and management.

[0041] Based on the above embodiment, in some embodiments, detecting the fault type of the startup failure includes:

[0042] S100: Determine the fault type based on hardware layer detection, protocol layer analysis, and software behavior analysis.

[0043] Among them, the fault types include at least network boot faults, hardware interaction faults and software configuration faults.

[0044] In this embodiment, the core mechanism for determining the fault type is based on hardware-layer detection, protocol-layer parsing, and software behavior analysis. Specifically, hardware-layer detection involves real-time monitoring of hardware indicators such as the Peripheral Component Interconnect Express (PCIe) bus link status and memory Error Correcting Code (ECC) errors through the Baseboard Management Controller (BMC). For example, if the BMC detects a 0x12 error from the memory controller, it determines that a memory controller communication anomaly exists. Protocol-layer parsing involves parsing the Option field in the DHCP response packet during the PXE boot process. If a valid IP address is not obtained three times in a row (e.g., a PXE-E52 error), a network configuration failure is identified. Software behavior analysis involves recording key nodes in the boot process (e.g., the execution status of the PostManagerHandshake function) in the BIOS log. If the boot item scan fails within a preset time, a boot item enumeration timeout is determined.

[0045] It should be noted that fault types include at least network boot faults, hardware interaction faults, and software configuration faults. The following details how to identify each type of fault:

[0046] (1) Determination of network boot failures;

[0047] Based on the above embodiments, in some embodiments, determining a network boot failure based on hardware layer detection, protocol layer parsing, and software behavior analysis includes:

[0048] S101: When no response is received after repeatedly sending the first number of address resolution requests, and the management controller detects that the physical layer signal of the network port is abnormal, it is determined that the fault type is a network cable abnormality.

[0049] S102: When the pre-boot execution environment client finds no bootable device and the boot sequence in the firmware is an empty set, it is determined that the fault type is no valid boot device.

[0050] S103: When no corresponding provision message is received after repeatedly sending the second number of DHCP discovery messages, and the management controller detects that the Internet Protocol address of the DHCP server does not exist or is incorrect, the fault type is determined to be unresponsiveness of the DHCP server.

[0051] Specifically, when the first number of repeated Address Resolution Protocol (ARP) requests does not receive a response, and the BMC detects an abnormality in the network port physical layer (PHY) signal, the fault type is confirmed to be a network cable abnormality, and the corresponding fault code is PXE-E61. It should be noted that in this embodiment, there is no limit on the first number, for example, it can be 5 times. When the PXE client does not find a bootable device and the boot sequence in the BIOS is an empty set, the fault type is confirmed to be no valid boot device, and the corresponding fault code is PXE-M0F. When the second number of repeated Dynamic Host Configuration Protocol Discovery (DHCP Discover) messages is not received after the corresponding Offer message is received, and the BMC detects that the IP address of the DHCP server does not exist or is incorrect, the fault type is confirmed to be no response from the DHCP server, and the corresponding fault code is PXE-E52. It should be noted that in this embodiment, there is no limit on the second number, for example, it can be 3 times.

[0052] (2) Determination of hardware interaction failures;

[0053] Based on the above embodiments, in some embodiments, hardware interaction faults are determined based on hardware layer detection, protocol layer parsing, and software behavior analysis, including:

[0054] S104: When the management controller reads the status register of the memory controller through the preset communication protocol and returns an error code of 0x12, it is determined that the fault type is a memory controller communication abnormality.

[0055] S105: When no valid device list is returned within a preset time after the startup item scanning function is executed, it is determined that the fault type is a startup item enumeration timeout.

[0056] S106: When the firmware detects that the initialization of the bus device link training has timed out, it determines that the fault type is a bus link training failure.

[0057] Specifically, when the BMC reads the status register of the memory controller through the preset communication protocol and returns the error code 0x12, it is confirmed that the fault type is a memory controller communication abnormality, and the corresponding fault code is BMC-0x01. It should be noted that in this embodiment, there is no restriction on the preset communication protocol, for example, it can be the System Management Bus (SMBus) protocol. When the valid device list is not returned within the preset time after executing the startup item scanning function PostManagerHandshake, the fault type is confirmed to be a startup item enumeration timeout, and the corresponding fault code is BIOS-0x05. It should be noted that in this embodiment, there is no restriction on the preset time, for example, it can be 5s. When the BIOS detects that the link training of the initialized bus device (such as a PCIe device) has timed out (for example, the graphics card does not respond), the fault type is confirmed to be a bus link training failure.

[0058] (3) Determination of software configuration faults;

[0059] Based on the above embodiments, in some embodiments, determining a software configuration fault based on hardware layer detection, protocol layer parsing, and software behavior analysis includes:

[0060] S107: When the startup parameters read from the non-volatile random access memory fail the cyclic redundancy check and the backup parameters corresponding to the startup parameters are available, confirming that the fault type is startup parameter check failure.

[0061] S108: When the firmware detects that the battery voltage is lower than the voltage threshold and the system time is abnormal, it is determined that the fault type is low battery voltage.

[0062] S109: When the management controller detects that the firmware version does not match the current hardware platform version, it determines that the fault type is firmware version incompatibility.

[0063] Specifically, when the boot parameters read from the Non-Volatile Random-Access Memory (NVRAM) fail the Cyclic Redundancy Check (CRC) and the backup parameters corresponding to the boot parameters are available, the fault type is confirmed as a boot parameter check failure, and the corresponding fault code is NVRAM-0x02. When the BIOS detects that the battery (such as the CMOS battery) voltage is lower than the voltage threshold and the system time is abnormal, the fault type is confirmed as low battery voltage, and the corresponding fault code is CMOS-0x01. It should be noted that in this embodiment, there is no restriction on the voltage threshold value, for example, it can be 2.8V. When the BMC detects that the BIOS version does not match the current hardware platform version, for example, the old BIOS does not support the new independent disk redundant array, the fault type is confirmed as firmware version incompatibility, and the corresponding fault code is FW-0x04.

[0064] In this way, network boot failures, hardware interaction failures, and software configuration failures are identified respectively, which significantly reduces the user's understanding cost of startup failures and improves the efficiency of restart processing.

[0065] On this basis, the specific process of determining the visual operation suggestion information corresponding to each fault type is as follows:

[0066] (1) Visualized operational advice for network boot failures;

[0067] Based on the above embodiment, in some embodiments, outputting corresponding visual operation suggestion information according to the fault type includes:

[0068] S111: When the fault type is network cable abnormality, a hotkey prompt is used to check the network cable connection or to switch to a backup network port.

[0069] S112: When the fault type is no valid boot device, a visual menu pops up to guide the user to select a universal serial bus boot disk, or prompts the user to load a default hard disk drive boot item.

[0070] S113: When the fault type is that the DHCP server does not respond, a prompt is given to adjust the polling interval of the DHCP discovery message, or a prompt is given to the user to input the static Internet Protocol address of the DHCP server.

[0071] Specifically, when the fault type is a network cable abnormality, the user is prompted to check the network cable connection through a hotkey, or is prompted to switch to the backup network port. It should be noted that the prompt to switch to the backup network port requires that the current computing device supports switching to the backup network port, otherwise the prompt to switch to the backup network port will not be given. When the fault type is no valid boot device, a visual menu pops up to guide the user to select a Universal Serial Bus (USB) boot disk, or prompts to load the default HDD boot item. When the fault type is no response from the Dynamic Host Configuration Protocol server, the user is prompted to adjust the polling interval of the DHCP Discover message, or is prompted to enter the static IP address of the DHCP server.

[0072] (2) Visualized action suggestions for hardware interaction failures;

[0073] Based on the above embodiment, in some embodiments, outputting corresponding visual operation suggestion information according to the fault type includes:

[0074] S114: When the fault type is memory controller communication abnormality, a prompt is provided to trigger memory hot standby switching, and a memory controller fault report is output.

[0075] S115: When the fault type is startup item enumeration timeout, a prompt is given to skip the current faulty device, or a prompt is given to manually select a startup item using the corresponding hotkey.

[0076] S116: When the fault type is bus link training failure, a prompt is given to reset the bus port, or to re-plug the bus device.

[0077] Specifically, when the fault type is abnormal communication of the memory controller, a prompt is given to trigger memory hot standby switching, and a memory controller fault report is output. It should be noted that the prompt to trigger memory hot standby switching requires that the current computing device supports memory hot standby switching, that is, redundant memory is configured, otherwise there is no prompt to trigger memory hot standby switching. When the fault type is a startup item enumeration timeout, a prompt is given to skip the current faulty device, or a prompt is given to manually select the startup item through the corresponding hot key (such as the F8 key). When the fault type is a bus link training failure, a prompt is given to reset the bus port, such as a prompt to reset the PCIe bus port, or a prompt is given to re-plug the bus device, such as re-plugging the graphics card.

[0078] (3) Visualized operational advice for software configuration failures;

[0079] Based on the above embodiment, in some embodiments, outputting corresponding visual operation suggestion information according to the fault type includes:

[0080] S117: When the fault type is startup parameter verification failure, a prompt is given to load backup parameters, or a prompt is given to reconfigure the startup sequence through the firmware setting page.

[0081] S118: When the fault type is low battery voltage, a warning window pops up to prompt the user to replace the battery, or prompt the user to start the firmware default configuration.

[0082] S119: When the fault type is firmware version incompatibility, a prompt is provided to download and install firmware that is compatible with the current hardware platform version, or a prompt is provided to manually update the firmware through the management controller web page.

[0083] Specifically, when the fault type is a startup parameter verification failure, a prompt is provided to load the backup parameters, or a prompt is provided to reconfigure the startup sequence through the BIOS setup page. When the fault type is low battery voltage, a warning window pops up to prompt the user to replace the battery, or a prompt is provided to boot the firmware to the default configuration to prevent data loss. When the fault type is firmware version incompatibility, a prompt is provided to download and install a BIOS firmware that is compatible with the current hardware platform version, or a prompt is provided to manually update the BIOS firmware through the BMC web page.

[0084] In summary, after determining the fault type, the corresponding visual operation suggestion information can enable the user to determine and select the specific method for the next restart operation, without having to repeatedly try different hotkeys or enter the firmware settings interface for troubleshooting, shortening the user operation process and reducing the difficulty of operation.

[0085] Currently, hotkey interactions in the startup settings of computing devices only support physical keyboard input, which cannot meet the interactive needs of remote maintenance. In order to implement remote maintenance of computing device startup, based on the above embodiments, in some embodiments, obtaining key events triggered by the user based on the visual operation suggestion information includes:

[0086] S121: Receive, through the management controller, a management bus interface command sent by the user through the remote interface.

[0087] S122: Parse the corresponding scan code according to the management bus interface command, and inject the scan code into the firmware to trigger the corresponding key event.

[0088] S123: Outputting a prompt message indicating that the key event has been triggered through the remote interface.

[0089] In this embodiment, after receiving the visual operation suggestion information, the user can choose to trigger the corresponding physical hotkey, or remotely trigger the key through remote maintenance. Specifically, the BMC receives the Intelligent Platform Management Interface (IPMI) command sent by the user through the remote interface. It should be noted that the remote interface can be a visual control interface of another computing device different from the current computing device, and the IPMI command sent by it is used to simulate physical hotkey input, such as SendHotkey=F12.

[0090] After receiving the IPMI command, the BMC parses the corresponding scan code (for example, DEL = 0x04, F11 = 0x3A, F12 = 0x3B) and injects the scan code into the BIOS to trigger the corresponding key event. Simultaneously, a virtual hotkey button is generated on the remote interface, and a local countdown is displayed simultaneously. Finally, a prompt indicating that the key event has been triggered is output on the remote interface, such as indicating that a PXE boot has been remotely triggered.

[0091] In this embodiment, the remote maintenance method of starting hotkey interaction of the device is improved, specifically, the remote administrator is enabled to simulate hotkey operations through IPMI commands, which greatly improves the operation efficiency and operation experience.

[0092] Currently, when a computing device fails to boot, if a reboot is required, the user must enter BIOS Setup to modify parameters such as the boot item priority or the PXE polling times. These cannot be adjusted directly on the fault interface, which interrupts the reboot process and affects reboot efficiency. To address the above issues, based on the above embodiments, in some embodiments, rebooting the device includes:

[0093] S131: Prompt the user to configure startup boot configuration parameters within a preset period.

[0094] The boot configuration parameter is the number of pre-boot execution environment polling times or the startup item priority.

[0095] S132: Determine whether the user configures the boot configuration parameters after the preset period ends; if not, proceed to step S133; if yes, proceed to step S134.

[0096] S133: Restarting the device according to the boot configuration parameters configured last time, and displaying information about the power-on self-test process.

[0097] S134: Restart the device according to the currently configured boot configuration parameters.

[0098] In order to improve the efficiency of the restart process, this embodiment provides real-time parameter adjustment: during the countdown, the user can dynamically modify the PXE polling times through the physical keyboard, touch slider or remote interface, and the adjustment results are displayed in real time on the visual interface.

[0099] Specifically, the user is prompted to configure boot configuration parameters within a preset period. It should be understood that the preset period is a countdown that begins when the computing device confirms a boot failure. In this embodiment, there is no limit on the length of the preset period; for example, it can be 15 seconds. It should also be noted that the boot configuration parameters can be either the PXE polling count or the boot item priority, with the user selecting either based on their specific needs. Furthermore, after configuration, the boot configuration parameters are automatically saved to NVRAM.

[0100] The system then determines whether the user has configured boot configuration parameters after the preset period. If no configuration has been performed, the system reboots according to the last configured boot configuration parameters, using, for example, the last PXE polling times, and displays POST progress information. If the user has configured boot configuration parameters within the preset period, the system reboots according to the newly configured boot configuration parameters without resetting to the BIOS.

[0101] In this embodiment, when executing a device restart, by prompting the user to configure the startup boot configuration parameters within a preset period, it can be ensured that the startup item boot is completed during the countdown without restarting to enter the BIOS, which can shorten the test cycle and improve the efficiency of maintenance and management.

[0102] Based on the above embodiment, in some embodiments, after executing the device restart, the method further includes:

[0103] S135: When the device is restarted according to the configured pre-boot execution environment polling times, determine whether the restart is successful; if not, proceed to step S136; if so, end.

[0104] S136: Determine whether the number of pre-boot execution environment polling times reaches the restart number threshold. If not, proceed to step S137; if so, proceed to step S138.

[0105] S137: Restart the device.

[0106] S138: Terminate the pre-boot execution environment polling and prompt a hot key selection through a visual interface.

[0107] S139: Outputting a prompt message indicating that the pre-boot execution environment fails to boot through the visual interface, and outputting fault information through the management controller.

[0108] To prevent repeated boot failures for the computing device, this embodiment also adds a PXE retry count option in BIOS Setup. This option sets a threshold for the number of retry counts, which serves as a control for the number of PXE polling cycles. Specifically, after a device reboot is executed, a check is performed to determine whether the reboot was successful when the configured PXE polling count is repeated. If the reboot is successful, the current process ends.

[0109] If it is confirmed that the current reboot has failed, a determination is made as to whether the number of PXE polling attempts has reached the reboot threshold. If it is confirmed that the reboot threshold has not been reached, the device reboot is performed again. If it is confirmed that the reboot threshold has been reached, the PXE polling attempt is terminated, and a hotkey selection prompt is displayed through the visual interface, such as a prompt to contact a staff member. At the same time, a prompt indicating that the PXE boot failed is output through the visual interface, and fault information is output through the BMC. It should also be noted that if the user does not respond within a certain period of time after the PXE polling attempt is terminated, the hotkey selection page output through the visual interface remains.

[0110] Furthermore, after a device reboot is executed, if the user successfully reboots the device using the target boot configuration parameters, the boot item corresponding to the target boot configuration parameters is recorded as a frequently used item, and the priority of the frequently used item is increased during the next reboot, thereby improving the efficiency and success rate of the next device reboot. For example, if the user selects HDD boot using the F11 key and the boot is successful, the HDD boot item is recorded as a frequently used item and its priority is increased during the next reboot.

[0111] In this embodiment, by setting the restart count threshold as a control condition for the PXE polling count, repeated startup failures of the computing device are avoided, thereby saving device resource consumption.

[0112] Figure 2 Schematic diagram of the hot key prompt and PXE polling times implementation scenario provided by the embodiment of the present invention. Figure 2 As shown, the hotkey prompt and PXE polling number implementation in the present invention includes the following five scenarios: normal startup (Boot), pressing the DEL key to enter the setup (DEL to Setup), pressing the F11 key to enter the boot menu (F11 to Boot menu), pressing the F12 key to perform PXE boot (F12 to PXE boot), and IPMI boot.

[0113] Among them, in the case of normal Boot, it is implemented by modifying the startup item scanning function PostManagerHandshake; in this function, all startup items are first traversed to find all PXE startup items, and then retries are performed according to the PXE retrycount set under Setup, and jumps are performed according to the setting conditions of Setup, and can respond to hot keys such as F11, F12, and Del.

[0114] DEL to Setup and F11 to Boot menu are implemented by modifying the BootLaunchBootNow function. This function first determines whether the currently selected Boot Option is a PXE boot option. If so, it retries according to the set retry threshold. This mode only retries the selected boot option and jumps back to the Setup or Boot menu if it fails.

[0115] The F12 to PXE boot function is implemented by modifying the PXE boot function, PxeBoot. PxeBoot is called during the hotkey check in PostManagerHandshake. The PxeBoot function exits PostManagerHandshake. The rest of the process is similar to a normal boot process: it first iterates through all boot items, finds all PXE boot items, then retries according to the PXE retry count configured in Setup, and then jumps based on the Setup conditions.

[0116] IPMI PXE boot is implemented by serializing the IPMI boot request check function OemCheckIpmiBootRequest. This function sets variables based on whether the IPMI command is a PXE boot and whether it is a permanent or single-time PXE boot. The variables are then checked in PostManagerHandshake. The rest of the process is similar to a normal boot: first, all boot items are traversed to identify all PXE boot items, then retries are performed based on the PXE retry count set in Setup, and jumps are made based on the conditions set in Setup. This implementation provides users with greater freedom and flexibility in manipulating boot items, significantly reducing BIOS firmware maintenance costs and avoiding frequent version releases and lengthy testing cycles.

[0117] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0118] Figure 3 This is a schematic diagram of a computing device startup device provided by the present invention. Figure 3 As shown, the device includes:

[0119] The detection module 10 is used to detect the fault type of the startup failure when a preset number of consecutive startup failures are detected.

[0120] The output module 11 is used to output corresponding visual operation suggestion information according to the fault type; wherein the visual operation suggestion information at least includes the fault code, operation suggestion and corresponding hot key selection prompt.

[0121] The acquisition module 12 is used to acquire the key events triggered by the user according to the visual operation suggestion information.

[0122] The restart module 13 is used to trigger a corresponding function according to a key event and execute a device restart.

[0123] In some embodiments, the detection module 10 includes:

[0124] Fault determination module, used to determine the fault type based on hardware layer detection, protocol layer parsing and software behavior analysis;

[0125] Among them, the fault types include at least network boot faults, hardware interaction faults and software configuration faults.

[0126] In some embodiments, the fault determination module includes:

[0127] A first confirmation module is configured to, when no response is received after repeatedly sending the first number of address resolution requests and the management controller detects an abnormality in the physical layer signal of the network port, confirm that the fault type is an abnormality in the network cable;

[0128] A second confirmation module is configured to confirm that the fault type is no valid boot device when the pre-boot execution environment client finds no bootable device and the boot sequence in the firmware is an empty set;

[0129] The third confirmation module is used to confirm that the fault type is that the dynamic host configuration protocol server is unresponsive when no corresponding provision message is received after repeatedly sending the dynamic host configuration protocol discovery message for a second number, and the management controller detects that the Internet Protocol address of the dynamic host configuration protocol server does not exist or is incorrect.

[0130] In some embodiments, the fault determination module includes:

[0131] a fourth confirmation module, configured to confirm that the fault type is a memory controller communication abnormality when the management controller reads the status register of the memory controller through a preset communication protocol and returns an error code of 0x12;

[0132] a fifth confirmation module, configured to confirm that the fault type is a startup item enumeration timeout when no valid device list is returned within a preset time after the startup item scan function is executed;

[0133] The sixth confirmation module is configured to confirm that the fault type is a bus link training failure when the firmware detects that the initialization of the bus device link training has timed out.

[0134] In some embodiments, the fault determination module includes:

[0135] a seventh confirmation module, configured to, when the startup parameters read from the non-volatile random access memory fail the cyclic redundancy check and the backup parameters corresponding to the startup parameters are available, confirm that the fault type is a startup parameter check failure;

[0136] an eighth confirmation module, configured to confirm that the fault type is low battery voltage when the firmware detects that the battery voltage is lower than a voltage threshold and the system time is abnormal;

[0137] The ninth confirmation module is configured to confirm that the fault type is firmware version incompatibility when the management controller detects that the firmware version does not match the current hardware platform version.

[0138] In some embodiments, the output module 11 includes:

[0139] The first output submodule is used to prompt the user to check the network cable connection or switch to the backup network port through a hotkey prompt when the fault type is a network cable abnormality;

[0140] The second output submodule is used to pop up a visual menu to guide the user to select a universal serial bus boot disk or prompt the user to load the default hard disk drive boot item when the fault type is no valid boot device;

[0141] The third output submodule is used to prompt the user to adjust the polling interval of the dynamic host configuration protocol discovery message or to prompt the user to input the static Internet Protocol address of the dynamic host configuration protocol server when the fault type is that the dynamic host configuration protocol server does not respond.

[0142] In some embodiments, the output module 11 includes:

[0143] The fourth output submodule is used to prompt triggering of memory hot standby switching and output a memory controller fault report when the fault type is memory controller communication abnormality;

[0144] The fifth output submodule is used to prompt to skip the current faulty device or to manually select a startup item through the corresponding hotkey when the fault type is startup item enumeration timeout;

[0145] The sixth output submodule is used to prompt the user to reset the bus port or to re-plug or re-unplug the bus device when the fault type is bus link training failure.

[0146] In some embodiments, the output module 11 includes:

[0147] The seventh output submodule is used to prompt the user to load backup parameters or reconfigure the startup sequence through the firmware setting page when the fault type is startup parameter verification failure;

[0148] The eighth output submodule is used to pop up a warning window to prompt the user to replace the battery or to start the firmware default configuration when the fault type is low battery voltage;

[0149] The ninth output submodule is used to prompt the user to download and install a firmware that is compatible with the current hardware platform version, or to prompt the user to manually update the firmware through the management controller web page when the fault type is incompatible firmware version.

[0150] In some embodiments, the acquisition module 12 includes:

[0151] A receiving module, configured to receive, through the management controller, a management bus interface command sent by a user through a remote interface;

[0152] A parsing module, configured to parse the corresponding scan code according to the management bus interface command and inject the scan code into the firmware to trigger the corresponding key event;

[0153] The tenth output submodule is used to output a prompt message indicating that a key event has been triggered through a remote interface.

[0154] In some embodiments, the restart module 13 includes:

[0155] A user prompt module is used to prompt the user to configure the boot configuration parameters within a preset period; wherein the boot configuration parameters are the number of pre-boot execution environment polling times or the boot item priority;

[0156] The first judgment module is used to judge whether the user configures the startup boot configuration parameters after the preset period ends; if not, the first restart submodule is triggered; if so, the second restart submodule is triggered.

[0157] The first restart submodule is used to restart the device according to the boot configuration parameters configured last time and display power-on self-test process information.

[0158] The second restart submodule is used to execute device restart according to the boot configuration parameters configured this time.

[0159] In some embodiments, the apparatus further comprises:

[0160] The second judgment module is used to judge whether the device restart is successful when the device restart is executed according to the pre-boot execution environment polling number configured this time; if not, trigger the third judgment module.

[0161] The third judgment module is used to determine whether the number of pre-boot execution environment polling times reaches the restart number threshold; if it is determined that the restart number threshold has not been reached, the device restart is executed again; if it is determined that the restart number threshold has been reached, the pre-boot execution environment polling is terminated and a hotkey selection is prompted through a visual interface;

[0162] The fault information output module is used to output prompt information of the failure of the pre-boot execution environment to boot through a visual interface, and output fault information through the management controller.

[0163] In some embodiments, the apparatus further comprises:

[0164] A recording module is used to record the startup item corresponding to the target boot configuration parameter as a common item when the user successfully restarts the device according to the target boot configuration parameter;

[0165] Priority setting module, used to increase the priority of frequently used items at the next restart.

[0166] For the description of the features in the embodiment corresponding to the computing device startup device, please refer to the relevant description of the embodiment corresponding to the computing device startup method, and no further details will be given here.

[0167] An embodiment of the present invention further provides an electronic device, comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned computing device startup method embodiments.

[0168] An embodiment of the present invention further provides a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps of any of the above-mentioned computing device startup method embodiments when running.

[0169] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0170] An embodiment of the present invention further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps of any of the above-mentioned computing device startup method embodiments are implemented.

[0171] An embodiment of the present invention also provides another computer program product, including a non-volatile computer-readable storage medium, the non-volatile computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, implementing the steps of any of the above-mentioned computing device startup method embodiments.

[0172] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0173] The above is a detailed introduction to a computing device startup method, device, medium and product provided by the present invention. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, the present invention can also be improved and modified in a number of ways, and these improvements and modifications also fall within the scope of protection of the present invention. < / del>

Claims

1. A method for starting a computing device, characterized in that: include: When a preset number of consecutive startup failures are detected, the failure type of the startup failure is detected; Outputting corresponding visual operation suggestion information according to the fault type; wherein the visual operation suggestion information at least includes the fault code, operation suggestion and corresponding hot key selection prompt; Acquire a key event triggered by the user according to the visual operation suggestion information; Trigger the corresponding function according to the key event and execute device restart; The types of startup failures detected include: Determine the fault type based on hardware layer detection, protocol layer analysis and software behavior analysis; The fault types include at least network boot faults, hardware interaction faults and software configuration faults. Determine the network boot failure based on hardware layer detection, protocol layer analysis, and software behavior analysis, including: When no response is received after repeatedly sending the first number of address resolution requests, and the management controller detects that the physical layer signal of the network port is abnormal, it is determined that the fault type is a network cable abnormality; When the pre-boot execution environment client finds no bootable device and the boot sequence in the firmware is an empty set, determining that the fault type is no valid boot device; When no corresponding offer message is received after repeatedly sending the second number of DHCP discovery messages, and the management controller detects that the Internet Protocol address of the DHCP server does not exist or is incorrect, the fault type is determined to be unresponsiveness of the DHCP server.

2. The computing device startup method according to claim 1, characterized in that: Determine the hardware interaction fault based on hardware layer detection, protocol layer analysis, and software behavior analysis, including: When the management controller reads the status register of the memory controller through the preset communication protocol and returns an error code of 0x12, it is confirmed that the fault type is a memory controller communication abnormality; When no valid device list is returned within a preset time after the startup item scanning function is executed, it is determined that the fault type is a startup item enumeration timeout; When the firmware detects that the initialization of the bus device link training has timed out, it determines that the fault type is a bus link training failure.

3. The computing device startup method according to claim 1, wherein: Determine the software configuration fault based on hardware layer detection, protocol layer analysis, and software behavior analysis, including: When the startup parameters read from the non-volatile random access memory fail the cyclic redundancy check and the backup parameters corresponding to the startup parameters are available, determining that the fault type is a startup parameter check failure; When the firmware detects that the battery voltage is lower than the voltage threshold and the system time is abnormal, it determines that the fault type is low battery voltage; When the management controller detects that the firmware version does not match the current hardware platform version, it determines that the fault type is firmware version incompatibility.

4. The computing device startup method according to claim 1, characterized in that: Output corresponding visual operation suggestion information based on the fault type, including: When the fault type is that the network cable is abnormal, a hotkey prompt is used to check the network cable connection, or a prompt is given to switch to a backup network port; When the fault type is no valid boot device, a visual menu pops up to guide the user to select a universal serial bus boot disk, or prompts the user to load a default hard disk drive boot item; When the fault type is that the DHCP server does not respond, a prompt is provided to adjust the polling interval of the DHCP discovery message, or a user is prompted to input a static Internet Protocol address of the DHCP server.

5. The computing device startup method according to claim 2, characterized in that: Output corresponding visual operation suggestion information based on the fault type, including: When the fault type is abnormal communication of the memory controller, prompting to trigger memory hot standby switching and outputting a memory controller fault report; When the fault type is startup item enumeration timeout, a prompt is given to skip the current faulty device, or a prompt is given to manually select a startup item using the corresponding hotkey; When the fault type is bus link training failure, a prompt is given to reset the bus port, or to re-plug or re-unplug the bus device.

6. The computing device startup method according to claim 3, characterized in that: Output corresponding visual operation suggestion information based on the fault type, including: When the fault type is the startup parameter verification failure, a prompt is given to load the backup parameters, or a prompt is given to reconfigure the startup sequence through the firmware setting page; When the fault type is low battery voltage, a warning window pops up to prompt the user to replace the battery, or prompts the user to start the firmware default configuration; When the fault type is that the firmware version is incompatible, a prompt is provided to download and install firmware that is compatible with the current hardware platform version, or a prompt is provided to manually update the firmware through the management controller web page.

7. The computing device startup method according to claim 1, characterized in that: Acquiring a key event triggered by the user according to the visual operation suggestion information, including: receiving, through the management controller, a management bus interface command sent by a user through a remote interface; Parsing a corresponding scan code according to the management bus interface command, and injecting the scan code into firmware to trigger the corresponding key event; A prompt message indicating that a key event has been triggered is outputted through the remote interface.

8. The computing device startup method according to any one of claims 1 to 7, characterized in that: Perform a device reboot, including: Prompting the user to configure a startup boot configuration parameter within a preset period; wherein the startup boot configuration parameter is the number of pre-boot execution environment polling times or the startup item priority; Determining whether the user configures the startup boot configuration parameters after the preset period ends; If not, the device will be restarted according to the last configured boot configuration parameters and the power-on self-test process information will be displayed; If so, the device will be restarted according to the boot configuration parameters configured this time.

9. The computing device startup method according to claim 8, characterized in that: After performing a device reboot, also includes: When the device restart is executed according to the configured pre-boot execution environment polling number, determine whether the restart is successful; If it is confirmed that the restart fails, determine whether the number of polling times of the pre-start execution environment reaches the restart number threshold; If it is confirmed that the restart count threshold has not been reached, restart the device again; If it is confirmed that the restart count threshold is reached, the pre-boot execution environment polling is terminated, and a hotkey selection is prompted through a visual interface; The prompt information of the failure of the pre-boot execution environment to boot is output through the visual interface, and the fault information is output through the management controller.

10. The computing device startup method according to claim 8, characterized in that: After performing a device reboot, also includes: When the user successfully restarts the device according to the target boot configuration parameter, the startup item corresponding to the target boot configuration parameter is recorded as a common item; Increase the priority of the frequently used item on the next restart.

11. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the computing device startup method according to any one of claims 1 to 10 when executing the computer program.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the steps of the computing device startup method according to any one of claims 1 to 10 are implemented.

13. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the computing device startup method according to any one of claims 1 to 10 are implemented.

Images