Configuration item repair-oriented Linux kernel boot test and configuration consistency intelligent repair method

Abstract

The invention discloses a configuration item repair-oriented Linux kernel boot test and configuration consistency intelligent repair method. The method comprises the following steps: collecting a compiling log, a boot log and a running state; performing segmentation, pattern matching and field extraction on the log, normalizing error information into structured error entries, and distinguishing a dependency missing class, a mutual exclusion conflict class and other compiling failure classes; performing preprocessing and grammar analysis on the Kconfig file, extracting configuration item attributes and constraint relationships, constructing a unified dependency graph and generating a configuration item metadata table; classifying and marking the configuration items based on the metadata, and calculating a key score; generating a repair action according to the structured error entry, the unified dependency graph and the key score, performing iteration execution, and performing recompilation and restart verification after each iteration until a reparated configuration file which can be compiled and started is obtained or a preset iteration upper limit is reached; according to the invention, the cross-version adaptation and problem closed-loop efficiency is improved.

Description

Technical Field

[0001] This invention relates to the field of software testing technology, and specifically to a Linux kernel boot test and configuration consistency intelligent repair method oriented towards configuration item repair. Background Technology

[0002] The Linux kernel provides a vast number of configuration items through the Kconfig mechanism, which are used to tailor and combine kernel functions under different hardware platforms and business scenarios. In current engineering practices, randomization or batching strategies such as randconfig are often used to generate a large number of candidate .config configuration files, which are then verified in conjunction with compilation and startup tests to achieve regression testing, customized tailoring, or defect exposure.

[0003] However, in scenarios involving large-scale configuration exploration and cross-version evolution, existing methods typically suffer from the following problems: Complex configuration constraints and difficulty in error localization: Configuration items not only have explicit dependencies such as depend on, select, and imply, but also implicit constraints such as choice mutual exclusion, architecture / platform limitations, reverse dependencies, and default value inducements. When constraints overlap, the root cause of compilation / startup failures often exhibits a "multiple causes, one effect" characteristic, making it difficult to quickly locate the key set of configuration items based solely on logs. Repair relies on manual experience, resulting in high iteration costs: When faced with compilation or startup failures, existing practices often rely on manually reading compilation logs, comparing configurations item by item, and repeatedly trying and failing. When the scale of configuration items is large and the types of failures are diverse, the repair process often requires multiple rounds of "modification-recompilation-restart," which is time-consuming and lacks reproducibility and traceability. The lack of semantic constraints in remediation strategies makes it difficult to guarantee satisfiability: Some heuristic remediation strategies only patch single errors locally, lacking system modeling of semantic constraints on configuration items. In the presence of implicit constraints or coupling of multiple configuration items, local remediation may introduce new conflicts or cause overall constraints to become unsatisfiable, resulting in "repairing more errors" or a large number of redundant attempts. The verification target is biased towards "compileable / bootable," with insufficient stability guarantees: Even after a successful one-time boot, runtime crashes, deadlocks, memory overflows, and other stability issues may still occur. Without a systematic runtime verification mechanism, "bootable but unstable" configurations are easily misjudged as usable results, affecting subsequent delivery and regression reliability. Cross-version evolution triggers regressions, lacking engineering-based localization methods: With kernel version iterations, renaming, splitting, obsolescence, and changes in default values ​​of configuration items amplify the risk of configuration inconsistencies. When existing configurations fail in new versions, without a commit-level localization mechanism combined with automated startup checks, it is often difficult to quickly locate the abnormal commits that introduce regressions. Summary of the Invention

[0004] Purpose of the invention: The purpose of this invention is to provide a Linux kernel boot test and configuration consistency intelligent repair method for configuration item repair. In batch configuration exploration scenarios, it can overcome the problems of existing technologies that rely on manual experience for kernel configuration error investigation, have low repair efficiency, and insufficient stability guarantee by combining reproducible boot tests, Kconfig semantic constraint modeling, automated repair decision-making, and stability verification in a closed loop.

[0005] Technical Solution: The present invention provides a method for intelligent repair of Linux kernel boot testing and configuration consistency based on configuration item repair, comprising the following steps: (1) Generate multiple candidate configuration files based on randomization or batching strategies, and record version information and reproducibility identifier for each candidate configuration file; (2) Compile the kernel for the candidate configuration file and boot it in the virtualization environment, collecting compilation logs, boot logs and running status; (3) Perform segmentation, pattern matching and field extraction on the compilation log and startup log, standardize the error information into structured error entries, and at least distinguish between dependency missing classes, mutual exclusion conflict classes and other compilation failure classes; (4) Perform preprocessing and syntax parsing on the Kconfig file in the kernel source code, extract configuration item attributes and constraint relationships, construct a unified dependency graph containing explicit dependencies and implicit constraints, and generate a configuration item metadata table; (5) Classify and label configuration items based on configuration item metadata and calculate key scores; (6) Generate repair actions based on structured error entries, unified dependency graph and criticality score and execute them iteratively. After each iteration, recompile and restart to verify until a compileable and startable repair configuration file is obtained or the preset iteration limit is reached.

[0006] Furthermore, in step 2, the virtualization environment is a reproducible automated boot test environment, including a unified root file system, fixed boot parameters, standardized kernel image artifacts, and repeatable boot judgment criteria, to ensure the comparability of test results for different candidate configurations.

[0007] Furthermore, in step 2, the structured error entry includes at least the error type, evidence text fragment, associated symbol or error file path, candidate configuration item set, and context location identifier; and a mapping relationship between the error entry and the candidate configuration item set is established based on the associated symbol or error file path and configuration item metadata.

[0008] Furthermore, in step 4, the preprocessing in the Kconfig semantic modeling step includes at least removing comments and blank lines, normalizing indentation and syntax keyword forms, filtering text structures unrelated to dependency extraction, and recursively expanding and normalizing source references to reduce parsing noise and improve the accuracy of syntax tree construction.

[0009] Furthermore, in step 4, the implicit constraints in the Kconfig semantic modeling step include at least choice mutual exclusion relationships, architecture or platform constraints, reverse dependency relationships, and default value induced constraints; the explicit dependencies and implicit constraints are uniformly represented as a queryable graph structure and stored in association with the configuration item metadata table.

[0010] Furthermore, in step 5, the configuration item classification includes at least core items, debugging items, security items, hardware items, and general items; among them, core items are determined based on the reverse dependency degree, dependency propagation scope, or menu path characteristics of the configuration items, and have higher priority or are set as protected sets during the repair process.

[0011] Furthermore, step 6 is as follows: When a dependency missing error is detected, recursively complete the missing dependencies along the unified dependency graph, and prioritize the configuration items with higher criticality scores in the candidate dependency set; when a mutual exclusion conflict error is detected, disable conflict items with lower scores or select alternative items based on the criticality scores of each configuration item in the conflict set; when other compilation failure errors are detected, locate the relevant configuration item set and implement a selective pruning strategy that retains high-scoring items and disables low-scoring items.

[0012] Furthermore, in step 6, after obtaining the bootable repaired configuration file, stability verification is further performed: a coverage-guided kernel fuzz test is run on the repaired kernel to generate system call sequences and monitor crash, deadlock, memory out-of-bounds, or abnormal restart events to evaluate the stability of the repaired kernel.

[0013] Furthermore, the method also includes: abnormal commit location. When compilation or startup fails when using the same configuration file in a new version kernel, the configuration file is fixed and combined with an automated startup test environment as a criterion. A commit binary search mechanism is used to locate the abnormal commit that caused the failure within the commit range.

[0014] Beneficial Effects: Compared with existing technologies, this invention has the following significant advantages: It provides reproducible and comparable automated compilation and startup testing capabilities in large-scale configuration spaces, reduces misjudgments caused by environmental differences, and facilitates integration into continuous integration regression processes. Through structured log parsing and error entry mapping, it significantly improves the efficiency of root cause localization, quickly converging unstructured log clues into a set of candidate configuration items. Through unified semantic modeling of explicit dependencies and implicit constraints, it improves the satisfiability and consistency of repair actions, reducing the probability of introducing new conflicts through local patching. By classifying configuration items and using key scoring, it reduces redundant attempts, improves the repair convergence speed, reduces reliance on human experience, and lowers the overall repair time and trial-and-error costs. Under the threshold and weight parameter configuration and testing conditions described in Example 3, compared with the binary repair method, the average repair time is reduced from 114 minutes to 86 minutes (a reduction of 24.5%), the crash rate is reduced from 7.8% to 2.4% (a reduction of 5.4%), and the repair success rate remains at the same order of magnitude. The above comparative results are used to illustrate the technical effects of this invention and do not constitute a limitation on the scope of protection of this invention. By introducing coverage-guided kernel fuzzing for runtime stability assessment, the risk of "bootable but unstable" delivery is reduced, and the reliability of output configurations is improved. By using startup tests as a decision criterion combined with binary search to locate anomaly commits, an engineering-based localization path and causal evidence are provided for cross-version regression, improving cross-version adaptation and issue closure efficiency. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the system framework design of the present invention, used to illustrate the functional module composition of the system of the present invention and the data interaction relationship between the modules;

[0016] Figure 2 This is a schematic diagram of the root file system creation process of the present invention, used to illustrate the steps of creating a unified root file system for virtualization boot testing;

[0017] Figure 3 This is a schematic diagram of the root file system directory structure of the present invention, used to illustrate the composition of the root file system and the layout of key directories and files;

[0018] Figure 4 This is a schematic diagram comparing the preprocessing process before and after the present invention, used to illustrate the effect of removing blank lines, comment statements, and statements irrelevant to this study from the Kconfig text on suppressing parsing noise;

[0019] Figure 5 This is a data flow diagram and schematic diagram of key processing points for Kconfig processing in this invention, used to illustrate the data input, processing steps and output results of Kconfig semantic modeling;

[0020] Figure 6This is a schematic diagram of the execution flow of the repair method of the present invention, used to illustrate the iterative closed loop of score-driven dynamic repair and the processing branches for different error types;

[0021] Figure 7 This is a schematic diagram of the fuzzing execution process of the present invention, used to illustrate the coverage-guided kernel fuzzing steps and key points of anomaly monitoring in the stability verification phase;

[0022] Figure 8 This is a schematic diagram of the abnormal submission location process of the present invention, used to illustrate the abnormal submission location process based on the startup determiner and the submission binary search mechanism in a cross-version regression scenario;

[0023] Figure 9 This is a schematic diagram comparing the threshold selection and repair effect of the present invention, used to illustrate the changing patterns of repair success rate and repair time under different threshold strategies;

[0024] Figure 10 This is a comparative diagram of the repair methods of the present invention, used to illustrate the comparison results between the method of the present invention and the binary repair method in terms of indicators such as crash rate and repair time;

[0025] Figure 11 This diagram illustrates the proportion of core configuration item categories under different thresholds according to the present invention, and is used to explain the impact of the threshold strategy on the composition of the core configuration item set. Detailed Implementation

[0026] The technical solution of the present invention will be further described below with reference to the accompanying drawings.

[0027] like Figure 1 As shown in the figure, this invention provides a Linux kernel boot test and configuration consistency intelligent repair method for configuration item repair, used to verify the bootability of a batch of candidate .config configurations and achieve automatic repair, characterized by including the following steps: (a) Configuration generation: Multiple candidate .config files are generated based on a random configuration generation strategy, and version information and reproducibility identifier are recorded for each candidate configuration; (b) Compilation and startup test: Compile the kernel for the candidate .config file and boot it in a virtualized environment, collecting compilation logs, startup logs and running status; (c) Log structured parsing: Perform segmentation, pattern matching and field extraction on the compilation log and startup log, standardize the error information into structured error entries, and at least distinguish between dependency missing classes, mutual exclusion conflict classes and other compilation failure classes; (d) Kconfig semantic modeling: preprocess and parse the Kconfig file in the kernel source code, extract the configuration item attributes and constraint relationships, construct a unified dependency graph containing explicit dependencies and implicit constraints, and generate a configuration item metadata table; (e) Classification and criticality assessment: Classify and label the configuration items based on the configuration item metadata and calculate criticality scores; (f) Rating-driven dynamic repair: Based on the structured error entries, the unified dependency graph and the key scores, repair actions are generated and executed iteratively. After each iteration, recompile and restart verification are performed until a compileable and startable repair configuration file is obtained or the preset iteration limit is reached. (g) Abnormal commit location: When compilation or startup fails when using the same configuration file in a new kernel version, the configuration file is fixed and combined with the automated startup test environment as the arbiter. The commit binary search mechanism is used to locate the abnormal commit that caused the failure within the commit range.

[0028] In step (b), the virtualization environment is a reproducible automated boot test environment, including: a unified root file system, fixed boot parameters, standardized kernel image artifacts, and repeatable boot judgment criteria, to ensure the comparability of test results.

[0029] In step (c), the structured error entry includes: error type, evidence text fragment, associated symbol or error file path, candidate configuration item set and context location identifier; and a mapping relationship between the error entry and the candidate configuration item set is established based on the associated symbol or error file path and the configuration item metadata.

[0030] In step (d), preprocessing includes: removing comments and blank lines, normalizing indentation and syntax keyword forms, filtering text structures unrelated to dependency extraction, and recursively expanding and normalizing source references to reduce parsing noise and improve the accuracy of syntax tree construction. Implicit constraints include: choice mutual exclusion, architecture / platform limitations, reverse dependencies, and default value-induced constraints; the explicit dependencies and implicit constraints are uniformly represented as a queryable graph structure and stored in association with the configuration item metadata table.

[0031] In step (e), the configuration items are categorized into: core items, debugging items, security items, hardware items, and general items. Core items are determined based on the reverse dependency threshold, dependency propagation range, or menu path characteristics of the configuration items, and have higher priority or are set as protected items during the repair process.

[0032] Step (f) includes: when a dependency missing error is detected, recursively completing the missing dependencies along the unified dependency graph and prioritizing the configuration items with higher criticality scores in the candidate dependency set; when a mutual exclusion conflict error is detected, disabling conflict items with lower scores or selecting alternative items based on the criticality scores of each configuration item in the conflict set; when other compilation failure errors are detected, locating the relevant configuration item set and implementing a selective pruning strategy of "keeping high-scoring items and disabling low-scoring items".

[0033] After obtaining a bootable, repaired configuration file, further stability verification is performed: a kernel fuzz test with coverage boot is run on the repaired kernel to generate system call sequences and monitor events such as crashes, deadlocks, memory out-of-bounds errors, or abnormal restarts to evaluate the stability of the repaired kernel.

[0034] Example 1: Batch compilation and virtualization startup testing for configuration item repair—semantic modeling—scoring and repair closed loop This embodiment describes a kernel boot test and consistency intelligent repair method oriented towards configuration item repair based on the above method.

[0035] like Figure 1 As shown, this embodiment provides an automated closed-loop method for repairing Linux kernel configuration items. The method takes a candidate .config file as input and outputs a "compilable and bootable repaired configuration file" and a "repair process evidence report." The overall process includes the following steps: (1) Candidate configuration generation and management: Multiple candidate .config files are obtained by random generation (e.g., randconfig) or batch import. To ensure reproducibility, each candidate configuration record includes at least: kernel version identifier, random seed or generation parameters, target architecture and build options; and the candidate configurations are numbered to form a queue to be tested.

[0036] (2) Kernel compilation and virtualization boot test: such as Figure 2 , Figure 3As shown, a unified root file system is constructed and used for automated boot testing. The root file system is generated using a reproducible process (e.g., including init, necessary system tools, and basic libraries) and used in conjunction with the kernel image in initramfs or an equivalent form. Kernel compilation is performed on each candidate .config file to obtain standardized artifacts (e.g., kernel image and necessary modules). The kernel is booted in a virtualized environment (e.g., QEMU) with fixed or configurable boot parameters, and boot criteria and timeout mechanisms are set. Boot criteria can be: reaching user-mode init, the serial port log showing a preset ready flag, or the system entering an interactive state; a timeout is considered a boot failure. Compilation logs, boot logs, and runtime status information are collected during compilation and boot processes as evidence of failure input to subsequent analysis modules.

[0037] In one optional implementation, the startup success determination criterion can be pre-configured as follows: a preset ready flag appears in the startup log, or the system enters an interactive state (e.g., it can execute a preset probe command and return the expected result); at the same time, a startup timeout threshold T is set, and if the startup success determination is not met after the threshold is exceeded, it is determined as a startup failure and the corresponding log evidence is output.

[0038] (3) Log Structured Parsing and Error Entry Mapping: The compilation log and startup log obtained in step (2) are segmented, rule-matched, and field-extracted to normalize the unstructured log into structured error entries. A structured error entry includes at least: error type, evidence text fragment, occurrence stage (compilation / linking / startup / running), associated symbol or error file path, and context location identifier. Further, the error entries are mapped to a set of candidate configuration items, distinguishing at least the following types: dependency missing (e.g., compilation or linking failure due to unmet dependencies); mutual exclusion conflict (e.g., conflict due to choice mutual exclusion or platform conditions); and other compilation failures (e.g., compilation failure strongly related to a specific subsystem / driver). The mapping can obtain a set of candidate configuration items based on the association between "symbol—source code path—configuration item metadata," which drives subsequent repair decisions.

[0039] In one alternative implementation, the source code directory or build target to which the error belongs can be located first based on the missing symbol name, compilation unit name, or error file path in the error entry; then, by combining the menu path, explicit dependency, and reverse dependency in the configuration item metadata, a set of candidate configuration items can be generated and sorted by criticality score, thereby improving mapping accuracy and repair convergence speed.

[0040] (4) Kconfig semantic modeling and unified dependency graph construction: such as Figure 4As shown, the Kconfig text is preprocessed to reduce parsing noise and improve the stability of syntax analysis. Preprocessing includes at least: removing blank lines and comment statements, filtering text structures irrelevant to this study, and normalizing keyword forms. For example... Figure 5 As shown, the preprocessed Kconfig file undergoes syntax parsing to extract configuration item attributes and constraint relationships, forming a configuration item metadata table and a unified dependency graph. The configuration item metadata table includes at least: configuration item name, menu path, type / default value, explicit dependencies, and inverse dependencies. The unified dependency graph simultaneously represents explicit dependencies (e.g., depend on, select / imply) and implicit constraints (e.g., choice mutual exclusion, architecture / platform limitations, inverse dependencies, and default value-induced constraints), and provides query capabilities for subsequent dependency completion, conflict detection, and impact analysis.

[0041] (5) Configuration Item Classification and Key Score: Configuration items are classified and labeled based on their metadata, such as into core items, security items, debugging items, hardware items, and general items. A key score for each configuration item is then constructed. In one implementation, the key score (Score) uses a linear weighted model and is calculated as Score = α·D + β·S + γ·T + δ·H + ε·E, where D is the number of dependencies, S is the security flag, T is the debugging flag, H is the hardware dependence, E is the default enabled feature, and α, β, γ, δ, and ε are the corresponding weights. Each dimension is normalized to minimum before calculation.

[0042] During the remediation decision-making phase, the criticality score is used to prioritize candidate remediation actions: when performing dependency completion, higher-scoring candidates are prioritized; when making conflict trade-offs, higher-scoring items are prioritized; and when selectively pruning, lower-scoring items are prioritized. Optionally, core items can be set as a protected set, giving them a higher retention priority during the remediation process; and a threshold strategy can be combined to allow core items to be disabled only when preset disabling conditions are met or the score is below a threshold.

[0043] (6) Scoring-driven dynamic repair closed loop: such as Figure 6 As shown, repair actions are generated and iteratively executed based on the error entries in step (3), the unified dependency graph in step (4), and the criticality scores in step (5). The repair strategies for different error types are as follows: For dependency missing errors, recursively complete the missing dependencies along the unified dependency graph, and prioritize the use of configuration items with higher criticality scores in the candidate dependency set; for mutual exclusion conflict errors, compare the criticality scores of the conflict set, disable conflict items with lower scores, or select alternative items to make the configuration satisfy the mutual exclusion constraint; for other compilation failure errors, locate the set of configuration items strongly related to the error, and execute a selective pruning strategy of "keeping high-scoring items and disabling low-scoring items" to reduce invalid combinations.

[0044] After each round of repair actions, the configuration is regenerated and recompilation and restart verification are triggered, updating error entries. The process terminates when a "compileable and bootable" repaired .config file is obtained; or it terminates when a preset iteration limit is reached, or when error entries no longer change, and outputs the reason for failure and process evidence. In addition to the above termination conditions, in an optional implementation, a convergence criterion can be set: if the set of structured error entries remains unchanged for two consecutive iterations or the number of errors no longer decreases, it is determined that further convergence is impossible and the process terminates early to avoid invalid iterations.

[0045] (7) Output of results: The output shall include at least the repaired .config file, the sequence of repair actions (enable / disable / replace and the reasons therefor), a summary of key log evidence, and environmental parameters and version information for reproduction, forming a result report.

[0046] Example 2: Stability Verification and Cross-Version Regression Localization Method Building upon the bootable repaired configuration file obtained in Example 1, this example further provides stability verification and anomaly submission location capabilities.

[0047] (1) Stability verification: such as Figure 7 As shown, after the repair, a kernel fuzz test with coverage boot can be started on the kernel to generate a system call sequence and continuously stress the runtime environment; monitor events such as crashes, deadlocks, memory out-of-bounds errors, and abnormal restarts, and record triggering test cases, kernel logs, and key status information to generate a stability assessment report. This step can reduce the risk of "bootable but unstable" and provide evidence for further configuration trade-offs or rollbacks.

[0048] (2) Location of abnormal submissions: such as Figure 8 As shown, when the same configuration file fails to compile or boot in a new kernel version, the configuration file is fixed, and an automated boot test is used as the criterion. A commit binary search mechanism is employed to locate the abnormal commit that caused the failure within the suspicious commit range. The location results include at least: the abnormal commit identifier, the failure type, and corresponding log evidence, thus providing an engineering basis for cross-version regression repair or rollback.

[0049] Example 3: Threshold and weight parameter selection and comparative verification of repair effects The following provides an example configuration of threshold and weight parameters, along with a comparison of the effects under this configuration, to illustrate the feasibility and technical effectiveness of the present invention. The experimental environment, testing process, and start-up criteria are consistent with the closed-loop process described in Example 1.

[0050] (1) Threshold selection and repair effect: To differentiate core configuration items, a dependency threshold was set, and the repair success rate and repair time were evaluated under different threshold strategies. The results are as follows: Figure 9 As shown.

[0051] (2) Weight selection and repair success rate: In the process of weight selection for the scoring model, a combination of statistical analysis and empirical rules was used to determine the weights; in order to avoid scale differences affecting the score, all factors were subjected to max-min normalization before calculation. The repair success rate results under different weight schemes are shown in Table 1.

[0052] Table 1 Weight Selection and Repair Success Rate ; (3) Comparison of repair methods: The configuration item priority repair method of the present invention is compared with the binary repair method, and the crash rate, average repair time and repair success rate are statistically analyzed.

[0053] The comparison results are shown in Table 2, and the visualization comparison is as follows: Figure 10 As shown.

[0054] Table 2 Comparison of Repair Methods ; As shown in Table 2, while maintaining the same order of magnitude in repair success rate (96.4% vs. 95.2%), the average repair time of the method described in this invention decreased from 114 minutes to 86 minutes (a reduction of 24.5%), and the crash rate, as determined by fuzzy testing, decreased from 7.8% to 2.4% (a reduction of 5.4 percentage points). These results further confirm that using a threshold strategy to distinguish core configuration items and introducing a criticality score for priority repair can improve repair efficiency and reduce runtime instability risks while ensuring configuration consistency and interpretability.

[0055] (4) Analysis of the composition of key lists and core configuration items: The set of core configuration items obtained based on the threshold strategy can be further statistically analyzed according to the configuration item type. The results of the proportion of core configuration item categories under different thresholds are as follows: Figure 11 As shown, this is used to help form a key list of configuration items and guide subsequent trimming and regression testing.

Claims

1. A method for intelligent repair of Linux kernel boot testing and configuration consistency based on configuration item repair, characterized in that, Includes the following steps: (1) Generate multiple candidate configuration files based on randomization or batching strategies, and record version information and reproducibility identifier for each candidate configuration file; (2) Compile the kernel for the candidate configuration file and boot it in the virtualization environment, collecting compilation logs, boot logs and running status; (3) Perform segmentation, pattern matching and field extraction on the compilation log and startup log, standardize the error information into structured error entries, and at least distinguish between dependency missing classes, mutual exclusion conflict classes and other compilation failure classes; (4) Perform preprocessing and syntax parsing on the Kconfig file in the kernel source code, extract configuration item attributes and constraint relationships, construct a unified dependency graph containing explicit dependencies and implicit constraints, and generate a configuration item metadata table; (5) Classify and label configuration items based on configuration item metadata and calculate key scores; (6) Generate repair actions based on structured error entries, unified dependency graph and criticality score and execute them iteratively. After each iteration, recompile and restart to verify until a compileable and startable repair configuration file is obtained or the preset iteration limit is reached.

2. The intelligent repair method for Linux kernel boot testing and configuration consistency based on configuration item repair as described in claim 1, characterized in that, In step 2, the virtualization environment is a reproducible automated boot test environment, including a unified root file system, fixed boot parameters, standardized kernel image artifacts, and repeatable boot judgment criteria, which are used to ensure the comparability of test results for different candidate configurations.

3. The intelligent repair method for Linux kernel boot testing and configuration consistency based on configuration item repair as described in claim 1, characterized in that, In step 2, the structured error entry includes at least the error type, evidence text fragment, associated symbol or error file path, candidate configuration item set, and context location identifier; and a mapping relationship between the error entry and the candidate configuration item set is established based on the associated symbol or error file path and configuration item metadata.

4. The intelligent repair method for Linux kernel boot testing and configuration consistency based on configuration item repair according to claim 1, characterized in that, In step 4, the preprocessing in the Kconfig semantic modeling step includes at least removing comments and blank lines, normalizing indentation and syntax keyword forms, filtering text structures that are not related to dependency extraction, and recursively expanding and normalizing source references to reduce parsing noise and improve the accuracy of syntax tree construction.

5. The intelligent repair method for Linux kernel boot testing and configuration consistency based on configuration item repair according to claim 1, characterized in that, In step 4, the implicit constraints in the Kconfig semantic modeling step include at least choice mutual exclusion, architecture or platform constraints, reverse dependency, and default value-induced constraints; the explicit dependencies and implicit constraints are uniformly represented as a queryable graph structure and stored in association with the configuration item metadata table.

6. The intelligent repair method for Linux kernel boot testing and configuration consistency based on configuration item repair as described in claim 1, characterized in that, In step 5, the configuration item classification includes at least core items, debugging items, security items, hardware items, and general items; among them, core items are determined based on the reverse dependency degree, dependency propagation scope, or menu path characteristics of the configuration items, and have higher priority or are set as protected sets during the repair process.

7. The intelligent repair method for Linux kernel boot testing and configuration consistency based on configuration item repair according to claim 1, characterized in that, Step 6 is as follows: When a dependency missing error is detected, recursively complete the missing dependencies along the unified dependency graph, and prioritize the configuration items with higher criticality scores in the candidate dependency set; when a mutual exclusion conflict error is detected, disable conflict items with lower scores or select alternative items based on the criticality scores of each configuration item in the conflict set; when other compilation failure errors are detected, locate the relevant configuration item set and implement a selective pruning strategy that retains high-scoring items and disables low-scoring items.

8. The intelligent repair method for Linux kernel boot testing and configuration consistency based on configuration item repair according to claim 1, characterized in that, In step 6, after obtaining the bootable repaired configuration file, further stability verification is performed: a coverage-guided kernel fuzz test is run on the repaired kernel to generate system call sequences and monitor crash, deadlock, memory out-of-bounds, or abnormal restart events to evaluate the stability of the repaired kernel.

9. The intelligent repair method for Linux kernel boot testing and configuration consistency based on configuration item repair according to claim 1, characterized in that, The method also includes: abnormal commit location. When compilation or startup fails when using the same configuration file in a new version kernel, the configuration file is fixed and combined with an automated startup test environment as a criterion. A commit binary search mechanism is used to locate the abnormal commit that caused the failure within the commit range.

Images