Operating System Update Method, Electronic Device, Storage Medium and Program Product

Abstract

The present application discloses an operating system update method, an electronic device, a storage medium, and a program product, relating to the field of computer technologies. The method includes updating a target operating system using a full update file, and when the unit to be updated supports online incremental updates, performing an online incremental update on the target operating system using the update sub-files therein, so as to enable the target operating system to complete system updates online. When the unit to be updated does not support online incremental updates, a restart full update of the target operating system can be performed using the full update file, reducing the cumbersome steps of obtaining the full update file additionally to improve the system update efficiency, solving the technical problems of system upgrades affecting business continuity and system performance, achieving the reduction of the situation of restarting due to system updates, thereby being able to improve the continuity of services and operations, and while improving the system update efficiency, also being able to improve the generalization of the operating system update method.

Description

Technical Field

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

[0002] When updating an operating system, it is usually necessary to restart the operating system to ensure the reliable loading and running of the new version of the operating system. However, restarting the operating system will disrupt the service-providing environment, resulting in the interruption of the provided services and affecting business continuity. Moreover, updating and restarting the operating system may take a long time, which means that the operating system is in a downtime and maintenance state for a long time during this period, and a large amount of system resources are also occupied for operating system updates, thus easily leading to poor operating system performance. Summary of the Invention

[0003] This 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 problems in the related art that system upgrades affect business continuity and system performance.

[0004] This 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 it using the update sub-file of the unit to be updated in the full update file; and in response to the unit to be updated not supporting the online incremental updates, performing a restart full update on the target operating system using the full update file.

[0005] This 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 operating system update methods when executing the computer program.

[0006] This application also provides a computer-readable storage medium, in which a computer program is stored, and the computer program, when executed by a processor, implements the steps of any of the above operating system update methods.

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

[0008] Through this application, since 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 sub-file therein is used to perform an online incremental update on the target operating system, so that the target operating system can complete the system update online. When the unit to be updated does not support online incremental updates, the full update file can be used to perform a restart full update on the target operating system, reducing the cumbersome steps of obtaining the full update file additionally to improve the system update efficiency. Therefore, the technical problems of system upgrade affecting business continuity and system performance can be solved, the situation of restarting due to system update can be reduced, so that the continuity of services and operations can be improved. At the same time, while improving the system update efficiency, the generalizability of the operating system update method can also be improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] To more clearly illustrate the embodiments of the present application, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0010] Figure 1 It is a schematic flowchart of an embodiment of the operating system update method of the present application;

[0011] Figure 2 It is a schematic flowchart of another embodiment of the operating system update method of the present application;

[0012] Figure 3 It is a schematic flowchart of an embodiment of the planned reload order of the present application;

[0013] Figure 4 It is a schematic structural diagram of an embodiment of the dependency relationship of the present application;

[0014] Figure 5 It is a schematic structural diagram of an embodiment of the dependency topology of the present application;

[0015] Figure 6 It is a schematic flowchart of an embodiment of obtaining the sorting queue of the present application;

[0016] Figure 7 It is a schematic flowchart of an embodiment of updating the target operating system of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0017] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present application.

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

[0019] In order to enable those skilled in the art of the present technology to better understand the solution of the present application, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0020] In combination with the specific application environment architecture or specific hardware architecture on which the execution of the operating system update method depends, the specific application environment architecture or specific hardware architecture will be described herein.

[0021] First, several main definitions involved in the present application are explained. The present application is a method for updating an operating system, and the update refers to deleting, modifying, adding, etc. the existing files and functions of the operating system. And, in the present application, there are mainly two methods for updating the operating system, namely full update (i.e., the restart full update described in the previous text of the present application) and incremental update (i.e., the online incremental update described in the previous text of the present application).

[0022] Specifically, the operating system can be considered as a built-in program for coordinating various hardware of a computer to interact with users, and the operating system can be considered as an interface between the user and the computer. For example, according to the operating environment of the operating system, 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, job management, etc.

[0023] The restart full update can be understood as processing the complete data set every time an update is made. Whether the data has changed or not, update processing will be performed. As the name implies, when performing a restart full update on the operating system, the operating system often needs to be restarted. The update method of the restart full update is conducive to ensuring data integrity and consistency, and usually can be adapted to scenarios that require high accuracy.

[0024] Online incremental update can be understood as processing data that has changed relative to the historical update, and data that has not changed can be left unprocessed. As the name implies, when performing an online incremental update on an operating system, the process of restarting the entire operating system can be reduced. The system units in the operating system that need to be updated can be updated online, which is equivalent to the system units supporting hot plugging, so that they can be updated individually and the updated system units can be restarted. Moreover, when performing an online incremental update, the data that has changed relative to the historical update can be transmitted as an update package. Thus, the update method of online incremental update can significantly reduce the data transmission volume and processing time, saving bandwidth and computing resources.

[0025] Among them, the system units of the operating system can be considered as components, organizations, individuals, or subsystems with certain functions of the operating system, etc. Each system unit interacts and is interconnected to form an operating system.

[0026] For example, the system units of the operating system can include one or more of basic system components, system firmware, and business software modules.

[0027] Specifically, the basic system components can include a system kernel, a Shell, a file system, system libraries, system tools, application programs, a toolchain, etc.

[0028] 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 an interface between hardware and software, 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. The Shell can be considered as the main way for users to interact with the operating system. Users can input commands through the Shell to control the system, manage files, start programs, etc. The file system can be used to manage files, directories, etc. System libraries can be used to support the operation of application programs. System tools can be used to manage system resources, monitor system status, configure system parameters, etc. Application programs can include, for example, office software, development tools, databases, etc. The toolchain can be composed of a series of utility tools, such as compilers, debuggers, etc., and can provide basic command-line operations, file management, compilation, debugging, etc. functions for users and developers.

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

[0030] Among them, the BIOS can store the basic input and output program of the computer, the power-on self-test program, and the system self-start program, etc., and can provide low-level and direct hardware settings and controls for the device. The BMC can be considered a dedicated service processor. The BMC can use sensors to monitor computers, network servers, other hardware drive devices, etc. The CPLD is a high-density programmable logic device, whose integration density is usually greater than 1000 gates, and has more input / output signals, product terms, and macro cells.

[0031] The business software module can refer to the core business software module, which usually refers to the software components that are directly related to the core functions, security, performance, and stability of the operating system. At the same time, the business software module can further include a basic module and a kernel module related to the business.

[0032] Among them, the kernel module represents the core business software module that needs to be loaded into the system kernel. The basic module represents the core business software module that does not need to be loaded into the system kernel.

[0033] The detailed working principle of the operating system update method of this application is illustrated by examples below.

[0034] Please refer to Figure 1 , Figure 1 which is a schematic flowchart of an embodiment of the operating system update method of this application.

[0035] S101: Obtain the full update file of the target operating system and the units to be updated of the target operating system.

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

[0037] As the name suggests, update files can be used to modify and improve existing operating systems to fix known issues, improve system performance and security, and enhance functionality. Generally speaking, update files can be, for example, update packages, typically including patches and updates. Therefore, a full update file is one that can be used to fully update the target operating system upon reboot.

[0038] The units to be updated represent system units that will change when the target operating system is currently updated. In other words, the system units may include the units to be updated that are currently waiting to be updated, and the units to be updated may be one or more of the system units. As previously explained, the units to be updated may include one or more of the following: basic system components, system firmware, and business software modules.

[0039] In other words, a full update file for updating the target operating system can be obtained. Information about the units to be updated can be used as input to obtain the units to be updated. Alternatively, the units to be updated can be adaptively identified based on the full update file, thereby reducing the tedious external verification of the units to be updated when updating the target operating system and improving operating system update performance.

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

[0041] In this embodiment, whether each unit to be updated supports online incremental updates can be directly or indirectly identified. Compared to identifying whether the target operating system requires a reboot during an update, adaptively selecting the target operating system update method based on the verification result can improve operating system update efficiency while ensuring the reliability of the update process.

[0042] 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-swapped, that is, when the unit to be updated is restarted, there is no need to restart the target operating system.

[0043] S103: In response to the unit to be updated supporting online incremental update, perform online incremental update on the unit to be updated using the update sub-file of the unit to be updated in the full update file.

[0044] 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.

[0045] It is easy to understand that the full-update file usually includes update files for each system unit as update sub-files. The difference is that the update file of the unit to be updated may be different from its current system file, while the update file of the unit not to be updated may match its current system file. Optionally, the update file of the unit to be updated may also match its current system file, and 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, this unit to be updated needs to be restarted synchronously, etc. Specific examples will be elaborated in the part about kernel modules later, and will not be elaborated here.

[0046] Therefore, in response to the unit to be updated supporting online incremental update, the update sub-file for updating the unit to be updated in the full-update file can be obtained, and the unit to be updated can be incrementally updated online using the update sub-file of the unit to be updated.

[0047] S104: In response to the unit to be updated not supporting online incremental update, use the full-update file to perform a full restart update on the target operating system.

[0048] In this embodiment, when it is determined that there is a unit to be updated that does not support online incremental update, 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 is a risk in performing online incremental update. Therefore, the full-update file can be used to perform a full restart update on the target operating system to synchronously update all units to be updated together and achieve the full update of the target operating system.

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

[0050] When the target operating system is updated and it supports both online incremental update and full restart update at the same time, it is preferred to use the online incremental update method to update the target operating system. In this way, when performing online incremental update on the unit to be updated, the problem of restarting required for updating the target operating system can be overcome, and a service environment can still be provided to maintain the continuity of services when updating the target operating system, which can ensure business continuity. In other words, it can enable the target operating system to complete the update without downtime, can ensure the continuous operation of the business, and is also conducive to improving the availability and stability of the target operating system. Moreover, it can reduce the situation of frequent restart of the target operating system due to updates, thereby reducing the risk of poor system stability caused by frequent restart, and reducing the maintenance difficulty and cost.

[0051] In this embodiment, when performing online incremental updates on the units to be updated, the update efficiency of the target operating system can also be significantly improved. It is easy to understand that online incremental updates can update some system units of the target operating system, which can reduce the time consumed in the update process compared to updating the entire target operating system. Moreover, the update process that takes a long time usually occupies too many system resources and there is a risk of affecting the operation of core services. The method of performing online incremental updates on the units to be updated separately in this embodiment can reduce the occupation of system resources, so as to reduce the interference to business operations during the update of the target operating system. Further, for large-scale systems, restarting them usually means a long downtime and maintenance window, which poses a certain operation risk. In this embodiment, online incremental updates can be used without restarting the target operating system, which can improve the update efficiency and overall performance of the target operating system.

[0052] At the same time, the file sent to update the target operating system in this embodiment is a full-update file. This means that a restart full-update of the target operating system can also be achieved using the full-update file, that is, when the units to be updated of the target operating system do not support online incremental updates, using the full-update file to perform a restart full-update on the target operating system can reduce the cumbersome steps of obtaining the full-update file again and can improve the update coherence of the target operating system.

[0053] In addition, it can be seen that different from using incremental update files to achieve online incremental updates of the target operating system, in this embodiment, a full-update file is used to perform online incremental updates on the target operating system. Traditional incremental update methods such as patch updates often need to bind content such as update content, system architecture, and software storage methods. And when the above content changes, it is very likely that a large number of adaptive modifications need to be made to the patch update method to meet the new update requirements, which has the problem of poor scalability and even easily leads to the crash of the target operating system. In this embodiment, a flexible update framework is introduced, which can judge whether the target operating system needs to be restarted for the units to be updated that need to be updated, so that the target operating system can flexibly and quickly respond to changes in the technical environment and diverse 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.

[0054] 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-files therein are used to perform an online incremental update 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 perform a restart full update on the target operating system, reducing the cumbersome steps of obtaining the full update file additionally to improve the system update efficiency.

[0055] Therefore, it is possible to solve the technical problems of system updates affecting business continuity and system performance, achieve a reduction in the situation of restarting due to system updates, thereby improving the continuity of services and operations, and while improving the system update efficiency, it is also possible to improve the generalization of the operating system update method.

[0056] Please refer to Figure 2 , Figure 2 which is a schematic flowchart of another embodiment of the operating system update method of this application.

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

[0058] In this embodiment, obtaining the full update file of the target operating system can be as described in step S101 of the foregoing embodiment, and will not be elaborated here.

[0059] In this embodiment, taking the full update file as the input when updating the target operating system, an example is given of adaptively identifying the unit to be updated of the target operating system by using the full update file. Thus, in this embodiment, the cumbersome preparatory work for externally updating the target operating system can be carried out without having to count the information of the unit to be updated, so as to reduce the risk of affecting the update of the target operating system due to incomplete or incorrect information related to the unit to be updated.

[0060] Further, 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 sub-files of each system unit. So as to facilitate updating each system update unit by using its update sub-file.

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

[0062] 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 relatively low, so step S203 can be executed; when the full update file fails to pass 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.

[0063] As the name implies, the multi-dimensional verification identifier can verify a full-update file in multiple dimensions to verify whether the full-update file is applicable to update the target operating system. Optionally, the system verification information carried in 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 for update. When performing 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 used for updating 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, and thus 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 update the target operating system, and thus step S210 can be executed.

[0064] Among them, regarding the verification method for performing multi-dimensional verification on the full-update file, it will be introduced together in the part about forming the full-update file later, and will not be elaborated here.

[0065] 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 has the conditions for operating system update. When it is determined that the current device has the conditions for operating system update, step S203 is allowed to be executed. That is, multi-dimensional verification can be performed on the full-update file, and it can also be verified whether the current device has the conditions for operating system update. When the verification results of both verification conditions pass, step S203 can be executed. When it is determined that the current device does not have the conditions for operating system update, step S210 can be executed. That is, when performing verification on both the multi-dimensional verification of the full-update file and whether the current device has the conditions for operating system update, when the verification result of at least one of them fails the verification, step S210 can be executed.

[0066] S203: Obtain the units to be updated of the target operating system.

[0067] In this embodiment, the target versions of each system unit in the full-update file can be parsed. The target version represents the version information of the system unit after being updated using the full-update file to update the target operating system. 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 can also be represented by an independent version rule, which is not limited here.

[0068] The current version information of the system unit can be obtained as the current version of the system unit. By comparing the current version of the system unit with the target version, it is possible to evaluate whether the target version and the current version match, so as to automatically determine whether the system unit is a unit to be updated.

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

[0070] In response to the match between the current version of the system unit and the target version, 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. Therefore, it can be determined that the system unit is not a unit to be updated.

[0071] However, it should be noted that considering kernel modules such as those 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 performing an online incremental update on the target operating system, it will definitely not involve operations such as reloading (i.e., unloading and then loading). In other words, even if the system unit is currently determined not to be a unit to be updated, there is still a possibility that it will be processed to some extent when performing an online incremental update on the target operating system. Moreover, when it is determined that the update method of the target operating system is a full restart update, the target operating system is globally updated using the full update file, which will also involve the update of system units that are not units to be updated.

[0072] Furthermore, the unit update information of the unit to be updated can be written into a container file. Among them, the unit update information can at least include the unit name and whether it supports online incremental update.

[0073] 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. Facilitating the subsequent selection of the target operating system update method, the information on whether each unit to be updated supports online incremental update can be extracted through the container file, thereby improving the selection efficiency of the target operating system update method. At the same time, when it is determined to perform an online incremental update on the target operating system, the update can be carried out according to the unit update information of the unit to be updated in the container file, which can reduce the risk of the unit to be updated being missed during the update, 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, etc., which will be elaborated in detail later and will not be elaborated here for the time being.

[0074] Furthermore, in this embodiment, it is also possible to further design whether the unit to be updated is suitable for online incremental update, which can contribute to the reliable update of the target operating system and improve the update efficiency while ensuring the update of the target operating system.

[0075] Specifically, the update method for the target operating system can be selected by combining the risk of update failure when performing online incremental update with the system unit, and / or the unit type.

[0076] That is to say, it is possible to preset some system units of unit types that are considered not to support online incremental update when they need to be updated. Or, the probability of update failure when the system unit performs online incremental update can be evaluated to determine whether the system unit is suitable for online incremental update. When the probability of online incremental update failure reaches a certain threshold, it can be considered that update failure is likely to occur during its online incremental update, so it can be determined that the system unit is not suitable for online incremental update. Or, it is possible to preset some system units of unit types that are considered not to support online incremental update when they need to be updated; at the same time, the probability of update failure when the system unit performs online incremental update can also be evaluated to determine whether the system unit is suitable for online incremental update.

[0077] For example, the preset unit types can include basic system components and system firmware. After obtaining the unit to be updated, the unit type of the unit to be updated can be obtained. In response to the unit type of the unit to be updated including basic system components and / or system firmware, it can be determined that there are units to be updated that do not support online incremental update. In response to the unit type of the unit to be updated not including basic system components and system firmware, it can be determined that each unit to be updated supports online incremental update.

[0078] The reasons for such a design in this embodiment will be elaborated in detail below in combination with the system units mentioned above, which can include basic system components, system firmware, business software modules including kernel modules and basic modules.

[0079] In this embodiment, considering that the basic system components can be regarded as the core of the operation of the operating system, it is 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 facilitate the effectiveness of the changes during the update and maintain the stability and security of the target operating system.

[0080] The update of system firmware usually involves operations at multiple levels, such as system file update, compatibility testing of drivers, deployment of security patches, etc. Considering the complexity of the system firmware update mechanism, restarting the operating system is beneficial for these update operations to be executed in a relatively "clean" state of the operating system, thus facilitating the integrity and effectiveness of the update. That is to say, by restarting the target operating system, the target operating system can close unnecessary programs and services, which is conducive to improving the smoothness of the update task. Moreover, considering that during the update process of system firmware, some running files may need to be replaced or modified, and these files are in a state of being occupied by other programs or services. Therefore, restarting the target operating system for update is beneficial to reduce the risk of update failure due to file locking, and reduce the risk of instability of the target operating system or uncompleted repair of security vulnerabilities, thereby ensuring the reliability of the target operating system update.

[0081] It should be noted that a global judgment can be made on whether the unit to be updated supports online incremental update to obtain the overall macro information on whether it supports online increment. Or, each unit to be updated can be judged separately, and the detailed verification results can be written into the container file.

[0082] Specifically, the unit types of the units to be updated can be obtained respectively to judge 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 the 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 the unit type preset by the non-preset unit type, it can be considered that the unit type of the unit to be updated is suitable for online incremental update.

[0083] When evaluating whether the system unit is suitable for online incremental update, the risk factors of the online incremental update risk of the system unit can be obtained. That is, the risk factors representing the online incremental update risk 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 by immediately combining at least one of the current device environment, the update amount of the target operating system, etc., and / or, it can be evaluated by combining the success probability of the update of this unit to be updated when updating the operating system historically. Among them, the historically updated operating system can include the current target operating system, or it can also include other types of operating systems while including the current target operating system, which will not be elaborated here.

[0084] Furthermore, some system units of certain unit types can be preset so that when they need to be updated, they are considered not to support online incremental updates. At the same time, the probability of update failure when the system unit performs online incremental updates can also be evaluated, and a specific implementation manner of evaluating whether the system unit is suitable for online incremental updates will be described by way of example.

[0085] Specifically, it is possible to first macroscopically or specifically determine whether the unit type of the unit to be updated is a preset unit type. When the unit type of the unit to be updated is a preset unit type, it can be considered that the target operating system needs to be restarted for a full update. Therefore, it is possible not to evaluate the risk factors of each unit to be updated, so as to effectively reduce the burden of analyzing the target operating system.

[0086] When it is determined that the unit type of the unit to be updated is suitable for online incremental updates, it is possible to further evaluate or obtain the risk factors of the unit to be updated.

[0087] 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 updates, and the relevant information is written to the corresponding position of the unit to be updated in the container file.

[0088] 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 updates. Therefore, it is determined that the unit to be updated does not support online incremental updates, 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 updates. Instead, the unit to be updated itself can perform online incremental updates. However, after comprehensive evaluation, it is considered that there is a relatively high risk of update failure when it is updated by the online incremental update method. Therefore, it is considered not suitable for online incremental updates, so as to reduce the cumbersome operations of repeatedly performing online incremental updates when the update fails. By restarting the full update method, the update smoothness can be improved, and even the update efficiency may be improved.

[0089] S204: Determine whether there is a need to restart the update of the target operating system.

[0090] In this embodiment, when it is determined that there is a need to restart the update of the target operating system, step S205 is executed. When it is determined that there is no need to restart the update of the target operating system, step S206 is executed.

[0091] 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. That is to say, when there is a unit to be updated in the container file that does not support online incremental updates, 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 update of the target operating system has a restart requirement.

[0092] In an alternative embodiment, it can also be independently determined whether there is a restart requirement when updating the target operating system, which will not be elaborated here. When determining whether there is a restart requirement when updating the target operating system, each unit to be updated can be verified separately.

[0093] S205: Perform a full restart update on the target operating system using the full update file.

[0094] In this embodiment, in response to the unit to be updated not supporting online incremental updates, the full update file can be used to perform a full restart update on the target operating system.

[0095] Furthermore, considering that the target operating system needs to be restarted during the process of performing a full restart update on 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 to be executed after the target operating system is restarted can be automatically identified, and a dynamic script that can be automatically executed is generated. The dynamic script is placed in the 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, etc. work of the target operating system restart, which can reduce the part that requires manual participation in the update process of the target operating system and further improve the performance of the operating system update.

[0096] 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. Perform a full restart update on the target operating system. In response to the restart of the target operating system, the dynamic script can be obtained from the cloud service and the dynamic script can be executed.

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

[0098] In this embodiment, in response to the unit to be updated supporting online incremental updates, the update sub-file of the unit to be updated in the full update file can be used to perform an online incremental update on it.

[0099] As described in the foregoing, the decompressed full - volume update file is used to obtain the update sub - files of each system unit respectively. The update sub - files of each unit to be updated can be extracted, and the system file of the unit to be updated is reloaded as the update sub - file.

[0100] Specifically, the system file of the unit to be updated can be updated to the update sub - file. The permission settings of the update sub - file are corrected, and the connection between the target operating system and the updated system file is updated. This is equivalent to updating the path of the updated system file of the unit to be updated and re - creating a soft link, which helps to ensure that the target operating system, applications, etc. can correctly access the updated system file. And the unit to be updated with the updated system file is hot - plugged independently, that is, the unit to be updated is restarted.

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

[0102] In this embodiment, when it is determined that the target operating system is updated successfully, the process ends. When it is determined that the target operating system is not updated successfully, step S208 is executed to timely evaluate whether the target operating system is updated successfully after the target operating system is updated, so as to be able to quickly respond to update exceptions when the target operating system update fails, thereby improving the reliability of the target operating system update.

[0103] Specifically, in response to the completion of 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. Thus, by verifying the system file and permissions of the system unit, it is indirectly verified whether the target operating system is updated. It can be considered that when the current system file matches the full - volume update file and the permission configuration is successful, the target operating system is updated. That is to say, in this embodiment, it can be macroscopically verified whether the target operating system as a whole is updated to confirm the effectiveness and reliability of the update, and when the update fails, timely remedial measures can be implemented, etc., so as to ensure the sustainable operation of the target operating system, reduce the risk that the target operating system becomes disabled due to the failure of the target operating system update, and even affect services and operations, and thus significantly improve the reliability of the target operating system.

[0104] Furthermore, after performing an online incremental update on the unit to be updated using the update sub - file of the unit to be updated in the full - volume update file, the update status of the unit to be updated can also be obtained, which helps to dynamically adjust the update method in a timely manner based on the update status of the unit to be updated.

[0105] In response to the update status of the unit to be updated indicating that the update is successful, the update status of the next updated unit to be updated can be verified until the update status of each unit to be updated is successful.

[0106] In response to the update status of the unit to be updated indicating an update failure, a full update file can be used to perform a full restart update on the target operating system. In this way, the risk of affecting the update of the target operating system or even causing the update of the target operating system to fail due to the unit to be updated with an update failure can be reduced. By promptly switching to the method of restarting the full update, it is beneficial to improve the update success rate of the target operating system and provide a certain fault tolerance rate and abnormal self-processing ability for the operating system update method.

[0107] In other words, it is also possible to separately verify whether each unit to be updated is updated successfully. After the unit to be updated is updated, when it is determined that the unit to be updated has failed to be updated, an online incremental update can be attempted again for the unit to be updated. When the number of times the unit to be updated fails to be updated reaches a preset number, the update method of the target operating system is switched to a full restart update, that is, a full update file is used to perform a full restart update on the target operating system. Or, once an update failure of the unit to be updated occurs, it can be considered that the unit to be updated is not suitable for online incremental update, and the method of switching to a full restart update in a timely manner is used to perform a full restart update on the target operating system, thereby improving the update efficiency of the target operating system.

[0108] S208: Perform exception handling for the update of the target operating system.

[0109] In this embodiment, in response to the target operating system not being updated successfully, exception handling for the update of the target operating system can be performed.

[0110] Combined 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 for updating the target operating system at a historical moment. For example, the historical update file can be the full update file that was used to update the target operating system at a historical moment and the update was successful. The historical update file is used to roll back the version of the target operating system to ensure the functionality of the target operating system in the case of a timely failure of the target operating system update, which is beneficial to improving the fault tolerance of the operating system update method and also beneficial to ensuring the reliability of the target operating system.

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

[0112] In this embodiment, as described in step S209, when the update of the target operating system using the full update file fails, the historical update file can be used to roll back the target operating system.

[0113] Therefore, in response to the successful update of the target operating system using the full update file, the full update file can be backed up as a historical update file.

[0114] S210: Exit the operating system update.

[0115] 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.

[0116] And / or, as exemplified in the previous text, 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.

[0117] Furthermore, as exemplified in the previous text, the system unit may include business software modules. 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, the dependencies between kernel modules will be further referred to. In other words, when reloading a kernel module, the kernel module having a dependency relationship with it can be adaptively reloaded, which is beneficial to improving the update effectiveness of the kernel module to be updated and further improving the reliability of the target operating system. The following gives an example of the detailed working principle of updating kernel modules when the unit to be updated includes kernel modules.

[0118] Please refer to Figure 3 , Figure 3 which is a schematic flowchart of an embodiment of the planned reload order of this application.

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

[0120] In this embodiment, in response to the unit to be updated including a kernel module, it can be queried whether the system kernel of the target operating system has loaded the kernel module to be updated. If so, different update strategies can be used to update the kernel module loaded into the system kernel and the kernel module not loaded into the system kernel respectively, so as to improve the update efficiency while ensuring the reliability of the kernel module update.

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

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

[0123] 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 updated sub-file, and the kernel module to be updated with the updated system file can be loaded into the system kernel, so as to be able to complete the update of the kernel module to be updated and also load the kernel module into the system kernel, thereby being able to improve the efficiency of the target operating system in loading the kernel module and further being conducive to optimizing the performance of the target operating system.

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

[0125] In this embodiment, when it is determined that there is no kernel module that has 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.

[0126] 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 process of reloading the kernel module needs to be further considered, so step S305 is executed.

[0127] Among them, the dependency relationship means the mutual dependence and association between kernel modules in the target operating system. The dependency relationship can be a direct dependency or an indirect dependency. 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 a module - level dependency relationship is formed between these two kernel modules, that is, there is dependency management between these two kernel modules.

[0128] As Figure 4 shown by the examples Figure 4 is a schematic structural diagram of an embodiment of the dependency relationship of the present application. Figure 4 gives examples of the dependency relationship among kernel module A, kernel module B, and kernel module C. Figure 4 The direction shown by the arrow in Figure 4 can be considered as the dependency direction. That is to say,

[0129] shows that kernel module A depends on kernel module B and kernel module C. 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 exemplified 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 exemplified from step S305 to step S313.

[0130] Optionally, a dependency file containing the dependencies between kernel modules in the target operating system can be pre-built, such as a dependency topology, a dependency list, etc. In this way, the dependency file can be queried to determine whether there are other kernel modules associated with the kernel module to be updated. Or, after obtaining the kernel module to be updated, the source code of the target operating system can be identified, and other kernel modules associated with the kernel module to be updated can be queried based on the source code, which is not limited herein.

[0131] S304: Update the target module system file using the update sub-file and reload it to the system kernel.

[0132] In this embodiment, in response to the kernel module that has been loaded into the system kernel not having other kernel modules with which it has a dependency relationship, the update sub-file of the kernel module to be updated in the full update file can be obtained, so that the update sub-file can be used to update the system file of the kernel module to be updated, and the updated kernel module can be reloaded to the system kernel. With such a design in this embodiment, the update efficiency of relatively independent kernel modules can be improved, which is beneficial to improving the efficiency of the target operating system, reducing the time affected by the update of the kernel module in the target operating system, and thus optimizing the performance of the target operating system.

[0133] Among them, it can be considered that reloading to the system kernel actually represents two processes, that is, 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 to the system kernel to complete the update of the kernel module to be updated.

[0134] S305: Use the kernel module to be updated and the kernel modules that have a dependency relationship with it as target modules.

[0135] In this embodiment, as described above, further update considerations can be made for the kernel module that has a dependency relationship with other kernel modules. When updating and reloading it, the kernel modules that have a dependency relationship with it can be processed in combination with the dependency relationship, which is beneficial to ensuring the reliable update of the kernel module without restarting the target operating system. That is, the kernel module to be updated and the kernel modules that have a dependency relationship with it can be used as target modules.

[0136] Traditional incremental update methods such as patch updates require relevant personnel to deeply consider the updated content, system architecture, coupling relationships between system units, etc. during the preparation of update packages to adaptively form patch packages, etc., resulting in poor scalability of the update process. That is, each time an update is performed, it is usually necessary to redesign the patch package, and it is difficult to reuse the design ideas of historical updates. When there are insufficient parts in the patch package, it is easy to cause problems such as the failure of the target operating system to update or even the crash of the target operating system. It can be seen that compared with traditional incremental update methods, the method of updating the target operating system through full - volume update files in this embodiment can be beneficial when the current update of the target operating system is not suitable for online incremental update, quickly switch to the method of restarting full - volume update to update the target operating system, and can save the process of obtaining update files again to improve the update efficiency. At the same time, in this embodiment, when updating the target operating system, a series of methods for adaptively identifying the relevance between system units are further planned to automatically complete the acquisition of the required content in the full - volume update file during the update process, which can reduce the burden of forming update files and is also beneficial to improving the reliability of the update process.

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

[0138] In this embodiment, in response to at least some of the kernel modules that are target modules among the filtered kernel modules, the dependency topology of the target module can be obtained.

[0139] Specifically, reference can be made to Figure 5 , Figure 5 which is a schematic structural diagram of an embodiment of the dependency topology of this application. As Figure 5 exemplarily shown in, the dependency topology when kernel modules A to kernel modules H are target modules, and the dependency topology can be a directed acyclic graph as Figure 5 exemplarily shown in.

[0140] Optionally, the dependency topology between target modules can be constructed after obtaining the target modules. Or, as exemplified in step S303, the dependency topology between the kernel modules of the target operating system can be pre - constructed so that in step S306, a part of the target modules in the dependency topology can be obtained, or a pruning process can be performed on other parts of the kernel modules in the dependency topology, etc., which is not limited here.

[0141] For example, the dependency topology can be a dependency relationship graph, etc. The kernel modules can be regarded as nodes, and directed edges can be used to represent the dependency relationships between kernel modules. 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 relationship graph.

[0142] S307: Assign an in-degree associated with the dependency frequency to each target module within the dependency topology.

[0143] In this embodiment, the dependency topology can be utilized to plan the reload order of target modules. To this end, the dependency relationships between 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 reload order of target modules, which is beneficial to improving the efficiency of planning the reload order and can also reduce the risk of unreasonable reload order or omission of target modules, thereby improving the update efficiency and reliability of the target operating system.

[0144] S308: Initialize a sorting queue.

[0145] In this embodiment, when planning the reload order of target modules, a sorting queue can be initialized. The sorting queue can be empty, that is, before sorting the target modules, the sorting queue may not contain information about the target modules.

[0146] S309: Sort the target modules in the preset in-degree order to obtain a sorting queue.

[0147] In this embodiment, the target modules can be sorted in the preset in-degree order, and the reload order can be obtained based on the sorting. Thus, the reload order of the update sub-files of the target modules is planned.

[0148] Specifically, the target modules with an in-degree equal to the preset value can be regarded as independent modules.

[0149] The independent modules can be added to the sorting queue, and the in-degrees of the adjacent modules in the dependency topology can be globally updated. Herein, the adjacent modules refer to the target modules that depend on the independent modules.

[0150] The target modules with an in-degree equal to the preset value after the update can be added to the sorting queue as new independent modules until all target modules are added to the sorting queue.

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

[0152] For example, the in-degree can be associated with the frequency of a target module depending on other target modules, that is, the in-degree of a target module is directly 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.

[0153] Specifically, reference can be made to Figure 6 , Figure 6This is a schematic flowchart of an embodiment for obtaining a sorting queue in this application. It can be seen that Figure 6 The illustration is based on Figure 5 the process of obtaining a sorting queue according to the shown dependency topology.

[0154] As Figure 6 exemplarily shown in [reference], after processing such as step S307 to assign in-degrees to each target module, the in-degrees of kernel modules A to H are 2, 1, 1, 2, 1, 0, 1, and 2 respectively.

[0155] It should be noted that Figure 6 the initial sorting queue is omitted in [reference]. The initial sorting queue can be considered as the sorting queue []. When initially screening independent modules, kernel module F, as a target module with an in-degree of the preset value 0, can be added as an independent module to the sorting queue [] to update it to the sorting queue [F].

[0156] Then Figure 6 in [reference], kernel module F and other target modules are distinguished and shown in a dotted line manner. After kernel module F is added as an independent module to the sorting queue, kernel modules G, H, and B that depend on kernel module F, as adjacent modules, can have their in-degrees decreased by one. After the global update of the adjacent modules that have undergone the minus-one processing by the adjacent modules, the in-degrees of kernel modules G and B are the preset value 0. Therefore, kernel modules G and B can be used as independent modules and added to the sorting queue [F] to update it to the sorting queue [F, G, B]. The in-degree of kernel module H, which is the adjacent module of kernel module G, can be updated from 1 to 0; the in-degree of kernel module A, which is 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 used as an independent module and added to the sorting queue [F, G, B] to update it to the sorting queue [F, G, B, H].

[0157] And so on, the sorting queues [F, G, B, H, C], [F, G, B, H, C, A], [F, G, B, H, C, A, E], and [F, G, B, H, C, A, E, D] can be gradually obtained. That is to say, until all target modules in the dependency topology are added to the sorting queue, namely the sorting queue [F, G, B, H, C, A, E, D] is formed, it can be considered that the sorting queue is completed.

[0158] It should be noted that Figure 6 in [reference], after the in-degree of kernel module A is updated to 0, the sorting queue [F, G, B, H, C, A] is obtained, and the process of first updating the in-degree of kernel module E that depends on kernel module A to 0 to obtain the sorting queue [F, G, B, H, C, A, E] is omitted. That is to say, in Figure 6In the ellipsis part of the two dependency topological processes at the bottom of the [dependency topological graph], the steps of obtaining the sorting queue [F, G, B, H, C, A, E] are omitted. Then, since the in-degree of kernel module E is 0, the in-degree of the adjacent module of kernel module E (i.e., kernel module D) can be updated to 0. Therefore, kernel module D can be used as an independent module and written into the sorting queue to obtain Figure 6 the final sorting queue [F, G, B, H, C, A, E, D] in the process steps exemplified in [the dependency topological graph].

[0159] It should be noted that when there are multiple independent modules with in-degree equal to the preset value, the addition order of the independent modules to the sorting queue can be random, so as to improve the addition efficiency. Or, certain addition rules can be preset, which is beneficial to adapting to actual requirements or business scenarios, etc., and will not be limited here.

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

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

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

[0163] S311: Determine that the sorting of the target modules fails.

[0164] 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. It is determined that there is a circular dependency and the sorting of the target modules fails. Further, relevant information about the possible circular dependency can also be fed back, so as to timely prompt the abnormality of the target operating system update.

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

[0166] In this embodiment, the order matching the sorting queue can be used as the unloading order of the target modules. The order reverse to the sorting queue can be used as the loading order of the target modules. That is to say, the reload order of the target modules can include two parts of data. One is the unloading order of the target modules, and the other is the loading order of the target modules.

[0167] For example, a result list can be further formed. When the sorting queue is not empty, the head element of the sorting queue can be added to the result list to form the reload order in the result list.

[0168] S313: Overload the update sub-files of the target module in the order of overload successively.

[0169] In this embodiment, the system file of the target module can be updated by using the update sub-file of the target module. Moreover, the target module can be unloaded from the system kernel in the order of uninstallation successively. In response to that the system file of the target module has been updated to the update sub-file carried in the full update file, the target module after updating the system file can be loaded into the system kernel in the order of loading successively.

[0170] For example, the business software module can include kernel module X, kernel module Y, and kernel module Z, and all three are loaded into the system kernel. Among them, kernel module X depends on kernel module Y, and kernel module Y depends on kernel module Z.

[0171] When the update sub-files of kernel module X and kernel module Z do not match their current system files, it can be considered that both kernel module X and kernel module Z are 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 overloaded.

[0172] Because kernel module X depends on kernel module Y, the overloading process of kernel module X should be in turn: unload kernel module Y, overload (i.e., unload and then load) kernel module X, and load kernel module Y.

[0173] Because kernel module Y depends on kernel module Z, the overloading process of kernel module Y should be in turn: unload kernel module Z, overload (i.e., unload and then load) kernel module Y, and load kernel module Z.

[0174] In view of this, it can be considered that when updating both kernel module X and kernel module Z, their system files can be replaced with the respective update sub-files in the full update file. Regarding the overloading order of the system kernel, it is: unload kernel module Z, unload kernel module Y, overload (i.e., unload and then load) kernel module X, load kernel module Y, and load kernel module Z.

[0175] The following gives an example to elaborate on the detailed principles such as the formation of the full update file and the verification method for multi-dimensional verification of the full update file. Please refer to Figure 7 , Figure 7 This is a schematic flowchart of an embodiment for updating the target operating system in this application.

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

[0177] The following gives examples to elaborate on the verification dimensions of the verification file.

[0178] When the verification dimension includes target operating system verification, the verification information can include system version information of the target operating system such as the system version number. For example, the system version number can 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.

[0179] When the verification dimension includes identity verification, the verification information can include the user's identity authentication information, etc. 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.

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

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

[0182] When verifying the business software modules, the key business software and / or core business software running in the target operating system can be verified. For example, the hash values of the relevant source files of each basic module and / or kernel module can be calculated and recorded, and the calculated hash values can be used as the verification information of each basic module and / or kernel module of the business software module.

[0183] 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 components such as BIOS, BMC, and CPLD can be recorded. In this way, when updating the target operating system, comparison and verification can be performed on the system firmware before and after the update, which is beneficial to ensuring the compatibility and stability of hardware such as the system firmware.

[0184] In this way, 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.

[0185] Furthermore, when the operating system update device updates the target operating system, it can obtain the full update file carrying the verification file and download it to the local device. The full update file can be verified through verification methods such as signature tools and passwords, so as to confirm the integrity and authenticity of the full update file.

[0186] In response to the full update file passing the authenticity verification, the compressed full update file can be decompressed, and further, the integrity of the verification file can be judged to confirm whether it contains the verification information exemplified in the previous text.

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

[0188] Specifically, when the verification dimension includes target operating system verification, 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, distribution version, and 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 this part of the verification. Otherwise, it can be considered that the target operating system cannot be updated using the full update file.

[0189] 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.

[0190] When verifying the basic system components, the information of the core components in the target operating system can be read using the target operating system commands as the verification information. By comparing the verification information read from the target operating system with the verification information in the verification file, while matching whether the basic system components match, it is also possible to screen the basic system components that need to be updated and generate a list of components that need to be updated.

[0191] When verifying a business software module, the information of the business software module 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 business software module is matched, and at the same time, it is possible to screen the basic module and / or kernel module that needs to be updated, and generate container files such as a list of business software that needs to be updated. Further, 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.

[0192] 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 is matched, and at the same time, it is possible to screen the system firmware that needs to be updated, and generate container files such as a list of components that needs to be updated. Among them, when generating the firmware list of the system firmware, the system firmware name, the current version information, and the target version information of the update sub-files included in the full update file can be recorded together.

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

[0194] As described in the previous text, when updating the basic system components and the system firmware, it can be considered that the target operating system needs to be restarted for the update. When updating the basic module in the business software module, it can be considered that the target operating system does not need to be restarted for the update. When updating the kernel module in the business software module, it is necessary to consider whether it is loaded into the system kernel and other kernel modules that have dependencies on it. However, this is not absolute, and the risk factors of each system unit can also be considered together.

[0195] When performing the update of the target operating system, if an online incremental update is performed on the target operating system, the full update file can be decompressed to obtain the update sub-files of each system unit. According to the container file, the system files of the unit to be updated can be replaced with its update sub-files. The permission settings of the newly replaced system files can be checked and adjusted, and soft links can be recreated according to the path of the updated system files to help ensure that the system and applications can reliably access the updated system files.

[0196] If a full restart update is performed on the target operating system, the system files of the files to be updated can be replaced with their updated sub-files as described above. It is also possible to further generate a dynamic script and link it to cloud services such as the target operating system service. So that when the target operating system restarts, the dynamic script can be automatically executed, and corresponding update steps can be performed and the system services related to the restart can be executed.

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

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

[0199] For the description of the features in the embodiments corresponding to the system update device, reference can be made to the relevant descriptions in the embodiments corresponding to the operating system update method, which will not be elaborated here one by one.

[0200] The embodiments of the present application also provide an electronic device, including a memory and a processor. 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 embodiments of the operating system update method.

[0201] The embodiments of the present application also provide a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps in any of the above embodiments of the operating system update method when running.

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

[0203] The embodiments of the present application also provide a computer program product, which includes a computer program. When the computer program is executed by a processor, it implements the steps in any of the above embodiments of the operating system update method.

[0204] Embodiments of the present application further provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, where the computer program, when executed by a processor, implements the steps in any of the above-described embodiments of the operating system update method.

[0205] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the components and steps of each example have been generally described according to their functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present application.

[0206] The above has introduced in detail an operating system update method, an electronic device, a computer-readable storage medium, and a computer program product provided by the present application. Specific examples are used herein to illustrate the principles and implementation manners of the present application. The description of the above embodiments is only used to help understand the method and its core idea of the present application. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A method for updating an operating system, characterized in that, The operating system update method includes: The target operating system obtains the full update file of the target operating system and the units to be updated of the target operating system; Verify whether the units to be updated support online incremental updates; In response to the units to be updated supporting the online incremental updates, perform online incremental updates on them using the update sub-files of the units to be updated in the full update file; in response to the units to be updated including kernel modules, query whether the system kernel of the target operating system has loaded the kernel modules to be updated; In response to the target operating system not loading the kernel modules to be updated, update the system files of the kernel modules to be updated to their update sub-files, and load the kernel modules to be updated with the updated system files into the system kernel; In response to the system kernel loading the kernel modules to be updated, query the kernel modules that have a dependency relationship with the kernel modules to be updated loaded into the system kernel; take the kernel modules to be updated loaded into the system kernel and the kernel modules that have a dependency relationship with them as target modules; plan the reload order of the update sub-files of the target modules; reload the update sub-files of the target modules in sequence according to the reload order; the system units of the target operating system include kernel modules associated with services; In response to the units to be updated not supporting the online incremental updates, perform a restart full update on the target operating system using the full update file; where the full update file refers to an update file that can perform a restart full update on the target operating system.

2. The operating system update method according to claim 1, wherein The performing a restart full update on the target operating system using the full update file includes: Extract the full update file to obtain the update sub-files of each system unit; where the system units include the units to be updated; Extract the update sub-files of each of the units to be updated respectively, and reload the system files of the units to be updated as the update sub-files.

3. The operating system update method according to claim 1, wherein The planning the reload order of the update sub-files of the target modules includes: Obtain the dependency topology of the target modules; Assign an in-degree associated with their dependency frequency to each of the target modules in the dependency topology; Sort the target modules in the preset in-degree order, and obtain the reload order based on the sorting.

4. The operating system update method according to claim 3, wherein The sorting the target modules in the preset in-degree order includes: Initialize a sorting queue; Take the target modules with an in-degree of a preset value as independent modules and add them to the sorting queue; Globally update the in-degrees of the adjacent modules in the dependency topology, and take the target modules with an in-degree of the preset value after the update as new independent modules and add them to the sorting queue until all the target modules are added to the sorting queue; where the adjacent modules refer to the target modules that depend on the independent modules.

5. The operating system update method according to claim 4, wherein After the step of until all the target modules are added to the sorting queue, it further includes: Compare the number of target modules included in the sorting queue and the dependency topology; In response to the number of target modules included in the two not matching, determine that there is a circular dependency and the sorting of the target modules fails.

6. The operating system update method according to claim 4, wherein The obtaining of the overloading order based on sorting includes: Taking the order matching the sorting queue as the unloading order of the target module; taking the order reverse to the sorting queue as the loading order of the target module; The sequentially reloading the updated sub-files of the target module according to the overloading order includes: Updating the system file of the target module by using the updated sub-file of the target module; Sequentially unloading the target module from the system kernel according to the unloading order; Sequentially loading the target module after updating the system file to the system kernel according to the loading order.

7. The operating system update method according to claim 1, characterized in that After the response to the unit to be updated includes the kernel module, it 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, updating the system file of the kernel module to be updated to its updated sub-file, and loading the kernel module to be updated with the updated system file to the system kernel.

8. The operating system update method according to claim 1, wherein The verifying 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 unit to be updated including basic system components and / or system firmware, determining that the unit to be updated does not support the online incremental update.

9. The operating system update method according to claim 1, characterized in that The verifying whether the unit to be updated supports online incremental update includes: Evaluating a risk factor characterizing the risk of online incremental update of the unit to be updated; In response to the risk factor reaching the risk threshold, determining that the unit to be updated does not support the online incremental update.

10. The operating system update method according to claim 1, wherein The performing online incremental update on the unit to be updated by using the updated sub-file of the unit to be updated in the full update file includes: Updating the system file of the unit to be updated to the updated sub-file; Correcting the permission setting of the updated sub-file, and updating the connection between the target operating system and the updated system file; Restarting the unit to be updated.

11. The operating system update method according to claim 1, wherein The performing a restart full update on the target operating system by using the full update file includes: Analyzing the steps to be executed after the target operating system restarts to generate a dynamic script; Linking the dynamic script to the cloud service of the target operating system; Performing a restart full update on the target operating system; In response to the target operating system restarting, obtaining and executing the dynamic script from the cloud service.

12. The operating system update method according to claim 1, wherein After obtaining the full update file of the target operating system, it further includes: Parsing the system verification information carried by the full update file; Obtaining the 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, determining that the full update file can be used to update the target operating system.

13. The operating system update method according to claim 1, wherein Obtaining the unit to be updated of the target operating system includes: Parsing the target version of each system unit in the full update file; Comparing the 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, determining that the system unit is the unit to be updated.

14. The operating system update method according to claim 13, wherein The determining that the system unit is the unit to be updated includes: Write the unit update information of the unit to be updated into a container file; wherein, the unit update information includes the unit name and whether it supports online incremental update; The verification of whether the unit to be updated supports online incremental update includes: Traverse the container file to obtain whether each unit to be updated supports online incremental update.

15. The operating system update method according to claim 1, wherein After performing online incremental update on the unit to be updated using the update sub-file of the unit to be updated in the full update file, it further includes: Obtain the update status of the unit to be updated; In response to the update status of the unit to be updated indicating update failure, perform a restart full update on the target operating system using the full update file.

16. The operating system update method according to claim 1, wherein After performing online incremental update or restart full update, it further includes: In response to completing the system update, obtain the current system file of the unit to be updated; Verify the current system file and its permissions; In response to the verification of the current system file and its permissions failing, obtain the backup historical update file; wherein, the historical update file represents the full update file used to update the target operating system at a historical moment; Perform a version rollback on the target operating system using the historical update file.

17. The operating system update method according to claim 16, wherein After performing online incremental update or restart full update, it further includes: In response to successfully updating the target operating system using the full update file, back up the full update file as a historical update file.

18. An electronic device, characterized in that, Includes: A memory for storing a computer program; A processor for implementing the steps of the operating system update method according to any one of claims 1 to 17 when executing the computer program.

19. A computer-readable storage medium, characterized in that, A computer program is stored in the computer-readable storage medium, wherein the computer program implements the steps of the operating system update method according to any one of claims 1 to 17 when executed by a processor.

20. A computer program product comprising a computer program, characterized in that, The computer program implements the steps of the operating system update method according to any one of claims 1 to 17 when executed by a processor.

Images