Operating system loading method and electronic equipment

Abstract

The invention discloses an operating system loading method and electronic equipment, and relates to the technical field of operating systems. According to the operating system loading method, if operating system loading fails, when it is determined that starting equipment currently carrying out operating system loading is historical starting equipment successfully supporting operating system loading at the historical moment, reloading of an operating system is automatically carried out; various temporary faults of the starting equipment in the process of loading the operating system from the starting equipment can be effectively handled, service interruption caused by loading failure of the operating system due to the temporary faults is reduced, and service continuity of a server is guaranteed.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of operating systems, and particularly relates to an operating system loading method and an electronic device. BACKGROUND

[0002] A starting device refers to a hardware device used for loading an operating system when a server system starts.

[0003] Since the stability and reliability of the operating system loading process directly affect whether the server can normally run, when the operating system loading fails, manual intervention is usually needed to determine and solve the fault, such as checking hardware connection, replacing the starting device, and the like.

[0004] However, manual intervention needs a certain time to locate and repair the fault, and in this process, the continuity of the server business is affected. SUMMARY

[0005] The present application provides an operating system loading method and an electronic device, to at least solve the problem of insufficient continuity of the server business in the related art.

[0006] The present application provides an operating system loading method, comprising: obtaining historical device information, the historical device information being device information of at least one historical starting device used when the server successfully loads the operating system at a historical moment; when the operating system fails to be loaded from a first starting device, obtaining first device information corresponding to the first starting device; performing consistency verification on the first device information and the historical device information; if the consistency verification passes, determining that the first starting device is one of the at least one historical starting device, and re-loading the operating system from the first starting device.

[0007] The present application further provides an electronic device, comprising: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of any one of the above operating system loading methods.

[0008] Through the present application, if the operating system loading fails, when it is determined that the starting device currently used for loading the operating system is a historical starting device that successfully supports the operating system loading at a historical moment, the operating system is automatically reloaded, various temporary faults of the starting device in the process of loading the operating system from the starting device can be effectively coped with, the business interruption caused by the temporary fault leading to the operating system loading failure is reduced, and the business continuity of the server is ensured. BRIEF DESCRIPTION OF DRAWINGS

[0009] In order to more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. Obviously, the drawings described below are only some of the embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort based on these drawings.

[0010] Figure 1 A flow chart of an operating system loading method provided by an embodiment of the present application; Figure 2 A flow chart of historical device information acquisition provided by another embodiment of the present application; Figure 3 A flow chart of an operating system loading method provided by another embodiment of the present application; Figure 4 A structural schematic diagram of an operating system loading device provided by the present application. DETAILED DESCRIPTION

[0011] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without any creative effort fall within the protection scope of the present application.

[0012] It should be noted that, in the description of the present application, the terms "comprise", "contain" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms "first", "second" and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0013] In order to make the skilled in the art better understand the present application, the present application will be further described in detail below with reference to the drawings and specific embodiments.

[0014] Figure 1 A flow chart of an operating system loading method provided by an embodiment of the present application. The method can be applied to a server, which takes a starting device (such as a hard disk) as an operating system storage medium, and needs to rely on the starting device when starting the operating system.

[0015] As shown in Figure 1 , the operating system loading method comprises the following steps: S101, acquiring historical device information.

[0016] The historical device information is device information of at least one historical boot device used by the server to successfully load an operating system at a historical time.

[0017] The historical device information includes device information of at least one historical boot device. Optionally, the device information includes a device type, a device path, and a device serial number. The device type includes a hard disk, a network card, and the like. The device path is a string describing a position of the hard disk in a hardware topology of the server. The device serial number is a unique identification number of the hard disk.

[0018] Whenever the server successfully loads an operating system from a boot device, the boot device used is recorded as a historical device, and device information of the historical device is recorded and saved to a non-volatile random access memory (NVRAM) of the server, for use in loading the operating system from the boot device next time.

[0019] Optionally, when saving the device information of the historical device, a data deduplication operation is performed, and only one copy of the same device information is retained.

[0020] S102, when loading an operating system from a first boot device fails, first device information corresponding to the first boot device is acquired.

[0021] The first boot device is a boot device currently attempted by the server to load an operating system. When the server attempts to read an operating system kernel, an initialization program, and the like in the first boot device, a hardware response timeout, a data verification error, an interface communication interruption, and the like occur, causing an operating system startup process to fail to proceed normally, returning to an initialization phase of firmware, and failing to normally enter an operating system running state, and thus it is determined that loading the operating system from the first boot device fails.

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

[0023] S103, the first device information is subjected to consistency verification with the historical device information.

[0024] The consistency verification refers to comparing the first device information with key feature fields in the historical device information, to verify whether the first boot device is the same as a certain historical boot device.

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

[0026] If the historical device information includes the device information of the historical device consistent with the first device information, it is determined that the consistency check passes; if the historical device information does not include the device information of the historical device consistent with the first device information, it is determined that the consistency check fails.

[0027] In S104, if the consistency check passes, it is determined that the first starting device is one of the at least one historical starting device, and the operating system is reloaded from the first starting device.

[0028] The consistency check passing means that the device information of the first device is consistent with the device information of a historical starting device, which represents that the first starting device currently performing the operating system loading has supported the server to successfully load the operating system at a historical time, and the first starting device has a basis for normal operation, and the server fails to load the operating system from the first starting device is more likely to be a temporary failure.

[0029] After it is determined that the first starting device is one of the at least one historical starting device, a restart process is automatically performed, and after a repair operation is performed on the first starting device, the operating system data is read from the first starting device again according to the normal starting logic, and the kernel and the initializer are loaded.

[0030] The embodiments of the present application can effectively cope with various temporary failures of the starting device in the process of loading the operating system from the starting device, reduce the business interruption caused by the temporary failure of the operating system loading, and ensure the business continuity of the server, by automatically reloading the operating system when it is determined that the starting device currently performing the operating system loading is a historical starting device that has successfully supported the operating system loading at a historical time, and the operating system loading fails.

[0031] In some embodiments, if the consistency check passes, it is determined that the first starting device is one of the at least one historical starting device, and the operating system is reloaded from the first starting device, including: if the consistency check passes, the operating system is reloaded from the first starting device until the number of times of loading the operating system from the first starting device reaches a preset number threshold.

[0032] After the consistency check passes, the server reattempts to load the operating system from the first starting device. Since the recovery of some temporary failures requires a certain time, multiple attempts are allowed to reload the operating system from the first starting device.

[0033] When the server reattempts to load the operating system from the first starting device, the number of loading times is recorded. The number of loading times is accumulated once every time the operating system is loaded from the first starting device, and the server stops reloading the operating system from the first starting device when the number of loading times reaches a preset number threshold.

[0034] The embodiment of the application can meet the recovery requirement of temporary failure as much as possible by allowing the server to reload for a certain number of times, and improve the success rate of loading the operating system. Meanwhile, by setting a preset number threshold, the server is prevented from repeatedly attempting to load the operating system from the first starting device for an unlimited number of times, occupying interface resources and affecting the normal operation of other components, and the stability of the server operation is improved.

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

[0036] The preset starting device list includes a plurality of starting devices arranged in a predetermined order, and the second starting device is the next starting device of the first starting device in the preset starting device list.

[0037] When the number of times of loading the operating system from the first starting device reaches the preset number threshold and the operating system is still unable to be successfully loaded from the first starting device, it means that the failure causing the first starting device to be unable to normally support the loading of the operating system may be persistent, for example, a permanent hardware failure. In order to avoid the server from being unable to normally operate due to continuous attempts to load, another starting device needs to be switched to load the operating system.

[0038] The preset starting device list is a priority sequence of a plurality of starting devices pre-configured in the server firmware, which includes various starting devices such as hard disks and network cards. The user can adjust the order of the starting devices in the preset starting device list according to the business requirements, and arrange the starting devices corresponding to the core business as the starting devices with high priority and the standby starting devices as the starting devices with low priority.

[0039] The second starting device is the device arranged after the first starting device in the preset starting device list, and the device type of the second starting device can be the same as or different from that of the first starting device.

[0040] For example, when the first starting device is a hard disk, the second starting device can be another standby hard disk; or when the first starting device is a hard disk, the second starting device can be a network card.

[0041] When the loading of the operating system from the first starting device is still unsuccessful after multiple attempts, the first starting device is switched to the second starting device, and the loading of the operating system from the second starting device is attempted. Or, the Setup menu is forced to enter to wait for the maintenance personnel to repair.

[0042] Optionally, when the loading of the operating system from the second starting device fails, second device information corresponding to the second starting device is acquired; consistency check is performed on the second device information and the historical device information; if the consistency check passes, the second starting device is determined to be one of the at least one historical starting device, and the loading of the operating system from the second starting device is restarted.

[0043] Optionally, if the consistency check passes, the loading of the operating system from the second starting device is restarted until the number of times of loading the operating system from the second starting device reaches a preset number threshold, and if the loading of the operating system is still unsuccessful, a third device is determined based on the preset starting device list. In this way, the loading of the operating system is restarted until the loading of the operating system is successful.

[0044] The embodiments of the present application can switch to the second starting device in time based on the preset starting device list when the loading of the operating system from the first starting device fails for multiple times, so that the order of the starting devices meets the user's expectation or business requirement, thereby meeting the user's business deployment intention. Meanwhile, a buffer time is left for the fault repair of the first starting device, thereby reducing the operation and maintenance cost and ensuring the stability of the server operation.

[0045] In some embodiments, when the loading of the operating system from the first starting device fails, after the first device information corresponding to the first starting device is acquired, the method further includes: acquiring fault information of the first starting device; when the loading of the operating system from the first starting device is successful, determining the number of times of loading the operating system from the first starting device; and adjusting a preset number threshold corresponding to the first device type based on the fault information and the number of times.

[0046] The first device type is the device type of the first starting device.

[0047] The fault information includes an original error code of the first starting device and a fault scene feature. The fault scene feature represents the hardware state of the first starting device and other devices or communication links related to the first starting device when the loading of the operating system from the first starting device fails.

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

[0049] Meanwhile, device running state information of the first starting device is read and saved as a fault scene feature of this time of fault. The fault scene feature is associated with the original error code to obtain a fault type. Thus, the fault type can reflect both a fault performance of this time of fault and an environmental cause of the fault, and is more comprehensive than the original error code.

[0050] In a possible implementation, the fault type is determined by a fault classification model. The original error codes and the device running state information when the operating system fails to be loaded multiple times are used to label the fault type, and are used as inputs of the fault classification model to be trained. The labeling result of the fault type is used as an output of the fault classification model to be trained. The fault classification model to be trained is trained to obtain a final fault classification model.

[0051] It can be understood that the fault classification model can be continuously optimized as the event of loading the operating system occurs, so as to improve the accuracy of the fault classification model.

[0052] After the first starting device is reloaded with the operating system at least once and finally successfully loads the operating system, the number of loadings in this loading process is determined.

[0053] Each time the operating system is successfully loaded, the above fault information, a device type of the starting device currently used (for example, the first starting device), and the number of loadings are saved as event information, and are classified according to the device type. Further, multiple event information corresponding to each device type is comprehensively analyzed to determine a preset number threshold corresponding to the device type.

[0054] Specifically, the recoverability parameter of the fault type is adjusted according to the number of loadings. The recoverability parameter represents a degree of difficulty in recovery of the fault type in multiple re-loading processes of the operating system, and is negatively correlated with an average number of loadings in multiple loading events corresponding to the fault type.

[0055] The higher the recoverability parameter is, the easier the fault type is to recover in the multiple re-loading processes of the operating system, and the fewer the required loadings are. The lower the recoverability parameter is, the more difficult the fault type is to recover in the multiple re-loading processes of the operating system, and the more the required loadings are.

[0056] For example, for an A fault type, only 2 re-loadings are required in multiple loading events to successfully load the operating system. For a B fault type, 5 re-loadings are required in multiple loading events to successfully load the operating system. Thus, the recoverability parameter of the A fault type is greater than that of the B fault type.

[0057] Further, for each device type, the recoverability parameters of the plurality of fault types corresponding to the device type are calculated respectively, a target fault type corresponding to the recoverability parameter of each device type is determined, and a preset number threshold is determined based on the average loading number of the target fault type.

[0058] Optionally, for each device type, the occurrence probability of each fault type is counted. For the fault type with an occurrence probability less than a preset probability threshold, the recoverability parameter is not involved in the comparison process. That is, when determining the target fault type corresponding to the recoverability parameter of each device type, only the recoverability parameters of the fault types with an occurrence probability greater than or equal to the preset probability threshold are compared.

[0059] Optionally, since the preset number threshold needs to be an integer, a positive integer closest to the average loading number and greater than the average loading number is determined as the preset number threshold corresponding to the device type.

[0060] Therefore, based on the loading number required by different fault types, the preset number threshold of different device types is dynamically determined, so that the preset number threshold is more consistent with the actual running state and fault law of the device type, and can meet the loading number required by the plurality of fault types corresponding to the device type as much as possible, while excluding the influence of the fault type with a small occurrence probability, balancing the efficiency and success rate during reloading.

[0061] Correspondingly, if the operating system is successfully loaded from the first startup device, event information is generated based on the fault information and the loading number corresponding to the first startup device, and the preset number threshold corresponding to the first device type is adjusted by re-determining the preset number threshold in the above manner after merging with the previously saved event information.

[0062] The embodiment of the application reflects the influence of the characteristics of different devices and the actual use environment on the operating system loading by using the fault information and the retry loading number, and then dynamically adjusts the preset number threshold, so that the retry strategy is more suitable for the characteristics of different device types and the actual use environment, and the rationality of reloading the operating system is further improved.

[0063] Figure 2 A historical device information acquisition flowchart provided by another embodiment is shown in FIG. 6. Figure 2 As shown in FIG. 6, the acquisition of historical device information includes: S201, according to the callback function registration operation, register the exit boot service callback function in the basic input output system.

[0064] According to the callback function registration operation of the user, register the exit boot service callback function for acquiring the device variable in the BIOS.

[0065] S202, calling a runtime service to obtain a boot device variable in the exit boot service callback function.

[0066] The boot device variable is used to identify a historical boot device.

[0067] The exit boot service callback function is triggered when the server system enters a Grand Unified Bootloader (GRUB) phase.

[0068] Specifically, in response to the operating system being loaded into the GRUB phase, a plurality of pre-registered callback functions are triggered, and the plurality of pre-registered callback functions include the exit boot service callback function; in response to the exit boot service callback function being triggered, the exit boot service callback function is used to call a variable obtaining interface of a runtime service to obtain a boot device variable.

[0069] When the server is successfully loaded into the GRUB phase through the historical boot device, an Exit Boot Service event is triggered, and all pre-registered callback functions are traversed and called. In this process, the previously registered boot service callback function is triggered and starts to execute corresponding logic.

[0070] The variable obtaining interface is a standardized function entry provided by the runtime service, and is used to read various variable parameters maintained by the system. When the exit boot service callback function is triggered, a preset boot device variable obtaining request is input to the variable obtaining interface of the runtime service. After the runtime service receives the boot device variable obtaining request, the legality of the boot device variable obtaining request is verified. After the legality verification passes, the runtime service obtains the boot device variable from a variable database maintained by itself and feeds back to the boot service callback function.

[0071] S203, parsing the boot device variable to obtain historical device information.

[0072] The server locates a device path of the historical boot device according to the boot device variable, and further determines device type, device serial number and other information of the historical boot device to obtain the historical device information.

[0073] S204, saving the historical device information to a preset storage space.

[0074] The preset storage space can be an NVRAM of the server.

[0075] The embodiments of the present application register the exit boot service callback function, thereby automatically triggering the obtaining process of the historical device information when the BIOS runs to a specified settlement, without changing the basic logic of loading and starting the operating system, realizing automatic acquisition without invasion, and reducing operation and maintenance costs.

[0076] Figure 3 A flow chart of a method for loading an operating system is provided for another embodiment of the present application. As shown in the figure, the method comprises the following steps: Figure 3 S301, obtaining first device information corresponding to a first boot device when loading the operating system from the first boot device fails.

[0077] S302, determining a device path of the first boot device according to the first device information.

[0078] S303, determining a device type of the first boot device based on the device path of the first boot device.

[0079] Optionally, when loading the operating system from the first boot device fails, a boot service callback function is triggered. Based on the boot service callback function, a runtime service is called to obtain the device path of the first boot device, and the specific implementation manner is consistent with that of obtaining the device path of the historical boot device, which will not be described herein again.

[0080] S304, determining whether the device type of the first boot device conforms to a preset device type.

[0081] If yes, S305 is executed; if no, S308 is executed.

[0082] In some scenarios, if a user only wants to execute the operating system loading method of the present application on a boot device of a specified device type, or the historical device information only includes device information of a historical boot device of a preset device type, it is determined whether the device type of the first boot device is the preset device type before consistency check is performed. For example, the preset device type is a hard disk.

[0083] If the device type of the first boot device is the preset device type, the consistency check and the subsequent reloading of the operating system are normally executed; if the device type of the first boot device is not the preset device type, it is determined that the trigger condition of the consistency check and the subsequent reloading of the operating system is not met, and the operating system is directly loaded from a second boot device.

[0084] Optionally, the same judgment process is executed 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 continuously executed on a third boot device until the server successfully loads the operating system.

[0085] S305, determining whether the first boot device is one of at least one historical boot device.

[0086] If yes, S306 is executed; if no, S308 is executed.

[0087] ​S306, judging whether the number of times of loading the operating system from the first starting device reaches a preset number threshold.

[0088] If yes, performing S308; if no, performing S307.

[0089] S307, reloading the operating system from the first starting device.

[0090] S308, loading the operating system from the second starting device.

[0091] The embodiment of the present application first judges whether the device type of the current starting device conforms to the preset device type before reloading the operating system, and only executes the retry mechanism of reloading the operating system when it conforms, so that the retry mechanism has certain pertinence, can meet the individualized needs of users for different types of starting devices in diversified scenarios, and improves the flexibility of the operating system starting method.

[0092] On the basis of any of the above embodiments, after determining that the first starting device is one of the at least one historical starting device, the method further comprises: sending retry information to a preset component of the server, the preset component comprising a serial port and / or a display device, and the retry information comprising one or more of a device path of the first device, a device type of the first device, and a number of times of loading.

[0093] When the server attempts to reload the operating system, the retry information is sent to the preset component, so that the operation and maintenance personnel can learn the loading state or retry state of the current operating system in time through the preset component, and the operation and maintenance efficiency is improved.

[0094] For example, the retry information "hard disk: xxx:xx:xx.xxx OS fails to start. Restart the machine for the xxx time" is sent to the serial port and / or the display device, wherein hard disk is the device type "hard disk", xxx:xx:xx.xxx represents the device path, and xxx time is the number of times of loading.

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

[0096] The embodiment of the present application also provides an operating system loading device. Figure 4 A structural schematic diagram of an operating system loading device provided by the present application is shown in FIG. 1. Figure 4As shown, the operating system loading apparatus 40 comprises a first obtaining module 41, a second obtaining module 42, a checking module 43, and a loading module 44. The first obtaining module 41 is configured to obtain historical device information, the historical device information being device information of at least one historical boot device used when the server successfully loads the operating system at a historical time. The second obtaining module 42 is configured to obtain first device information corresponding to the first boot device when the operating system fails to be loaded from the first boot device. The checking module 43 is configured to perform consistency checking on the first device information and the historical device information. The loading module 44 is configured to determine that the first boot device is one of the at least one historical boot device if the consistency checking passes, and to load the operating system from the first boot device again.

[0097] Optionally, the loading module 44 is specifically configured to load the operating system from the first boot device again until the number of times of loading the operating system from the first boot device reaches a preset number threshold if the consistency checking passes.

[0098] Optionally, the operating system loading apparatus 40 further comprises an adjusting module configured to obtain failure information of the first boot device after obtaining the first device information corresponding to the first boot device when the operating system fails to be loaded from the first boot device, to determine the number of times of loading the operating system from the first boot device again when the operating system is successfully loaded from the first boot device, and to adjust the preset number threshold corresponding to the first device type based on the failure information and the number of times, the first device type being a device type of the first boot device.

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

[0100] Optionally, the calling unit is configured to trigger a plurality of pre-registered callback functions when the operating system is loaded to a unified boot loader stage, the plurality of pre-registered callback functions including the exit boot service callback function. The exit boot service callback function is triggered in response to the exit boot service callback function. The exit boot service callback function is used to call a variable obtaining interface of the runtime service to obtain the boot device variable.

[0101] Optionally, the operating system loading apparatus 40 further comprises a sending module configured to send 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 a device path of the first device, a device type of the first device, and the number of times of loading.

[0102] 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 of loading the operating system from the first boot device reaches a preset number threshold and the loading of the operating system from the first boot device fails, the preset boot device list comprising a plurality of boot devices arranged in a predetermined order, the second boot device being a next boot device of the first boot device in the preset boot device list; and load the operating system from the second boot device.

[0103] Optionally, the first device information comprises a device path of the first boot device. The operating system loading apparatus 40 further comprises a determining module configured to determine a device type of the first boot device based on the device path of the first boot device before the consistency check of the first device information and the historical device information. The loading module 44 is further configured to load the operating system from a second boot device if the device type of the first boot device does not conform to a preset device type.

[0104] Optionally, the checking module 43 is specifically configured to compare the first device information with the device information of each historical device in the historical device information. If the historical device information comprises the device information of a historical device consistent with the first device information, it is determined that the consistency check is passed.

[0105] The features of the embodiments of the operating system loading apparatus can be referred to the related descriptions of the embodiments of the operating system loading method, which will not be repeated here.

[0106] The embodiments of the present application further provide an electronic device comprising a memory and a processor, the memory storing a computer program, and the processor being configured to run the computer program to perform the steps in any of the embodiments of the operating system loading method.

[0107] The embodiments of the present application further provide a computer readable storage medium storing a computer program, wherein the computer program is configured to perform the steps in any of the embodiments of the operating system loading method when running.

[0108] In an example embodiment, the computer readable storage medium can include, but is not limited to, a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media capable of storing computer programs.

[0109] The embodiments of the present application further provide a computer program product comprising a computer program, the computer program being executed by a processor to perform the steps in any of the embodiments of the operating system loading method.

[0110] The embodiment of the present application further provides another computer program product, comprising a nonvolatile computer readable storage medium, the nonvolatile computer readable storage medium storing a computer program, the computer program being executed by a processor to implement the steps in any of the above operating system loading method embodiments.

[0111] Those skilled in the art can further understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized in electronic hardware, computer software or a combination of both. In order to clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been described in the above description in general terms. Whether the functions are performed 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 the present application.

[0112] The above describes in detail the operating system loading method and electronic device provided by the present application. The principles and implementation modes of the present application are described by applying specific examples. The above description of the embodiments is only applicable to help understand the method of the present application and its core idea. It should be pointed out that for those skilled in the art, without departing from the principles of the present application, some improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. An operating system loading method, characterized in that, The method is applied to a server, and the method includes: 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 first boot device is determined to be one of the at least one historical boot device, and the operating system is reloaded from the first boot device.

2. The method according to claim 1, characterized in that, If the consistency check passes, then determining that the first boot device is one of the at least one historical boot device, and reloading the operating system from the first boot device, includes: 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.

3. The method according to claim 2, 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.

4. The method according to claim 1, characterized in that, The acquisition of historical device information includes: Register the exit bootstrap service callback function in the basic input / output system based on the callback function registration operation; When the operating system is successfully loaded from the historical boot device, the runtime service is called in the exit boot service callback function to obtain the boot device variable, which is used to identify the historical boot device. The historical device information is obtained by parsing the startup device variables.

5. The method according to claim 4, characterized in that, When the operating system is successfully loaded from the historical boot device, the runtime service is called in the exit boot service callback function to obtain the boot device variables, including: 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 startup device variable is obtained by calling the runtime service's variable retrieval interface through the exit boot service callback function.

6. 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 device, 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.

7. The method according to claim 2, 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.

8. The method according to claim 7, 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.

9. The method according to claim 1, characterized in that, The consistency verification between the first device information and the historical device information includes: The first device information is compared with the device information of each historical device in the historical device information; If the historical device information includes device information of a historical device that is consistent with the first device information, then the consistency check is determined to be successful.

10. 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 9.

Images