Operation system updating method, electronic equipment, storage medium and program product

Abstract

The invention discloses an operating system updating method, electronic equipment, a storage medium and a program product, and relates to the technical field of computers, the operating system updating method comprises the following steps: updating a target operating system by using a total updating file, and when a to-be-updated unit supports online incremental updating, performing online incremental updating on the target operating system by using an updating sub-file in the to-be-updated unit, therefore, the target operating system can complete system updating on line, and when the to-be-updated unit does not support online incremental updating, the total updating file can be utilized to perform restart total updating on the target operating system, so that extra tedious steps of obtaining the total updating file are reduced to improve the system updating efficiency, and the updating efficiency of the system is improved. The technical problem that the service continuity and the system performance are affected by system upgrading is solved, and the technical effects that the situation that the system is restarted due to system updating is reduced, so that the service and service continuity can be improved, and the generalization of the operating system updating method can be improved while the system updating efficiency is improved are achieved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an operating system updating method, an electronic device, a computer-readable storage medium, and a computer program product. Background Art

[0002] When updating the operating system, it is usually necessary to restart the operating system to ensure that the new version of the operating system is reliably loaded and runs. However, restarting the operating system will destroy the service environment, so that the provided services are interrupted and business continuity is affected. In addition, updating and restarting the operating system may take a long time, which means that the operating system is in a state of downtime and maintenance for a long time during this period, and a large amount of system resources will be occupied for operating system updates, which may easily lead to poor operating system performance. Summary of the invention

[0003] The present application provides an operating system update method, an electronic device, a computer-readable storage medium, and a computer program product to at least solve the problem in the related art that system upgrades affect business continuity and system performance.

[0004] The present application provides an operating system update method, which includes: obtaining a full update file of a target operating system and a unit to be updated of the target operating system; verifying whether the unit to be updated supports online incremental updates; in response to the unit to be updated supporting the online incremental updates, performing online incremental updates on the unit to be updated using an update subfile of the unit to be updated in the full update file; in response to the unit to be updated not supporting the online incremental updates, restarting the target operating system for a full update using the full update file.

[0005] The present application also provides an electronic device, which includes: a memory and a processor; the memory is used to store a computer program; and the processor is used to implement the steps of any of the above-mentioned operating system update methods when executing the computer program.

[0006] The present application also provides a computer-readable storage medium, in which a computer program is stored, wherein when the computer program is executed by a processor, the steps of any of the above-mentioned operating system updating methods are implemented.

[0007] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned operating system update methods when executed by a processor.

[0008] Through the present application, a single full update file can be used to be compatible with online incremental updates and restart full updates. When the unit to be updated supports online incremental updates, the update subfile therein is used to perform online incremental updates on the target operating system, so that the target operating system can complete the system update online, and when the unit to be updated does not support online incremental updates, the full update file can be used to restart the target operating system for a full update, thereby reducing the cumbersome steps of additionally obtaining the full update file to improve the system update efficiency. Therefore, the technical problem of system upgrades affecting business continuity and system performance can be solved, and the situation of system updates and restarts can be reduced, thereby improving the continuity of services and businesses, and while improving the system update efficiency, the technical effect of improving the generalizability of the operating system update method can also be achieved. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0010] Figure 1 This is a flow chart of an embodiment of an operating system update method of the present application; Figure 2 This is a flowchart of another embodiment of the operating system update method of the present application; Figure 3 A flowchart of an embodiment of planning a reload sequence for this application; Figure 4 This is a schematic diagram of the structure of an embodiment of the dependency relationship of this application; Figure 5 This is a schematic diagram of the structure of an embodiment of the present application that relies on topology 1; Figure 6 A flowchart of an embodiment of obtaining a sorting queue for this application; Figure 7 A flowchart of an embodiment of updating a target operating system according to the present application is shown. DETAILED DESCRIPTION

[0011] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0012] It should be noted that, in the description of this application, the terms "include", "comprise" or any other variant thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. 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.

[0013] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below in conjunction with the accompanying drawings and specific implementation methods.

[0014] In conjunction with the specific application environment architecture or the specific hardware architecture on which the execution of the operating system update method depends, the specific application environment architecture or the specific hardware architecture is described herein.

[0015] First, the main definitions involved in this application are explained. This application is a method for updating an operating system. Update refers to the deletion, modification, addition, etc. of existing files and functions of the operating system. In addition, this application mainly involves two operating system update methods, namely full update (i.e., the restart full update described in the previous text of this application) and incremental update (i.e., the online incremental update described in the previous text of this application).

[0016] Specifically, an operating system can be considered as a built-in program that cooperates with various hardware of a computer to interact with the user. The operating system can be considered as an interface between the user and the computer. For example, according to the environment in which the operating system runs, the operating system can be divided into desktop operating systems, mobile operating systems, server operating systems, embedded operating systems, etc. The operating system can implement functions such as processor management, memory management, device management, file management, and job management.

[0017] Restart full update can be understood as processing the complete data set at each update, regardless of whether the data has changed. As the name implies, when the operating system is restarted, it is often accompanied by a restart of the operating system. The restart full update method is conducive to ensuring data integrity and consistency, and can usually adapt to scenarios that require high accuracy.

[0018] Online incremental update can be understood as processing data that has changed relative to historical updates, and data that has not changed can be left unprocessed. As the name implies, when performing online incremental updates on the operating system, the process of restarting the entire operating system can be reduced, and system units that need to be updated within the operating system can be updated online, which is equivalent to the system units being able to support hot plugging to update them individually and restart the updated system units. In addition, when performing online incremental updates, data that has changed relative to historical updates can be transmitted as update packages. In this way, the online incremental update method can significantly reduce the amount of data transmission and processing time, saving bandwidth and computing resources.

[0019] The system unit of the operating system can be considered as a component, organization, individual, or subsystem with certain functions of the operating system. The system units interact and communicate with each other to form an operating system.

[0020] For example, the system unit of the operating system may include one or more of basic system components, system firmware, and business software modules.

[0021] Specifically, basic system components may include system kernel, Shell, file system, system library, system tools, application programs, tool chain, etc.

[0022] Among them, the system kernel can be considered as the core part of the operating system, which can be responsible for managing system resources, providing hardware and software interfaces, scheduling processes, etc. It can also manage key functions such as memory, processes, file systems and network communications, and can interact with hardware through device drivers. Shell can be considered as the main way for users to interact with the operating system. Users can enter commands through Shell to control the system, manage files, start programs, etc. The file system can be used to manage files and directories, etc. The system library can be used to support the operation of applications. System tools can be used to manage system resources, monitor system status, configure system parameters, etc. Applications can include office software, development tools, databases, etc. The tool chain can be composed of a series of practical tools, such as compilers, debuggers, etc., which can provide users and developers with basic command line operations, file management, compilation, debugging and other functions.

[0023] System firmware can refer to FW (Firmware), which can be considered as the device "driver" stored inside the device, that is, the operating system uses the firmware to implement the operation of a specific machine according to the standard device driver. For example, system firmware can include BIOS (Basic Input Output System), BMC (Baseboard Management Controller), CPLD (Complex Programmable Logic Device), etc.

[0024] Among them, BIOS can save the computer's basic input and output programs, power-on self-test programs, and system self-starting level, etc., and can provide low-level, direct hardware settings and controls for devices. BMC can be considered a dedicated service processor. BMC can use sensors to monitor computers, network servers, and other hardware drive devices. CPLD is a high-density programmable logic device with an integration density of usually more than 1,000 gates, with more input / output signals, product terms, and macro units.

[0025] Business software modules can refer to core business software modules, usually software components that are directly related to the core functions, security, performance and stability of the operating system. At the same time, business software modules can further include basic modules and kernel modules related to the business.

[0026] The kernel module refers to a core business software module that needs to be loaded into the system kernel, and the basic module refers to a core business software module that does not need to be loaded into the system kernel.

[0027] The following is an example of the detailed working principle of the operating system update method of the present application.

[0028] See also Figure 1 , Figure 1 This is a flowchart of an embodiment of the operating system updating method of the present application.

[0029] S101: Obtaining a full update file of a target operating system and a unit to be updated of the target operating system.

[0030] In this embodiment, the target operating system refers to the operating system currently to be updated, which may include operating systems applied to servers, personal computers, embedded systems, etc.

[0031] As the name implies, update files can be used to modify and improve existing operating systems to fix known issues, improve system performance and security, enhance functions, etc. In layman's terms, update files can be update packages, etc., which usually include patches, updates, etc. It can be understood that a full update file refers to an update file that can be used to restart the target operating system and perform a full update.

[0032] The unit to be updated represents the system unit that will change when the target operating system is updated for the current time. In other words, the system unit may include the unit to be updated that is currently to be updated, and the unit to be updated may be one or more of the system units. As described above, the unit to be updated may include one or more of the basic system components, system firmware, and business software modules.

[0033] That is, a full update file for updating the target operating system can be obtained. The information of the unit to be updated can be used as input to obtain the unit to be updated; or, the unit to be updated can be adaptively identified based on the full update file to reduce the cumbersome operation of external confirmation of the unit to be updated when updating the target operating system, and can also improve the operating system update performance.

[0034] S102: Check whether the unit to be updated supports online incremental update.

[0035] In this embodiment, it is possible to directly or indirectly identify whether each unit to be updated supports online incremental update. Compared with being able to identify whether the target operating system has a restart requirement when updating, adaptively selecting the update method of the target operating system based on the verification result can improve the operating system update efficiency while taking into account the reliability of the update process.

[0036] The fact that the unit to be updated supports online incremental update may mean that when the unit to be updated is updated, the independent unit to be updated may be updated and hot-plugged, that is, when the unit to be updated is restarted, there is no need to restart the target operating system.

[0037] S103: In response to the unit to be updated supporting online incremental update, performing online incremental update on the unit to be updated using the update subfile of the unit to be updated in the full update file.

[0038] In this embodiment, when it is determined that the unit to be updated supports online incremental update, it can be considered that the unit to be updated can be independently restarted when the unit to be updated is updated, that is, the unit to be updated can be restarted without restarting the target operating system.

[0039] It is easy to understand that the full update file usually includes the update files of each system unit as update sub-files. The difference is that the update files of the unit to be updated may be different from its current system files, while the update files of the unit not to be updated may match its current system files. Optionally, the update files of the unit to be updated may also match its current system files. The unit to be updated itself may not have an update requirement, but it has a correlation with other units to be updated. For example, when other units to be updated are updated, the unit to be updated needs to be restarted synchronously. This will be explained in detail with examples in the kernel module section later, so I will not go into details here.

[0040] Therefore, in response to the unit to be updated supporting online incremental update, an update subfile in the full update file for updating the unit to be updated may be obtained, and the unit to be updated may be incrementally updated online using the update subfile.

[0041] S104: In response to the unit to be updated not supporting online incremental update, restarting and fully updating the target operating system using the full update file.

[0042] In this embodiment, when it is determined that there is a unit to be updated that does not support online incremental updates, it can be considered that when updating the unit to be updated, there is a need to synchronously restart the target operating system and / or there are risks in performing online incremental updates. Therefore, the full update file can be used to restart the target operating system for a full update, so as to synchronously update each unit to be updated and realize a full update of the target operating system.

[0043] That is to say, the operating system update method in this embodiment is compatible with online incremental updates and restart full updates.

[0044] When the target operating system is updated, it supports both online incremental updates and restart full updates. It is preferred to update the target operating system using online incremental updates. In this way, when the update unit is updated online, the problem of restarting the target operating system update can be overcome, and a service environment can still be provided to maintain service continuity when the target operating system is updated, which can ensure business continuity. In other words, the target operating system can be updated without shutting down, which can ensure the continuous operation of the business and help improve the availability and stability of the target operating system. In addition, it can reduce the situation of frequent restarts due to updates to the target operating system, thereby reducing the risk of frequent restarts leading to poor system stability and reducing maintenance difficulty and cost.

[0045] In this embodiment, when the update unit is updated online, the update efficiency of the target operating system can be significantly improved. It is easy to understand that the online incremental update can update some system units of the target operating system, which can reduce the time of the update process compared to updating the target operating system as a whole. In addition, the update process that takes a long time usually takes up too many system resources, and there is a risk of affecting the operation of core businesses. In this embodiment, the method of performing online incremental updates on the update units separately can reduce the occupation of system resources, so as to reduce the interference with business operations when the target operating system is updated. Furthermore, for large systems, restarting them usually means a long downtime and maintenance window, and there are certain operational risks. In this embodiment, the use of online incremental updates can eliminate the need to restart the target operating system, which can improve the update efficiency and overall performance of the target operating system.

[0046] At the same time, the file sent in this embodiment for updating the target operating system is a full update file. This means that the full update file can also be used to restart the target operating system for full update, that is, when the unit to be updated of the target operating system does not support online incremental update, the full update file can be used to restart the target operating system for full update, which can reduce the tedious steps of obtaining the full update file again and improve the update continuity of the target operating system.

[0047] In addition, it can be seen that, unlike the use of incremental update files to achieve online incremental updates of the target operating system, in this embodiment, the target operating system is updated online incrementally using full update files. Incremental update methods such as traditional patch updates often require binding of update content, system architecture, software storage methods, and other contents. Moreover, when the above content changes, it is extremely likely that a large number of adaptive modifications to the patch update method will be required to adapt to new update requirements, which has the problem of poor scalability and may even easily cause the target operating system to crash. In this embodiment, a flexible update framework is introduced, which can determine whether the unit to be updated needs to restart the target operating system, so that the target operating system can flexibly and quickly respond to changes in the technical environment and diversified user needs, and can also flexibly extract the update sub-files required for the update process from the full update file. It can be seen that compared with the incremental update mode of traditional patch updates, this embodiment can improve the scalability and flexibility of the target operating system.

[0048] In other words, this embodiment can use a single full update file to be compatible with online incremental updates and restart full updates. When the unit to be updated supports online incremental updates, the update sub-file therein is used to perform online incremental updates on the target operating system, so that the target operating system can complete the system update online. And when the unit to be updated does not support online incremental updates, the full update file can be used to restart the full update of the target operating system, reducing the cumbersome steps of obtaining additional full update files to improve the system update efficiency.

[0049] Therefore, the technical problem of system updates affecting business continuity and system performance can be solved, and the situation of restarting due to system updates can be reduced, thereby improving service and business continuity. While improving system update efficiency, the technical effect of improving the generalizability of the operating system update method can also be achieved.

[0050] See also Figure 2 , Figure 2 This is a flowchart of another embodiment of the operating system updating method of the present application.

[0051] S201: Obtain the full update file of the target operating system.

[0052] In this embodiment, obtaining the full update file of the target operating system may be as described in step S101 in the above embodiment, which will not be described in detail here.

[0053] In this embodiment, a full update file is used as input when updating the target operating system, and the full update file is used to adaptively identify the units to be updated of the target operating system. In this way, in this embodiment, the tedious preparation work for updating the target operating system can be performed externally, and there is no need to count the information of the units to be updated, so as to reduce the risk of affecting the update of the target operating system due to incomplete or erroneous information related to the units to be updated.

[0054] Furthermore, in this embodiment, in response to obtaining the full update file for updating the target operating system, the full update file can be decompressed, that is, the full update file can be decompressed to obtain the update subfiles of each system unit, so as to update the system using the update subfiles of each system update unit.

[0055] S202: Perform multi-dimensional verification on the full update file.

[0056] In this embodiment, when the full update file passes the multi-dimensional verification, it can be considered that the current full update file matches the target operating system and the update risk is low, so step S203 can be executed; when the full update file fails the multi-dimensional verification, it can be considered that there is a mismatch between the current full update file and the target operating system and / or there is a risk of update failure, so step S210 can be executed.

[0057] As the name implies, the multi-dimensional verification identifier can perform multi-dimensional verification on the full update file to verify whether the full update file is applicable to updating the target operating system. Optionally, the system verification information carried by the full update file can be parsed; wherein the system verification information identifies the system information of the operating system to which the full update file is applicable. When performing a multi-dimensional verification on the full update file, since the goal is to use the full update file to update the target operating system, the system information of the target operating system is obtained. The system verification information and the system information can be compared to evaluate whether the operating system updated by the full update file is the target operating system. In response to the system verification information matching the system information, it is determined that the full update file can be used to update the target operating system, so that step S203 can be executed. In response to the system verification information not matching the system information, it is determined that the full update file is not applicable to updating the target operating system, so step S210 can be executed.

[0058] Among them, the verification method for multi-dimensional verification of the full update file will be introduced together with the part of forming the full update file in the following text, so it will not be repeated here.

[0059] Furthermore, the current device environment of the current device where the target operating system is located can also be verified to confirm whether the current device meets the operating system update conditions. When it is determined that the current device meets the operating system update conditions, step S203 is allowed to be executed. That is, the full update file can be verified in multiple dimensions, and whether the current device meets the operating system update conditions can also be verified. When the verification results of both verification conditions are passed, step S203 can be executed. When it is determined that the current device does not meet the operating system update conditions, step S210 can be executed. That is, when the full update file is verified in multiple dimensions and whether the current device meets the operating system update conditions are verified, when the verification result of at least one of them fails the verification, step S210 can be executed.

[0060] S203: Acquire the to-be-updated unit of the target operating system.

[0061] In this embodiment, the target version of each system unit in the full update file can be parsed. The target version represents the updated version information of the system unit after the target operating system is updated using the full update file. For example, the target version can be represented by the version information of the update sub-file of the system unit in the full update file, or it can be represented by an independent version rule, which is not limited here.

[0062] The current version information of the system unit can be obtained as the current version of the system unit, so as to compare the current version of the system unit with the target version, thereby evaluating whether the target version matches the current version, so as to automatically determine whether the system unit is a unit to be updated.

[0063] In response to the mismatch between the current version and the target version of the system unit, it can be considered that the system unit after updating is a different version from the current one, that is, the system unit needs to be updated, so the system unit is determined as a unit to be updated.

[0064] In response to the current version of the system unit and the target version matching, it can be considered that even if the system unit is updated, the system unit will not change. It can be considered that the system unit does not necessarily need to be updated, so it can be determined that the system unit is not a unit to be updated.

[0065] However, it should be noted that, considering the kernel modules mentioned above, their updates may involve reloading the system kernel, etc. Therefore, it can be considered that even if the system unit is currently determined not to be a unit to be updated, it does not mean that when the target operating system is incrementally updated online, it will not involve processing such as reloading (i.e. loading after unloading). In other words, even if the system unit is currently determined not to be a unit to be updated, there is a possibility that it will be processed to a certain extent when the target operating system is incrementally updated online. In addition, when it is determined that the update method of the target operating system is to restart the full update, the full update file is used to perform a global update of the target operating system, which will also involve the update of system units that are not units to be updated.

[0066] Furthermore, the unit update information of the unit to be updated may be written into the container file, wherein the unit update information may at least include the unit name and whether it supports online incremental update.

[0067] That is to say, when updating the target operating system, container files such as lists and databases can be created and maintained to store relevant information when updating the target operating system. In order to facilitate the subsequent selection of the target operating system update method, the information on whether each unit to be updated supports online incremental updates can be extracted through the container file, thereby improving the efficiency of selecting the target operating system update method. At the same time, when it is determined that the target operating system is to be incrementally updated online, it can be updated according to the unit update information of the unit to be updated in the container file, which can reduce the risk of missing updates of the unit to be updated, and is also conducive to improving the reliability of the target operating system update through the reliable design of the unit update information in the container file. For example, the reload operation of the kernel module can be recorded, which will be explained in detail later, so it will not be repeated here.

[0068] Furthermore, in this embodiment, the design can be further performed to determine whether the update unit is suitable for online incremental update, thereby facilitating reliable update of the target operating system and improving update efficiency while ensuring the update of the target operating system.

[0069] Specifically, the update method of the target operating system may be selected in combination with the risk of update failure when the system unit is updated online incrementally and / or the unit type.

[0070] That is to say, system units of some unit types can be preset, and when they need to be updated, it is considered that they do not support online incremental updates. Alternatively, the probability of update failure of a system unit during online incremental updates can be evaluated to evaluate whether the system unit is suitable for online incremental updates. When the probability of online incremental update failure reaches a certain threshold, it can be considered that update failure is likely to occur during online incremental updates, so it can be determined that the system unit is not suitable for online incremental updates. Alternatively, system units of some unit types can be preset, and when they need to be updated, it is considered that they do not support online incremental updates; at the same time, the probability of update failure of a system unit during online incremental updates can be evaluated to evaluate whether the system unit is suitable for online incremental updates.

[0071] For example, the preset unit type may include basic system components and system firmware. After obtaining the unit to be updated, the unit type of the unit to be updated may be obtained. In response to the unit type of the unit to be updated including the basic system components and / or the system firmware, it may be determined that there is a unit to be updated that does not support online incremental update. In response to the unit type of the unit to be updated not including the basic system components and the system firmware, it may be determined that each unit to be updated supports online incremental update.

[0072] In combination with the system unit mentioned above, which may include basic system components, system firmware, business software modules including kernel modules and basic modules, the reasons for the design in this embodiment are explained in detail below.

[0073] In this embodiment, it is considered that the basic system components can be regarded as the core of the operating system operation, and it can be considered that updating the basic system components usually involves system-level changes, etc. Therefore, it is considered necessary to restart the target operating system to ensure that the changes in the update process can take effect and maintain the stability and security of the target operating system.

[0074] The update of system firmware usually involves operations at multiple levels, such as system file updates, driver compatibility testing, deployment of security patches, etc. Considering the complexity of the system firmware update mechanism, restarting the operating system is conducive to the execution of these update operations in a relatively "clean" state of the operating system, thereby ensuring the integrity and effectiveness of the update. In other words, by restarting the target operating system, the target operating system can shut down non-essential programs and services to improve the smoothness of the update task. In addition, considering that during the update of the system firmware, it may be necessary to replace or modify some running files, and these files are occupied by other programs or services, restarting the target operating system for update is conducive to reducing the risk of update failure due to file locking, reducing the risk of instability of the target operating system or unrepaired security vulnerabilities, thereby ensuring the reliability of the target operating system update.

[0075] It should be noted that a global judgment can be made on whether the unit to be updated supports online incremental update to obtain overall macro information on whether online incremental update is supported. It is also possible to make a judgment on each unit to be updated separately and write the detailed verification results into the container file.

[0076] Specifically, the unit types of the units to be updated can be obtained respectively to determine whether the unit types of the units to be updated belong to the preset unit types. When it is determined that the unit type of the unit to be updated is one of the preset unit types, it can be considered that the unit to be updated is not suitable for online incremental update, and information that the unit to be updated does not support online incremental update can be written into the container file. When it is determined that the unit type of the unit to be updated is a unit type preset by a non-preset unit type, it can be considered that the unit type of the unit to be updated is suitable for online incremental update.

[0077] When evaluating whether the system unit is suitable for online incremental update, the risk factor of the risk of online incremental update of the system unit can be obtained. That is, the risk factor characterizing the risk of online incremental update of the unit to be updated can be evaluated. In response to the risk factor reaching the risk threshold, it can be determined that the unit to be updated does not support online incremental update. In response to the risk factor not reaching the risk threshold, it can be determined that the unit to be updated supports online incremental update. Among them, the risk factor can be evaluated in real time in combination with at least one of the current device environment, the target operating system update amount, etc., and / or, it can be evaluated in combination with the probability of successful update of the unit to be updated when the operating system is historically updated. Among them, the historically updated operating system may include the current target operating system, or may include other types of operating systems while including the current target operating system, which will not be repeated here.

[0078] Furthermore, system units of some unit types can be preset and considered as not supporting online incremental updates when they need to be updated; at the same time, the probability of update failure of the system unit during online incremental updates can also be evaluated, thereby giving an example of a specific implementation method for evaluating whether the system unit is suitable for online incremental updates.

[0079] Specifically, the unit to be updated can be first macroscopically or individually determined to determine whether the unit type is a preset unit type. When the unit type of a unit to be updated is a preset unit type, it can be considered that the target operating system needs to be restarted and fully updated. Therefore, the risk factor of each unit to be updated can be omitted to effectively reduce the burden of analyzing the target operating system.

[0080] When it is determined that the unit type of the unit to be updated is suitable for online incremental update, the risk factor of the unit to be updated may be evaluated or obtained.

[0081] In response to the risk factor of the unit to be updated not reaching the risk threshold, it can be determined that the unit to be updated supports online incremental update, and the relevant information is written into the location corresponding to the unit to be updated in the container file.

[0082] In response to the risk factor of the unit to be updated reaching the risk threshold, it can be determined that there is a risk of update failure when the unit to be updated performs online incremental update, so it is determined that the unit to be updated does not support online incremental update, and the relevant information is written to the corresponding position of the unit to be updated in the container file. It should be noted that this does not mean that the unit to be updated itself does not support online incremental update, but that the unit to be updated itself can perform online incremental update, but after comprehensive evaluation, it is considered that there is a greater risk of update failure when it is updated through online incremental update, so it is considered that it is not suitable for online incremental update, thereby reducing the tedious operation of repeatedly performing online incremental update when its update fails, and the smoothness of the update can be improved by restarting the full update, and it may even be able to improve the update efficiency.

[0083] S204: Determine whether updating the target operating system requires a restart.

[0084] In this embodiment, when it is determined that the target operating system needs to be restarted after updating, step S205 is executed. When it is determined that the target operating system needs not to be restarted after updating, step S206 is executed.

[0085] For example, in combination with the container file formed in the above steps, the container file contains information on whether the unit to be updated supports online incremental updates. The container file can be traversed to obtain whether each unit to be updated supports online incremental updates. In other words, when there are units to be updated that do not support online incremental updates in the container file, it can be considered that the target operating system needs to be restarted when the target operating system is updated, that is, it can be determined that the target operating system has a restart requirement for updating.

[0086] In an alternative embodiment, it is also possible to independently determine whether the target operating system has a restart requirement when it is updated, which is not described in detail here. When determining whether the target operating system has a restart requirement when it is updated, each unit to be updated can be checked separately.

[0087] S205: Restart and fully update the target operating system using the full update file.

[0088] In this embodiment, in response to the unit to be updated not supporting online incremental update, the target operating system may be restarted and fully updated using the full update file.

[0089] Furthermore, considering that the target operating system needs to be restarted during the process of restarting and fully updating the target operating system, it can be considered that the restart of the target operating system is equivalent to a kind of initialization. In this embodiment, in order to enable the restarted target operating system to automatically continue the update steps, the steps that need to be executed after the target operating system is restarted can be automatically identified, and an automatically executable dynamic script can be generated. The dynamic script is placed in a cloud service associated with the target operating system, so that after the target operating system is restarted, the dynamic script in the cloud service can be automatically executed to automatically continue the update, configuration and other work of the restart of the target operating system, which can reduce the part of the update process of the target operating system that requires manual participation and further improve the performance of the operating system update.

[0090] Specifically, the steps to be executed after the target operating system is restarted can be analyzed to generate a dynamic script. The dynamic script can be linked to the cloud service of the target operating system. The target operating system is fully updated after restart. In response to the restart of the target operating system, the dynamic script can be obtained from the cloud service and executed.

[0091] S206: Performing an online incremental update on the target operating system using the update sub-file.

[0092] In this embodiment, in response to the unit to be updated supporting online incremental update, the update subfile of the unit to be updated in the full update file may be used to perform online incremental update on it.

[0093] As described above, the full update file has been decompressed to obtain the update sub-files of each system unit respectively, and the update sub-files of each unit to be updated can be extracted respectively, and the system files of the unit to be updated can be reloaded as update sub-files.

[0094] Specifically, the system file of the unit to be updated can be updated to an updated sub-file. The permission setting of the updated sub-file is corrected, and the connection between the target operating system and the updated system file is updated. This is equivalent to updating the updated system file path of the unit to be updated and re-creating the soft connection to help ensure that the target operating system and applications can correctly access the updated system file. The unit to be updated whose system file has been updated is hot-swapped independently, that is, the unit to be updated is restarted.

[0095] S207: Determine whether the target operating system is updated successfully.

[0096] In this embodiment, when it is determined that the target operating system is successfully updated, the process ends. When it is determined that the target operating system is not successfully updated, step S208 is executed to timely evaluate whether the target operating system is successfully updated after the target operating system is updated, so that when the target operating system fails to update, it can quickly respond to update exception processing to improve the reliability of the target operating system update.

[0097] Specifically, in response to completing the system update, the current system file of the unit to be updated can be obtained. The current system file and its permissions are verified, so that by verifying the system files and permissions of the system unit, it is indirectly verified whether the target operating system has completed the update. It can be considered that when the current system file matches the full update file and the permission configuration is successful, the target operating system has completed the update. In other words, in this embodiment, it is possible to verify whether the target operating system as a whole has completed the update at a macro level to confirm the effectiveness and reliability of the update, and to implement remedial measures in a timely manner when the update fails, so as to ensure the sustainable operation of the target operating system, reduce the risk of the target operating system being disabled or even affecting services and businesses due to the failure of the target operating system update, and thus significantly improve the reliability of the target operating system.

[0098] Furthermore, after performing online incremental update on the unit to be updated using the update subfile of the unit to be updated in the full update file, the update status of the unit to be updated can be obtained, so as to facilitate timely dynamic adjustment of the update mode according to the update status of the unit to be updated.

[0099] In response to the update status of the unit to be updated indicating that the update is successful, the update status of the next unit to be updated that has completed the update may be verified until the update status of each unit to be updated indicates that the update is successful.

[0100] In response to the update status of the unit to be updated indicating that the update has failed, the target operating system can be restarted and fully updated using the full update file. In this way, the risk of affecting the update of the target operating system or even causing the update failure of the target operating system due to the failed update of the unit to be updated can be reduced. By switching to the restart full update method in a timely manner, the update success rate of the target operating system can be improved, and a certain fault tolerance rate and abnormal self-handling capability can be provided for the operating system update method.

[0101] In other words, it is also possible to verify whether each unit to be updated is updated successfully, so that after the unit to be updated is updated, when it is determined that the update of the unit to be updated fails, it can be tried to perform online incremental update on the unit to be updated again. When the number of update failures of the unit to be updated reaches a preset number, the update method of the target operating system is switched to restart full update, that is, the target operating system is restarted and fully updated using the full update file. Alternatively, once the update of the unit to be updated fails, it can be considered that the unit to be updated is not suitable for online incremental update, and it is promptly switched to restart full update mode to restart full update of the target operating system, thereby improving the efficiency of the target operating system update.

[0102] S208: Perform update exception processing on the target operating system.

[0103] In this embodiment, in response to the target operating system not being updated successfully, update exception processing may be performed on the target operating system.

[0104] In combination with the examples described in the above steps, the current system files and their permissions can be verified. In response to the failure of the verification of the current system files and their permissions, a backup historical update file can be obtained. Among them, the historical update file can represent the full update file used to update the target operating system at a historical moment. For example, the historical update file can be a full update file that successfully updated the target operating system at a historical moment. The target operating system is rolled back using the historical update file to ensure the functionality of the target operating system in the event of a timely target operating system update failure, thereby helping to improve the fault tolerance of the operating system update method, and can also help to ensure the reliability of the target operating system.

[0105] S209: Back up the full update file as a historical update file.

[0106] In this embodiment, as described in step S209, when the target operating system fails to be updated using the full update file, the target operating system can be rolled back using the historical update file.

[0107] Therefore, in response to the target operating system being successfully updated using the full update file, the full update file may be backed up as a historical update file.

[0108] S210: Exit operating system update.

[0109] In this embodiment, in response to the full update file failing the multi-dimensional verification, it can be considered that the full update file is abnormal and / or the full update file is not applicable to the target operating system, and the operating system update can be exited, that is, the target operating system is not updated.

[0110] And / or, as described in the above examples, when the current device environment of the target operating system does not meet the operating system update conditions, the operating system update can be exited.

[0111] Further, as described in the foregoing examples, the system unit may include a business software module. Among them, the business software module may include a basic module and a kernel module that needs to be loaded into the system kernel. In this application, considering that there may be dependencies between kernel modules, when the unit to be updated includes a kernel module, reference will be made to the dependencies between kernel modules. In other words, when the kernel module is overloaded, the kernel module with which it has a dependency can be adaptively overloaded, which is conducive to improving the update effectiveness of the kernel module to be updated and further improving the reliability of the target operating system. The following is an example of the detailed working principle of updating the kernel module when the unit to be updated includes a kernel module.

[0112] See also Figure 3 , Figure 3 A flowchart of an embodiment of planning a reload sequence for this application.

[0113] S301: Query whether the system kernel of the target operating system has loaded the kernel module to be updated.

[0114] In this embodiment, in response to the unit to be updated including a kernel module, it is possible to query whether the system kernel of the target operating system has loaded the kernel module to be updated. In this way, the kernel module loaded into the system kernel and the kernel module not loaded into the system kernel can be updated using different update strategies, respectively, thereby facilitating the reliability of kernel module updates while improving update efficiency.

[0115] For example, the target operating system command may be used to check whether the system kernel of the current device has loaded the kernel module to be updated.

[0116] S302: Update the system file of the kernel module to be updated into its update sub-file, and load it into the system kernel.

[0117] In this embodiment, in response to the target operating system not loading the kernel module to be updated, the system file of the kernel module to be updated can be updated to its update sub-file, and the kernel module to be updated of the updated system file is loaded into the system kernel to complete the update of the kernel module to be updated. The kernel module can also be loaded into the system kernel, thereby improving the efficiency of the target operating system in loading the kernel module, which can be beneficial to optimizing the performance of the target operating system.

[0118] S303: Determine whether there is a kernel module that has a dependency relationship with the kernel module to be updated.

[0119] In this embodiment, when it is determined that there is no kernel module having a dependency relationship with the kernel module to be updated, it can be considered that the kernel module to be updated can be updated and reloaded independently, so step S304 is executed.

[0120] When it is determined that there is a kernel module that has a dependency relationship with the kernel module to be updated, it can be considered that the reloading process of the kernel module needs to be further considered, so step S305 is executed.

[0121] The dependency relationship represents the mutual dependence and association between kernel modules in the target operating system. The dependency relationship can be direct or indirect. Specifically, when a kernel module needs to call the function of another kernel module, and / or use its data, and / or interact with it, it can be considered that an inter-module dependency relationship is formed between the two kernel modules, that is, there is dependency management between the two kernel modules.

[0122] like Figure 4 As shown in the example, Figure 4 This is a structural diagram of an embodiment of the dependency relationship of this application. Figure 4 The dependency relationship between kernel module A, kernel module B and kernel module C is given as an example. Figure 4 The direction shown by the arrow in the middle can be considered as the dependent direction. In other words, Figure 4 The example shows that kernel module A depends on kernel module B and kernel module C.

[0123] In other words, in this embodiment, the kernel module that has a dependency relationship with the kernel module to be updated can be queried. When the kernel module to be updated has been loaded into the system kernel, and it is found through query that there is no kernel module that has a dependency relationship with it, it can be updated in the manner described by example in step S304. However, when the kernel module to be updated has been loaded into the kernel module, and it is found through query that there is a kernel module that has a dependency relationship with it, it can be updated in the manner described in steps S305 to S313.

[0124] Optionally, a dependency file containing the dependency relationships between kernel modules in the target operating system, such as a dependency topology, a dependency list, etc., may be pre-built. If so, the dependency file may be queried to determine whether the kernel mode to be updated has other kernel modules associated with it. Alternatively, after obtaining the kernel module to be updated, the source code of the target operating system may be identified, and other kernel modules associated with the kernel module to be updated may be queried based on the source code, which is not limited here.

[0125] S304: Update the target module system file using the update sub-file, and reload it into the system kernel.

[0126] In this embodiment, in response to the kernel module loaded into the system kernel not having other kernel modules with which it has a dependency relationship, an update subfile of the kernel module to be updated in the full update file can be obtained, so that the kernel module system file to be updated can be updated using the update subfile, and the updated kernel module can be reloaded into the system kernel. This design in this embodiment can improve the update efficiency of relatively independent kernel modules, thereby facilitating the improvement of the efficiency of the target operating system, reducing the time of the target operating system affected by the kernel module update, and thus facilitating the optimization of the performance of the target operating system.

[0127] Among them, it can be considered that reloading to the system kernel actually represents two processes, namely, first unloading the kernel module to be updated from the system kernel, and then loading the kernel module to be updated after updating the system file into the system kernel to complete the update of the kernel module to be updated.

[0128] S305: The kernel module to be updated and the kernel modules that have dependencies thereon are taken as target modules.

[0129] In this embodiment, as described above, further update considerations can be made for kernel modules that have dependencies with other kernel modules, and when updating or reloading the kernel modules, the kernel modules that have dependencies with the kernel modules can be processed in combination with the dependencies, thereby facilitating reliable updates of the kernel modules without restarting the target operating system. That is, the kernel module to be updated and the kernel modules that have dependencies with the kernel modules can be used as target modules.

[0130] Traditional incremental update methods such as patch updates require relevant personnel to deeply consider the update content, system architecture, coupling relationship between system units, etc. in the update process when preparing the update package, so as to adaptively form the patch package, etc., resulting in poor scalability of the update process, that is, the patch package usually needs to be redesigned each time it is updated, and it is difficult to reuse the design ideas of historical updates. When there are some insufficient contents in the patch package, it is easy to cause the target operating system to fail to update or even crash. It can be seen that compared with the traditional incremental update method, the method of updating the target operating system through the full update file in this embodiment can be beneficial to the target operating system when the current update is not suitable for online incremental update, and quickly switch to restarting the full update method to update the target operating system, which can save the process of obtaining the update file again to improve the update efficiency. At the same time, in this embodiment, it is further planned that when the target operating system is updated, a series of adaptive identification methods of the correlation between system units are used to automatically complete the update process to obtain the content required for the update in the full update file, thereby reducing the burden of the formation of the update file and improving the reliability of the update process.

[0131] S306: Obtain the dependency topology of the target module.

[0132] In this embodiment, in response to at least some kernel modules in the filtered kernel modules being target modules, the dependency topology of the target module may be obtained.

[0133] Specifically, see Figure 5 , Figure 5 This is a schematic diagram of the structure of an embodiment of the present application that relies on topology 1. Figure 5 As shown in the example, the dependency topology when kernel module A to kernel module H are used as target modules can be as follows Figure 5 The directed acyclic graph shown as an example in .

[0134] Optionally, the dependency topology between the target modules may be constructed after the target modules are obtained. Alternatively, as described in step S303, the dependency topology between the kernel modules of the target operating system may be constructed in advance, so that in step S306, the portion of the target module in the dependency topology may be obtained, or the portion of other kernel modules in the dependency topology may be pruned, etc., which is not limited here.

[0135] For example, the dependency topology can be a dependency graph, etc., the kernel modules can be regarded as nodes, and the dependency relationship between the kernel modules can be represented by directed edges. For example, when kernel module A depends on kernel module B, a directed edge from kernel module A to kernel module B can be formed in the dependency graph.

[0136] S307: Assign each target module in the dependency topology an in-degree associated with its dependency frequency.

[0137] In this embodiment, the reloading order of the target modules can be planned using the dependency topology. To this end, the dependency relationship between the target modules can be quantified through the in-degree associated with the dependency frequency of the target modules, so that the quantified data can be used as reference data for planning the reloading order of the target modules, which is conducive to improving the efficiency of planning the reloading order, and can also reduce the risk of unreasonable reloading order or target module being omitted, thereby improving the update efficiency and reliability of the target operating system.

[0138] S308: Initialize the sorting queue.

[0139] In this embodiment, when planning the reloading order of the target modules, a sorting queue may be initialized, and the sorting queue may be blank, that is, before sorting the target modules, the sorting queue may not contain information of the target modules.

[0140] S309: Sort the target modules according to the preset in-degree order to obtain a sorted queue.

[0141] In this embodiment, the target modules may be sorted according to a preset in-degree order, and the reloading order may be obtained based on the sorting, so as to implement the reloading order of the update sub-files of the target module.

[0142] Specifically, the target module whose in-degree is a preset value may be used as an independent module.

[0143] Independent modules can be added to the sorting queue and the in-degree of the adjacent modules in the dependency topology can be globally updated, where the adjacent modules represent the target modules that depend on the independent modules.

[0144] The target module whose updated in-degree is a preset value may be added to the sorting queue as a new independent module until the target module is completed and added to the sorting queue.

[0145] It can be considered that an independent module means that it does not depend on other kernel modules in the current dependency topology, or the kernel modules it depends on have been added to the sorting queue. In other words, the independent module does not depend on other kernel modules that have not yet been added to the sorting queue.

[0146] For example, the in-degree can be associated with the frequency of the target module's dependence on other target modules, that is, the in-degree of the target module can be proportional to the number of other target modules it depends on. Therefore, the preset value can be 0, indicating that the target module does not depend on other target modules or the target modules it depends on have been added to the sorting queue.

[0147] For details, see Figure 6 , Figure 6This is a flow chart of an embodiment of obtaining a sorting queue for this application. It can be seen that Figure 6 Shown is based on Figure 5 The process of obtaining an ordered queue depending on the topology is shown.

[0148] like Figure 6 As shown in the example, after the process of assigning the in-degree to each target module such as step S307, the in-degrees of kernel module A to kernel module H are 2, 1, 1, 2, 1, 0, 1, 2 respectively.

[0149] It should be noted that Figure 6 The initial sorting queue is omitted in , and the initial sorting queue can be considered as the sorting queue []. When the independent modules are screened for the first time, the kernel module F is the target module with the in-degree of the preset value 0, and it can be added to the sorting queue [] as an independent module to update it to the sorting queue [F].

[0150] then Figure 6 In the example, kernel module F is distinguished from other target modules by dashed lines. After kernel module F is added to the sorting queue as an independent module, kernel module G, kernel module H and kernel module B that depend on kernel module F are used as adjacent modules and can be processed by reducing the in-degree by one. After the adjacent modules are globally updated by reducing the in-degree by one, the in-degrees of kernel module G and kernel module B are the preset value 0, so kernel module G and kernel module B can be added to the sorting queue [F] as independent modules to update to the sorting queue [F, G, B]. The in-degree of kernel module H, the adjacent module of kernel module G, can be updated from 1 to 0; the in-degree of kernel module A, the adjacent module of kernel module B, can be updated from 2 to 1. Since the in-degree of kernel module H is the preset value 0, kernel module H can be added to the sorting queue [F, G, B] as an independent module to update to the sorting queue [F, G, B, H].

[0151] By analogy, we can gradually obtain the sorting queue [F, G, B, H, C], sorting queue [F, G, B, H, C, A], sorting queue [F, G, B, H, C, A, E], and sorting queue [F, G, B, H, C, A, E, D]. In other words, until all the target modules in the dependent topology are added to the sorting queue, that is, the sorting queue [F, G, B, H, C, A, E, D] is formed, the sorting queue can be considered complete.

[0152] It should be noted that Figure 6 In the above example, after the in-degree of kernel module A is updated to 0, the sorted queue [F, G, B, H, C, A] is obtained. The process of updating the in-degree of kernel module E that depends on kernel module A to 0 first to obtain the sorted queue [F, G, B, H, C, A, E] is omitted. In other words, Figure 6The ellipsis part of the two dependent topology processes at the bottom of the sorting queue omits the step of obtaining the sorting queue [F, G, B, H, C, A, E]. Then, since the in-degree of kernel module E is 0, the in-degree of the adjacent module of kernel module E (that is, kernel module D) can be updated to 0, so kernel module D can be used as an independent module and written into the sorting queue to obtain Figure 6 The final sorted queue obtained in the process steps given in the example is [F, G, B, H, C, A, E, D].

[0153] It should be noted that when there are multiple independent modules with preset in-degrees, the order in which the independent modules are added to the sorting queue can be random, thereby improving the adding efficiency. Alternatively, certain adding rules can be preset to facilitate adapting to actual needs or business scenarios, etc., which are not limited here.

[0154] S310: Compare the number of target modules included in the sorting queue and the dependency topology.

[0155] In this embodiment, when the number of target modules included in the sorting queue and the number of target modules included in the dependency topology do not match, step S311 is executed. When the number of target modules included in the sorting queue and the number of target modules included in the dependency topology match, step S312 is executed.

[0156] That is to say, in this embodiment, the reliability of the sorting queue is also verified to check whether there is a circular dependency, so as to further improve the update reliability of the target operating system.

[0157] S311: Determine that the target module sorting fails.

[0158] In this embodiment, in response to the mismatch between the number of target modules included in the sorting queue and the dependency topology, it can be considered that there is a circular dependency, and the topological sorting may not be completed, and it is determined that there is a circular dependency and the sorting of the target module fails. Further, relevant information about the possible existence of the circular dependency can also be fed back, so that the target operating system update abnormality can be promptly prompted.

[0159] S312: Obtain a reload order based on the sorting queue.

[0160] In this embodiment, the order matching the sorting queue can be used as the unloading order of the target module. The order reverse to the sorting queue can be used as the loading order of the target module. That is, the reloading order of the target module can include two parts of data, one is the unloading order of the target module, and the other is the loading order of the target module.

[0161] For example, a result list may be further formed, and when the sorting queue is not empty, the head element of the sorting queue may be added to the result list to form a reload order in the result list.

[0162] S313: reload the update sub-files of the target module in sequence according to the reloading order.

[0163] In this embodiment, the target module's system file can be updated using the update subfile of the target module. Furthermore, the target module can be uninstalled from the system kernel in sequence according to the uninstallation order. In response to the system file of the target module being updated to the update subfile carried by the full update file, the target module after the system file is updated can be loaded into the system kernel in sequence according to the loading order.

[0164] For example, the business software module may include kernel module X, kernel module Y, and kernel module Z, all of which are loaded into the system kernel, wherein kernel module X depends on kernel module Y, and kernel module Y depends on kernel module Z.

[0165] When the update subfiles of kernel module X and kernel module Z do not match their current system files, kernel module X and kernel module Z can be considered as units to be updated, and since the system kernel has loaded kernel module X and kernel module Z, it can be considered that kernel module X and kernel module Z need to be reloaded.

[0166] Because kernel module X depends on kernel module Y, the reloading process of kernel module X should be as follows: unload kernel module Y, reload (i.e., load after unloading) kernel module X, and load kernel module Y.

[0167] Because kernel module Y depends on kernel module Z, the reloading process of kernel module Y should be as follows: unload kernel module Z, reload (i.e., load after unloading) kernel module Y, and load kernel module Z.

[0168] In view of this, it can be considered that when updating kernel module X and kernel module Z, the system files of the two can be replaced with their respective update sub-files in the full update file. The reloading sequence of the system kernel is: uninstall kernel module Z, uninstall kernel module Y, reload (i.e., uninstall and then load) kernel module X, load kernel module Y, and load kernel module Z.

[0169] The following is an example of the detailed principles of the formation of the full update file and the verification method of the full update file in multiple dimensions. Figure 7 , Figure 7 A flowchart of an embodiment of updating a target operating system according to the present application is shown.

[0170] In one embodiment, the relevant data that can update the target operating system can be formed into a full update file. At the same time, a verification file that can verify the update of the current version of the target operating system can be formed. For example, the verification dimension can include at least one of the target operating system verification, identity verification, and system unit verification.

[0171] The following is an example of the verification dimensions of the verification file.

[0172] When the verification dimension includes the target operating system verification, the verification information may include system version information of the target operating system such as system version number, etc. For example, the system version number may include one or more of the system kernel version, release version, and version information of the core business software of the current target operating system.

[0173] When the verification dimension includes identity verification, the verification information may include user identity authentication information, etc. For example, the identity authentication information of the user in the target operating system may be generated in the form of a password hash value.

[0174] When the verification dimension includes system unit verification, as described above, the system unit may include one or more of the basic system components, system firmware, and business software modules. Then, when verifying the system unit, the system unit categories included in the target operating system can be adaptively verified separately.

[0175] Specifically, when verifying the basic system components, the changes of at least one core component such as the kernel, boot loader, basic system library, etc. can be monitored, and the version information of the core component can be recorded. In this way, when updating the target operating system, verification can be achieved by comparing the version information of the core component.

[0176] When verifying the business software module, the key business software and / or core business software running in the target operating system can be verified. For example, the hash value of the source file related to each basic module and / or kernel module can be calculated and recorded, and the calculated hash value can be used as the verification information of each basic module and / or kernel module of the business software module.

[0177] When verifying the system firmware, the firmware version information of the system firmware in the target operating system can be recorded. For example, the firmware version information of BIOS, BMC, CPLD, etc. can be recorded. In this way, when updating the target operating system, the system firmware can be compared and verified before and after the update, which is conducive to ensuring the compatibility and stability of hardware such as the system firmware.

[0178] If so, the verification file and the full update file can be sent to the target operating system together to verify and update the target operating system.

[0179] Furthermore, when updating the target operating system, the operating system update device can obtain the full update file with the verification file and download it to the local device. The full update file can be verified by a signature tool, password or other verification methods, so as to confirm the integrity and authenticity of the full update file.

[0180] In response to the full update file passing the authenticity verification, the compressed full update file may be decompressed, and the integrity of the verification file may be further determined to confirm whether it contains the verification information as described in the above example.

[0181] When it is confirmed that the verification file passes the integrity verification, a verification script or the like may be started to guide or automate the verification process.

[0182] Specifically, when the verification dimension includes the verification of the target operating system, the system version information of the target operating system, such as the system version number, can be read. For example, the system version number can include one or more of the system kernel version, the distribution version, and the version information of the core business software of the current target operating system. The verification information read from the target operating system is compared with the verification information in the verification file. When the two match, it is determined that the verification file passes the partial verification. Otherwise, it can be considered that the target operating system cannot be updated using the full update file.

[0183] When the verification dimension includes identity verification, the identity authentication information stored in the target operating system can be read. For example, the identity authentication information of the user in the target operating system can be generated in the form of a password hash value. The verification information read from the target operating system is compared with the verification information in the verification file. When the two match, it is determined that the verification file passes this part of the verification. Otherwise, it can be considered unauthorized, so the target operating system cannot be updated using the full update file, and the target operating system update program is stopped.

[0184] When verifying the basic system components, the target operating system command can be used to read the information of the core components in the target operating system as verification information. The verification information read from the target operating system is compared with the verification information in the verification file to match whether the basic system components match, and the basic system components that need to be updated can be screened to generate a list of components that need to be updated.

[0185] When verifying the business software module, the information of the business software module in the target operating system can be read as verification information. The verification information read from the target operating system is compared with the verification information in the verification file. While matching whether the business software module matches, the basic modules and / or kernel modules that need to be updated can also be screened to generate container files such as a list of business software that needs to be updated. Furthermore, the basic module can be marked as needing to be updated. For the kernel module, while marking it as needing to be updated, it can also be recorded that a system kernel reload operation needs to be performed on it.

[0186] When verifying the system firmware, the information of the system firmware in the target operating system can be read as verification information. By comparing the verification information read from the target operating system with the verification information in the verification file, it is possible to match whether the system firmware matches or not, and to filter the system firmware that needs to be updated, and generate container files such as a list of components that need to be updated. When generating a firmware list of the system firmware, the system firmware name, current version information, and target version information of the update sub-files contained in the full update file can be recorded at the same time.

[0187] In this way, the component list, the business software list, the firmware list, etc. can be aggregated to form a container file. The target operating system can be updated based on the container file.

[0188] As explained above, when updating basic system components and system firmware, it can be considered that the target operating system update requires a restart. When updating the basic modules in the business software module, it can be considered that the target operating system update does not require a restart. When updating the kernel module in the business software module, whether it is loaded into the system kernel and other kernel modules with dependencies can be considered together. However, this is not absolute, and the risk factors of each system unit can also be considered together.

[0189] When updating the target operating system, if you are performing an online incremental update of the target operating system, you can decompress the full update file to obtain the update sub-files of each system unit. Based on the container file, you can replace the system file of the unit to be updated with its update sub-file. You can check and adjust the permission settings of the newly replaced system file, and you can also recreate the soft link based on the updated system file path to help ensure that the system and applications can reliably access the updated system files.

[0190] If the target operating system is to be restarted and fully updated, the system file of the file to be updated can be replaced with its update sub-file as described above. A dynamic script can also be further generated and linked to a cloud service such as the target operating system service. When the target operating system is restarted, the dynamic script can be automatically executed to perform the corresponding update steps and restart the relevant system services.

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

[0192] The embodiment of the present application also provides a system update device, which may include an input module and a control module. The input module may be used to obtain a global update file of a target operating system. The control module may be used to implement the steps in any of the above operating system update method embodiments.

[0193] For the description of the features in the embodiment corresponding to the system updating device, reference can be made to the relevant description of the embodiment corresponding to the operating system updating method, which will not be repeated here.

[0194] An embodiment of the present application further provides an electronic device, including a memory and a processor, wherein a computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any of the above operating system updating method embodiments.

[0195] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above operating system updating method embodiments when running.

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

[0197] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above operating system update method embodiments are implemented.

[0198] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, the non-volatile computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned operating system update method embodiments are implemented.

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

[0200] The above is a detailed introduction to an operating system update method, electronic device, computer-readable storage medium, and computer program product provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application, and the description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. A method for updating an operating system, characterized in that: The operating system updating method comprises: Obtaining a full update file of a target operating system and a unit to be updated of the target operating system; Verifying whether the unit to be updated supports online incremental update; In response to the unit to be updated supporting the online incremental update, performing an online incremental update on the unit to be updated using the update subfile of the unit to be updated in the full update file; In response to the unit to be updated not supporting the online incremental update, the target operating system is restarted and fully updated using the full update file.

2. The operating system updating method according to claim 1, characterized in that: The restarting and fully updating the target operating system by using the full update file comprises: Decompressing the full update file to obtain update sub-files of each system unit; wherein the system unit includes the unit to be updated; The update sub-files of the units to be updated are extracted respectively, and the system files of the units to be updated are reloaded as the update sub-files.

3. The operating system updating method according to claim 2, characterized in that: The system unit of the target operating system includes a kernel module associated with the service; and reloading the system file of the unit to be updated as the update sub-file includes: In response to the unit to be updated including the kernel module, querying a kernel module having a dependency relationship with the kernel module to be updated; The kernel module to be updated and the kernel modules having dependencies thereon are used as target modules; Planning the reloading order of the update sub-files of the target module; The update sub-files of the target modules are reloaded in sequence according to the reloading order.

4. The operating system update method according to claim 3, characterized in that: The planning of the reloading order of the update sub-file of the target module includes: Obtaining the dependency topology of the target module; Assigning each of the target modules in the dependency topology an in-degree associated with its dependency frequency; The target modules are sorted according to a preset in-degree order, and the reloading order is obtained based on the sorting.

5. The operating system updating method according to claim 4, characterized in that: The step of sorting the target modules according to a preset in-degree order includes: Initialize the sorting queue; Add the target module whose in-degree is a preset value as an independent module to the sorting queue; The in-degree of the adjacent modules in the dependency topology is globally updated, and the target module whose updated in-degree is the preset value is added to the sorting queue as a new independent module until the target module is added to the sorting queue; wherein the adjacent module represents the target module that depends on the independent module.

6. The operating system updating method according to claim 5, characterized in that: The step of adding the target module to the sorting queue further comprises: Comparing the number of target modules included in the sorting queue and the number of target modules included in the dependency topology; In response to the mismatch in the numbers of target modules included in the two, it is determined that there is a circular dependency and sorting of the target modules fails.

7. The operating system updating method according to claim 5, characterized in that: The obtaining of the overloading order based on sorting includes: The order matching the sorting queue is used as the unloading order of the target module; the order inverse to the sorting queue is used as the loading order of the target module; The update sub-files for sequentially reloading the target modules in the reloading order include: Using the update subfile of the target module to update its system file; Uninstalling the target modules from the system kernel in sequence according to the uninstallation order; The target modules after the system files are updated are loaded into the system kernel in sequence according to the loading order.

8. The operating system updating method according to claim 3, characterized in that: After the to-be-updated unit includes the kernel module, the method further includes: Querying whether the system kernel of the target operating system has loaded the kernel module to be updated; In response to the target operating system not loading the kernel module to be updated, the system file of the kernel module to be updated is updated as its update subfile, and the kernel module to be updated of the updated system file is loaded into the system kernel.

9. The operating system updating method according to claim 1, characterized in that: The checking whether the unit to be updated supports online incremental update includes: Obtaining the unit type of the unit to be updated; In response to the unit type of the to-be-updated unit including basic system components and / or system firmware, it is determined that the to-be-updated unit does not support the online incremental update.

10. The operating system updating method according to claim 1, characterized in that: The checking whether the unit to be updated supports online incremental update includes: Evaluate a risk factor characterizing a risk of performing an online incremental update on the unit to be updated; In response to the risk factor reaching a risk threshold, it is determined that the to-be-updated unit does not support the online incremental update.

11. The operating system updating method according to claim 1, characterized in that: The online incremental update of the to-be-updated unit by using the update sub-file in the full update file comprises: Updating the system file of the unit to be updated into the update sub-file; Correcting the permission setting of the update subfile, and updating the target operating system to connect with the updated system file; Restart the unit to be updated.

12. The operating system updating method according to claim 1, characterized in that: The restarting and fully updating the target operating system by using the full update file comprises: Analyzing the steps to be executed after the target operating system is restarted to generate a dynamic script; Linking the dynamic script to a cloud service of the target operating system; Restarting and fully updating the target operating system; In response to the target operating system being restarted, the dynamic script is obtained from the cloud service and executed.

13. The operating system updating method according to claim 1, characterized in that: After obtaining the full update file of the target operating system, the method further includes: Parsing the system verification information carried by the full update file; Acquire system information of the target operating system; comparing the system verification information and the system information; In response to the system verification information matching the system information, it is determined that the full update file can be used to update the target operating system.

14. The operating system updating method according to claim 1, characterized in that: Obtaining the units to be updated of the target operating system includes: Parsing the target version of each system unit in the full update file; comparing a current version of the system unit with the target version; In response to the current version and the target version of the system unit not matching each other, the system unit is determined as the unit to be updated.

15. The operating system updating method according to claim 14, characterized in that: The determining that the system unit is the unit to be updated comprises: Writing the unit update information of the unit to be updated into the container file; wherein the unit update information includes the unit name and whether it supports online incremental update; The checking whether the unit to be updated supports online incremental update includes: The container file is traversed to obtain whether each of the to-be-updated units supports online incremental update.

16. The operating system updating method according to claim 1, characterized in that: After the online incremental update of the updated sub-file of the unit to be updated in the full update file is performed, the method further includes: Obtaining the update status of the unit to be updated; In response to the update status of the to-be-updated unit indicating update failure, the target operating system is restarted and fully updated using the full update file.

17. The operating system updating method according to claim 1, characterized in that: After performing the online incremental update or the restarting full update, the following further comprises: In response to completing the system update, obtaining the current system file of the unit to be updated; Verifying the current system files and their permissions; In response to the current system file and its permission verification failing, obtaining a backup historical update file; wherein the historical update file represents a full update file used for updating the target operating system at a historical moment; The target operating system is version rolled back using the historical update file.

18. The operating system updating method according to claim 17, characterized in that: After performing the online incremental update or the restarting full update, the following further comprises: In response to the target operating system being successfully updated using the full update file, the full update file is backed up as a historical update file.

19. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the operating system updating method as claimed in any one of claims 1 to 18 when executing the computer program.

20. 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 operating system updating method according to any one of claims 1 to 18.

21. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the operating system updating method according to any one of claims 1 to 18 are implemented.

Images