Environment diagnosis and restoration method and system before Linux system upgrading

Abstract

The invention discloses an environment diagnosis and restoration method and system before Linux system upgrading, and the method comprises the steps: constructing a software package dependence topological structure of a current to-be-restored Linux system, determining a first abnormal software package set, and generating a corresponding restoration strategy according to the abnormal state type of the first abnormal software package set; constructing a software package dependence topological structure of the standard reference Linux system, comparing the software package dependence topological structure of the current to-be-repaired Linux system with the software package dependence topological structure of the standard reference Linux system to determine a second abnormal software package set, and generating a corresponding repair strategy according to the second abnormal software package set; and repairing the abnormal software packages in the first abnormal software package set and the second abnormal software package set according to the repairing strategy. According to the method, accurate recognition and difference analysis of the software packages in the abnormal state in the system can be achieved, it is ensured that all the related software packages are repaired and are in the stable state before upgrading, and the success rate and stability of the system upgrading process are improved.

Description

Technical Field

[0001] This invention relates to the field of Linux system repair technology, specifically to a method and system for environmental diagnosis and repair before upgrading a Linux system. Background Technology

[0002] In domestically developed operating systems, the kernel and user-space software are organized and managed as software packages, with complex dependencies between different packages. Compared to mature operating systems like Windows and macOS, the upgrade scenarios for domestic operating systems are more complex, and compatibility issues are more prominent. Domestic platform applications come from diverse sources, encompassing different developers and development environments, resulting in a lack of unified development standards. Third-party applications exhibit significant differences in their dependencies on component libraries, system interfaces, and runtime environments. These factors collectively contribute to the complexity of the system's software package environment, increasing compatibility challenges during upgrades. To ensure stable system operation, accurately identifying the status of software packages and verifying their dependencies and versions has become a critical task in upgrades and maintenance. However, with the continuous evolution of baseline versions and the deep customization of various application environments, the system's software package environment is becoming increasingly complex, posing even greater challenges to the success rate and compatibility of system upgrades.

[0003] Currently, most mainstream domestic operating systems use APT package managers for dependency resolution and software package installation. However, their system software package environment diagnosis and repair capabilities are limited. This is mainly reflected in the lack of system-level dependency topology analysis capabilities, the lack of comparison capabilities with standard system benchmarks, the inability to provide necessary checks during repair, and the lack of standardized recovery criteria in abnormal states, making it difficult to meet the requirements for dependency self-consistency in diverse application environments.

[0004] Furthermore, within domestically developed platforms, application software comes from diverse sources and adheres to varying standards. Many applications heavily rely on specific versions of system components. In the event of dependency conflicts or corrupted software packages, APTs struggle to provide reliable remediation suggestions, potentially leading to both system updates and software malfunction. Existing solutions generally rely on manual intervention, exhibiting low levels of automation and high technical barriers, making it difficult to support the security and maintainability requirements of modern systems.

[0005] Therefore, there is an urgent need for a method for diagnosing and repairing the software package environment before system upgrades, in order to improve the success rate and stability of the system upgrade process and enhance the maintainability and user experience of domestic operating systems. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a method and system for environmental diagnosis and repair before upgrading a Linux system, in order to detect and repair potential conflicts in the current system software package environment before upgrading, and avoid system instability caused by abnormal software package dependencies during the upgrade process.

[0007] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for environment diagnosis and repair before upgrading a Linux system, including the following steps: Construct the package dependency topology of the current Linux system to be repaired and determine the first abnormal package set based on the package dependency topology of the current Linux system to be repaired. Generate the corresponding repair strategy according to the abnormal state type of the first abnormal package set. Construct the package dependency topology of the standard reference Linux system, compare the package dependency topology of the current Linux system to be repaired with that of the standard reference Linux system to determine the second set of abnormal packages, and generate a corresponding repair strategy based on the second set of abnormal packages. The abnormal packages in the first and second abnormal package sets are repaired according to the repair strategy.

[0008] Furthermore, construct the package dependency topology of the current Linux system to be repaired, specifically including: Extract metadata information of installed packages, including one or more fields from package name (Package), dependent packages (Depends), recommended packages (Recommends), package version (Version), and package status (Status); Based on the Package field, generate a set of nodes for all software packages and build the initial topology framework; Read the Version and Status fields corresponding to each package, and record the version information and installation status information as node attributes; Based on the dependencies defined in the Depends and Recommendations fields, the system resolves and establishes directed connections between nodes, mapping the dependencies to edges in the topology to form a dependency topology with software packages as nodes and dependencies as directed edges.

[0009] Furthermore, based on the current package dependency topology of the Linux system to be repaired, the first set of abnormal packages is determined, including packages with abnormal installation status and abnormal dependency status. The specific steps are as follows: Read the Status field from the package metadata information. If the Status field does not indicate "installed", mark the package and the corresponding node as an installation exception. Parse the Depends field in the metadata information and determine the status of the packages that each package depends on. If it is determined that a package that a certain package depends on does not exist in the current system, the corresponding package is marked as a missing dependency. If it is determined that the version of a package that a certain package depends on does not meet the dependency requirements in the current system, the corresponding package is marked as an abnormal dependency version.

[0010] Furthermore, a corresponding repair strategy is generated based on the exception state type of the first set of exception packages, specifically including: If the abnormal status type is dependency missing, determine whether the missing package is available in the current software source. If so, the repair strategy is to install the corresponding missing package; otherwise, the repair strategy is to uninstall the missing dependent package. If the exception status type is a dependency version exception, the remediation strategy is to upgrade or downgrade the version of the dependent software package to the target version that meets the dependency requirements. If the exception status type is installation exception, and the specific exception is determined to be package configuration failure based on the value of the Status field in the package metadata information, the repair strategy is as follows: first try to restore the configuration process; if it still fails, block the problematic script and skip the script to restore the configuration; finally, reinstall the package. If the exception status type is installation exception, and the specific exception is determined to be that the package is not fully installed based on the value of the Status field in the package metadata information, then the repair strategy is to reinstall the corresponding package.

[0011] Furthermore, the package dependency topology of the standard reference Linux system is constructed, specifically including the following steps: T1 downloads and installs the basic configuration package from the Kylin standard software source repository, parses the configuration file provided by the basic configuration package, and extracts the set of basic software packages necessary for the system to maintain basic operation from the configuration file; T2 uses each package in the basic package set as a node and the metadata information of the package as a node attribute. Based on the dependency relationship defined in the Depends and Recommendations fields of the package, directed edges are recursively established between the nodes to form a dependency topology structure with packages as nodes and dependencies as edges. This process continues until all dependencies are resolved and no more are added, resulting in the minimum standard system dependency topology structure required for the complete operation of the system. T3: Obtain the standard system core package set from the basic configuration package, and build the complete Linux standard system dependency topology based on the standard system core package set in the manner of step T2, while minimizing the standard system dependency topology.

[0012] Furthermore, the package dependency topology of the current Linux system to be repaired is compared with that of the standard reference Linux system to determine a second set of anomalous packages. Based on this second set of anomalous packages, a corresponding repair strategy is generated, specifically including: Compare the differences in package dependency topology between the current Linux system to be repaired and the standard reference Linux system, extract the missing standard packages and redundant non-standard packages in the current system, and generate a repair strategy: uninstall the redundant non-standard packages and install the missing standard packages; For software packages with the same name in the current system and the standard system, the version field (Version) in the package metadata is further extracted and compared. If the version of the package in the current Linux system to be repaired is inconsistent with the version in the standard system, a repair strategy is generated: upgrade or downgrade the package to the version of the standard system.

[0013] Furthermore, after determining the first set of abnormal software packages, the process also includes recursively resolving the dependencies of each abnormal software package in the first set of abnormal software packages based on the transitive closure algorithm, until all dependencies are resolved, in order to obtain all abnormal software packages to be repaired and their dependent software packages. The expression for the transitive closure algorithm is as follows:

[0014] In the above formula, S represents the set of software packages necessary for the system to maintain its basic operating environment. Denotes the set of direct dependencies of S. This indicates a direct dependency. This indicates a final dependency that will not generate any new dependencies.

[0015] Furthermore, when repairing abnormal packages in the first and second abnormal package sets according to the repair strategy, the critical system configurations are first backed up. The backup content includes one or more of the following: software source configuration, installed package list, critical system service configuration, and application custom settings. Then, it is determined whether there are critical system components in the package to be installed according to the repair strategy. If so, the repair process is terminated and a message is displayed indicating that the current system environment cannot be repaired.

[0016] An environment diagnosis and repair system for Linux system upgrades includes a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to perform the steps of an environment diagnosis and repair method for Linux system upgrades.

[0017] A computer-readable storage medium storing a computer program / instructions programmed or configured to perform steps of an environment diagnostic and repair method prior to a Linux system upgrade via a processor.

[0018] Compared with the prior art, the advantages of the present invention are as follows: This invention identifies packages in an abnormal state within the current Linux system by constructing a package dependency topology structure between the current Linux system to be repaired and the standard reference Linux system. This enables accurate identification and difference analysis of packages in an abnormal state, uncovering potential conflicts between packages and predicting their impact before system upgrades, thus mitigating potential risks during the upgrade process. By generating corresponding repair strategies based on the abnormal state type of the packages, it ensures that all relevant packages are repaired and in a stable state before the upgrade, effectively improving the success rate and stability of the system upgrade process, guaranteeing a smooth upgrade, and reducing the risk of upgrade failure. Attached Figure Description

[0019] Figure 1 This is a flowchart illustrating the method for environmental diagnosis and repair before upgrading a Linux system, as described in an embodiment of the present invention.

[0020] Figure 2 This is a flowchart illustrating the process of constructing the software package dependency topology of the Linux system to be repaired in this embodiment of the invention.

[0021] Figure 3 This is a flowchart illustrating the process of constructing the package dependency topology of a standard reference Linux system in an embodiment of the present invention.

[0022] Figure 4 This is a flowchart illustrating how to identify all abnormal software packages in an abnormal state within the Linux system to be repaired, and how to generate corresponding repair strategies, in an embodiment of the present invention.

[0023] Figure 5 This is a flowchart illustrating the corresponding repair operations performed on the abnormal software package in an embodiment of the present invention. Detailed Implementation

[0024] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0025] Currently, conventional APT package managers have the following drawbacks in providing system package environment repair capabilities: Lack of system-level dependency topology analysis capabilities: APT focuses more on dependency handling during a single command execution process and cannot build or analyze a complete system-level dependency topology. Therefore, it is difficult to discover complex issues such as missing packages, version discrepancies, or abnormal installation states in package dependencies.

[0026] Lack of comparative capability against standard system benchmarks: APT cannot compare the differences between the current system and the standard release version in terms of package dependency structure, package version, key components, etc., and lacks "benchmarking" repair methods, which makes it easy to uninstall key system components and fail to identify and repair abnormal packages during the recovery process.

[0027] Failure to provide necessary checks during repair: When repairing dependency issues, APT may lack a comprehensive check of dependencies. This can lead to omissions in the repair process, failure to effectively identify and resolve potential problems, and consequently, uninstallation of essential system packages, impacting system stability.

[0028] The repair operation lacks strategic support: Most existing APT repair methods (such as --fix-broken install or dpkg --configure-a) are based on default policies and cannot be combined with the differences in the user's actual environment to carry out repair strategies based on standard systems and package classification, such as upgrading, downgrading, refilling, forced reinstallation, dependency completion, etc. for abnormal packages.

[0029] Therefore, in order to solve the above-mentioned technical problems, such as Figure 1 As shown in the figure, this embodiment of the invention provides a method for environment diagnosis and repair before upgrading a Linux system, including the following steps: S1, construct the package dependency topology of the current Linux system to be repaired and determine the first abnormal package set based on the package dependency topology of the current Linux system to be repaired, and generate the corresponding repair strategy according to the abnormal state type of the first abnormal package set; S2, construct the package dependency topology of the standard reference Linux system, compare the package dependency topology of the current Linux system to be repaired with that of the standard reference Linux system to determine the second set of abnormal packages, and generate a corresponding repair strategy based on the second set of abnormal packages; S3, Repair the abnormal packages in the first abnormal package set and the second abnormal package set according to the repair strategy.

[0030] It is understood that this embodiment identifies packages in an abnormal state in the current system by constructing the package dependency topology of the current Linux system to be repaired and the standard reference Linux system. This enables accurate identification and difference analysis of packages in an abnormal state in the system, discovering potential conflicts between packages, and thus predicting their impact before system upgrade and avoiding potential risks during the upgrade process. By generating corresponding repair strategies based on the abnormal state type of the packages, it is possible to ensure that all relevant packages are repaired and in a stable state before the upgrade, effectively improving the success rate and stability of the system upgrade process, ensuring the smooth completion of the system upgrade, and reducing the risk of upgrade failure.

[0031] In this embodiment, constructing the package dependency topology of the current Linux system to be repaired specifically includes: Extract metadata information of installed packages, including one or more fields from package name (Package), dependent packages (Depends), recommended packages (Recommends), package version (Version), and package status (Status); Based on the Package field, generate a set of nodes for all software packages and build the initial topology framework; Read the Version and Status fields corresponding to each package, and record the version information and installation status information as node attributes; Based on the dependencies defined in the Depends and Recommendations fields, the system resolves and establishes directed connections between nodes, mapping the dependencies to edges in the topology to form a dependency topology with software packages as nodes and dependencies as directed edges.

[0032] In specific application embodiments, such as Figure 2 As shown, the specific steps for building the package dependency topology of the current Linux system to be repaired in step S1 are as follows: S101: Extract detailed information about local system software packages: This step involves extracting detailed information about installed software packages from the system. This is primarily done by reading the contents of the ` / var / lib / dpkg / status` file, including metadata such as package name, version, architecture, dependencies, and package conflicts. This information is then parsed to construct a dependency chain between packages to identify dependencies. Once extraction is complete, proceed to the next step, S102. S102: Analyze the information extracted in step S101, generate a package dependency topology, and mark abnormal nodes: Based on the metadata information of the installed packages extracted in step S101, including key fields such as Package (package name), Depends (dependent packages), Recommends (recommended packages), and Version (package version), first, based on the Package field, generate a set of nodes for all packages to construct an initial topology framework; simultaneously, read the Version and Status fields corresponding to each package, recording their version information and installation status information as node attributes. Then, according to the dependency relationships defined in the Depends and Recommends fields, the system parses and establishes directed connections between nodes. Dependencies are mapped to edges in the topology, thus forming a dependency network graph with packages as nodes and dependencies as edges. By further analyzing the Status field and other status information, package nodes in abnormal installation states can be identified. Specifically, if the value of the Status field is not "install" or "installed" (meaning it is installed), such as "half-installed" (meaning the package is only partially installed), "unpacked" (unpacked but not configured), "half-configured" (configuration process incomplete), or "reinstreq" (requires reinstallation), it indicates that the package is in an abnormal installation state, and the system marks the corresponding node as "installation abnormal." Furthermore, when parsing the Depends field, if the system finds that a target package that a package depends on is not installed or has failed to install in the current system, it marks the node as a "dependency missing" abnormal state. If it finds that the version does not meet the dependency requirements, it marks the node as a "dependency version abnormal" state. Simultaneously, it adds an "unmet" status marker to the dependency edge corresponding to the abnormal package that the abnormal node depends on, and records detailed information such as the missing package name and required version. Finally, a package dependency topology structure with abnormal status markers is generated, and after generation, the process proceeds to the next step, S103. Common abnormal software package states include: iF state: installed but configuration failed; iHR state: the software package is installed but not fully configured, usually due to an interruption in the installation process or missing dependencies; iU state: unpacked but not yet fully configured, system functions may be unstable.

[0033] S103: Determine whether all installed software packages in the system have been analyzed. If the determination fails, mark the software packages that have not been analyzed and repeat step S102 to recalculate and analyze the dependency structure of the installed software packages.

[0034] It is understandable that, based on the system's installed software package metadata, dependency relationships, and abnormal state marker information extracted and analyzed in steps S101 to S103, a complete software package dependency topology of the current Linux system to be repaired can be comprehensively constructed. This topology, with software packages as nodes and dependencies as directed edges, comprehensively describes the dependency structure and abnormal states between software packages in the current system, providing fundamental support for the formulation and execution of subsequent repair strategies. Analysis of this topology can identify potential conflicts such as abnormal installation states or missing dependencies between software packages, thereby predicting their impact before system upgrades and mitigating potential risks during the upgrade process.

[0035] In this embodiment, the construction of the package dependency topology of the standard reference Linux system includes the following steps: T1 downloads and installs the basic configuration package from the Kylin standard software source repository, parses the configuration file provided by the basic configuration package, and extracts the set of basic software packages necessary for the system to maintain basic operation from the configuration file; T2 uses each package in the basic package set as a node and the metadata information of the package as a node attribute. Based on the dependency relationship defined in the Depends and Recommendations fields of the package, directed edges are recursively established between the nodes to form a dependency topology structure with packages as nodes and dependencies as edges. This process continues until all dependencies are resolved and no more are added, resulting in the minimum standard system dependency topology structure required for the complete operation of the system. T3: Obtain the standard system core package set from the basic configuration package, and build the complete Linux standard system dependency topology based on the standard system core package set in the manner of step T2, while minimizing the standard system dependency topology.

[0036] In specific application embodiments, such as Figure 3 As shown, the specific steps for building the package dependency topology of the standard reference Linux system in step S1 are as follows: S201: Obtain standard software source index information: The system first reads the configuration file / etc / apt / sources.list (in the Kylin operating system, the software source is / var / lib / kylin-system-updater / sources.list) to obtain the address of the currently used software source. Then, it executes the apt-get update command to update the metadata information (including package name, version, dependency relationship, etc.) of all available packages to the local cache directory / var / lib / apt / lists / by synchronizing the index file with the software source repository server, providing complete basic data support for the subsequent construction of the standard system dependency topology.

[0037] S202: Obtain the Standard Reference System Basic Configuration Package: Download the basic configuration package (kylin-update-desktop-config package in Kylin OS) from the software source repository. After downloading, parse the configuration file provided by the package (located at / usr / share / kylin-update-desktop-config / config / kylin-update-desktop-system.json). This configuration file contains the minimum list of installed packages, the core package list, and the system package set, providing data support for subsequent steps to build the standard reference system.

[0038] S203: Constructing a Standard Minimal System Package Dependency Topology: The system first obtains the minimum set of basic software packages necessary for maintaining basic system operation from step S201. This set includes key system components such as libc6 (providing C standard library support), base-files (for building the basic structure of the file system), and coreutils (providing basic system commands such as ls, cp, mv, etc.). Based on this set of basic software packages, an initial dependency topology framework is constructed using each package name as a node. Subsequently, the software source index file obtained in step S201 is parsed, for example, the standard index path corresponding to Kylin OS version 2403: / var / lib / apt / lists / archive.kylinos.cn_kylin_KYLIN-ALL_dists_-2403-update2--2403-update2.2_main_binary-arm64_Packages. By parsing the index file, key fields including Package (package name), Depends (required dependencies), Recommends (recommended dependencies), and Version (version number) are extracted, and the version number and other metadata information are appended as node attributes. Based on this, the system establishes directed edges between nodes according to the dependency relationships defined in the Depends and Recommends fields, forming a directed graph structure with packages as nodes and dependencies as edges. The construction of dependency edges adopts a recursive approach until all transitive dependencies are fully resolved and the dependency topology is closed. This dependency resolution process can be assisted by the apt-cachedepends or apt-rdepends tools; for example, executing the command apt-rdepends libc6 can obtain the complete dependency chain of the libc6 package. Finally, the system completes the closure construction of the minimum basic package set and its transitive dependencies, forming a standard minimal system dependency topology covering the set of packages necessary for the normal operation of the system, providing a complete and traceable benchmark topology model for subsequent difference comparisons and dependency verification.

[0039] S204: Determine whether the minimized system package in the basic configuration package is in the standard minimized system package topology built in step S202. If the determination fails, mark the incomplete package and repeat step S202 to recalculate and analyze the dependency graph; otherwise, proceed to the next step. S205: Constructing the Standard Reference System Package Dependency Topology. Based on the minimized standard system dependency topology constructed in step S203, and further combining the list of core standard system packages obtained in step S202, the complete standard system package dependency topology is constructed. In the basic configuration of the Kylin operating system, the kylin-update-desktop-system.json configuration file defines a list of key packages required to build a complete operating system environment. This list is categorized and managed according to functional modules and system levels, and is formulated by system maintenance personnel based on the actual operating environment and system design requirements. This core package list covers components of multiple key system subsystems, including the kernel and its related modules, security components (kysec), the UKUI desktop environment core package, input method framework, font support package, and multi-language localization support components. The above package set constitutes the necessary software foundation for a complete and runnable operating system environment. Based on the above standard package list, the system adopts the same dependency resolution strategy as in step S203, recursively resolving the dependencies of each package and constructing their dependency edges, thereby incorporating these core packages and their transitive dependencies into the existing minimized dependency topology. Ultimately, the system completes the construction of the software package dependency topology of the standard reference system, forming a software package dependency network diagram covering all functional components of the system, providing a benchmark model for the subsequent system consistency verification and repair strategy formulation.

[0040] S206: Determine whether the core software package in the basic configuration package is in the standard system software package topology built in step S205. If the determination fails, mark the incomplete software package and repeat step S205 to recalculate and analyze the dependencies.

[0041] It is understandable that, based on steps S201 to S206, the standard software source index information, the minimum system base package set of the standard reference system, and the complete core package list are obtained. Combining the index information and the basic configuration package list, and utilizing APT dependency resolution, a complete package dependency topology of the standard reference system can be constructed. This topology, with packages as nodes and dependencies as directed edges, systematically describes the dependencies and version information between packages in the standard environment. It serves as an important reference benchmark for subsequent difference comparison and remediation strategy formulation, providing crucial reference for system remediation, dependency verification, and system consistency checks.

[0042] In this embodiment, the first set of abnormal software packages is determined based on the software package dependency topology of the current Linux system to be repaired. This set includes software packages with abnormal installation status and abnormal dependency status. The specific steps are as follows: Read the Status field from the package metadata information. If the Status field does not indicate "installed", mark the package and the corresponding node as an installation exception. Parse the Depends field in the metadata information and determine the status of the packages that each package depends on. If it is determined that a package that a certain package depends on does not exist in the current system, the corresponding package is marked as a missing dependency. If it is determined that the version of a package that a certain package depends on does not meet the dependency requirements in the current system, the corresponding package is marked as an abnormal dependency version.

[0043] Based on the exception status type of the first exception package set, a corresponding repair strategy is generated, specifically including: If the abnormal status type is dependency missing, determine whether the missing package is available in the current software source. If so, the repair strategy is to install the corresponding missing package; otherwise, the repair strategy is to uninstall the missing dependent package. If the exception status type is a dependency version exception, the remediation strategy is to upgrade or downgrade the version of the dependent software package to the target version that meets the dependency requirements. If the exception status type is installation exception, and the specific exception is determined to be package configuration failure based on the value of the Status field in the package metadata information, the repair strategy is as follows: first try to restore the configuration process; if it still fails, block the problematic script and skip the script to restore the configuration; finally, reinstall the package. If the exception status type is installation exception, and the specific exception is determined to be that the package is not fully installed based on the value of the Status field in the package metadata information, then the repair strategy is to reinstall the corresponding package.

[0044] Compare the package dependency topology of the current Linux system to be repaired with that of the standard reference Linux system to determine the second set of anomalous packages. Based on this second set of anomalous packages, generate a corresponding repair strategy, which includes: Compare the differences in package dependency topology between the current Linux system to be repaired and the standard reference Linux system, extract the missing standard packages and redundant non-standard packages in the current system, and generate a repair strategy: uninstall the redundant non-standard packages and install the missing standard packages; For software packages with the same name in the current system and the standard system, the version field (Version) in the package metadata is further extracted and compared. If the version of the package in the current Linux system to be repaired is inconsistent with the version in the standard system, a repair strategy is generated: upgrade or downgrade the package to the version of the standard system.

[0045] In specific application embodiments, such as Figure 4As shown, the process involves identifying all abnormal software packages (including the first set of abnormal software packages and the second set of abnormal software packages) in the Linux system to be repaired, and generating corresponding repair strategies based on the abnormal state type of each abnormal software package. Specifically, this includes the following steps: S301: Obtain the list of abnormal software packages in the current system: This step iterates through the topology of the software packages in the current system to be repaired, scanning and checking the status of each node in the topology graph. The system identifies and extracts the abnormal state nodes marked in step S102, including the following types: software packages with missing dependencies, software packages that have been installed but whose configuration process failed, and corrupted software packages that have only been unpacked but not yet configured. If an abnormal software package node is detected, the process proceeds to step S302; otherwise, it proceeds to step S303 to perform difference comparison operations.

[0046] S302: Generate Repair Strategy Input List: After obtaining the software packages in the current system that are in an abnormal state in step S301, classify and analyze them according to the abnormality type of each software package, and construct the "Repairable Dependency List", "Pending Deletion List", "Abnormal Script Processing Marker List", and "Reinstallation Required List" respectively. This operation aims to clarify the processing path for different abnormalities, providing a structured data foundation and decision-making basis for subsequent dependency completion, software package deletion, script repair, and reinstallation operations; classify and process according to the specific abnormality type of the software package: 1. Missing Package Dependencies (IF Status): In the package dependency topology of the system to be repaired, the system traverses all nodes marked as "missing dependencies" and their corresponding invalid dependency edges, extracting all unmet dependencies. For each missing dependency, its package name and version requirements are recorded, and its availability is confirmed by querying the software source information. If the dependency exists in the current software source, it is added to the "Repairable Dependency List"; if it is not available in the software source, its corresponding missing dependency source node (i.e., the package that is abnormal due to the missing dependency) is recorded in the "Pending Deletion List". These two lists serve as the core input for subsequent dependency completion and repair strategy formulation. Whether a dependency exists in the current software source can be determined by executing the `apt-cache policy <dependency package name>` command: if the result shows "Candidate:(none)," the dependency is considered unavailable in the current software source.

[0047] 2. Package configuration failure (iHR status, such as errors in pre- and post-installation scripts): In the package dependency topology of the system to be repaired, the system traverses all nodes marked as "installed but configuration failed," forcibly deleting the executed pre- and post-installation scripts and repairing their status. Specifically: First, use `dpkg--configure -a` to attempt to restore the configuration process. If it still fails, disable the problematic script (e.g., rename the corresponding `.postinst` file or clear its contents), and then execute `dpkg--configure` again. <package>Skip the script to restore configuration; finally, add the package to the "Abnormal Script Handling Flag List" for subsequent automatic repair processes.

[0048] 3. In the case of incomplete package installation (IU state, only unpacked and not configured), in the package dependency topology of the system to be repaired, the system traverses all nodes marked as "only unpacked but not yet configured" and records the detected package names in the "list of packages to be reinstalled"; then the repair process reinstalls them.

[0049] Once generated, the process will automatically proceed to the next stage, S303.

[0050] S303: Compare the dependency topology of the standard reference system to generate a "list of differing software packages": The system compares the generated current system software dependency topology with the standard system software dependency topology to identify and extract the set of software packages that differ from each other. This dependency topology graph uses a directed graph structure to represent the dependencies between software packages, where each node represents a software package and includes attributes such as version number, architecture information, and source. The directed edges in the graph represent the dependency direction; that is, edge A→B indicates that software package A depends on software package B. The specific processing flow is as follows: First, the node sets of the current system and the standard system are extracted separately, denoted as packages_cur=set(G_cur.nodes) and packages_std=set(G_std.nodes), representing the sets of software packages installed in the current system and the standard system, respectively. Through set difference calculation, missing standard software packages (missing_in_cur=packages_std-packages_cur) and redundant non-standard software packages (extra_in_cur=packages_cur-packages_std) in the current system are identified. Missing packages are marked as "to be backfilled," and redundant packages are marked as "to be uninstalled," and both are added to the difference package list. Next, for package nodes with the same name in the current system and the standard system, their Version attribute is further extracted for comparison: if the current system version is lower than the standard system version, the package is marked as "needs to be upgraded"; if the current version is higher than the standard version, it is marked as "needs to be downgraded." All packages with inconsistent versions are also included in the difference package list. After completing the above difference analysis, the system finally generates the difference package list and proceeds to the next step, S304.

[0051] S304: After generating the list of difference packages, a verification process will be executed to confirm that all differences have been generated correctly. This involves iterating through the list of difference packages to check for any missing or ungenerated packages. If all differences have been marked and generated, proceed to the next step, S305; otherwise, continue adding markings and return to step S303 for remarking.

[0052] S305: Based on the list generated in step S302 and the list of differing software packages generated in step S303, the relevant software packages will be marked with status according to various exception types, and the subsequent processing operations will be specified. Specifically, the target operation status of the software package will be marked as "install," "upgrade," "downgrade," "delete," or "reinstall," etc., indicating the actual action to be performed. Packages in the differential package list are marked as needing upgrade if the current system version is lower than the standard version, and marked as needing downgrade if the current system version is higher than the standard version. Missing packages will be marked as installable, and redundant packages will be marked as uninstallable.

[0053] Packages in the fixable dependency list will be processed according to the current system status: if the dependency is not yet installed, it will be marked as installed; if it is installed but the version is higher than the dependency requirement, it will be marked as downgraded; if the version is lower than the dependency requirement, it will be marked as upgraded. Packages in the pending deletion list will be marked for uninstallation; Packages in the abnormal script handling flag list will have their associated installation / uninstallation scripts (such as postinst, prerm, etc.) removed before being repaired to eliminate script abnormal interference, and then marked for reinstallation; Packages in the reinstallation process list are marked as reinstallation operations.

[0054] S306: Recursively resolve the packages marked in step S305 and process their dependencies. Utilizing APT's dependency resolution mechanism, the dependencies of each marked package to be repaired are recursively resolved based on the transitive closure algorithm until all dependencies are resolved and no new dependencies are added. This process uses the `apt-cache depends` and `apt-rdepends` tools. Finally, a list of all packages to be repaired and their dependencies is obtained; if dependency resolution is complete, the process proceeds to step S307. The expression for the transitive closure algorithm is: In the formula, S represents the set of software packages necessary for the system to maintain its basic operating environment. Denotes the set of direct dependencies of S. This indicates a direct dependency. This indicates a final dependency that will not generate any new dependencies.

[0055] S307: Check all marked packages to determine if their dependencies have been fully resolved. By traversing the marked packages and their dependencies, confirm that all dependencies for each package are satisfied. If all dependencies have been successfully resolved without omissions or conflicts, proceed to the next step, S308; if incompletely resolved dependencies or missing dependencies are found, return to step S306 to recursively calculate and ensure that all marked package dependencies are completely correct.

[0056] Understandably, based on the dependency topology of the system's software packages to be repaired, and combined with the installation status of the software packages recorded at each node in the topology, abnormal software packages in the system are identified, and corresponding repair strategies are formulated accordingly. This strategy covers comprehensive detection and handling of issues such as missing dependencies and installation anomalies (e.g., configuration failures or only unpacking without configuration). Simultaneously, using the dependency topology of the standard reference system's software packages as a comparison benchmark, a difference analysis is performed on the software package dependencies and version information between the current system to be repaired and the standard system. The comparison includes not only the existence of software packages but also the verification of version consistency. For example, if the current system is running Kylin OS 2022, but due to environmental pollution or abnormal updates, some version 2503 software packages were mistakenly installed, it may cause conflicts between software packages, configuration errors, and compatibility issues. Furthermore, by comparing the dependency topology of the standard and the current system, missing standard software packages, redundant or conflicting software packages, and software packages with versions that are too low or abnormally high can be accurately identified. Based on these analysis results, steps S301-S307 will ultimately generate a list of benchmark repair strategy packages that are based on the Kylin operating system and match the user's actual environment. Specifically, this list includes: filling in missing standard packages, uninstalling conflicting or redundant packages, upgrading packages to versions lower than the standard, and downgrading packages to versions higher than the standard. This provides a solid foundation for the subsequent repair process and ensures the stability and consistency of the system package environment.

[0057] Subsequently, as Figure 5 As shown, corresponding repair operations are performed on these abnormal software packages to repair the system environment. The specific steps are as follows: S401: Based on the baseline repair strategy package list, first perform a security check to see if the uninstalled packages are critical system components. If core software (such as the kernel, desktop environment, etc.) is detected to have been uninstalled, immediately terminate the repair process and prompt the user that the current system environment cannot be repaired. Otherwise, proceed to the next step S402.

[0058] S402: Determine whether the uninstalled packages in the current list of repaired packages contain third-party packages (such as WPS, 360 Browser, etc.). If third-party packages are detected, proceed to step S403 to execute the packaging process for the uninstalled packages; otherwise, jump directly to S404 to continue with subsequent operations.

[0059] S403: Repackage the installed software package. The .deb installation package is rebuilt by extracting the installed package files and metadata from the system. Once built, it is saved to the system for KARE to use and reinstall. After packaging is complete, proceed to S404.

[0060] S404: Critical system configurations need to be backed up to ensure restoration to the original state in case of anomalies during the repair process. Backup content typically includes software source configurations, a list of installed software packages, critical system service configurations (such as network, user permissions, bootloader, etc.), and custom settings for applications. A complete backup allows the repair tool to restore the system if necessary, preventing functional damage or data loss due to repair failure. Proceed to S405 after backup is complete.

[0061] S405: Download the software package that needs repair from the software source to the local directory, and verify its MD5 value after the download is complete. If the verification fails, download the software package again; otherwise, proceed to step S406 to continue with the subsequent operations.

[0062] S406: Determine if all software packages have been downloaded. If any packages have not been downloaded or have failed verification, re-enter step S305 to download and verify the MD5 value; otherwise, proceed to step S407 to perform the installation operation.

[0063] S407: Utilizes APT / DPKG tools to uniformly perform package repair operations, including installing missing packages, uninstalling conflicting packages, upgrading outdated versions of packages, and downgrading outdated versions of packages. During the repair process, APT calls the underlying DPKG tools, including: During the installation process, the .deb package is unpacked, its contents are extracted to the target file system path, and pre-installation and post-installation scripts are executed as needed. During the uninstallation process, DPKG is used to execute the uninstallation process (including calling the prerm and postrm scripts) to clean up files and related configurations. When performing an upgrade / downgrade, DPKG first extracts the new version's .deb package and places its contents into a specified directory on the system. Next, DPKG compares the differences between the old and new versions and replaces files from the old version. For file conflicts, DPKG handles and resolves them to ensure the new version is installed correctly.

[0064] S408: Determine if all software packages have been installed. If all software packages have been installed, the system environment repair is successful; otherwise, proceed to step S407 to continue installing the remaining software packages.

[0065] Understandably, after formulating the repair strategy, steps S401-S408 lead to the specific repair operation phase. This phase includes the installation, uninstallation, upgrading, and downgrading of software packages. Before performing the repair, the system will prioritize packaging the software packages to be uninstalled and back up critical configurations to enable rollback in case of emergencies. During the repair process, the system will execute the generated repair strategy step by step in an orderly manner, ensuring that all relevant software packages are in a stable state before the upgrade. Ultimately, this ensures the system successfully completes the upgrade and reduces the risk of upgrade failure.

[0066] Compared with the prior art, the present invention has the following beneficial effects: 1. Improved System Upgrade Success Rate: This invention constructs a system package graph to detect potential dependency conflicts and version incompatibility issues in advance, thereby avoiding upgrade failures due to dependency corruption. Through automated recursive calculations and dependency network construction technology based on the target version, it ensures that dependencies are accurately resolved and repaired before the upgrade, significantly improving the upgrade success rate.

[0067] 2. Rapid Recovery of System Dependencies: When dependency conflicts or corruption occur in the environment before a system upgrade, this invention can quickly diagnose the problem and automatically repair it. During the repair process, the system can compare the standard system dependency topology with the current system software package dependency topology, accurately identify differences and repair them, reducing manual intervention and improving system repair efficiency.

[0068] 3. Optimized dependency resolution process: By constructing the dependency topology of the current system and standard software packages, it is possible to deeply analyze the dependency chains between software packages, avoiding conflicts caused by complex dependency relationships in traditional methods. The dependency resolution process optimizes package management and installation processes, improving system performance and stability.

[0069] 4. Ensure system stability: When implementing the repair strategy, this invention strictly checks the integrity and version compatibility of the software packages to ensure that all necessary dependencies are correctly introduced and resolved after the system upgrade, preventing system instability caused by missing or conflicting software packages.

[0070] 5. Automated Repair and Optimization: Through automated dependency resolution and repair mechanisms, this invention not only solves the difficulty of manually repairing complex dependency problems in existing technologies, but also provides flexible repair strategies, supports optimization schemes for different operating system environments, and improves the overall performance and reliability of the system.

[0071] In summary, this invention, through the combination of software package dependency analysis, intelligent repair strategy formulation, and automated repair execution, ensures the smooth progress of system upgrades, reduces the upgrade failure rate caused by dependency issues, greatly improves the efficiency and reliability of operating system upgrades, and ensures that the system environment remains stable throughout the upgrade process, thereby enhancing the maintainability and stability of the system.

[0072] The present invention further provides an environment diagnosis and repair system for Linux system before upgrade, including a microprocessor and a memory interconnected, wherein the microprocessor is programmed or configured to perform the steps of the environment diagnosis and repair method for Linux system before upgrade.

[0073] The present invention further provides a computer-readable storage medium storing a computer program / instructions, the computer program / instructions being programmed or configured to execute, via a processor, the steps of an environment diagnosis and repair method prior to a Linux system upgrade.

[0074] The system and medium of the present invention, corresponding to the methods described above, also have the advantages described above.

[0075] The present invention can implement all or part of the processes in the methods of the above embodiments, or it can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium. When the computer program is executed by a processor, it can implement the steps of the above method embodiments. The computer program includes computer program code, which can be in the form of source code, object code, executable file, or some intermediate form. Computer-readable media include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. The memory is used to store computer programs and / or modules. The processor implements various functions by running or executing the computer programs and / or modules stored in the memory, and by calling data stored in the memory. The memory may include high-speed random access memory, as well as non-volatile memory, such as hard disks, RAM, plug-in hard disks, smart media cards (SMC), secure digital (SD) cards, flash cards, at least one disk storage device, flash memory device, or other volatile solid-state storage devices.

[0076] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.< / package>

Claims

1. A method for environmental diagnosis and repair before upgrading a Linux system, characterized in that, Including the following steps: Construct the package dependency topology of the current Linux system to be repaired and determine the first abnormal package set based on the package dependency topology of the current Linux system to be repaired. Generate the corresponding repair strategy according to the abnormal state type of the first abnormal package set. Construct the package dependency topology of the standard reference Linux system, compare the package dependency topology of the current Linux system to be repaired with that of the standard reference Linux system to determine the second set of abnormal packages, and generate a corresponding repair strategy based on the second set of abnormal packages. The abnormal packages in the first and second abnormal package sets are repaired according to the repair strategy.

2. The method for environmental diagnosis and repair before upgrading a Linux system according to claim 1, characterized in that, Build the package dependency topology of the current Linux system to be repaired, specifically including: Extract metadata information of installed packages, including one or more fields from package name (Package), dependent packages (Depends), recommended packages (Recommends), package version (Version), and package status (Status); Based on the Package field, generate a set of nodes for all software packages and build the initial topology framework; Read the Version and Status fields corresponding to each package, and record the version information and installation status information as node attributes; Based on the dependencies defined in the Depends and Recommendations fields, the system resolves and establishes directed connections between nodes, mapping the dependencies to edges in the topology to form a dependency topology with software packages as nodes and dependencies as directed edges.

3. The method for environmental diagnosis and repair before upgrading a Linux system according to claim 2, characterized in that, The first set of abnormal packages is determined based on the package dependency topology of the current Linux system to be repaired. This includes packages with abnormal installation status and abnormal dependency status. The specific steps are as follows: Read the Status field from the package metadata information. If the Status field does not indicate "installed", mark the package and the corresponding node as an installation exception. Parse the Depends field in the metadata information and determine the status of the packages that each package depends on. If it is determined that a package that a certain package depends on does not exist in the current system, the corresponding package is marked as a missing dependency. If it is determined that the version of a package that a certain package depends on does not meet the dependency requirements in the current system, the corresponding package is marked as an abnormal dependency version.

4. The method for environmental diagnosis and repair before upgrading a Linux system according to claim 1, characterized in that, Based on the exception status type of the first exception package set, a corresponding repair strategy is generated, specifically including: If the abnormal status type is dependency missing, determine whether the missing package is available in the current software source. If so, the repair strategy is to install the corresponding missing package; otherwise, the repair strategy is to uninstall the missing dependent package. If the exception status type is a dependency version exception, the remediation strategy is to upgrade or downgrade the version of the dependent software package to the target version that meets the dependency requirements. If the exception status type is installation exception, and the specific exception is determined to be package configuration failure based on the value of the Status field in the package metadata information, the repair strategy is as follows: first try to restore the configuration process; if it still fails, block the problematic script and skip the script to restore the configuration; finally, reinstall the package. If the exception status type is installation exception, and the specific exception is determined to be that the package is not fully installed based on the value of the Status field in the package metadata information, then the repair strategy is to reinstall the corresponding package.

5. The method for environmental diagnosis and repair before upgrading a Linux system according to claim 1, characterized in that, Building a standard reference Linux system's package dependency topology involves the following steps: T1 downloads and installs the basic configuration package from the Kylin standard software source repository, parses the configuration file provided by the basic configuration package, and extracts the set of basic software packages necessary for the system to maintain basic operation from the configuration file; T2 uses each package in the basic package set as a node and the metadata information of the package as a node attribute. Based on the dependency relationship defined in the Depends and Recommendations fields of the package, directed edges are recursively established between the nodes to form a dependency topology structure with packages as nodes and dependencies as edges. This process continues until all dependencies are resolved and no more are added, resulting in the minimum standard system dependency topology structure required for the complete operation of the system. T3: Obtain the standard system core package set from the basic configuration package, and build the complete Linux standard system dependency topology based on the standard system core package set in the manner of step T2, while minimizing the standard system dependency topology.

6. The method for environmental diagnosis and repair before upgrading a Linux system according to claim 1, characterized in that, Compare the package dependency topology of the current Linux system to be repaired with that of the standard reference Linux system to determine the second set of anomalous packages. Based on this second set of anomalous packages, generate a corresponding repair strategy, which includes: Compare the differences in package dependency topology between the current Linux system to be repaired and the standard reference Linux system, extract the missing standard packages and redundant non-standard packages in the current system, and generate a repair strategy: uninstall the redundant non-standard packages and install the missing standard packages; For software packages with the same name in the current system and the standard system, the version field (Version) in the package metadata is further extracted and compared. If the version of the package in the current Linux system to be repaired is inconsistent with the version in the standard system, a repair strategy is generated: upgrade or downgrade the package to the version of the standard system.

7. The method for environmental diagnosis and repair before upgrading a Linux system according to any one of claims 1-6, characterized in that, After determining the first set of abnormal software packages, the process further includes recursively resolving the dependencies of each abnormal software package in the first set of abnormal software packages based on the transitive closure algorithm, until all dependencies are resolved, in order to obtain all abnormal software packages to be repaired and their dependent software packages. The expression for the transitive closure algorithm is as follows: In the above formula, S represents the set of software packages necessary for the system to maintain its basic operating environment. Denotes the set of direct dependencies of S. This indicates a direct dependency. This indicates a final dependency that will not generate any new dependencies.

8. The method for environmental diagnosis and repair before upgrading a Linux system according to any one of claims 1-6, characterized in that, When repairing abnormal packages in the first and second abnormal package sets according to the repair strategy, the critical system configurations are backed up first. The backup content includes one or more of the following: software source configuration, list of installed packages, critical system service configuration, and custom settings of applications. Then, it is determined whether there are critical system components in the packages to be installed according to the repair strategy. If so, the repair process is terminated and a message is displayed indicating that the current system environment cannot be repaired.

9. A system for environmental diagnosis and repair before upgrading a Linux system, comprising a microprocessor and a memory interconnected, characterized in that, The microprocessor is programmed or configured to perform the steps of the Linux system pre-upgrade environment diagnosis and repair method as described in any one of claims 1 to 8.

10. A computer-readable storage medium storing a computer program / instructions, characterized in that, The computer program / instructions are programmed or configured to execute the steps of the Linux system pre-upgrade environment diagnosis and repair method according to any one of claims 1 to 8 via a processor.

Images