Operating system loading method and electronic device

Abstract

This application discloses an operating system loading method and an electronic device, relating to the field of operating system technology. Through this application, if the operating system loading fails, when it is determined that the boot device currently loading the operating system is a historical boot device that successfully supported operating system loading at a historical moment, the operating system is automatically reloaded. This can effectively cope with various temporary failures of the boot device during the process of loading the operating system from the boot device, reduce business interruptions caused by temporary failures leading to operating system loading failure, and ensure the business continuity of the server.

Description

Technical Field

[0001] This application relates to the field of operating system technology, and in particular to an operating system loading method and an electronic device. Background Technology

[0002] A boot device is a hardware device used to load the operating system when a server system starts up.

[0003] Since the stability and reliability of the operating system loading process directly affect whether the server can run normally, when the operating system fails to load, it is usually necessary to intervene manually in a timely manner to identify and resolve the fault, such as checking hardware connections and replacing the boot device.

[0004] However, manual intervention requires time to locate and repair the fault, which can affect the continuity of server operations. Summary of the Invention

[0005] This application provides an operating system loading method and an electronic device to at least solve the problem of insufficient continuity of server services in related technologies.

[0006] This application provides an operating system loading method, including:

[0007] Obtain historical device information, which is the device information of at least one historical boot device used when the server successfully loaded the operating system at a historical moment.

[0008] When loading the operating system from the first boot device fails, obtain the first device information corresponding to the first boot device;

[0009] Perform a consistency check between the first device information and the historical device information;

[0010] If the consistency check passes, the first boot device is determined to be one of at least one historical boot device, and the operating system is reloaded from the first boot device.

[0011] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for implementing the steps of any of the above-described operating system loading methods when executing the computer program.

[0012] This application enables automatic reloading of the operating system if the operating system fails to load. If the boot device currently loading the operating system is determined to be a historical boot device that successfully supported operating system loading at a previous time, the operating system can be reloaded automatically. This effectively addresses various temporary failures of the boot device during the process of loading the operating system from the boot device, reduces business interruptions caused by temporary failures leading to operating system loading failures, and ensures the continuity of server services. Attached Figure Description

[0013] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A flowchart of an operating system loading method provided in an embodiment of this application;

[0015] Figure 2 A flowchart for obtaining historical device information is provided for another embodiment of the application;

[0016] Figure 3 A flowchart of an operating system loading method provided in another embodiment of this application;

[0017] Figure 4 This is a schematic diagram of an operating system loading device provided in this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0019] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0020] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0021] Figure 1 This is a flowchart illustrating an operating system loading method provided in an embodiment of this application. This method can be applied to a server that uses a boot device (such as a hard disk) as the operating system storage medium and relies on the boot device when booting the operating system.

[0022] like Figure 1 As shown, the operating system loading method includes the following steps:

[0023] S101. Obtain historical device information.

[0024] Among them, the historical device information refers to the device information of at least one historical boot device used when the server successfully loaded the operating system at a historical moment.

[0025] Historical device information includes device information for at least one historically booted device. Optionally, the device information includes device type, device path, and device serial number. Device type includes hard drives, network interface cards (NICs), etc. Device path is a string describing the hard drive's location in the server hardware topology; device serial number is the hard drive's unique identifier.

[0026] Whenever the server successfully loads the operating system from the boot device, it treats the boot device as a historical device, records the device information of the historical device, and saves it to the server's non-volatile random access memory (NVRAM) for use the next time the operating system is loaded from the boot device.

[0027] Optionally, when saving historical device information, a data deduplication operation can be performed, so that only one copy of the same device information is retained.

[0028] S102. When loading the operating system from the first boot device fails, obtain the first device information corresponding to the first boot device.

[0029] The first boot device is the boot device that the server is currently attempting to load the operating system from. If the server encounters problems such as hardware response timeout, data verification error, or interface communication interruption while attempting to read critical data such as the operating system kernel and initialization program from the first boot device, causing the operating system boot process to fail and revert to the firmware initialization stage, and fails to enter the operating system running state normally, then it is determined that loading the operating system from the first boot device has failed.

[0030] When loading the operating system from the first boot device fails, the first device information corresponding to the first boot device is obtained for consistency verification with historical device information.

[0031] S103. Perform a consistency check between the first device information and the historical device information.

[0032] Consistency verification refers to comparing the key feature fields in the first device information with those in the historical device information to verify whether the first startup device is the same startup device as a certain historical startup device.

[0033] Optionally, the first device information is compared with the device information of each historical device in the historical device information to determine whether there is any device information that is consistent with the first device information.

[0034] If the historical device information includes device information of historical devices that are consistent with the first device information, then the consistency check is determined to be successful; if the historical device information does not include device information of historical devices that are consistent with the first device information, then the consistency check is determined to be unsuccessful.

[0035] S104. If the consistency check passes, the first boot device is determined to be one of at least one historical boot device, and the operating system is reloaded from the first boot device.

[0036] A successful consistency check means that the device information of the first device is consistent with the device information of a historically booted device. This indicates that the first booted device, which is currently failing to load the operating system, once supported the server in successfully loading the operating system. The first booted device has the foundation for normal operation, and the server's failure to load the operating system from the first booted device is most likely due to a temporary fault.

[0037] Once the first boot device is determined to be one of at least one historical boot device, the reboot process is automatically executed. After performing a repair operation on the first boot device, the system attempts to read operating system data, load the kernel, and initialize the program from the first boot device again according to the normal boot logic.

[0038] This application embodiment, by determining that the boot device currently loading the operating system is a historical boot device that successfully supported operating system loading at a historical moment, automatically reloads the operating system if the operating system loading fails. This can effectively cope with various temporary failures of the boot device during the process of loading the operating system from the boot device, reduce business interruptions caused by temporary failures leading to operating system loading failures, and ensure the business continuity of the server.

[0039] In some embodiments, if the consistency check passes, the first boot device is determined to be one of at least one historical boot device, and the operating system is reloaded from the first boot device, including: if the consistency check passes, the operating system is reloaded from the first boot device until the number of times the operating system is loaded from the first boot device reaches a preset threshold.

[0040] After the consistency check passes, the server re-attempts to load the operating system from the first boot device. Since recovery from some temporary failures takes time, multiple attempts to reload the operating system from the first boot device are permitted.

[0041] The server records the number of times it re-attempts to load the operating system from the first boot device. Each time the operating system is loaded from the first boot device, the load count is incremented until a preset threshold is reached, at which point the server stops re-loading the operating system from the first boot device.

[0042] This application embodiment allows the server to reload a certain number of times, thereby meeting the recovery needs of temporary faults as much as possible and improving the success rate of operating system loading. At the same time, by setting a preset threshold number of times, it avoids the server from retrying to load the operating system from the first boot device indefinitely, which would occupy interface resources and affect the normal operation of other components, thus improving the stability of server operation.

[0043] Furthermore, when the number of times the operating system is loaded from the first boot device reaches a preset threshold and loading the operating system from the first boot device fails, a second boot device is determined based on a preset boot device list; the operating system is then loaded from the second boot device.

[0044] The preset startup device list includes multiple startup devices arranged in a predetermined order, and the second startup device is the next startup device after the first startup device in the preset startup device list.

[0045] If the number of times the server attempts to load the operating system from the first boot device reaches a preset threshold and still fails to load the operating system successfully from the first boot device, it indicates that the fault causing the first boot device to be unable to support the normal loading of the operating system may be persistent, such as a permanent hardware failure. In order to avoid the server from failing to operate normally due to continuous attempts to load, it is necessary to switch to another boot device to load the operating system.

[0046] The preset boot device list is a priority sequence of multiple boot devices pre-configured in the server firmware, including various boot devices such as hard drives and network cards. Users can adjust the order of boot devices in the preset boot device list according to business needs, making the boot devices corresponding to core business the first boot devices and the backup boot devices the last boot devices.

[0047] The second startup device is a device listed after the first startup device in the preset startup device list. Its device type can be the same as or different from the first startup device.

[0048] For example, when the first boot device is a hard drive, the second boot device can be another spare hard drive; or, when the first boot device is a hard drive, the second boot device can be a network card.

[0049] If multiple attempts to load the operating system from the first boot device fail, switch the first boot device to the second boot device and attempt to load the operating system from the second boot device. Alternatively, force entry into the Setup menu and wait for maintenance personnel to perform the repair.

[0050] Optionally, when loading the operating system from the second boot device fails, the second device information corresponding to the second boot device is obtained; the consistency of the second device information and the historical device information is checked; if the consistency check passes, the second boot device is determined to be one of at least one historical boot device, and the operating system is reloaded from the second boot device.

[0051] Optionally, if the consistency check passes, the operating system is reloaded from the second boot device until the number of times the operating system is loaded from the second boot device reaches a preset threshold. If the operating system still fails to load successfully, a third device is determined based on a preset boot device list. This process continues until the operating system is successfully loaded.

[0052] This embodiment of the application, when multiple attempts to load the operating system from the first boot device fail, promptly switches to the second boot device based on a preset boot device list. This ensures that the order of boot devices matches user expectations or business needs, thereby fulfilling the user's business deployment intentions. Simultaneously, it allows buffer time for troubleshooting the first boot device, reducing maintenance costs and ensuring server stability.

[0053] In some embodiments, when loading the operating system from the first boot device fails, after obtaining the first device information corresponding to the first boot device, the method further includes: obtaining fault information of the first boot device; when loading the operating system from the first boot device succeeds, determining the number of times to reload the operating system from the first boot device; and adjusting a preset number threshold corresponding to the first device type based on the fault information and the number of loading attempts.

[0054] The first device type is the device type of the first startup device.

[0055] The fault information includes the original error code of the first boot device and the fault scenario characteristics. The fault scenario characteristics characterize the hardware status of the first boot device and other devices or communication links related to the first boot device when the loading of the operating system from the first boot device fails.

[0056] When the server fails to load the operating system from the first boot device and returns to the Basic Input Output System (BIOS) initialization phase, it reads the fault information of the first boot device through the interface. For example, it reads the error log and / or error report register of the first boot device through the standard interface to obtain the original error code, such as the original error code "0x01" representing an interface communication interruption, or the original error code "0x03" representing a data read timeout.

[0057] Simultaneously, the device operating status information of the first started device is read and saved as the fault scenario characteristics of this fault. These fault scenario characteristics are then correlated with the original error code to obtain the fault type. Therefore, the fault type can reflect both the fault manifestation and the environmental causes that triggered the fault, providing a more comprehensive picture than the original error code.

[0058] One possible approach is to determine the fault type using a fault classification model. Fault types are labeled based on the original error codes from multiple failed operating system loads and the device's operating status information. These original error codes and operating status information are then used as input to the fault classification model to be trained, and the labeled fault types are used as the output. This process is then used to train the fault classification model, resulting in the final fault classification model.

[0059] It is understandable that the fault classification model can continue to be optimized as events occur during the loading of the operating system, in order to improve the accuracy of the fault classification model.

[0060] After reloading the operating system at least once on the first boot device and finally successfully loading the operating system, the number of times the loading process was performed is determined.

[0061] Whenever the operating system is successfully loaded, the above-mentioned fault information, the device type of the currently used boot device (e.g., the first boot device), and the number of times it has been loaded are saved as event information. The event information is then categorized according to the device type. Furthermore, the multiple event information corresponding to each device type is comprehensively analyzed to determine the preset number of times threshold corresponding to that device type.

[0062] Specifically, the recoverability parameter of the fault type is adjusted according to the number of loads. The recoverability parameter represents the ease with which the fault type can be recovered during multiple reloads of the operating system, and is negatively correlated with the average number of loads in multiple load events corresponding to the fault type.

[0063] A higher recoverability parameter indicates that the type of failure is easier to recover from during multiple operating system reloads, requiring fewer reloads; a lower recoverability parameter indicates that the type of failure is more difficult to recover from during multiple operating system reloads, requiring more reloads.

[0064] For example, for fault type A, if the operating system can be successfully loaded successfully by reloading only twice in multiple load events, while for fault type B, the operating system needs to be reloaded five times in multiple load events, then the recoverability parameter of fault type A is greater than that of fault type B.

[0065] Furthermore, for each equipment type, recoverability parameters are calculated for each of the various fault types corresponding to that equipment type. The target fault type with the smallest recoverability parameter for each equipment type is determined, and a preset number threshold is determined based on the average number of loads for the target fault type.

[0066] Optionally, for each equipment type, the probability of occurrence of each fault type is calculated. Fault types with an occurrence probability less than a preset probability threshold are not included in the comparison of recoverability parameters. That is, when determining the target fault type with the minimum recoverability parameter for each equipment type, only the recoverability parameters corresponding to fault types with an occurrence probability greater than or equal to the preset probability threshold are compared.

[0067] Optionally, since the preset number of times threshold needs to be an integer, the positive integer closest to the average number of loads and greater than the average number of loads is determined as the preset number of times threshold corresponding to this device type.

[0068] Therefore, based on the number of loads required for different fault types, the preset number of load thresholds for different equipment types are dynamically determined, so that the preset number of load thresholds are more in line with the actual operating status and fault patterns of the equipment type. This can meet the load requirements of multiple fault types corresponding to the equipment type as much as possible, while excluding the influence of fault types with low probability of occurrence, and balancing the efficiency and success rate during reloading.

[0069] Correspondingly, if the operating system is successfully loaded from the first boot device, event information is generated based on the fault information and loading count corresponding to the first boot device. After merging with the previously saved event information, the preset number threshold corresponding to the first device type is re-determined and adjusted in the manner described above.

[0070] This application embodiment utilizes fault information and the number of retry loading attempts to reflect the impact of different device characteristics and actual usage environments on operating system loading, thereby dynamically adjusting the preset number of attempts threshold to make the retry strategy more adaptable to the characteristics of different device types and actual usage environments, further improving the rationality of operating system reloading.

[0071] Figure 2 A flowchart illustrating the process of obtaining historical device information, provided for another embodiment of the application. (For example...) Figure 2 As shown, obtaining historical device information includes:

[0072] S201. Based on the callback function registration operation, register the exit boot service callback function in the basic input / output system.

[0073] Based on the user's callback function registration operation, register an exit boot service callback function in the BIOS to obtain device variables.

[0074] S202. In the exit boot service callback function, call the runtime service to obtain the boot device variables.

[0075] The startup device variable is used to identify historical startup devices.

[0076] When the server system enters the Grand Unified Bootloader (GRUB) stage, the exit boot service callback function is triggered.

[0077] Specifically, in response to the operating system loading to the unified boot loader stage, multiple pre-registered callback functions are triggered, including the exit boot service callback function; in response to the exit boot service callback function being triggered, the runtime service's variable retrieval interface is called through the exit boot service callback function to obtain the boot device variables.

[0078] When the server successfully loads into the GRUB stage via the historical boot device, the Exit Boot Service event is triggered, iterating through and calling all pre-registered callback functions. During this process, the previously registered boot service callback functions are triggered and begin executing their corresponding logic.

[0079] The variable retrieval interface is a standardized functional entry point provided by the runtime service for reading various variable parameters maintained by the system. When the exit bootstrap service callback function is triggered, a preset startup device variable retrieval request is passed to the runtime service's variable retrieval interface. Upon receiving the startup device variable retrieval request, the runtime service verifies its validity. If the validity verification passes, the runtime service retrieves the startup device variables from its own maintained variable database and returns them to the bootstrap service callback function.

[0080] S203. Parse the startup device variables to obtain historical device information.

[0081] The server locates the device path of the historically booted device based on the boot device variable, and then determines the device type, device serial number and other information of the historically booted device to obtain historical device information.

[0082] S204. Save historical device information to the preset storage space.

[0083] The preset storage space can be the server's NVRAM.

[0084] This application embodiment registers an exit boot service callback function, thereby automatically triggering the historical device information acquisition process when the BIOS runs to a specified settlement, without changing the basic logic of loading and starting the operating system, achieving non-intrusive automatic acquisition and reducing operation and maintenance costs.

[0085] Figure 3 This is a flowchart illustrating an operating system loading method according to another embodiment of this application. Figure 3 As shown, the method includes the following steps:

[0086] S301. When loading the operating system from the first boot device fails, obtain the first device information corresponding to the first boot device.

[0087] S302. Determine the device path of the first startup device based on the first device information.

[0088] S303. Determine the device type of the first startup device based on the device path of the first startup device.

[0089] Optionally, if loading the operating system from the first boot device fails, an exit boot service callback function is triggered. Based on the exit boot service callback function, the runtime service is called to obtain the device path of the first boot device. The specific implementation is the same as that for obtaining the device path of historical boot devices, and will not be described in detail here.

[0090] S304. Determine whether the device type of the first startup device matches the preset device type.

[0091] If yes, execute S305; otherwise, execute S308.

[0092] In some scenarios, if the user only wants to execute the operating system loading method of this application on a boot device of a specified device type, or if the historical device information only includes device information of historical boot devices of a preset device type, then it is necessary to determine whether the device type of the first boot device is the preset device type before performing consistency verification. For example, the preset device type is a hard disk.

[0093] If the device type of the first boot device is the preset device type, the consistency check and subsequent operating system reload process will be executed normally; if the device type of the first boot device is not the preset device type, it will be determined that the triggering conditions for the consistency check and subsequent operating system reload process are not met, and the operating system will be loaded directly from the second boot device.

[0094] Optionally, the same judgment process is performed on the second boot device. If loading the operating system from the second boot device fails and the device type of the second boot device is not the preset device type, the above judgment process is continued on the third boot device until the server successfully loads the operating system.

[0095] S305. Determine whether the first startup device is one of at least one historical startup device.

[0096] If yes, proceed to S306; otherwise, proceed to S308.

[0097] S306. Determine whether the number of times the operating system has been loaded from the first boot device has reached the preset threshold.

[0098] If yes, execute S308; otherwise, execute S307.

[0099] S307. Reload the operating system from the first boot device.

[0100] S308, Load the operating system from the second boot device.

[0101] This application embodiment determines whether the device type of the current boot device matches a preset device type before reloading the operating system, and only executes a retry mechanism to reload the operating system if it matches. This makes the retry mechanism more targeted, which can meet the personalized needs of users for different types of boot devices in diverse scenarios and improve the flexibility of the operating system boot method.

[0102] Based on any of the above embodiments, after determining that the first boot device is one of at least one historical boot device, the method further includes: sending retry information to a preset component of the server, the preset component including a serial port and / or a display device, and the retry information including one or more of the device path of the first device, the device type of the first device, and the number of loads.

[0103] When the server attempts to reload the operating system, retry information is sent to a preset component so that operations and maintenance personnel can promptly obtain the current loading or retry status of the operating system through the preset component, thereby improving operations and maintenance efficiency.

[0104] For example, send the retry message "hard disk: xxx:xx:xx.xxx OSfails to start. Restart the machine for the xxx time" to the serial port and / or display device, where hard disk is the device type "hard disk", xxx:xx:xx.xxx represents the device path, and xxx time is the number of times to load.

[0105] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0106] Embodiments of this application also provide an operating system loading device. Figure 4 This is a schematic diagram of an operating system loading device provided in this application. Figure 4 As shown, the operating system loading device 40 includes a first acquisition module 41, a second acquisition module 42, a verification module 43, and a loading module 44. The first acquisition module 41 is used to acquire historical device information, which is the device information of at least one historical boot device used when the server successfully loaded the operating system at a historical time. The second acquisition module 42 is used to acquire the first device information corresponding to the first boot device when loading the operating system from the first boot device fails. The verification module 43 is used to perform consistency verification between the first device information and the historical device information. The loading module 44 is used to determine that the first boot device is one of at least one historical boot device if the consistency verification passes, and to reload the operating system from the first boot device.

[0107] Optionally, the loading module 44 is specifically used to reload the operating system from the first boot device if the consistency check passes, until the number of times the operating system is loaded from the first boot device reaches a preset threshold.

[0108] Optionally, the operating system loading device 40 further includes an adjustment module, which is used to obtain the first device information corresponding to the first boot device and then obtain the fault information of the first boot device when the loading of the operating system from the first boot device fails; when the loading of the operating system from the first boot device is successful, determine the number of times to reload the operating system from the first boot device; and adjust the preset number threshold corresponding to the first device type based on the fault information and the number of loadings, wherein the first device type is the device type of the first boot device.

[0109] Optionally, the first acquisition module 41 includes a registration unit, a calling unit, and a parsing unit; the registration unit is used to register the exit boot service callback function in the basic input / output system according to the callback function registration operation; the calling unit is used to call the runtime service in the exit boot service callback function to obtain the boot device variable when the operating system is successfully loaded from the historical boot device, and the boot device variable is used to identify the historical boot device; the parsing unit is used to parse the boot device variable to obtain the historical device information.

[0110] Optionally, the calling unit is used to trigger multiple pre-registered callback functions in response to the operating system loading to the unified boot loader stage. The multiple pre-registered callback functions include an exit boot service callback function. In response to the exit boot service callback function being triggered, the runtime service's variable retrieval interface is called through the exit boot service callback function to retrieve boot device variables.

[0111] Optionally, the operating system loading device 40 further includes a sending module for sending retry information to a preset component of the server. The preset component includes a serial port and / or a display device. The retry information includes one or more of the following: the device path of the first device, the device type of the first device, and the number of loading attempts.

[0112] Optionally, the loading module 44 is further configured to determine a second boot device based on a preset boot device list when the number of times the operating system is loaded from the first boot device reaches a preset threshold and loading the operating system from the first boot device fails. The preset boot device list includes multiple boot devices arranged in a predetermined order, and the second boot device is the next boot device after the first boot device in the preset boot device list; and load the operating system from the second boot device.

[0113] Optionally, the first device information includes the device path of the first boot device. The operating system loading device 40 further includes a determining module, used to determine the device type of the first boot device based on the device path of the first boot device before performing a consistency check between the first device information and historical device information; the loading module 44 is also used to load the operating system from the second boot device if the device type of the first boot device does not conform to the preset device type.

[0114] Optionally, the verification module 43 is specifically used to compare the first device information with the device information of each historical device in the historical device information; if the historical device information includes the device information of a historical device that is consistent with the first device information, then the consistency verification is determined to be successful.

[0115] For a description of the features in the embodiment corresponding to the operating system loading device, please refer to the relevant description in the embodiment corresponding to the operating system loading method, which will not be repeated here.

[0116] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above-described operating system loading method embodiments.

[0117] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above-described operating system loading method embodiments at runtime.

[0118] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0119] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described operating system loading method embodiments.

[0120] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described operating system loading method embodiments.

[0121] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0122] The above provides a detailed description of an operating system loading method and an electronic device provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. An operating system loading method, characterized in that, The method is applied to a server, and the method includes: Register the exit bootstrap service callback function in the basic input / output system based on the callback function registration operation. In response to the operating system loading to the unified boot loader stage, an Exit Boot Service event is triggered, and multiple pre-registered callback functions are traversed and called, including the exit boot service callback function; In response to the exit boot service callback function being triggered, the runtime service's variable retrieval interface is called through the exit boot service callback function to obtain the startup device variable, which is used to identify the historical startup device; Parse the boot device variable to obtain historical device information, which is the device information of at least one historical boot device used when the server successfully loaded the operating system at a historical moment. When loading the operating system from the first boot device fails, obtain the first device information corresponding to the first boot device; Perform a consistency check between the first device information and the historical device information; If the consistency check passes, the operating system is reloaded from the first boot device until the number of times the operating system is loaded from the first boot device reaches a preset threshold. The method further includes: Analyze multiple event information corresponding to each device type to determine a preset number threshold for the device type. The event information includes fault information, device type, and the number of times the operating system is successfully loaded. For each fault type in the fault information, the recoverability parameter of the fault type is adjusted according to the number of loading events. The recoverability parameter is negatively correlated with the average number of loading events in the multiple loading events corresponding to the fault type. For each device type, recoverability parameters are calculated for the various fault types corresponding to the device type. The target fault type with the smallest recoverability parameter for each device type is determined, and a preset number threshold is determined based on the average number of loads for the target fault type.

2. The method according to claim 1, characterized in that, When loading the operating system from the first boot device fails, after obtaining the first device information corresponding to the first boot device, the method further includes: Obtain fault information of the first startup device; When the operating system is successfully loaded from the first boot device, determine the number of times the operating system will be reloaded from the first boot device; Based on the fault information and the number of loading attempts, the preset number of loading attempts threshold corresponding to the first device type is adjusted, where the first device type is the device type of the first startup device.

3. The method according to claim 1, characterized in that, After determining that the first boot device is one of the at least one historical boot devices, the method further includes: Retry information is sent to a preset component of the server. The preset component includes a serial port and / or a display device. The retry information includes one or more of the following: the device path of the first device, the device type of the first device, and the number of loads.

4. The method according to claim 1, characterized in that, The method further includes: When the number of times the operating system is loaded from the first boot device reaches a preset threshold and loading the operating system from the first boot device fails, a second boot device is determined based on a preset boot device list. The preset boot device list includes multiple boot devices arranged in a predetermined order, and the second boot device is the next boot device after the first boot device in the preset boot device list. The operating system is loaded from the second boot device.

5. The method according to claim 4, characterized in that, The first device information includes the device path of the first startup device. Before performing a consistency check between the first device information and the historical device information, the method further includes: Based on the device path of the first boot device, determine the device type of the first boot device; If the device type of the first boot device does not match the preset device type, the operating system is loaded from the second boot device.

6. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the method as claimed in any one of claims 1 to 5.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 5.

Images