System upgrade failure repair method and system based on patch baseline and risk simulation

Abstract

The application discloses a system upgrade fault repair method and system based on patch baseline and risk simulation, and belongs to the technical field of computers. The method comprises the following steps: collecting system version and environment information, obtaining a construction identifier, an operating system version, an update version normalization value and a processor identifier, and querying a construction mapping table to obtain a candidate baseline identifier; comparing a current version of a system anchor point package with a corresponding version of the candidate baseline to obtain a target baseline identifier; reading a monthly patch package set with a monthly increment mark of 1 under the target baseline identifier and excluding software packages that need to be ignored, comparing the software packages with a current system software package state, and generating a missing set, a low version set and an abnormal state set; determining an online source, performing simulation analysis based on the online source, obtaining a simulation operation package set, calculating a total risk score and determining a risk level, and performing repair according to the risk level. The patch baseline is matched by collecting environment information, the risk level is evaluated after the source availability is verified and simulation analysis is performed, and the upgrade fault is repaired according to the level control.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computers, and in particular to a system upgrade fault repair method and system based on patch baseline and risk simulation. BACKGROUND

[0002] During the monthly patch iteration, system update and software package installation process of the Kirin desktop operating system, it is easy to be disturbed by various abnormal factors. External accidents such as power failure, network interruption and forced shutdown, as well as internal faults such as abnormal software source configuration, package parsing error and installation interruption, will all interrupt the update installation process, causing problems such as software package half-installation, incomplete configuration, version disorder or dependency anomaly, which seriously affect the system stability and subsequent patch upgrade work.

[0003] For software package abnormal faults caused by system upgrade interruption, the current operation and maintenance adopts the traditional manual command repair method. In actual operation and maintenance, the staff does not need to perform pre-checking and risk prediction, and directly executes the original repair commands such as dpkg --configure -a, apt-get -f install, apt-get -y install and dpkg -P, to complete the emergency repair by repairing the dependency relationship, cleaning up the installation residues and resetting the abnormal software package, which is the current mainstream conventional disposal means.

[0004] However, the existing repair method is prone to baseline determination errors, inaccurate abnormal package positioning, damage to the original system environment, uncontrollable risks such as software uninstallation or downgrade generated during the repair process, and the repair result lacks effective effect verification basis, the repair reliability is poor, which leads to repeated system faults and patch upgrade failures, and it is difficult to guarantee the long-term stable operation of the Kirin desktop operating system. SUMMARY

[0005] The embodiments of the present application provide a system upgrade fault repair method and system based on patch baseline and risk simulation, to solve the technical problems that the existing system upgrade fault repair lacks pre-checking and risk prediction, is prone to misjudgment and uncontrollable risks, lacks effect verification and has poor reliability, and is difficult to guarantee the stable operation of the system and the patch upgrade.

[0006] In a first aspect, the embodiments of the present application provide a system upgrade fault repair method based on patch baseline and risk simulation, comprising: Collecting system version and environment information to obtain a build identifier, an operating system version, an update version normalized value and a processor identifier, querying a build mapping table based on the build identifier, the operating system version, the update version normalized value and the processor identifier to obtain a candidate baseline identifier; read the current installation version of the anchor package kylin-update-desktop-config in the system, and query the anchor package version corresponding to the candidate baseline identifier, obtain the target baseline identifier according to the comparison result of the current installation version of the anchor package and the anchor package version corresponding to the candidate baseline identifier; read the monthly patch package set with the monthly increment marked as 1 under the target baseline identifier, and exclude the software packages that need to be ignored, obtain the target monthly patch package set, compare the current system software package state with the target monthly patch package set, and generate the missing set, the low version set and the abnormal state set; read / etc / apt / sources.list of the current system, judge whether each target software package version in the target monthly patch package set can be obtained, and determine the online source based on the judgment result; based on the online source, call apt-get -s-f install for simulation analysis, obtain the simulation operation package set, calculate the total risk score based on the missing set, the low version set, the abnormal state set and the simulation operation package, determine the risk level combined with the simulation operation package set, and perform repair based on the online source according to the risk level.

[0007] In the second aspect, the embodiments of the present application also provide a system upgrade fault repair system based on patch baseline and risk simulation, comprising: The acquisition module is configured to acquire system version and environment information, obtain a build identifier, an operating system version, an update version normalized value and a processor identifier, query a build mapping table based on the build identifier, the operating system version, the update version normalized value and the processor identifier, and obtain a candidate baseline identifier. The comparison module is configured to read the current installation version of the anchor package kylin-update-desktop-config in the system, and query the anchor package version corresponding to the candidate baseline identifier, obtain the target baseline identifier according to the comparison result of the current installation version of the anchor package and the anchor package version corresponding to the candidate baseline identifier. The set generation module is configured to read the monthly patch package set with the monthly increment marked as 1 under the target baseline identifier, and exclude the software packages that need to be ignored, obtain the target monthly patch package set, compare the current system software package state with the target monthly patch package set, and generate the missing set, the low version set and the abnormal state set. The judgment module is configured to read / etc / apt / sources.list of the current system, judge whether each target software package version in the target monthly patch package set can be obtained, and determine the online source based on the judgment result. The repairing module is configured to call apt-get -s-f install based on an online source to perform a simulation analysis, obtain a simulation operation package set, calculate a total risk score based on a missing set, a low version set, an abnormal state set and the simulation operation package, determine a risk level in combination with the simulation operation package set, and perform a repair based on the online source according to the risk level.

[0008] In a third aspect, the embodiments of the present application further provide a system upgrade fault repairing device based on patch baseline and risk simulation, comprising: one or more processors; a storage device configured to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors are caused to implement the system upgrade fault repairing method based on patch baseline and risk simulation provided by the above-mentioned embodiments.

[0009] In a fourth aspect, the embodiments of the present application further provide a medium containing computer executable instructions, which are configured to perform the system upgrade fault repairing method based on patch baseline and risk simulation provided by the above-mentioned embodiments when executed by a computer processor.

[0010] The system upgrade fault repair method and system based on patch baseline and risk simulation provided by the embodiment of the application collect system version and environment information, obtain a build identifier, an operating system version, an update version normalized value and a processor identifier, query a build mapping table based on the build identifier, the operating system version, the update version normalized value and the processor identifier, and obtain a candidate baseline identifier; the current installation version of an anchor package kylin-update-desktop-config in the system is read, and the anchor package version corresponding to the candidate baseline identifier is queried, and the target baseline identifier is obtained according to the comparison result of the current installation version of the anchor package and the anchor package version corresponding to the candidate baseline identifier; the monthly patch package set in which the monthly increment mark under the target baseline identifier is 1 is read, and the software package that needs to be ignored is excluded, and the target monthly patch package set is obtained, the current system software package state is compared with the target monthly patch package set, and the missing set, the low version set and the abnormal state set are generated; the / etc / apt / sources.list of the current system is read, it is judged whether each target software package version in the target monthly patch package set can be acquired, and the online source is determined based on the judgment result; the apt-get -s -f install is called based on the online source to perform simulation analysis, the simulation operation package set is obtained, the total risk score is calculated based on the missing set, the low version set, the abnormal state set and the simulation operation package, the risk level is determined in combination with the simulation operation package set, and the repair is performed according to the risk level based on the online source. Through baseline mapping matching, anchor package version calibration, incremental package abnormal classification, online source verification and risk simulation grading repair, the accurate and safe repair of system upgrade fault is realized. BRIEF DESCRIPTION OF DRAWINGS

[0011] The accompanying drawings, which form a part of the present application, are included to provide a further understanding of the application and are incorporated herein for explanation by reference. The present application will become more fully understood from the detailed description and accompanying drawings given below.

[0012] Figure 1 is a flowchart of the system upgrade fault repair method based on patch baseline and risk simulation provided by the first embodiment of the application; Figure 2 is a flowchart of the system upgrade fault repair method based on patch baseline and risk simulation provided by the second embodiment of the application; Figure 3 is a structural diagram of the system upgrade fault repair device based on patch baseline and risk simulation provided by the third embodiment of the application; Figure 4 is a structural diagram of the device provided by the fourth embodiment of the application. DETAILED DESCRIPTION

[0013] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0014] Example 1 Figure 1 This is a flowchart of a system upgrade fault repair method based on patch baseline and risk simulation provided in Embodiment 1 of the present invention. This embodiment can be applied to software package anomaly fault repair scenarios during the monthly patch iteration and system update process of the Kylin desktop operating system, and specifically includes the following steps: Step 110: Collect system version and environment information to obtain build identifier, operating system version, update version normalization value and processor identifier. Based on the build identifier, operating system version, update version normalization value and processor identifier, query the build mapping table to obtain candidate baseline identifiers.

[0015] Build identifier, operating system version, update version normalization value, and processor identifier are four core environment parameters used to locate the patch baseline. The build identifier is a unique number for the system's compilation build batch, used to distinguish different build artifacts within the same system version. The operating system version is the system's major version branch identifier, used to define the major version range of the system. The update version normalization value is the standardized update version number after removing format markers, used to match the iteration node of monthly patches. The processor identifier is a standard short code for the CPU hardware platform, used to distinguish different hardware operating environments.

[0016] Collecting the above four parameters is a prerequisite for achieving accurate baseline matching. It ensures that the subsequently retrieved patch baselines completely correspond to the current system's build batch, version iteration, and hardware architecture, preventing repair failures or system compatibility issues caused by baseline mismatches from the outset. For example, in actual execution, the collection and processing of the four parameters are as follows: First, build identifier collection. The system reads the ` / etc / kylin-build` file, extracts the value corresponding to the `buildid` field, and directly obtains the current system's build identifier. This identifier is permanently written during the system build phase and is unique and immutable. Second, operating system version and update version normalization value collection. The system reads the system version file or the results of a customized version identification module to obtain the operating system version and the original update version. Then, normalization processing is performed on the original update version, removing the trailing asterisk character to generate a uniformly formatted update version normalization value, eliminating interference from version marker format differences on baseline matching. Third, processor identifier collection. The system reads hardware information interfaces such as ` / proc / cpuinfo` and `lscpu`, and converts real CPU models from different manufacturers and with different naming formats into processor identifiers in a standardized short code format according to preset keyword conversion rules. For example, it converts the Phytium D2000 / 8-E8c processor into the FTD2000 identifier, the Huawei Kunpeng Kirin 9006C processor into the HW9006C identifier, and uniformly converts x86_64 or amd64 architectures into the x86 identifier. In addition, the system can also obtain CPU architecture parameters through the `dpkg --print-architecture` command, but these parameters are only used as auxiliary verification information and are not used as the primary key field for patch baseline matching.

[0017] After collecting the four system environment parameters, a mapping table is built to match these parameters to the patch baseline. This is a crucial preliminary step for accurately locating the target baseline for repair. In this embodiment, the build mapping table corresponds to the `build_mappings` table in the baseline database. This table is a self-built data table specific to this embodiment, stored in the `baseline_packages.db` baseline database. It is pre-built by the project maintainer and distributed with maintenance tools. It is neither natively included with the Kylin operating system nor a built-in data table of the dpkg or apt package manager. Upon program startup, it pre-verifies the completeness of all data tables in the baseline database. If any table is missing, the baseline data is deemed incomplete, and the repair process terminates. The build mapping table establishes the mapping relationship between four parameters—build identifier, operating system version, processor identifier, and update version normalization value—and the baseline identifier. Duplicate baseline identifiers are allowed within the table; multiple different build identifiers can share the same set of baseline identifiers to accommodate scenarios where multiple build batches share the same patch baseline. For example, the system uses the four collected parameters as query conditions to match the build mapping table in one go, simultaneously completing hierarchical diagnosis from broad to narrow and a four-field full match query. If any of the following four situations occur: the build identifier is not registered in the table, the mapping relationship between the operating system version and the build identifier does not match, the processor identifier does not match a registered corresponding baseline, or the update version normalization value is not registered, the system will uniformly output that the current system environment does not support repair, and list the specific reasons for not supporting it in the details information. At the same time, the entire process will be terminated, and no dpkg repair, apt repair, source configuration modification, or package installation and uninstallation operations will be performed. Only when all four parameters are successfully matched will the corresponding candidate baseline identifier be retrieved from the build mapping table, and the subsequent steps will proceed.

[0018] Step 120: Read the current installed version of the anchor package kylin-update-desktop-config in the system, and query the anchor package version corresponding to the candidate baseline identifier. Based on the comparison result between the current installed version of the anchor package and the anchor package version corresponding to the candidate baseline identifier, obtain the target baseline identifier.

[0019] Anchor packages are iconic configuration packages used to identify the monthly patch baseline version nodes. In this embodiment, kylin-update-desktop-config is used as the monthly patch anchor package. It is an essential component of every valid patch baseline, and its version number corresponds to the iteration node of the patch baseline, serving as the core reference for baseline version verification. Reading the actual version of the local anchor package and comparing it with the anchor package version of the candidate baseline is a crucial step in the secondary calibration of the candidate baselines obtained from the initial mapping. This corrects baseline deviations caused by the initial environment matching, ensuring that the final target baseline matches the current actual patch level of the system, and avoiding problems such as patch downgrades and dependency conflicts caused by the baseline version lagging behind the current system status.

[0020] For example, after obtaining candidate baseline identifiers by constructing a mapping table, the system reads the current actual installed version of the kylin-update-desktop-config anchor package on the local system. Simultaneously, it queries the baseline database for the target version of the kylin-update-desktop-config anchor package recorded under the candidate baseline identifier. According to the baseline data specification, each valid baseline identifier must contain a version record of the anchor package, serving as a mandatory verification standard for baseline data integrity. If a candidate baseline identifier lacks a corresponding version record of the anchor package, the system will directly determine that the patch baseline data is incomplete and terminate the overall repair process, preventing subsequent version comparison and repair operations from proceeding with erroneous repairs based on missing baseline data.

[0021] After completing the candidate baseline identifier query and baseline data integrity verification, the system performs a secondary calibration of the candidate baselines by comparing anchor package versions, ultimately determining the target baseline identifier that matches the current system state. Optionally, the system reads the actual installed version of the kylin-update-desktop-config anchor package in the current system and compares it with the target version of the anchor package corresponding to the candidate baseline identifier. Three corresponding processing steps are performed: when the current installed version of the anchor package is equal to the version of the anchor package corresponding to the candidate baseline, the candidate baseline identifier is directly determined as the target baseline identifier. When the current installed version of the anchor package is lower than the version of the anchor package corresponding to the candidate baseline, the candidate baseline identifier is still used as the target baseline identifier, and the subsequent integrity verification process continues. When the current installed version of the anchor package is higher than the version of the anchor package corresponding to the candidate baseline, it indicates that the candidate baseline is lagging behind the current patch level of the system. At this time, the system uses the same build identifier, operating system version, and processor identifier as the limit, and combines the preset baseline package table and build mapping table to reverse search for matching baseline identifiers based on the current installed version of the anchor package. The baseline package table is a self-built data table in the supporting baseline database, which stores the correspondence between the baseline identifier and the package name, package version, and monthly increment mark. It does not save the build identifier information. When only one baseline identifier is obtained after the reverse search, the retrieved baseline identifier is determined as the target baseline identifier. If there is no matching result after the reverse search or multiple conflicting baseline identifiers are retrieved, the system determines that the baseline matching has failed and terminates the execution.

[0022] Using the version of the monthly patch anchor package as the core verification benchmark, the candidate baselines obtained from the initial environment mapping are calibrated a second time. By comparing the actual installed version of the system with the version recorded by the baseline, the target baseline that matches the current patch level of the system can be accurately locked. This can avoid problems such as reverse downgrade of software packages, dependency incompatibility and repair failure caused by baseline mismatch and version lag.

[0023] Step 130: Read the set of monthly patch packages marked with monthly increment of 1 under the target baseline identifier, and exclude the packages that need to be ignored to obtain the target monthly patch package set. Compare the current system package status with the target monthly patch package set to generate the missing set, the low version set, and the abnormal status set.

[0024] After completing the target baseline calibration, filtering the monthly incremental patch packages corresponding to the baseline and excluding preset ignored packages is a necessary step to accurately define the scope of the repair target. This allows the repair scope to be focused on the monthly patch category, while exempting specific packages that do not need to be processed, avoiding interference from non-target packages in anomaly detection and repair execution. For example, the system uses the target baseline identifier as the search condition to extract packages with a monthly incremental marker is_monthly_delta of 1 from the baseline package table, forming an initial monthly patch package set. Here, is_monthly_delta is an identifier field in the baseline package table, with a value of 1 indicating that the corresponding package belongs to the monthly patch package, and a value of 0 indicating that it is not a monthly patch package. The upgrade integrity repair function of this system only processes monthly patch packages and does not involve non-monthly patch packages with is_monthly_delta of 0. Subsequently, the system reads the ignored package set corresponding to the target baseline identifier in the ignored package table, excludes all packages in the set from the initial monthly patch package set, and finally obtains the target monthly patch package set for subsequent anomaly comparison. The ignored package table is a self-built data table in the baseline database baseline_packages.db. It is used to define the range of packages that need to be exempted from repair under each baseline item. The ignored package table, together with the build mapping table and the baseline package table, constitute the three core data tables of the baseline database. All of them are pre-built by the project maintainer and distributed with the maintenance tools. They are neither natively included with the Kylin operating system nor built into the dpkg or apt package manager. During the program startup phase, the completeness of the three data tables will be uniformly verified. If any one of them is missing, it will be judged as the baseline data is incomplete and the repair process will be terminated.

[0025] After completing the screening of the target monthly patch package set, the current system package status is compared with the target set item by item and various anomaly sets are generated. This is a necessary step to locate system upgrade failures and classify anomaly levels. It can clearly identify three types of problems: missing package installations, outdated versions, and abnormal status.

[0026] Optionally, the system can collect the dpkg installation status and current version of all software packages in the current system by executing the `dpkg -l` command. The command outputs the installation status identifier and corresponding version number of all software packages in the system. The dpkg installation status includes normal installation (i.e., i.e., iU, iF, iH, iHR, reinstreq, rc, etc.) and abnormal installation status. The comparison process strictly follows mutually exclusive classification rules; the same software package is only classified into one major risk set in the same comparison. The priority for judgment is: abnormal dpkg status > missing installation > version difference. When the target software package is in an abnormal installation state (iU, iF, iH, iHR, reinstreq, or other abnormal installation states), the system prioritizes classifying the package into the abnormal state set and will not perform subsequent installation existence checks or version comparisons. Here, iU represents a package that has been unpacked but not yet configured; iF represents a package configuration failure; iH represents a package in a partial installation state; iHR represents a package expected to be installed but currently in a partial installation state and marked as needing reinstallation; and reinstreq represents a package marked as needing reinstallation. All of these states are considered installation anomalies affecting system updates. If the target software package has no installation record in the system, it is classified into the missing set. If the target software package is in a normal installation state (ii), the current installed version is further compared with the corresponding target version in the target monthly patch package set. If the current version is lower than the target version, it is classified into the lower version set. If the current version is equal to the target version, it is marked as normal. If the current version is higher than the target version, it is considered an acceptable state, not added to any abnormal set, not included in risk scoring, and no package downgrade action is generated. For packages in the rc state (i.e., the package body has been deleted but the configuration file still remains), the system does not treat them as default automatic repair targets and will not automatically perform cleanup operations based on the state. Instead, it only includes them in the dpkg state risk score with a low weight, in order to assess the consistency of the system state while avoiding accidental operations from affecting the system environment.

[0027] First, using the target baseline identifier as the search criterion, all monthly incremental patch packages within the baseline are filtered out, and ignored packages that are exempt from pre-defined repairs are removed, accurately generating the target monthly patch package set to be verified. Then, the local package installation status and version information obtained through the dpkg -l command are compared item by item with the target patch package set. Based on mutual exclusion classification rules, the missing package set, the low version set, and the dpkg installation abnormal status set are automatically identified and divided, comprehensively summarizing all kinds of patch deviation issues that exist in the current system relative to the target baseline.

[0028] Step 140: Read the current system's / etc / apt / sources.list, determine whether the versions of each target package in the target monthly patch package set are available, and determine the online source based on the determination result.

[0029] Online repositories are the sources of APT software repositories from which monthly patch package versions are downloaded. They serve as the supply channel for packages during online patch repair. Online repositories include both existing system software repositories and manually configured backup source templates. After completing the collection of patch anomalies, verifying the downloadable sources of the patch packages to be repaired and selecting available online repositories is a crucial preliminary step for performing online repair operations. This ensures that subsequent missing or lower-version packages can obtain the target version installation package corresponding to the baseline, avoiding repair failures due to invalid source addresses or missing versions. For example, the system reads the ` / etc / apt / sources.list` source configuration file within the current system to verify whether the currently configured system sources can provide the target versions of all packages within the target monthly patch package set. The verification process prioritizes using existing system sources for availability queries. If the current system source can provide all target package versions, it is directly used as the online source for this repair. If the current system source cannot provide all target patch package versions, the system queries the manually maintained source mapping set based on the build identifier (`buildid`) to retrieve the corresponding pre-configured source template filename. The pre-built source template filenames use the naming format {os_version}_{cpu_id}_sources.list, such as 2203_X86_sources.list and 2203_FTD2000_sources.list. The correspondence between buildids and source templates is stored internally in the code or in a separate mapping file. The pre-built source templates are then loaded as online sources. After selecting a backup pre-built source, the system performs source access verification. If faults occur such as a missing pre-built source template file, failure of the apt-get update command, unreachable repository, failed index download, abnormal Release file, abnormal digital signature, or CPU architecture incompatibility, the system determines that the online repair conditions are not met and terminates the online repair process directly. This online source access verification is only used to check the availability of patch package downloads to determine whether to enable online repair; the source verification result is not included in the calculation of the package risk score.

[0030] Step 150: Based on the online source, call apt-get -s -f install to perform simulated parsing and obtain a set of simulated operation packages. Calculate the total risk score based on the missing set, low version set, abnormal state set, and simulated operation packages. Combine the simulated operation package set to determine the risk level and perform repair according to the risk level based on the online source.

[0031] Simulation analysis involves performing a pre-calculation by invoking APT repair commands with simulation parameters, based on a selected online source, without actually modifying the local system or downloading and installing any software packages. It can pre-calculate all software package changes triggered by the APT package manager to satisfy dependencies when the baseline patch repair operation is completed, outputting a complete set of simulated operation packages. This serves as a risk assessment step before the actual repair execution.

[0032] Selecting an online source and then performing simulated analysis and repair actions is an essential pre-verification step before officially executing patch repairs. This step can proactively detect risks such as dependency chain changes, unexpected uninstalls, and unintended downgrades, preventing system environment anomalies caused by actual repair operations. For example, before performing the actual patch repair operation, the system calls the `apt-get -s -f install` command to run simulated analysis based on the verified online source. The `-s` parameter represents simulation mode; the command only outputs the simulation results and does not substantially change the current system package state. The `-f` parameter enables automatic dependency repair logic. The console output returned by the system's simulation command is categorized according to the changes to be performed on the packages, generating five sets: `install_set` (installation set), `upgrade_set` (upgrade set), `remove_set` (removal set), `purge_set` (purge set), and `downgrade_set` (downgrade set). These five sets together constitute the simulated operation package set. The installation set consists of packages that the simulation results indicate require a fresh installation. The upgrade set consists of packages whose version numbers need to be updated upwards based on the simulation results. The removal set consists of software packages that, according to the simulation results, require uninstallation and deletion of the main software while retaining configuration files. The cleanup set corresponds to the purge action and consists of software packages that, according to the simulation results, require uninstallation and complete deletion of all their configuration files. The downgrade set consists of software packages whose version numbers are downgraded according to the simulation results. The system can then use this data from the five sets of simulated operation packages to assess the risks of remediation actions.

[0033] Before officially initiating baseline patch repair, conducting multi-dimensional comprehensive risk scoring and level determination can quantify potential risks of the repair operation from three levels: baseline version deviation, local package installation anomalies, and incidental changes brought about by repair simulation. This allows for early interception of high-risk actions, preventing system failures caused by patch repair. Optionally, a baseline difference risk score can be calculated first, using a formula... Calculations are performed, in which, Baseline difference risk score, This represents the total number of software packages in the missing set. The total number of packages in the lower version set is given, with a single risk weight of 4 for missing packages and 2 for lower version packages. Next, the status risk score is calculated. The system's dpkg installation status is read traversally, and the number of packages corresponding to rc, iU, iF, iH, reinstreq, and other abnormal installation statuses is counted. The status risk score dpkg_status_score is then calculated according to the preset weights. The calculation formula is as follows: ,in, Assign risk based on state, This refers to the number of packages corresponding to the rc status in the dpkg installation process. This represents the number of software packages corresponding to the iU status in the dpkg installation process. This represents the number of packages corresponding to the iF state in the dpkg installation process. This represents the number of software packages corresponding to the iH status in the dpkg installation process. dpkg is in the installation state The number of packages corresponding to the status This represents the number of packages in the dpkg installation state corresponding to other abnormal installation states. The rc state participates in the scoring with only a low weight and will not trigger the default purge cleanup action. Then, based on the five sets of simulated operation packages obtained from simulation parsing, the simulation risk score is calculated using the formula: simulation_risk_score = count(install_set). 0.5 + count(upgrade_set) 1 + count(remove_set) 8 + count(purge_set) 10 + count(downgrade_set) 8. Here, `simulation_risk_score` is the simulated risk score, `count(install_set)` is the number of packages corresponding to the installation set, `count(upgrade_set)` is the number of packages corresponding to the upgrade set, `count(remove_set)` is the number of packages corresponding to the removal set, `count(purge_set)` is the number of packages corresponding to the cleanup set, and `count(downgrade_set)` is the number of packages corresponding to the downgrade set. Different change actions are configured with differentiated risk weights: adding an installation has the lowest risk, followed by upgrading, then removal and downgrade have higher risk weights, and the thorough cleanup (purge) action has the highest risk weight. The total risk score is obtained by summing the above three scores. After the score calculation, a risk level determination is performed. If any one of the removal, cleanup, or downgrade sets is not empty, or if the total risk score is greater than 60, the risk level is determined to be high risk. In this case, the system does not perform a repair operation, outputs the risk reason, and transfers the case to manual processing. When the total risk score is greater than 25 and less than or equal to 60, and all three sets (removal set, cleanup set, and downgrade set) are empty, the risk level is determined to be medium risk. The system will prompt the operator to confirm the information again before executing the patch repair. When the total risk score is less than or equal to 25, and all three sets (removal set, cleanup set, and downgrade set) are empty, the risk level is determined to be low risk, and the system will automatically execute the baseline patch repair process directly.

[0034] In scenarios where remediation is permitted, the system executes remediation action mappings based on online sources, matching corresponding remediation commands to different anomaly sets while strictly avoiding high-risk modification operations. If the anomaly set contains packages with configurable anomaly states such as iU, iF, and iH, the system executes the command `dpkg --configure -a` to perform package configuration remediation. This command only runs during the controlled remediation phase; the detection phase only collects package status and calculates risks, without prematurely modifying the system's original anomaly state, ensuring the accuracy and validity of the risk assessment. If the missing set is not empty, the system executes the installation command `apt-get install-y` for each package within the missing set, specifying the target version.<package_name> =<baseline_version> The missing patch packages will be installed to the baseline version. If the lower version set is not empty, the version locking installation command will also be invoked to upgrade the corresponding packages to the baseline target version. The dependency exception set is obtained by parsing the install_set, upgrade_set, remove_set, purge_set, and downgrade_set outputs of the simulated command to perform a self-check of the system software environment. When the dependency exception set is not empty, and the remove_set, purge_set, and downgrade_set are all empty, apt-get-f install-y will be executed to repair system dependency faults. It should be noted that even if the simulated removal, purge, or downgrade sets contain content, as long as the repair execution phase has begun, the system will not perform actions such as uninstallation, purge, and version downgrading that could easily damage the existing system environment, in order to avoid introducing new faults during the repair process. By executing apt simulation parsing on an online source to obtain a set of simulated operation packages, and combining it with a set of multiple anomalies obtained from baseline comparison to calculate a total risk score, the risk level is determined. Based on the risk level, repairs are performed in stages, enabling the prediction of dependency risks before repair, avoiding high-risk repair actions, and improving the safety and controllability of system upgrade fault repair.

[0035] This embodiment collects system version and environment information to obtain build identifier, operating system version, update version normalization value, and processor identifier. Based on the build identifier, operating system version, update version normalization value, and processor identifier, it queries the build mapping table to obtain candidate baseline identifiers. It reads the current installed version of the anchor package kylin-update-desktop-config in the system and queries the anchor package version corresponding to the candidate baseline identifier. Based on the comparison result between the current installed version of the anchor package and the anchor package version corresponding to the candidate baseline identifier, it obtains the target baseline identifier. It reads the set of monthly patch packages marked with a monthly increment of 1 under the target baseline identifier, excludes packages that need to be ignored, and obtains the target monthly patch package set. It compares the current system package status with the target monthly patch package set to generate a missing set, a low version set, and an abnormal status set. It reads the current system's / etc / apt / sources.list to determine whether the versions of each target package in the target monthly patch package set are available, and determines the online source based on the determination result. Based on the online source, it calls apt-get -s -f. The install process simulates and parses data to obtain a set of simulated operation packages. Based on the missing data set, low-version data set, abnormal state data set, and simulated operation packages, a total risk score is calculated. This score, combined with the simulated operation package set, determines the risk level. Repair is then performed based on the online source according to the stated risk level. Through baseline mapping matching, anchor package version calibration, incremental package anomaly classification, online source verification, and risk simulation-based graded repair, precise and secure repair of system upgrade failures is achieved.

[0036] Example 2 Figure 2 This is a flowchart of a system upgrade fault repair method based on patch baseline and risk simulation provided in Embodiment 2 of the present invention. This embodiment is optimized based on the above embodiment. After the repair steps are performed according to the risk level based on the online source, it also includes: re-collecting the current system software package status after the repair is completed, checking and counting the remaining problems after the repair, comparing the number of remaining problems after the repair with the total number of problems before the repair, outputting a successful repair when the number of remaining problems after the repair is equal to 0, outputting a partial repair result and outputting a set of remaining problems after the repair when the number of remaining problems after the repair is greater than 0 and less than the total number of problems before the repair, and outputting a repair failure or no improvement when the total number of problems after the repair is greater than or equal to the total number of problems before the repair, and outputting the corresponding failure reason.

[0037] See Figure 2 System upgrade fault repair methods based on patch baselines and risk simulation include: Step 210: Collect system version and environment information to obtain build identifier, operating system version, update version normalization value and processor identifier. Based on the build identifier, operating system version, update version normalization value and processor identifier, query the build mapping table to obtain candidate baseline identifiers.

[0038] Step 220: Read the current installed version of the anchor package kylin-update-desktop-config in the system, and query the anchor package version corresponding to the candidate baseline identifier. Based on the comparison result between the current installed version of the anchor package and the anchor package version corresponding to the candidate baseline identifier, obtain the target baseline identifier.

[0039] Step 230: Read the set of monthly patch packages marked with 1 under the target baseline identifier, and exclude the packages that need to be ignored to obtain the target monthly patch package set. Compare the current system package status with the target monthly patch package set to generate the missing set, the low version set, and the abnormal status set.

[0040] Step 240: Read the current system's / etc / apt / sources.list, determine whether the versions of each target package in the target monthly patch package set are available, and determine the online source based on the determination result.

[0041] Step 250: Based on the online source, call apt-get -s -f install to perform simulated parsing to obtain a set of simulated operation packages. Calculate the total risk score based on the missing set, low version set, abnormal state set, and simulated operation packages. Combine the simulated operation package set to determine the risk level. Perform repair based on the online source according to the risk level.

[0042] Step 260: After the repair is completed, collect the current system package status again, check and count the remaining problems after the repair, compare the number of remaining problems after the repair with the total number of problems before the repair, output the repair is successful when the number of remaining problems after the repair is equal to 0, output the partial repair result and output the set of remaining problems after the repair when the number of remaining problems after the repair is greater than 0 and less than the total number of problems before the repair, output the repair failure or no improvement, and output the corresponding failure reason.

[0043] The post-repair retesting and verification process allows for an objective evaluation of the actual effectiveness of the controlled repair, avoiding misjudgments caused by relying solely on the return codes of the repair commands. It quantifies and compares the number of issues before and after the repair, outputting tiered repair results for operations personnel to intuitively understand the true state of the system. For example, after the system completes the repair action, it doesn't immediately declare the repair complete. Instead, it re-collects the current system package status after the repair, performs a complete version baseline comparison and dpkg status check again, and re-calls `apt-get -s -f install` to perform dependency simulation, generating the repaired missing sets, low-version sets, abnormal status sets, and dependency anomaly sets. Based on these anomaly sets, the system checks and counts the remaining issues after the repair, comparing the count of remaining issues with the total number of issues counted before the repair. When the number of remaining issues equals 0, it indicates that baseline differences, package anomalies, and dependency anomalies have all been eliminated, and the system outputs a successful repair. If the number of remaining issues after repair is greater than 0, but less than the total number of issues before repair, it indicates that some faults have been resolved, but unresolved anomalies still exist. The system outputs partial repair results, along with the set of remaining issues after repair, to help operations personnel locate legacy faults. If the total number of issues after repair is greater than or equal to the total number of issues before repair, it indicates that the repair did not eliminate the faults, or even introduced new software package anomalies. The system outputs "Repair Failed" or "No Improvement," along with the corresponding reason for failure, for operations personnel to carry out subsequent manual handling.

[0044] This embodiment collects system version and environment information to obtain build identifier, operating system version, update version normalization value, and processor identifier. Based on the build identifier, operating system version, update version normalization value, and processor identifier, it queries the build mapping table to obtain candidate baseline identifiers. It reads the current installed version of the anchor package kylin-update-desktop-config in the system and queries the anchor package version corresponding to the candidate baseline identifier. Based on the comparison result between the current installed version of the anchor package and the anchor package version corresponding to the candidate baseline identifier, it obtains the target baseline identifier. It reads the set of monthly patch packages marked with a monthly increment of 1 under the target baseline identifier, excludes packages that need to be ignored, and obtains the target monthly patch package set. It compares the current system package status with the target monthly patch package set to generate a missing set, a low version set, and an abnormal status set. It reads the current system's / etc / apt / sources.list to determine whether the versions of each target package in the target monthly patch package set are available, and determines the online source based on the determination result. Based on the online source, it calls apt-get -s -f. The `install` function performs simulated parsing to obtain a set of simulated operation packages. Based on the missing set, low-version set, abnormal state set, and simulated operation packages, a total risk score is calculated. This score, combined with the simulated operation package set, determines the risk level. Repair is then performed based on the online source according to the risk level. After the repair is completed, the current system package status is re-collected. The remaining issues are checked and counted, comparing the number of remaining issues with the total number of issues before the repair. If the number of remaining issues after the repair is 0, a successful repair is output. If the number of remaining issues after the repair is greater than 0 but less than the total number of issues before the repair, partial repair results and the set of remaining issues after the repair are output. If the total number of issues after the repair is greater than or equal to the total number of issues before the repair, a repair failure or no improvement is output, along with the corresponding failure reason. Using this method, a graded risk repair of system faults is achieved based on the patch baseline. Furthermore, by quantitatively comparing the problem scale before and after the repair through post-repair re-measurement, the repair effectiveness is objectively reflected, and corresponding repair results and problem information are output, improving the completeness and traceability of the system upgrade fault repair process.

[0045] Example 3 Figure 3 This is a schematic diagram of the system upgrade fault repair device based on patch baseline and risk simulation provided in Embodiment 3 of the present invention, as shown below. Figure 3 As shown, the device includes: The acquisition module 310 is used to acquire system version and environment information, obtain build identifier, operating system version, update version normalization value and processor identifier, and query the build mapping table based on the build identifier, operating system version, update version normalization value and processor identifier to obtain candidate baseline identifier; The comparison module 320 is used to read the current installed version of the anchor package kylin-update-desktop-config in the system, query the anchor package version corresponding to the candidate baseline identifier, and obtain the target baseline identifier based on the comparison result between the current installed version of the anchor package and the anchor package version corresponding to the candidate baseline identifier. The set generation module 330 is used to read the set of monthly patch packages marked with 1 under the target baseline identifier, exclude the packages that need to be ignored, obtain the target monthly patch package set, compare the current system package status with the target monthly patch package set, and generate the missing set, low version set and abnormal status set. The judgment module 340 is used to read the current system's / etc / apt / sources.list, determine whether the versions of each target package in the target monthly patch package set are available, and determine the online source based on the judgment result; Repair module 350 is used to perform simulated parsing based on the online source by calling apt-get -s -f install, obtain a set of simulated operation packages, calculate the total risk score based on the missing set, low version set, abnormal state set and simulated operation packages, determine the risk level in combination with the set of simulated operation packages, and perform repair based on the online source according to the risk level.

[0046] The system upgrade fault repair device based on patch baseline and risk simulation provided in this embodiment collects system version and environment information to obtain build identifier, operating system version, update version normalization value, and processor identifier. Based on the build identifier, operating system version, update version normalization value, and processor identifier, it queries the build mapping table to obtain candidate baseline identifiers. It reads the current installed version of the anchor package kylin-update-desktop-config in the system and queries the anchor package version corresponding to the candidate baseline identifier. Based on the comparison result between the current installed version of the anchor package and the anchor package version corresponding to the candidate baseline identifier, it obtains the target baseline identifier. It reads the set of monthly patch packages marked with a monthly increment of 1 under the target baseline identifier, excludes packages that need to be ignored, and obtains the target monthly patch package set. It compares the current system package status with the target monthly patch package set to generate a missing set, a low version set, and an abnormal status set. It reads the current system's / etc / apt / sources.list to determine whether the versions of each target package in the target monthly patch package set are available, and determines the online source based on the determination result. Based on the online source, it calls apt-get -s -f. The install process simulates and parses data to obtain a set of simulated operation packages. Based on the missing data set, low-version data set, abnormal state data set, and simulated operation packages, a total risk score is calculated. This score, combined with the simulated operation package set, determines the risk level. Repair is then performed based on the online source according to the stated risk level. Through baseline mapping matching, anchor package version calibration, incremental package anomaly classification, online source verification, and risk simulation-based graded repair, precise and secure repair of system upgrade failures is achieved.

[0047] Based on the above embodiments, the data acquisition module includes: A build identifier generation unit is used to read the / etc / kylin-build file, extract the value corresponding to the buildid field, and obtain the build identifier; The updated version normalization value generation unit is used to read the system version file, obtain the operating system version and the updated version, remove the trailing asterisk character from the updated version, and generate the updated version normalization value. The processor identifier generation unit is used to read / proc / cpuinfo and lscpu hardware information, and generate the processor identifier by converting the actual CPU model of the system according to the preset keyword conversion rules. The candidate baseline identifier generation unit is used to verify whether the build identifier, operating system version, update version normalization value, and processor identifier can be matched in a preset build mapping table. If any of the build identifier, operating system version, update version normalization value, and processor identifier fails to match, the unit outputs that repair is not supported in the current system environment and terminates the process. If the match is successful, the unit queries the build mapping table based on the build identifier, operating system version, update version normalization value, and processor identifier to obtain the candidate baseline identifier.

[0048] Based on the above embodiments, the comparison module includes: The first target baseline identifier acquisition unit is used to use the candidate baseline identifier as the target baseline identifier when the current installation version is equal to the anchor package version corresponding to the candidate baseline identifier, or when the current installation version is lower than the anchor package version corresponding to the candidate baseline identifier. The second target baseline identifier acquisition unit is used to, when the current installed version is higher than the anchor package version corresponding to the candidate baseline identifier, retrieve the baseline identifier in reverse based on the current installed version of the anchor package in a preset baseline package table and build mapping table, with the same build identifier, operating system version and processor identifier as the limit. When the reverse search yields only one baseline identifier, the retrieved baseline identifier is determined as the target baseline identifier. When the reverse search yields no results or multiple baseline identifiers, the execution is terminated.

[0049] Based on the above embodiments, the collection generation module includes: The system software package status acquisition unit is used to acquire the current system software package status that has been pre-collected. The current system software package status includes the dpkg installation status and current installation version of each software package in the system. The dpkg installation status includes ii status, iU status, iF status, iH status, iHR status, rc status, reinstreq status, and other abnormal installation statuses. The abnormal state set inclusion unit is used to include the corresponding software package into the abnormal state set when the dpkg state of the system software package is iU state, iF state, iH state, iHR state, reinstreq state or other abnormal installation state. The missing set inclusion unit is used to compare the corresponding system package status with the target monthly patch package set when the dpkg status of the system package is not iU, iF, iH, iHR, reinstreq, or other abnormal installation status. If the corresponding system package is not installed, the corresponding system package is included in the missing set. The low version set inclusion unit is used to compare the status of the corresponding system package with the target monthly patch package set when the dpkg status of the corresponding system package is not in the iU, iF, iH, iHR, reinstreq, or other abnormal installation states. If the dpkg installation status of the corresponding system package is in the ii state and the installation version of the corresponding system package is lower than the version of the corresponding package in the target monthly patch package set, the corresponding system package is included in the low version set.

[0050] Based on the above embodiments, the determination module includes: The system source judgment unit is used to read the current system's / etc / apt / sources.list and verify whether the current system source can provide the versions of each target package in the target monthly patch package set; The first online source determination unit is used to use the current system source as the online source when the current system source can provide the versions of each target software package within the target monthly patch package set; The second online source determination unit is used to query the manually maintained source mapping set according to the build identifier when the current system source cannot provide the versions of each target software package in the target monthly patch package set, obtain the preset source template file name, and use the corresponding preset source template as the online source.

[0051] Based on the above embodiments, the repair module includes: The simulated operation package set acquisition unit is used to perform simulated parsing based on the online source by executing apt-get -s -f install to obtain a simulated operation package set. The simulated operation package set includes an installation set, an upgrade set, a removal set, a cleanup set, and a downgrade set. The installation set is a set of packages that simulate need to be newly installed. The upgrade set is a set of packages that simulate need to be upgraded. The removal set is a set of packages that simulate need to be uninstalled. The cleanup set is a set of packages that simulate need to be completely removed. The downgrade set is a set of packages that simulate need to be downgraded. The baseline difference risk score calculation unit is used to calculate the baseline difference risk score based on the missing set and the low version set. The status risk score calculation unit is used to calculate the status risk score based on the dpkg installation status of each software package in the system. The simulated risk score calculation unit is used to calculate the simulated risk score based on the installation set, upgrade set, removal set, cleanup set, and downgrade set. The total risk score calculation unit is used to sum the baseline difference risk score, the state risk score, and the simulation risk score to obtain the total risk score. The high-risk determination unit is used to determine the risk level as high-risk when any of the removal set, cleanup set or downgrade set is not empty, or the total risk score is greater than 60. In this case, no repair is performed, the risk reason is output and the case is transferred to manual processing. The medium-risk determination unit is used to determine the risk level as medium-risk when the total risk score is greater than 25 and less than or equal to 60, and the removal set, cleanup set and downgrade set are all empty, prompting confirmation and then performing repair. The low-risk determination unit is used to determine the risk level as low when the total risk score is less than or equal to 25 and the removal set, cleanup set and downgrade set are all empty, and to directly perform repair.

[0052] The system upgrade fault repair device based on patch baseline and risk simulation provided in the embodiments of the present invention can execute the system upgrade fault repair method based on patch baseline and risk simulation provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method.

[0053] Example 4 Figure 4 This is a schematic diagram of a system upgrade fault repair device based on patch baseline and risk simulation, provided in Embodiment 4 of the present invention. Figure 4 A block diagram of an exemplary device 12 suitable for implementing embodiments of the present invention is shown. Figure 4 The device 12 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0054] like Figure 4 As shown, device 12 is represented as a general-purpose computing device. Components of device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and a bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0055] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0056] Device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by device 12, including volatile and non-volatile media, removable and non-removable media.

[0057] System memory 28 may include computer system readable media in the form of volatile memory, such as RAM 30 and / or cache 32. Device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media ( Figure 4 Not shown; usually referred to as a "hard drive"). Although Figure 4 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0058] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0059] Device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with device 12, and / or with any device that enables device 12 to communicate with one or more other computing devices (e.g., network interface card, modem, etc.). This communication can be performed via I / O interface 22. Furthermore, device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of device 12 via bus 18. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0060] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28, such as implementing the system upgrade fault repair method based on patch baseline and risk simulation provided in the embodiments of the present invention.

[0061] Example 5 Embodiment 5 of the present invention also provides a medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform any of the system upgrade fault repair methods based on patch baseline and risk simulation provided in the above embodiments.

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

[0063] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0064] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

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

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

Claims

1. A system upgrade fault repair method based on patch baseline and risk simulation, characterized in that, include: Collect system version and environment information to obtain build identifier, operating system version, update version normalization value and processor identifier. Based on the build identifier, operating system version, update version normalization value and processor identifier, query the build mapping table to obtain candidate baseline identifiers. Read the current installed version of the anchor package kylin-update-desktop-config in the system, and query the anchor package version corresponding to the candidate baseline identifier. Based on the comparison result between the current installed version of the anchor package and the anchor package version corresponding to the candidate baseline identifier, obtain the target baseline identifier. Read the set of monthly patch packages marked with monthly increment of 1 under the target baseline identifier, and exclude the packages that need to be ignored to obtain the target monthly patch package set. Compare the current system package status with the target monthly patch package set to generate the missing set, low version set and abnormal status set. Read the current system's / etc / apt / sources.list, determine whether the versions of each target package in the target monthly patch package set are available, and determine the online source based on the determination result; The system uses the online source to call `apt-get -s -f install` to perform simulated parsing, obtaining a set of simulated operation packages. Based on the missing set, low version set, abnormal state set, and simulated operation packages, the total risk score is calculated, and the risk level is determined in combination with the set of simulated operation packages. The system then performs repairs based on the risk level from the online source.

2. The method according to claim 1, characterized in that, The system version and environment information are collected to obtain a build identifier, operating system version, update version normalized value, and processor identifier. Based on the build identifier, operating system version, update version normalized value, and processor identifier, the build mapping table is queried to obtain candidate baseline identifiers, including: Read the / etc / kylin-build file, extract the value corresponding to the buildid field, and obtain the build identifier; Read the system version file to obtain the operating system version and the update version, remove the trailing asterisk character from the update version, and generate the normalized value of the update version; Read the / proc / cpuinfo and lscpu hardware information, and convert the actual CPU model of the system into the processor identifier according to the preset keyword conversion rules; Verify whether the build identifier, operating system version, update version normalization value, and processor identifier can be matched in the preset build mapping table. If any of the build identifier, operating system version, update version normalization value, and processor identifier fails to match, output that repair is not supported in the current system environment and terminate the process. If the match is successful, query the build mapping table based on the build identifier, operating system version, update version normalization value, and processor identifier to obtain the candidate baseline identifier.

3. The method according to claim 1, characterized in that, The step of obtaining the target baseline identifier based on the comparison result between the current installed version of the anchor package and the anchor package version corresponding to the candidate baseline identifier includes: When the current installed version is equal to the anchor package version corresponding to the candidate baseline identifier, or when the current installed version is lower than the anchor package version corresponding to the candidate baseline identifier, the candidate baseline identifier is used as the target baseline identifier. When the current installed version is higher than the anchor package version corresponding to the candidate baseline identifier, the baseline identifier is retrieved in reverse based on the current installed version of the anchor package in the preset baseline package table and build mapping table, with the same build identifier, operating system version and processor identifier as the limit. When the reverse search yields only one baseline identifier, the retrieved baseline identifier is determined as the target baseline identifier. When the reverse search yields no results or multiple baseline identifiers, the execution is terminated.

4. The method according to claim 1, characterized in that, The step of comparing the current system software package status with the target monthly patch package set to generate a missing set, a low version set, and an abnormal status set includes: Obtain the pre-collected current system package status, which includes the dpkg installation status and current installation version of each package in the system. The dpkg installation status includes ii status, iU status, iF status, iH status, iHR status, rc status, reinstreq status, and other abnormal installation statuses. When the dpkg status of the system package is iU, iF, iH, iHR, reinstreq, or other abnormal installation status, the corresponding package will be classified into the abnormal status set. When the dpkg status of a system package is not iU, iF, iH, iHR, reinstreq, or other abnormal installation status, the corresponding system package status is compared with the target monthly patch package set. If the corresponding system package is not installed, the corresponding system package is included in the missing set. If the dpkg status of a system package is not in the iU, iF, iH, iHR, reinstreq, or other abnormal installation states, the corresponding system package status is compared with the target monthly patch package set. If the dpkg installation status of the corresponding system package is in the ii state and the installation version of the corresponding system package is lower than the version of the corresponding package in the target monthly patch package set, the corresponding system package is classified into the low version set.

5. The method according to claim 1, characterized in that, The process of reading the current system's ` / etc / apt / sources.list`, determining whether the versions of each target package in the target monthly patch package set are available, and identifying the online source based on the determination result includes: Read the current system's / etc / apt / sources.list and verify whether the current system's sources can provide the versions of each target package in the target monthly patch package set; If the current system source can provide the versions of each target software package within the target monthly patch package set, use the current system source as the online source; When the current system source cannot provide the versions of each target software package within the target monthly patch package set, the source mapping set maintained manually is queried according to the build identifier to obtain the file name of the preset source template, and the corresponding preset source template is used as the online source.

6. The method according to claim 4, characterized in that, The process involves using the online source to call `apt-get -s -f install` for simulated parsing, obtaining a set of simulated operation packages, calculating a total risk score based on the missing set, low version set, abnormal state set, and simulated operation packages, and determining the risk level based on the set of simulated operation packages. Then, based on the online source, repair is performed according to the risk level, including: Based on the online source, the `apt-get -s -f install` command is executed to perform simulated parsing, resulting in a set of simulated operation packages. This set includes an installation set, an upgrade set, a removal set, a cleanup set, and a downgrade set. The installation set simulates the packages that need to be newly installed, the upgrade set simulates the packages that need to be upgraded, the removal set simulates the packages that need to be uninstalled, the cleanup set simulates the packages that need to be completely removed, and the downgrade set simulates the packages that need to be downgraded. Based on the missing set and the low-version set, a baseline difference risk score is calculated. The baseline difference risk score is calculated as follows: ； in, Baseline difference risk score, The total number of software packages in the missing set. This represents the total number of software packages in the lower version set. Based on the installation status of each software package (dpkg) in the system, a status risk score is calculated. The status risk score is calculated as follows: in, Assign risk based on state, This refers to the number of packages corresponding to the rc status in the dpkg installation process. This represents the number of software packages corresponding to the iU status in the dpkg installation process. This represents the number of packages corresponding to the iF state in the dpkg installation process. This represents the number of software packages corresponding to the iH status in the dpkg installation process. dpkg is in the installation state The number of packages corresponding to the status This represents the number of software packages corresponding to other abnormal installation states in the dpkg installation process. Based on the installation set, upgrade set, removal set, cleanup set, and downgrade set, a simulated risk score is calculated. The formula for calculating the simulated risk score is as follows: simulation_risk_score=count(install_set) 0.5+count(upgrade_set) 1+count(remove_set) 8+count(purge_set) 10+count(downgrade_set) 8; Where, simulation_risk_score is the simulated risk score, count(install_set) is the number of packages corresponding to the installation set, count(upgrade_set) is the number of packages corresponding to the upgrade set, count(remove_set) is the number of packages corresponding to the removal set, count(purge_set) is the number of packages corresponding to the purge set, and count(downgrade_set) is the number of packages corresponding to the downgrade set; The baseline difference risk score, the state risk score, and the simulation risk score are summed to obtain the total risk score. If any of the removal set, cleanup set, or downgrade set is not empty, or the total risk score is greater than 60, the risk level is determined to be high risk, no repair is performed, the risk reason is output and the case is transferred to manual processing. When the total risk score is greater than 25 and less than or equal to 60, and the removal set, cleanup set, and downgrade set are all empty, the risk level is determined to be medium risk, and a confirmation prompt is given to perform repair. If the total risk score is less than or equal to 25, and the removal set, cleanup set, and downgrade set are all empty, the risk level is determined to be low risk, and repair is performed directly.

7. The method according to claim 1, characterized in that, The process of calling `apt-get -s -f install` from the online source to perform simulated parsing, obtaining a set of simulated operation packages, calculating a total risk score based on the missing set, low version set, abnormal state set, and simulated operation packages, and determining the risk level based on the set of simulated operation packages, and then performing repair steps according to the risk level based on the online source, further includes: After the repair is completed, the current system software package status is re-collected, and the remaining issues after the repair are checked and tallied. Compare the number of remaining issues after the repair with the total number of issues before the repair. If the number of remaining issues after the repair is equal to 0, output that the repair was successful. If the number of remaining issues after the repair is greater than 0 and less than the total number of issues before the repair, output the partial repair result and the set of remaining issues after the repair. If the total number of issues after repair is greater than or equal to the total number of issues before repair, output "repair failed" or "no improvement", and output the corresponding reason for failure.

8. A system upgrade and fault repair system based on patch baselines and risk simulation, characterized in that, include: The acquisition module is used to collect system version and environment information, obtain build identifier, operating system version, update version normalization value and processor identifier, and query the build mapping table based on the build identifier, operating system version, update version normalization value and processor identifier to obtain candidate baseline identifiers; The comparison module is used to read the current installed version of the anchor package kylin-update-desktop-config in the system, query the anchor package version corresponding to the candidate baseline identifier, and obtain the target baseline identifier based on the comparison result between the current installed version of the anchor package and the anchor package version corresponding to the candidate baseline identifier. The set generation module is used to read the set of monthly patch packages marked with 1 under the target baseline identifier, exclude the packages that need to be ignored, obtain the target monthly patch package set, compare the current system package status with the target monthly patch package set, and generate the missing set, low version set and abnormal status set. The judgment module is used to read the current system's / etc / apt / sources.list, determine whether the versions of each target package in the target monthly patch package set are available, and determine the online source based on the judgment result; The repair module is used to perform simulated parsing based on the online source by calling apt-get -s -f install, obtain a set of simulated operation packages, calculate the total risk score based on the missing set, low version set, abnormal state set and simulated operation packages, determine the risk level based on the set of simulated operation packages, and perform repair based on the online source according to the risk level.

9. A system upgrade fault repair device based on patch baseline and risk simulation, characterized in that, The device includes: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the system upgrade fault repair method based on patch baseline and risk simulation as described in any one of claims 1-7.

10. A medium containing computer-executable instructions, which, when executed by a computer processor, are used to perform the system upgrade fault repair method based on patch baseline and risk simulation as described in any one of claims 1-7.

Images