Linux upgrade path recommendation method and device and storage medium

Abstract

Embodiments of the invention disclose a Linux upgrade path recommendation method and apparatus, and a storage medium. The method comprises the steps of generating at least two upgrade paths according to an upgrade relationship between versions; system upgrading simulation testing is carried out on each upgrading path; querying a first packet list of the system after the simulation test is upgraded by using each upgrade path; querying a second packet list which is normally and directly installed to the system of the highest version; comparing the first packet list with the second packet list, and judging whether the first packet list comprises all files in the second packet list or not; and when all the files in the second package list are included, judging whether the first package list includes different versions of files related to upgrade application program data or not, and if so, taking an upgrade path corresponding to the first package list as a recommended path. And a proper upgrading path can be selected for recommendation through testing, so that the system upgrading efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of Linux system upgrade, and in particular to a Linux upgrade path recommendation method, device and storage medium. Background Art

[0002] With the rapid development of the software industry, the version iteration of the system is getting faster and faster. At present, differentiated updates are generally performed online. Specifically, a software source server can be set up, which has a software source warehouse for storing software packages (deb packages) and source index files, maintained by the administrator, and provides software download services for system upgrade clients through https. At the same time, it provides a storage environment for software packages submitted by developers in accordance with warehouse management specifications. The system upgrade client performs update detection, update download and installation through the interface, downloads the index file from the corresponding software warehouse by reading the system sourcelist file, and then downloads the update package according to the index and completes the installation. The source manager server provides a software source query and distribution interface, and completes the interaction with the source manager client through https.

[0003] In the process of implementing the present invention, the inventors discovered the following technical problem: with the update and iteration of versions, there will be a situation where multiple versions of software coexist in the market, and each version has a potential demand for system upgrades. Figure 1 This is a schematic diagram of the system upgrade path in the prior art, see Figure 1 , taking the latest version D of the current system as an example, it is necessary to support upgrades from three versions: A, B, and C. In this way, at least three upgrade test paths are necessary, namely A->D, B->D, and C->D. However, the actual situation is far more than that. Assuming that version A is the most original version, both versions B and C need to be viewed in two situations. The first is a newly installed version B or C, and the second is a version B or C upgraded from an earlier version. Because the newly installed version B or C may not be completely consistent with the upgraded version B or C. As can be seen from the figure, the test path combination has increased by 4, becoming 7. Different upgrade paths may cause application exceptions. Selecting an improper upgrade path will affect the efficiency of system upgrades. Summary of the invention

[0004] The embodiment of the present invention provides a Linux upgrade path recommendation method, device and storage medium to solve the technical problem in the prior art that in the presence of multiple upgrade paths, an improper upgrade path affects the upgrade efficiency.

[0005] In a first aspect, an embodiment of the present invention provides a Linux upgrade path recommendation method, comprising:

[0006] Generate at least two upgrade paths according to the upgrade relationship between versions;

[0007] Conduct system upgrade simulation tests for each upgrade path respectively;

[0008] Query the first package list of the system after the simulation test is upgraded using each upgrade path;

[0009] Query the second package list that is normally installed directly to the highest version of the system;

[0010] Compare the first package list with the second package list to determine whether the first package list includes all the files in the second package list;

[0011] When all files in the second package list are included, it is determined whether the first package list includes files of different versions related to the upgraded application data, and if included, the upgrade path corresponding to the first package list is used as a recommended path.

[0012] In a second aspect, an embodiment of the present invention further provides a Linux upgrade path recommendation device, comprising:

[0013] A generation module, used for generating at least two upgrade paths according to the upgrade relationship between versions;

[0014] A simulation test module is used to perform system upgrade simulation tests on each upgrade path;

[0015] A first query module, used for querying a first package list of the system after the upgrade simulation test using each upgrade path;

[0016] A second query module is used to query a second package list of a system that is normally directly installed to the highest version;

[0017] A comparison module, used for comparing the first package list with the second package list, and determining whether the first package list includes all the files in the second package list;

[0018] As a module, it is used to determine whether the first package list includes files of different versions related to upgrading application data when all files in the second package list are included, and if included, take the upgrade path corresponding to the first package list as the recommended path.

[0019] In a third aspect, an embodiment of the present invention further provides a storage medium comprising computer executable instructions, wherein the computer executable instructions, when executed by a computer processor, are used to execute the Linux upgrade path recommendation method provided in the above embodiment.

[0020] The Linux upgrade path recommendation method, device and storage medium provided by the embodiment of the present invention generate at least two upgrade paths according to the upgrade relationship between versions; perform system upgrade simulation test for each upgrade path respectively; query the first package list of the system after the upgrade simulation test using each upgrade path; query the second package list of the system directly installed to the highest version normally; compare the first package list and the second package list, and judge whether the first package list includes all the files in the second package list; when all the files in the second package list are included, judge whether the first package list includes files of different versions related to the upgraded application data, and when included, take the upgrade path corresponding to the first package list as the recommended path. By using the simulation test, the file package in the system finally upgraded after each upgrade path can be compared with the file package in the system with the latest version installed normally, determine the difference between the two, and judge whether the files corresponding to the software dependency exist in the new system after the normal upgrade path, and determine the recommended path accordingly. The appropriate upgrade path can be selected for recommendation through testing, and the user can upgrade the system according to the recommended path without trying according to multiple upgrade paths, thereby improving the system upgrade efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0022] Figure 1 This is a schematic diagram of the system upgrade path in the prior art

[0023] Figure 2 It is a flowchart of a Linux upgrade path recommendation method provided by Embodiment 1 of the present invention;

[0024] Figure 3 : is a flowchart of a Linux upgrade path recommendation method provided by Embodiment 2 of the present invention;

[0025] Figure 4 It is a structural diagram of a Linux upgrade path recommendation device provided in Embodiment 3 of the present invention. DETAILED DESCRIPTION

[0026] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0027] Embodiment 1

[0028] Figure 1: is a flow chart of a Linux upgrade path recommendation method provided by Embodiment 1 of the present invention. This embodiment can recommend a suitable upgrade path when there are multiple upgrade paths. The method can be executed by a Linux upgrade path recommendation device, and specifically includes the following steps:

[0029] Step 110: Generate at least two upgrade paths according to the upgrade relationship between versions.

[0030] For example, please refer to Figure 1 The relationship between the system versions in the above example can generate multiple upgrade paths. For example, each system version can be used as a node. With the initial system as the starting node and the final upgraded version as the end node, each node is traversed to generate multiple upgrade paths. Furthermore, according to the statistical situation, the initial version with a large circulation can be further screened to reduce the number of use cases for the later simulation test.

[0031] Step 120: Perform a system upgrade simulation test on each upgrade path.

[0032] Exemplarily, corresponding test cases may be set according to each upgrade path, and system upgrade simulation tests may be performed separately.

[0033] Step 130, querying the first package list of the system after the upgrade simulation test using each upgrade path.

[0034] Exemplarily, after the simulation test is performed to upgrade to the latest version of the system according to each upgrade path, the package list file is queried through the corresponding command in the Linux system. Exemplarily, the following command can be used to obtain it: dpkg-l|sed'1,5d'|awk'{print$2,$3}'. Optionally, before this, a part of the upgrade path that cannot be normally upgraded to the latest version of the system according to the path is excluded.

[0035] Step 140, query the second package list that is normally directly installed to the highest version of the system.

[0036] Exemplarily, the above Linux command can still be used to query the second package list that is normally and directly installed to the latest version of the system.

[0037] The said directly installing to the highest version system can be a bare metal terminal without any operating system installed, directly installing the latest version system without using any upgrade method to reach the latest version system.

[0038] Step 150: compare the first package list and the second package list to determine whether the first package list includes all the files in the second package list.

[0039] The upgraded package list should include the new system's package list. That is, the new system's package list is a subset of the upgraded package list. Use the above method to determine whether the latest version of the system upgraded using the upgrade path is abnormal.

[0040] Step 160, when all files in the second package list are included, determine whether the first package list includes files of different versions related to upgrading the application data, and if included, use the upgrade path corresponding to the first package list as a recommended path.

[0041] In the process of upgrading through the upgrade path, in most cases, at least one intermediate version will be passed. Therefore, during the upgrade process, some files with the same data of some applications may have files of different system versions than those installed directly. If such files exist, it means that during the upgrade process, these files can better support the application of the system upgraded to the latest version. Therefore, the upgrade path corresponding to this file package is used as the recommended path.

[0042] This embodiment generates at least two upgrade paths according to the upgrade relationship between versions; performs system upgrade simulation tests for each upgrade path respectively; queries the first package list of the system after the upgrade simulation test using each upgrade path; queries the second package list of the system that is normally directly installed to the highest version; compares the first package list and the second package list to determine whether the first package list includes all the files in the second package list; when all the files in the second package list are included, determine whether the first package list includes files of different versions related to the upgraded application data, and when included, use the upgrade path corresponding to the first package list as the recommended path. The simulation test can be used to compare the file package in the system after the final upgrade of each upgrade path with the file package in the system with the latest version installed normally, determine the difference between the two, and determine whether the files corresponding to the software dependency exist in the new system after the normal upgrade path, and determine the recommended path accordingly. The appropriate upgrade path can be selected for recommendation through testing, and the user can upgrade the system according to the recommended path without having to try multiple upgrade paths, thereby improving the system upgrade efficiency.

[0043] In a preferred implementation of this embodiment, the upgrade path corresponding to the first package list can be used as a recommended path, and the specific optimization is: when there are multiple upgrade paths corresponding to the first package list, the upgrade path with the shortest path is used as the recommended path. Using the above method, the optimal upgrade path can be selected to further improve the upgrade efficiency of the Linux system.

[0044] Embodiment 2

[0045] Figure 3This is a flow chart of the Linux upgrade path recommendation method provided by the second embodiment of the present invention. This embodiment is optimized based on the above embodiment, and the method can also add the following steps: query the third package list of the system before the upgrade. Determine the third-party software that the system upgrade client depends on; determine whether the first package list includes files that the third-party software depends on; if included, determine whether the files that the third-party software depends on are files in the third package list; if they are not files in the third package list, exclude the corresponding upgrade path from the recommended path.

[0046] See also Figure 3 , the Linux upgrade path recommendation method comprises:

[0047] Step 310: Generate at least two upgrade paths according to the upgrade relationship between versions, and perform a system upgrade simulation test on each upgrade path.

[0048] Step 220, query the first package list of the system after the upgrade simulation test using each upgrade path, and query the second package list of the system directly installed to the highest version normally.

[0049] Step 230 , comparing the first package list and the second package list to determine whether the first package list includes all the files in the second package list.

[0050] Step 240, when all files in the second package list are included, determine whether the first package list includes files of different versions related to upgrading the application data, and if included, use the upgrade path corresponding to the first package list as a recommended path.

[0051] Step 250, query the third package list of the system before the upgrade, determine the third-party software that the system upgrade client depends on, and determine whether the first package list includes files that the third-party software depends on.

[0052] For operating system upgrades, there are usually third-party software that is relied on. Third-party software products (such as Zhaoxin Driver, Qi'anxin Browser, etc.) may be used between the new and old versions of the system. In this case, it is necessary to provide detection of third-party software to avoid the situation where the product does not work after the product upgrade.

[0053] Therefore, in this embodiment, the command provided by the Linux system in the above embodiment is first used to query the package list file of the non-upgraded system, and to query whether the upgraded system includes files that the third-party software depends on.

[0054] Step 260, determining whether the file that the third-party software depends on is a file in the third package list, and if it is not a file in the third package list, excluding the corresponding upgrade path from the recommended path.

[0055] The upgraded package list should be a collection of the old and new system package lists. For this part, you need to pay attention to whether the third-party software is upgraded. If not, it means that the third-party software has problems in the upgrade process corresponding to the upgrade path. Therefore, the corresponding upgrade path needs to be excluded from the recommended path.

[0056] This embodiment adds the following steps: query the third package list of the system before the upgrade. Determine the third-party software that the system upgrade client depends on; determine whether the first package list includes files that the third-party software depends on; if included, determine whether the files that the third-party software depends on are files in the third package list; if they are not in the third package list, exclude the corresponding upgrade path from the recommended path. This can avoid the impact on the third-party software required for the upgrade during the corresponding upgrade process in the upgrade path, thereby causing upgrade errors, and can improve the efficiency of Linux system upgrades.

[0057] In a preferred implementation of this embodiment, the system upgrade simulation test can be optimized for each upgrade path respectively to improve the accuracy of the simulation test and reduce the possibility of upgrade anomalies.

[0058] Specifically, it may include: during the automatic check and upgrade process, checking whether the normal functions of the system can be used normally. For example, during the upgrade process, simulating people to operate common functions such as the start menu and taskbar, simulating common function operations during the upgrade process, and judging whether the impact of system interoperability is normal; accordingly, taking the upgrade path corresponding to the first package list as the recommended path, and specifically optimizing as follows: filtering the upgrade path corresponding to the first package list according to whether the impact of system interoperability is normal; taking the filtered upgrade path as the recommended path. This is to avoid upgrade failures caused by normal operations during the early check and upgrade process.

[0059] It may also include: determining whether there is software that existed before the system upgrade and was deleted after the upgrade, and if so, determining whether the software is software that needs to be retained after the upgrade. For software that existed before the system upgrade and was deleted by the new version, the software that needs to be retained after the upgrade needs to be detected to avoid overwriting or deletion caused by the upgrade, and the upgrade path corresponding to the first package list is used as the recommended path, which is specifically optimized as follows: filtering the software that needs to be retained after the upgrade as a filtering condition; and using the filtered upgrade path as the recommended path.

[0060] It may also include: determining whether the modules that did not exist before the upgrade are correctly installed; and verifying whether the installation files of the modules that need to be updated are updated. Using the above method to determine whether the upgrade process is completed normally, the upgrade path corresponding to the first package list is used as the recommended path, and the specific optimization is: the upgrade path corresponding to the first package list is screened according to whether the newly added modules are correctly installed and whether the verification results are correct as screening conditions; and the screened upgrade path is used as the recommended path.

[0061] It can also include: comparing the configuration files of the new version after the upgrade and the version before the upgrade to determine whether the upgraded configuration files are retained; comparing the new version after the upgrade using each upgrade path and the configuration of the newly installed new version to determine whether they are consistent, so as to ensure that the configuration structure and data after the upgrade are correct. The above method can ensure the integrity of user data. And the upgrade path corresponding to the first package list is used as the recommended path, which is specifically optimized as follows: whether it is retained or whether it is consistent is used as a screening condition for screening; the screened upgrade path is used as the recommended path.

[0062] By using the above method, the system upgrade simulation test can be improved so that the system upgraded through the upgrade path can achieve data integrity, modules are correctly upgraded, and upgrade abnormalities are reduced, further improving the upgrade efficiency.

[0063] Embodiment 3

[0064] Figure 4 is a schematic diagram of the structure of the Linux upgrade path recommendation device provided by the third embodiment of the present invention, see Figure 4 , the Linux upgrade path recommendation device comprises:

[0065] A generating module 310, configured to generate at least two upgrade paths according to the upgrade relationship between versions;

[0066] A simulation test module 320, used to perform a system upgrade simulation test for each upgrade path;

[0067] A first query module 330 is used to query a first package list of the system after the upgrade simulation test using each upgrade path;

[0068] A second query module 340 is used to query a second package list of a system that is normally directly installed to the highest version;

[0069] A comparison module 350, configured to compare the first package list with the second package list to determine whether the first package list includes all the files in the second package list;

[0070] As module 360, when all files in the second package list are included, it is used to determine whether the first package list includes files of different versions related to upgrading the application data, and if included, take the upgrade path corresponding to the first package list as the recommended path.

[0071] The Linux upgrade path recommendation device provided in this embodiment generates at least two upgrade paths according to the upgrade relationship between versions; performs system upgrade simulation tests for each upgrade path respectively; queries the first package list of the system after the upgrade simulation test using each upgrade path; queries the second package list of the system that is normally directly installed to the highest version; compares the first package list and the second package list to determine whether the first package list includes all the files in the second package list; when all the files in the second package list are included, it is determined whether the first package list includes files of different versions related to the upgraded application data, and when included, the upgrade path corresponding to the first package list is used as the recommended path. The simulation test can be used to compare the file packages in the system after the final upgrade of each upgrade path with the file packages in the system with the latest version installed normally, determine the difference between the two, and determine whether the files corresponding to the software dependency exist in the new system after the normal upgrade path, and determine the recommended path accordingly. The appropriate upgrade path can be selected for recommendation through testing, and the user can upgrade the system according to the recommended path without having to try multiple upgrade paths, thereby improving the system upgrade efficiency.

[0072] Based on the above embodiments, the key test variables also include: the number of parks,

[0073] Accordingly, the generating module includes:

[0074] A determination unit, configured to determine the local and remote access amounts according to the service of the server when determining that the application scope of the server is internal use;

[0075] The setting unit is used to set the bandwidth upper limit range parameters of each park based on the remote access volume.

[0076] Based on the above embodiments, the optimization module includes:

[0077] An acquisition unit, used to acquire the lowest-cost campus server configuration, campus bandwidth purchase service and campus network device configuration that conforms to the test result range in the sorting results;

[0078] As a unit, it is used to configure the remote campus server, purchase bandwidth services in the campus and configure the campus network equipment as a design server network configuration service plan.

[0079] Based on the above embodiments, the device further includes:

[0080] The return module is used to adjust the off-site access volume of the campus when the cost of the designed server network configuration service plan exceeds the cost threshold, and return to generate multiple test recipe steps based on preset test key variables until it is lower than the cost threshold or the preset number of generations.

[0081] Based on the above embodiments, the device further includes:

[0082] The third query module is used to query the third package list of the system before the upgrade.

[0083] Based on the above embodiments, the device further includes:

[0084] A third-party determination module is used to determine the third-party software that the system upgrade client depends on;

[0085] A dependent file determination module, used to determine whether the first package list includes files that the third-party software depends on;

[0086] An inclusion judgment module is used to judge whether the file that the third-party software depends on is a file in the third package list when including;

[0087] The exclude module is used to exclude the corresponding upgrade path from the recommended path when it is not a third package list file.

[0088] Based on the above embodiments, the simulation test module includes:

[0089] The normal detection unit is used to check whether the normal functions of the system can be used normally during the automatic inspection and upgrade process;

[0090] Accordingly, the module includes:

[0091] A first screening unit, configured to screen the upgrade path corresponding to the first package list according to whether the impact on system interoperability is normal;

[0092] The first is used as a unit to use the screened upgrade path as a recommended path.

[0093] Based on the above embodiments, the simulation test module includes:

[0094] A software retention judgment unit, used to judge whether there is software that existed before the system upgrade but was deleted after the upgrade, and if so, whether the software is software that needs to be retained after the upgrade;

[0095] Accordingly, the module includes:

[0096] A second screening unit is used to screen the software that needs to be retained after the upgrade as a screening condition;

[0097] The second is a unit for taking the screened upgrade path as a recommended path.

[0098] Based on the above embodiments, the simulation test module includes:

[0099] A third judging unit, used to judge whether the module that did not exist before after the upgrade is correctly installed; and

[0100] Verify whether the installation files of the modules that need to be updated are updated;

[0101] Accordingly, the module includes:

[0102] A third screening unit, configured to screen the upgrade path corresponding to the first package list according to whether the newly added module is correctly installed and whether the verification result is correct as screening conditions;

[0103] The third unit is used to take the screened upgrade path as a recommended path.

[0104] Based on the above embodiments, the simulation test module includes:

[0105] A third judgment unit is used to compare the configuration files of the new version after the upgrade and the version before the upgrade to determine whether the configuration file after the upgrade is retained; or

[0106] Compare the configuration of the new version after upgrading using each upgrade path with that of the newly installed new version to determine whether they are consistent, so as to ensure that the configuration structure and data after upgrading are correct;

[0107] Accordingly, the module includes:

[0108] A fourth screening unit, used for screening by taking whether to be retained or whether to be consistent as a screening condition;

[0109] The fourth unit is used to use the screened upgrade path as a recommended path.

[0110] Based on the above embodiments, the module includes:

[0111] As a unit, it is used to take the shortest upgrade path as the recommended path when there are multiple upgrade paths corresponding to the first package list.

[0112] The Linux upgrade path recommendation device provided in the embodiment of the present invention can execute the Linux upgrade path recommendation method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0113] Embodiment 4

[0114] Embodiment 4 of the present invention further provides a storage medium comprising computer executable instructions, wherein the computer executable instructions, when executed by a computer processor, are used to execute any of the Linux upgrade path recommendation methods provided in the above embodiments.

[0115] The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0116] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0117] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0118] Computer program code for performing the operations of the present invention may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or device. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0119] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A Linux upgrade path recommendation method, characterized in that: include: Generate at least two upgrade paths according to the upgrade relationship between versions; Conduct system upgrade simulation tests for each upgrade path respectively; Query the first package list of the system after the simulation test is upgraded using each upgrade path; Query the second package list that is normally installed directly to the highest version of the system; Compare the first package list with the second package list to determine whether the first package list includes all the files in the second package list; When all files in the second package list are included, it is determined whether the first package list includes files of different versions related to the upgraded application data, and if included, the upgrade path corresponding to the first package list is used as a recommended path.

2. The method according to claim 1, characterized in that: The method further comprises: Query the third package list of the system before upgrading.

3. The method according to claim 2, characterized in that The method further comprises: Determine the third-party software that the system upgrade client depends on; Determining whether the first package list includes files that the third-party software depends on; When including, determining whether the file that the third-party software depends on is a file in the third package list; When the file is not a third-party package list file, the corresponding upgrade path is excluded from the recommended path.

4. The method according to claim 1, characterized in that: The system upgrade simulation test is performed for each upgrade path respectively, including: During the automatic check and upgrade process, check whether the normal functions of the system can be used normally; Accordingly, taking the upgrade path corresponding to the first package list as the recommended path includes: Screening the upgrade paths corresponding to the first package list according to whether the impact on system interoperability is normal; The screened upgrade path is used as the recommended path.

5. The method according to claim 1, characterized in that The system upgrade simulation test is performed for each upgrade path respectively, including: Determine whether there is software that existed before the system upgrade but was deleted after the upgrade, and if so, determine whether the software is software that needs to be retained after the upgrade; Accordingly, taking the upgrade path corresponding to the first package list as the recommended path includes: The software to be retained after the upgrade is used as a screening condition for screening; The screened upgrade path is used as the recommended path.

6. The method according to claim 1, characterized in that The system upgrade simulation test is performed for each upgrade path respectively, including: Determine whether modules that did not exist before are installed correctly after the upgrade; and Verify whether the installation files of the modules that need to be updated are updated; Accordingly, taking the upgrade path corresponding to the first package list as the recommended path includes: The upgrade path corresponding to the first package list is screened according to whether the newly added module is correctly installed and whether the verification result is correct as a screening condition; The screened upgrade path is used as the recommended path.

7. The method according to claim 1, characterized in that The system upgrade simulation test is performed for each upgrade path respectively, including: Compare the configuration files of the new version after the upgrade with those of the version before the upgrade to determine whether the configuration files after the upgrade are retained; or Compare the configuration of the new version after upgrading using each upgrade path with that of the newly installed new version to determine whether they are consistent, so as to ensure that the configuration structure and data after upgrading are correct; Accordingly, taking the upgrade path corresponding to the first package list as the recommended path includes: Whether it is retained or consistent is used as a screening condition for screening; The screened upgrade path is used as the recommended path.

8. The method according to claim 1, characterized in that The taking the upgrade path corresponding to the first package list as the recommended path includes: When there are multiple upgrade paths corresponding to the first package list, the upgrade path with the shortest path is used as the recommended path.

9. A Linux upgrade path recommendation device, characterized in that: include: A generation module, used to generate at least two upgrade paths according to the upgrade relationship between versions; A simulation test module is used to perform system upgrade simulation tests for each upgrade path; A first query module, used for querying a first package list of the system after the upgrade simulation test using each upgrade path; A second query module is used to query a second package list of a system that is normally directly installed to the highest version; A comparison module, used for comparing the first package list with the second package list, and determining whether the first package list includes all the files in the second package list; As a module, it is used to determine whether the first package list includes files of different versions related to upgrading application data when all files in the second package list are included, and if included, take the upgrade path corresponding to the first package list as the recommended path.

10. A storage medium containing computer executable instructions, characterized in that: The computer executable instructions are used to execute the Linux upgrade path recommendation method according to any one of claims 1 to 8 when executed by a computer processor.

Images